1. 项目概述Multi-GNSS并发定位到底在解决什么问题先聊点实际的。做过车载定位、无人机导航或者手持测绘设备的朋友大概率遇到过这种场景车开进城市高楼密集区GPS信号被遮挡了一半定位点开始乱跳明明在直行轨迹却画出了蛇形无人机在树林边悬停位置漂移从米级跳到十几米甚至在某些遮挡严重的路段接收机直接罢工屏幕上显示无定位。早期GNSS接收机只支持GPS单星座遇到这些问题只能认命。后来GLONASS恢复组网、Galileo逐步建成、BDS也完成了全球组网多星座接收开始普及但市面上很多所谓多系统产品其实只是按优先级做星座切换——GPS信号弱了切到GLONASS结果切换瞬间定位中断照样掉链子。真正能解决问题的是标题里这个关键字Concurrent Positioning并发定位。并发定位不是用哪个系统的问题而是同时用所有系统的问题接收机同时跟踪GPS、GLONASS、Galileo、BDS、QZSS多个星座的信号在一个解算周期内把所有观测值融合起来输出一个统一的位置结果。这个项目的核心就是搭建一个支持并发定位的Multi-GNSS平台让终端在任何环境下都有足够多的卫星可用从根上解决遮挡场景下的定位失效问题。这篇文章不打算写教科书式的原理堆砌。我会从方案选型、硬件平台、实操配置、实测对比、踩坑记录这几个角度把这个多系统并发定位平台从头到尾拆一遍。适合正在做GNSS方案选型的工程师、无人机和车载定位方向的开发者、以及想自己搭一套高可靠定位系统的爱好者参考。内容里涉及的硬件和软件都是我实际用过的踩过的坑也会一并列出来。2. 整体设计思路为什么一定要做并发架构2.1 并发定位和多系统支持是两码事先把概念掰清楚。市面上很多接收机模组标称GPSGLONASSGalileoBDS看起来支持四星座但内部实现可能是时分复用的一个射频通道在不同时间片切换跟踪不同星座或者虽然有多个通道但某个星座信号质量稍差就被调度器踢出去。这种方案的直接后果是可见卫星数统计表上很好看但真正参与定位解算的卫星可能只有七八颗而且一旦某个星座信号波动参与解算的卫星数就剧烈变化位置输出跟着跳。并发定位的架构是完全不同的思路。接收机的射频前端用足够宽的带宽把L1、L2、L5等频段的所有GNSS信号一并采下来基带部分给每个星座分配独立的硬件相关器通道同一个时刻并行跟踪几十颗卫星。以我常用的u-blox ZED-F9P为例它宣称支持184个通道也就是同时可以跟踪184颗卫星信号GPS、GLONASS、Galileo、BDS、QZSS全在并发工作而不是轮询切换。打个比方单系统定位就像公司只有一个员工生病了就停工多系统切换就像有几个员工但只能轮流上班换人的时候产线要停并发定位则是全员同时上班谁状态好谁多干活产线永远不断。这个比喻虽然粗但能很直观地解释为什么并发架构在恶劣环境下的优势是碾压级的。2.2 并发带来的收益不是多几颗星这么简单并发定位最直接的收益是可见卫星数大幅上升。在城市峡谷、山谷、矿区、集装箱堆场这类对空视野受限的场景任何一个星座的信号都很难覆盖完整的天穹但四个星座的信号叠加后总能拼出一个相对完整的天空覆盖。我实测过在上海某个高楼密集的路口单GPS接收机只能看到5到6颗星定位精度直接崩坏换成多系统并发平台后可见卫星数稳定在25颗以上PDOP值从6.8降到1.2左右。第二个收益是定位精度的提升。定位精度和参与解算卫星的几何分布密切相关DOP值是衡量这个几何分布的关键指标。卫星都在头顶时DOP值大精度差卫星分布在各个方向时DOP值小精度高。多系统并发后卫星在天空的分布不再依赖单一星座的轨道设计而是四个星座的轨道面互相补充几何构型更接近理想状态。再加上卫星数量多参与最小二乘解算的冗余观测值增加定位结果的噪声也明显下降。第三个收益是可靠性。单系统在遮挡场景下出现周跳或者失锁往往直接导致定位中断并发架构下某个星座的几颗卫星失锁其他星座的几十颗卫星还在正常工作解算结果只是稍微变差不会中断。这对高速运动的载体尤其重要。我做过一个实验用单系统接收机沿高架桥下方行驶平均每两分钟就出现一次定位中断换成四星座并发平台后全程没断过最差情况下HDOP也控制在2.5以内。2.3 平台架构的选型逻辑从硬件到软件的通盘考虑这个项目命名里的Platform容易让人联想到软件平台但GNSS领域里说的平台通常是硬件接收机、解算软件和外围系统的组合体。我选择的方案是高并发通道数的GNSS接收机模组作为信号采集主体通过串口或USB输出原始观测数据和解算结果上位机运行RTKLIB或者厂商SDK做深度处理。这套架构的好处是模块化程度高信号采集和定位解算解耦出了问题可以分别定位是硬件还是软件的原因。硬件端我主要对比过三类方案消费级模组u-blox NEO-M9N、ZED-F9P、国产高精度板卡和芯星通UM980、华测CGI-410、以及软件接收机方案GNSS-SDR搭配RTL-SDR。消费级模组胜在便宜、功耗低、上手快但并发通道数和载波相位观测值质量不一定能满足高精度需求高精度板卡性能强支持RTK和PPP但价格贵一个数量级软件接收机方案最灵活可以自己写信号处理算法但实时性很难保证。综合成本和项目需求ZED-F9P是性价比最高的选择而如果项目对精度有更高要求UM980这类板卡是更合适的方向。3. 并发定位的核心环节从信号捕获到位置解算3.1 射频前端并发定位的第一道关口并发定位的物理基础是射频前端能把多个频段的信号同时接收下来。GNSS信号分布在L11575.42 MHz、L21227.60 MHz、L51176.45 MHz等频段每个系统的信号中心频率略有差异。传统单频接收机只接收L1频段并发平台则要求射频前端有足够宽的带宽至少覆盖1160到1610 MHz的范围同时把L1、L2、L5都收下来。这里面有个容易被忽略的坑射频前端带宽太窄会让边带信号失真影响相关器对码相位的测量精度带宽太宽又会引入更多带外噪声降低信噪比。所以射频前端的SAW滤波器选型和LNA低噪声放大器的增益配置非常关键。实际项目中我倾向于选择集成度更高的模组因为独立搭建射频前端对PCB布线和阻抗匹配的要求很高稍不注意就出现镜像频率干扰排查起来相当痛苦。信号进入射频前端后经过放大、下变频、模数转换变成数字中频信号然后交给基带处理。基带部分的核心是相关器阵列每个相关器负责对某颗卫星的某个频点信号进行捕获和跟踪。并发定位要求相关器数量足够多也就是前面说的184通道、1400通道这些参数。通道数不够的话就算射频端收下了信号基带也没法同时处理并发也就无从谈起。3.2 基带调度与时钟同步并发架构的隐形战场大多数人不关心基带调度器的实现但这恰恰是并发平台能否真正并发的关键。接收机基带芯片内部每个通道独立跟踪一个卫星信号但通道之间的调度、卫星信号的锁定状态切换、以及观测值的生成时间戳对齐都需要统一的时钟基准和调度策略。GNSS系统的时间基准各不相同GPS使用GPSTGLONASS使用GLONASSTGalileo使用GSTBDS使用BDT。接收机必须先把各个系统的时间统一换算到同一个时间框架通常是GPST或者接收机本地时间才能把不同系统的观测值放到同一个定位方程里解算。时间基准没对齐的话误差会以光速传播1微秒的时间偏差就是300米的位置误差这种量级的错误一眼就能看出来。在我实测过程中ZED-F9P这类专业模组已经把时间同步做在了芯片内部用户不需要手动处理。但如果用软件接收机方案自研时间同步就是必须仔细处理的模块。我的建议是刚起步的项目不要碰软件接收机。先用手持模组把并发定位的应用逻辑跑通再考虑底层的时钟同步问题这样能把风险控制在一个可控范围内。3.3 观测值质量检查与定位解算并发之后的数据怎么融合多系统并发跟踪的卫星数一旦超过20颗定位解算策略就需要调整。最简单的位置解算方式是加权最小二乘把所有卫星的伪距观测值放到一起根据卫星仰角和信噪比分配权重解算出位置和接收机钟差。由于不同系统间存在系统间偏差ISB解算时每个系统还需要额外估计一个钟差参数这会让方程组的未知数增多。我用的RTKLIB在处理多系统融合时默认会给每个星座分配一个独立的接收机钟差参数这是最稳妥的做法因为不同系统之间的时间偏差不像理论上那样是固定值它随温度和硬件状态会有缓慢漂移。如果为了减少未知数而强制共用同一个钟差必须实时估计系统间偏差不然定位结果在高动态场景下会出现间歇性跳变。此外并发解算还面临一个浮点运算量和实时性的矛盾。卫星数越多矩阵维度越大解算耗时越长。对每秒10 Hz甚至20 Hz的定位输出要求来说解算必须在几十毫秒内完成。好在现在的ARM处理器性能足够强我在树莓派上跑RTKLIB四系统并发25颗星的RTK解算单次解算耗时大约8毫秒完全够用。3.4 天线选型并发平台最容易翻车的环节很多人把注意力放在接收机模组上对天线不太上心这是并发定位项目里最常见的错误。多系统并发意味着天线必须能同时接收L1、L2、L5频段的信号如果天线只支持单频段模组再怎么并发也是白搭。市面上常见的多频有源天线比如测量级天线常见的三频设计能覆盖GPS L1/L2/L5、GLONASS G1/G2/G3、Galileo E1/E5a/E5b、BDS B1/B2/B3增益一般在40 dB左右噪声系数在2 dB以内。这类天线适合固定站、车载和测绘场景。手持设备上用的贴片陶瓷天线虽然体积小、价格便宜但通常是单频或双频设计多系统并发时会损失大量L5频段的信号不建议在需要高可靠性的项目里用。有源天线的供电问题也要注意。模组通过RF线缆给天线馈电电压通常是3.3 V或者5 V电流在10到50 mA之间。如果RF线缆过长或者线损太大天线上得到的电压不足内部的LNA就会停止工作接收机表现为能搜到星但信号极弱定位成功率低。我踩过一次这个坑用10米长的RG174线缆连接外置天线结果定位时卫星数只有正常情况的三分之一。后来换成了RG58线缆并在模组端把天线供电电压调到5 V问题立即消失。所以天线选型一定不能拍脑袋要把线缆损耗、供电能力、安装环境放在一起算。4. 实操记录从零搭一个四系统并发定位平台4.1 硬件准备与连接5分钟变成一套完整定位终端我用的硬件清单如下u-blox ZED-F9P模组RTK高精度版或者NEO-M9N导航级两者都支持四系统并发区别是F9P支持载波相位和RTK多频有源天线我用的是陶特信TAU-1000支持GPS/GLONASS/Galileo/BDS全频段USB转串口模块FT232或者CP2102均可树莓派4B作为上位机运行解算软件5 V供电线和RF线缆连接方式很简单天线通过SMA接口接到模组的RF_IN引脚模组的UART1通过USB转串口接到树莓派USB口。如果使用的模组直接带USB接口比如ZED-F9P的USB口可以省掉USB转串口模块直接连电脑或者树莓派。上电后用串口工具检查输出如果能看到NMEA语句说明硬件链路已经通了。我建议第一次调试时先拿到开阔的楼顶或者操场去测不要在室内或者窗边因为多系统并发定位对卫星信号的依赖非常强室内环境连单系统都难定位更别说验证并发了。4.2 参数配置开启四星座并发和原始观测值输出ZED-F9P模组默认只输出NMEA协议定位模式和星座选择也需要先通过U-Center软件配置。U-Center是u-blox官方提供的上位机软件连接模组后进入Configuration视图重点设置以下参数PRT端口配置把UART1波特率设为460800或者更高因为四系统并发后观测数据量很大19200波特率根本传不完GNSS配置在GNSS页面勾选GPS、GLONASS、Galileo、BDS并确认每个星座的启用状态是1enable而不是0RATE定位频率根据应用需求设成1 Hz、5 Hz或者10 Hz。并发解算建议从5 Hz开始测试10 Hz对接收机硬件和上位机的处理能力要求更高UBX-OUT配置建议输出UBX-NAV-PVT、UBX-NAV-SAT、UBX-RXM-RAWX这几类消息。UBX-NAV-SAT能看到当前参与解算的卫星列表和信噪比UBX-RXM-RAWX是原始观测值做RTK或者PPP后处理必需配置完成后保存到模组的flash重启后模组就会按配置输出数据。4.3 上位机解算验证用RTKLIB确认并发是否生效我用RTKLIB的STRSVR接收串口数据流RTKNAVI做实时解算和显示。真正验证并发定位是否生效有三个信号特征可以作为判断依据第一可见卫星数。在开阔环境下并发平台应该同时看到30颗以上的卫星。如果只看到10颗左右说明某些星座没有启用或者天线不支持相应频段。这个现象在RTKLIB的skyplot窗口里一目了然四星座的卫星会在天空图上按轨道分布画出四组明显的卫星轨迹。第二参与解算的卫星数和PDOP值。ZED-F9P的UBX-NAV-SAT消息里会直接给出每颗卫星是否参与解算flags.svUsed字段。如果配置正确参与解算的卫星通常达到20颗以上PDOP值在1.0到2.0之间。如果PDOP大于5说明卫星几何分布很差移动下位置或者换更开阔的场地再试。第三定位结果的稳定性。在静置状态下并发平台的定位点抖动应该在1米以内码伪距解算甚至厘米级RTK模式下。如果定位点以米级幅度漂移大概率是某些卫星的信噪比太低或者天线安装位置有问题。4.4 实测对比单系统与三系统并发到底差多少我挑了一个典型的半遮挡场景来做对比实验一条南北向道路东侧有连续的高层建筑西侧是空地模拟城市峡谷的卫星信号遮挡环境。先关闭模组的GPS以外的所有星座只开GPS。测试结果惨不忍睹可见卫星数在4到8颗之间波动HDOP经常大于5定位轨迹有明显的锯齿状跳变每隔30秒左右就会出现一次位置跳变超过10米的情况这种输出在车辆导航上是不可用的。随后开启GPSGLONASSGalileo三系统并发同样的测试路线可见卫星数升到18到22颗HDOP稳定在1.5到2.2之间定位轨迹平滑了很多锯齿跳变基本消失偶尔还有小幅度漂移但整体可用性大幅提升。最后开启BDS实现四系统并发可见卫星数稳定在28颗以上HDOP降到1.0到1.5定位轨迹几乎没有跳变静置状态下定位点离散度明显小于三系统模式。在靠近高楼的区域四系统模式的定位结果依然可用而单GPS模式已经完全无法锁定位置。这个实验直接验证了一个结论多系统并发不是锦上添花而是遮挡环境下能否定位的分水岭。做车载导航或者城市巡检项目时不要纠结单系统精度高还是多系统精度高的问题直接上并发方案省得后面反复改版。5. 常见问题与排查技巧实录5.1 卫星数上不去或者一直搜不到某个星座这种情况最常见的原因有三个一是模组的卫星星座配置里没有启用该星座去U-Center的GNSS配置页检查二是天线频段不支持该星座的信号换成多频全星座天线三是当前环境的遮挡太严重该星座的卫星恰好全部在地平线以下。如果是第三个原因可以把接收机搬到开阔环境验证不要在室内纠结。另外一个隐藏原因在ZED-F9P这类模组上比较常见如果同时开启了太多星座但基带通道数分配不合理部分星座分配的通道数过少在信号质量稍差的时候会出现无法捕获或失锁。解决办法是把通道数分配给重点星座以及调整信号捕获的信噪比阈值。在U-Center的Advanced Configuration里可以逐星座调整通道分配参数但这个操作对大部分用户来说太底层建议默认配置就行除非你有明确的调试需求。5.2 定位结果在并发模式下反而变差有时候开启多系统后定位结果还不如单系统稳定。我遇到过这种情况排查下来是系统间偏差在作祟。RTKLIB默认对每个星座独立估计接收机钟差这能有效处理ISB问题。但如果用的是某些简化版的解算库它们把所有系统的卫星放在一起解算却只估计一个接收机钟差不同系统之间的时间偏差就会被映射到定位残差里导致定位结果出现系统性偏移。处理办法有两个一个是改用支持多钟差估计的解算软件另一个是只使用同一个系统的时间基准做解算其它系统的观测值先做时间同步偏差修正再加入方程。后者实现难度更高不建议从零自己实现优先用成熟的RTKLIB和商业SDK。5.3 并发模式下CPU负载过高实时性保不住卫星数量从10颗翻倍到30颗最小二乘矩阵的维度也翻倍解算耗时成倍增长。如果还开着RTK解算和写日志嵌入式设备很容易出现处理不过来、定位频率下降的问题。我做压力测试时遇到的情况是ZED-F9P输出10 Hz并发数据树莓派4B上RTKLIB的CPU占用达到80%左右偶发丢包。解决办法包括把定位频率降到5 Hz关闭不必要的日志记录在RTKLIB里启用RTCM3输出而不是同时输出多种格式用更高效的数据结构减小接收机状态更新的开销。如果是MCU级别的平台建议把定位解算放到Linux主机上做MCU只负责信号采集和转发否则很难同时满足并发和高频率输出。5.4 多系统并发下的时间基准问题GNSS授时是很多项目的核心场景。多系统并发时接收机输出的时间标签time tag是基于GPST还是本地时间的直接决定了后续的数据融合精度。我在做多传感器融合时发现把GNSS时间戳和IMU时间戳对齐必须在采用并发定位模式后重新做一次时间同步校准因为多系统并发的观测数据量增大后串口传输延迟和系统处理延迟都会变化原来单系统时测得的固定延迟值不再适用。实践中的做法是通过PPS秒脉冲信号和GNSS的UTC时间输出做硬件级时间同步配合软时间戳校准把时间误差控制在毫秒级以内。如果项目对时间同步精度要求到达微秒级需要用支持PPS输出的接收机和具有硬件时间戳捕获功能的处理器这属于时间同步系统的范畴这里提一句提醒大家注意即可。5.5 常见问题速查表现象可能原因排查思路卫星数始终不超过10颗星座未启用或天线不支持检查GNSS配置和天线频段某星座一直无信号遮挡严重或通道分配不足去开阔环境复测并发后定位反而漂移系统间偏差未正确处理改用多钟差解算CPU占用过高、定位频率下降数据量过大或处理能力不足降低频率、精简输出定位中断频繁遮挡严重但并发数仍不足加天线增益或更换安装位置天线已接但信号极弱馈线损耗大或供电不足换低损耗线缆、提高馈电电压6. 应用场景延展并发定位可以往哪些方向落地6.1 城市峡谷环境下的车载导航与自动驾驶城市道路两侧高楼遮挡是GNSS定位最常见的挑战。单系统GPS在城市峡谷里的可用率通常只有60%到80%根本无法作为自动驾驶的可靠定位输入。多系统并发配合IMU和轮速计做组合导航可以把可用率提升到99%以上这是L2级辅助驾驶和自动泊车方案里的常见架构。这个项目里的并发平台可以直接作为组合导航系统的GNSS数据源输出原始观测值给融合算法使用。6.2 无人机巡检与精准农业无人机在山区、峡谷和树林边作业时卫星遮挡和信号多路径效应是定位误差的主要来源。多系统并发能显著提高固定翼和多旋翼在复杂地形下的定位稳定性配合RTK甚至可以实现厘米级航线精度。精准农业的拖拉机导航和变量作业也依赖高可靠定位大片开阔农田场景下并发平台的性能优势不明显但在林缘、果园这类半遮挡场景下多系统并发能明显减少定位跳变导致的作业重叠或漏行。6.3 测绘与工程测量测绘级应用对定位精度要求极高必须使用载波相位观测值。并发平台的原始观测数据UBX-RXM-RAWX经过PPK或者RTK解算后可以在城市环境下实现厘米级精度。传统单频接收机在楼宇间经常出现整周模糊度无法固定的问题多系统并发让参与解算的卫星和频率组合大幅增加模糊度固定成功率显著提升。我测试过在建筑密集区域单系统RTK的固定率可能只有50%四系统并发RTK的固定率可以达到95%以上。6.4 时间同步与科研应用GNSS本身是免费的高精度授时源。多系统并发授时最大的优势是冗余性某一个系统的卫星出现问题后其它系统可以无缝接管保证时间输出不中断。科研项目中多系统并发GNSS接收机也经常作为水汽探测、电离层监测等研究的数据源提供更密集的观测数据。7. 写在最后的几点体会做这个项目最深的感受是并发定位的技术难点并不在定位算法本身而是在信号链路的完整性和数据链路的稳定性这两个容易被忽略的环节。天线选型、馈线损耗、供电电压、输出协议格式、时间基准对齐每一环都是系统工程的一部分任何一环掉链子最终定位结果都会以一种难以排查的方式恶化。另外多系统并发带来的数据量膨胀是很多从单系统切换过来的人没有心理准备的。从串口波特率到上位机处理能力都要预留足够的余量。我用默认的38400波特率跑过一次四系统数据流结果输出被截断定位结果完全不可用排查了半天才发现是波特率不够。这类基础配置问题最容易浪费大量调试时间。最后一个建议是验证并发定位效果时一定要选一个有真实遮挡的环境测试而不是在开阔操场。开阔环境下单系统和多系统的差异可能只有20%但在城市峡谷这种极端场景下差异是能不能用级别的。真实环境的测试数据才能支撑你在方案评审或者论文写作中拿出有说服力的对比结论。如果你正打算把定位方案从单系统升级到多系统并发或者想在高遮挡环境下提高定位可靠性这套平台搭起来之后会对GNSS的并发有一个非常直观的认知。拿着数据回头再看上面的技术点很多概念会清晰很多。