1. 项目概述与核心需求拆解做定位平台最怕什么不是天线位置没摆好也不是解算算法跑不通而是好不容易调通了一套单星座的方案一到城市峡谷、高架桥下或者厂房密集的作业区定位结果就开始飘。单颗卫星的信号被遮挡、多径干扰一上来RTK的固定率直线往下掉这时候你才会意识到单系统定位的天花板是实实在在存在的。Multi-GNSS Platform Supports Concurrent Positioning这个项目核心就一句话做一套能够同时接收多个卫星导航系统信号、并在同一时间基准下并发完成定位解算的平台。这里的关键词是并发——不是说我支持GPS也支持北斗但只能选一个用而是四个系统GPS、BDS、GLONASS、Galileo的信号同时进、同时解、同时出结果。最初做这套平台的动机很简单手里的仪器在遮挡环境下可用性太差我想自己搭一套多星座接收与解算的验证环境没想到一路从板卡选型做到了完整平台。这套东西适合谁参考两类人。一类是GNSS行业里做接收机开发或者算法验证的工程师想找一个多星座并发融合的落地框架另一类是测绘、无人机、自动驾驶领域做定位方案选型的技术负责人需要搞清楚多并发到底能带来多少收益、又要额外付出什么代价。下面我按自己的实操路径把整件事的来龙去脉、踩过的坑和最终能跑通的方案完整梳理一遍。1.1 为什么需要多星座并发而非单一系统先说一个基础事实单星座系统的可见卫星数量在开阔环境下通常足够用但一到复杂场景就开始捉襟见肘。GPS目前在轨可用卫星约31颗在你头顶上空某一时刻能被接收机看到的通常只有8到12颗而且这还是在仰角截止设为10度左右的情况下。如果环境里有一半的天空被建筑物挡住可用卫星直接掉到五六颗几何精度因子GDOP)迅速恶化定位误差从米级跳到十几米甚至几十米。多星座并发解决的就是这个可用性问题。把GPS、BDS、GLONASS、Galileo四个系统加起来全球任意地点任意时刻的可见卫星数量大约在25到40颗之间是单星座的3倍以上。卫星多了天空覆盖的几何形状就好GDOP值自然降下来。我在城市高架路段的实测对比里单GPS的PDOP经常在4到6之间反复横跳而四系统并发时的PDOP能稳定压在2以下这种差异直接反映在定位精度上。但你说的并发不是简单地把四组观测量堆在一起就行。四个系统各自有各自的时间基准GPS用GPS时北斗用北斗时GLONASS用GLONASS时Galileo用伽利略系统时它们之间的细微偏差如果不处理直接混在一起解算会出现系统性偏差。这也是并发和多模支持这两件事的本质区别——后者只需要切来切去前者要求你把所有信号源放在同一个解算框架里统一处理。1.2 这套平台要解决的具体痛点在实际工程中我总结出四个只有并发定位才能解决的顽固痛点。其一恶劣环境下的连续性。不管是车辆穿过隧道群、农机在果园里作业树冠遮挡严重还是测量员在建筑工地贴着楼体作业卫星信号都处于时断时续的状态。单系统一旦长时间失锁重新捕获需要几十秒甚至几分钟这段时间定位完全不可用。四系统并发时某一系统的信号断了其余三个系统还能撑住连续定位失锁的影响被大幅削弱。其二动态场景下的初始化速度。RTK和PPP这类高精度模式都需要一个收敛或固定的过程。卫星数越多模糊度解算可用的约束就越多固定速度越快。实际测过同样的环境下四系统并发RTK首次固定时间在10到20秒左右而单GPS往往要等上一两分钟甚至更久。其三干扰与欺骗场景的鲁棒性。单一频段受到射频干扰时单系统方案基本直接瘫痪。多星座并发天然提供了频段和方向的多样性——不同系统的信号分布在L1、L2、L5等多处干扰源很难把全部频段都压死至少能保留部分定位能力。其四欺骗检测的可行性。并发处理多个星座信号以后可以通过交叉验证各系统之间的时钟一致性、位置解算一致性来识别异常信号。单系统遇到精心设计的欺骗信号时几乎毫无还手之力而多系统之间的互相校验让欺骗难度翻了好几倍。2. 关键技术选型与分析2.1 硬件平台选型从板卡到整机的取舍做多星座并发平台第一步就是选硬件这里的坑最多。市面上GNSS板卡从几百块的民用模块到几万块的测绘级板卡差异不只是价格而是内在的通道数、信号处理能力和固件策略。我的建议是如果需要认真验证并发定位算法选板卡时重点关注三个指标通道数、星座频段支持能力、原始观测量输出格式。通道数决定了你能同时跟踪多少颗卫星。比如一块256通道的板卡理论上可以同时跟踪四系统所有频段的卫星而32通道的旧款板卡跑单系统都勉强更别说多系统并发。我最初用一块64通道的板子做四系统全频段实验结果在信号环境比较好的情况下GPS加BDS就已经吃掉了大部分通道GLONASS和Galileo的信号经常被通道调度策略挤掉后来换成256通道的板子才彻底解决了这个瓶颈。频段支持上建议优先选择支持全频段的型号。常规的L1/L2双频已经能实现很好的RTK效果但如果要把平台做成长期可用的基础设施L5频段GPS、B2aBDS、E5aGalileo这些新频段迟早要用上。频段越多抗干扰和模糊度解算的余量就越大。输出格式上一定选能输出原始观测量伪距、载波相位、多普勒的型号而且要在高刷新率下保持稳定输出至少10Hz起步。很多模块只给NMEA协议的结果那对并发解算的验证来说等于是黑盒根本没法分析问题出在哪个环节。从我个人的使用体验来看u-blox F9P这类定位在千元级的板卡适合做原型验证它支持四系统双频通道数也够性价比极高。如果要上到测绘级应用Trimble BD9xx或者Septentrio的Mosaic系列更可靠但价格贵了不止一个量级。自己搭建平台如果不差钱直接上Sepentrio它的原始观测量质量和对多星座并发的支持做得很出色如果预算有限F9P完全能跑通整个流程只是解算精度上限略低一点。2.2 并发定位的软件架构与算法框架硬件定了软件才是真正拉开差距的地方。多星座并发定位的软件架构最重要的是把时间基准统一这一层做好否则后端的滤波器再正确都是白搭。整个接收机的处理链路可以分成三层。前端是信号处理层完成四个星座所有可见卫星信号的捕获、跟踪和解调输出各颗卫星的伪距、载波相位和多普勒观测值。中间层是数据组织层要把来自不同星座的观测数据按照统一的参考时间戳组织起来生成标准的RINEX格式或内部自定义格式同时完成各系统时间基准到接收机时间的对齐。后端是位置解算层跑PVT解算或者RTK/PPP滤波这里需要考虑系统间偏差ISB参数把它作为未知量或者利用先验信息修正。在解算算法上常用的是扩展卡尔曼滤波器或最小二乘估计。区别在于最小二乘适合静态场景实时性和平滑性不够好EKF能够自然地融合IMU、气压计等其他传感器是动态定位平台的更优选择。状态向量除了位置、速度和接收机钟差还必须包含各系统相对于参考系统的时间偏差参数。以GPS为基准系统的话BDS、GLONASS、Galileo各自相对于GPS的时钟偏移就是三个额外的状态量在滤波器里做实时估计。这里有个很关键且容易忽略的细节GLONASS比较特殊它的频分多址FDMA设计导致不同卫星使用不同频率码间偏差IFB需要逐颗卫星处理。这是很多人在多星座并发时解算精度上不去的隐形杀手——GPS、BDS、Galileo的CDMA信号可以共享同一个ISB参数但GLONASS的每颗星都需要单独估计偏差项。如果不做这个处理GLONASS的观测值会在残差里引入几十厘米到几米的偏差反而拖累整组解算结果。2.3 并发定位中的时间同步与系统间偏差处理时间同步问题可以这样理解四个星座各自都有自己的原子钟网络它们各自定义了一个系统时间——GPS时、北斗时、GLONASS时、伽利略系统时。这几个时间体系之间有固定的偏差和微小的漂移。接收机测量到的伪距是信号发射时刻到信号接收时刻的时间差乘以光速如果发射端和接收端用的是两个不同步的时钟伪距里就会混入一个系统偏差。在单星座定位里接收机钟差可以作为未知数在方程里被估计掉。但多星座系统里不同星座的时间基准不同接收机对每颗卫星测量时混入的时间误差其实可以分为两部分接收机自身时钟相对理想时间的偏差以及每个星座的系统时相对理想时间的偏差。前者是所有卫星共用的后者是每个系统公用的但系统间不同。工程上有两种主流处理方式。一种是在接收机内部做时间基准对齐——由固件实时监测各系统时间的偏差将非基准系统的观测值直接修正到基准时间上输出的观测值已经是统一时间基准了。这是很多商用接收机的处理方式好处是对后端解算透明坏处是这个对齐修正本身存在误差精度要求高的场景依然不够。另一种是原始数据不做修正把ISB作为参数放进解算滤波器里实时估计。这种方式更灵活也是我自己实现时的选择。实测下来两种方案在开阔环境下的定位精度差异不大但在强多径或遮挡场景下实时估计ISB的方式明显更稳健因为它能通过滤波平滑掉一部分观测噪声的影响。3. 平台搭建与实操过程3.1 接收机配置与固件更新搭建平台的第一步是把硬件环境吃透。这里大多数人的第一个坑就是固件版本。我最初用的那块板卡出厂固件只支持GPS和SBAS跑BDS和Galileo需要先升级固件库。升级之后还要仔细看配置文档里关于星座使能的设置项不是升级完就自动开启的。配置板卡时的几个关键参数我直接列出来。星座使能明确开启GPS、BDS、GLONASS、Galileo四个系统关闭SBAS星基增强系统在很多场景下和并发定位功能有冲突。频段选择开启所有可用的载波频段L1/L2/L5等用于后续双频甚至三频解算。仰角截止角建议先设为10度太低会把多径严重的低仰角卫星纳入解算太高会牺牲遮挡环境的可用卫星数。动态模式如果平台将来要装到车上或无人机上选动态或机载模式这会影响接收机内部的滤波带宽设置。观测值输出设置输出原始观测值包括伪距、载波相位、多普勒、载噪比C/N0等刷新率放到10Hz。一个容易被忽视的细节是天线选型。普通单频贴片天线接收四系统的L1频率没问题但如果要做L2/L5频段的并发定位必须用双频或多频有源天线否则高频段信号根本进不来。天线最好选带有抗多径扼流圈设计的测地型天线尤其是固定站或者基准站多径抑制能力直接影响整个平台的下限。3.2 多星座并发解算的软件实现接下来进入软件层面。我会在RTKLIB的基础上进行二次开发自己扩展一个并发解算模块走通整个流程。RTKLIB本身支持多星座但默认配置和解算策略上有很多需要调的地方。软件链路的主要框架可以分为四步。第一步是数据流接入。用rtkrcv或者自己写的串口/UDP读取程序接收接收机发来的原始数据流实时解析成RTKLIB内部的obs结构体。这一步的关键是确保数据帧同步不丢包。实测下来用USB转串口接收10Hz的全星座观测数据时如果串口驱动或操作系统调度有问题很容易出现缓冲区溢出丢包。建议直接用网口/UDP方式接收接收机数据稳定性和吞吐量都比串口好很多。第二步是星历处理。接收机输出的导航电文解析成星历参数后需要按时效性做管理。GPS和BDS的广播星历两小时内精度尚可超过两小时的星历误差会明显放大。如果平台是长期运行的建议接入实时精密星历服务或者事后精密星历来替代广播星历对定位精度的提升立竿见影。我在自己的平台上试过用实时精密星历替换广播星历后静态PPP精度从米级直接进了分米级。第三步是并发解算核心。这一步主要是要做系统间偏差的处理。根据前面说的把ISB参数加进EKF状态向量把GLONASS逐颗卫星的码间偏差也纳入估计。RTKLIB的默认配置对这部分支持有限需要自己修改定位算法的实现。第四步是结果输出。解算结果除了经纬度和高程以外一定要把可见卫星数、PDOP值、固定状态、各系统卫星数分布这些过程信息同时输出。这些信息对后面分析定位质量非常重要。3.3 关键参数解析与精度评估方法平台搭建完成后验证工作才是重头戏。这里我提供三个最常用的评估指标和对应的测量方法。第一个指标是可见卫星数和PDOP。在开阔场地做基准测试记录一小时的四系统并发可见星数和PDOP分布同时和单GPS模式做对比。按照我实测的数据开阔环境下四系统并发可见星数在30颗上下波动单GPS只有10到12颗PDOP方面并发模式常在1.2左右单GPS则波动在2到3之间。第二个指标是定位精度。静态场景下可以架在已知坐标的控制点上连续采集24小时数据做事后统计分析看水平误差和高程误差的分布。动态场景下可以用已知轨迹的载体跑一圈对比实际轨迹和定位轨迹的偏差也可以和差分GPS的高精度结果做差。第三个指标是固定率和首次固定时间。RTK模式下固定率是指所有历元中成功固定模糊度的占比首次固定时间是指从失锁/重新捕获到重新固定所需的时间。这两个指标在遮挡环境下最能体现多星座并发的价值。我的实测数据是林荫道环境下单GPS固定率不到60%四系统并发固定率能到90%以上首次固定时间从单GPS的40多秒缩短到并发模式的十几秒。在评估时有一个容易忽略的点——载噪比C/N0的变化。多星座并发时接收机通道资源被大量占用个别卫星的载噪比可能会比单一系统模式下稍微下降一点这是正常现象不是硬件故障。如果载噪比下降了10dB以上那才需要怀疑是不是通道调度策略有问题或者固件在多星座模式下有什么限制。4. 常见问题与排查技巧实录4.1 并发定位中的典型故障现象我在整个开发过程中遇到的问题不少挑几个典型到不能再典型的分享出来这些现象在文档里通常找不到现成答案。第一个是多系统反而比单系统精度差。初次搭建时我把所有星座全部开起来结果在城市峡谷环境的定位误差竟然比只开GPS还大。排查了很久才找到原因低仰角的GLONASS卫星受到多径干扰后产生了大误差而并发模式下滤波器给这些低质量观测值的权重不够低污染了整个解算结果。解决办法是把GLONASS卫星的仰角截止角单独调高到15度并对观测值按载噪比做自适应加权。第二个是BDS的伪距总有一个固定偏差。当时在检查残差时发现BDS的P1伪距残差整体偏大大概有几十厘米的常数偏差。这是BDS的码间偏差DCB问题。广播星历参数里包含了一定的DCB改正信息但是否启用、用哪一版本的改正参数不同板卡和不同软件的处理方式不一样。最终解决办法是把DCB文件明确定义为GPS时到BDS时的系统时间偏差加码间偏差而不是只做时间对齐。第三个是固定解频繁丢失。在RTK模式下明明周围环境不错固定解却动不动掉成浮点解。检查发现这是因为并发模式下卫星多了模糊度搜索空间变大而默认的模糊度固定策略又是基于单历元的没有充分利用多历元的约束。解决办法是把模糊度固定策略改为连续多个历元的一致性校验并且启用部分固定功能——在全部卫星的模糊度没法全部固定时选择质量最好的子集进行固定。4.2 排查思路与工具链遇到定位异常不要急着改参数先建立一套完整的排查流程和工具链效率能高很多。我自己的排查习惯分四步走。第一步看原始观测数据是否正常。用RTKLIB或者自己写的可视化工具画卫星轨迹、载噪比时间序列、伪距残差序列观察有没有异常的跳变、多径噪声或者数据缺失。第二步看定位解算过程量。把EKF的状态量变化过程特别是钟差和ISB的估计值序列导出来看是否有收敛趋势是否出现突变。第三步做差分定位还是精密单点定位的把这两者的结果和标准答案做逐历元对比定位误差大的历元和前面两步找到的异常数据做时间关联。第四步对找出的关联段做精细化分析——缩小时间窗口看载波相位是否发生了周跳、伪距是否出现异常跳变、某颗卫星的载噪比是否骤降。工具链方面我强烈推荐这几个组合。RTKLIB的实时和后处理功能足够胜任大部分分析工作配合一个自研的数据可视化前端把卫星天空图、PDOP时间序列、定位误差时间序列画在一起比单纯盯着一堆数字高效得多。如果做更深度的信号质量分析可以用像GNSS-SDR这类开源软件接收机直接处理中频采样数据从信号层面验证多星座并发时是否存在通道间串扰的问题。4.3 几条值得沉淀的工程经验最后整理几条我觉得对后来者最有价值的经验都不是从课本上直接能学到的。第一通道数真的越多越好。不管你算法写得再好通道资源不够就只能被迫调度被丢弃的卫星信号是不可挽回的。预算允许的情况下通道数往高里选。第二调试环境要层次化。先在楼顶开阔环境把功能跑通再逐步切换到半遮挡、全遮挡场景。如果一上来就在复杂环境调试出现问题很难定位是算法问题还是环境问题。这个道理朴素但很多人因为赶进度跳步最后花的时间反而更多。第三把过程数据完整记录下来。很多问题当时没在意后面出现对比需求时才发现数据没存够。我在平台里加了自动存储功能所有原始观测值、星历、姿态数据和结算结果按日期和场景自动归档这样任何时候都可以回放和分析排查问题时的回溯能力会强很多。第四系统间偏差的稳定性比预想的好但还是需要维护。不同厂商的接收机对ISB估计的初始收敛速度和长期稳定性表现不一样。如果平台要7乘24小时连续运行建议定期检查ISB估计值是否存在缓慢漂移必要时做参数重置或者引入外部约束。第五也是我认为最重要的一条——多星座并发定位冗余的价值远不止提高精度。在两颗卫星星座被干扰的场景下其余两个星座依然能够维持基础的定位能力。这套平台在这个逻辑下天然具备了一种故障降级的健壮性在设计时不用专门做应对策略架构本身就消化掉了大部分单点故障。这一步在真正做产品化或者业务化部署的时候价值会体现得特别明显。我对这套平台的最终定位是在硬件成熟基础上软件定义了一台并发接收机。硬件支持多星座是底座真正决定多并发生态的上限还是在如何处理好时间基准、系统偏差和质量控制这些看不见的细节上。把每一个系统当作平等的信号源、把每一条观测值当作有待验证的假设来对待这个平台才能交出值得信任的定位结果。