GNSS + 自动驾驶:RTK 已经 Fix 了,为什么车端还是不敢信?

GNSS + 自动驾驶：RTK 已经 Fix 了，为什么车端还是不敢信？

★

📌 本文位置：GNSS观察 · G30 · 自动驾驶定位完整性 · RTK Fixed 之后的可信边界

关于无线 Battlecard

这里记录无线通信、卫星通信、GNSS、WiFi、5G-A 与测试验证中的工程判断。

如果你希望系统阅读，可从文末合集入口进入；也欢迎关注并星标，方便持续看到后续文章。

开场

车端定位团队最容易被一个字段误导：RTK Fixed。

这个字段看起来很硬。Fixed，好像问题已经解决；厘米级，好像已经能进车道级；差分链路正常，好像定位系统已经可以交给规划控制使用。但自动驾驶系统真正害怕的场景，是RTK 已经 Fix 了，却 Fix 在一个错误解上，而且系统没有及时意识到它错了。

这个问题不是纸面假设。u-blox 在公开的 ZED-X20P high precision GNSS module（来源：https://www.u-blox.com/en/product/zed-x20p-module） 页面里，把 all-band high precision GNSS、RTK/PPP-RTK、ADAS/Autonomous driving、jamming detection、Galileo OSNMA、secure boot/updates 放在同一个产品叙事里。这个组合很有代表性：汽车定位已经不再只问“能不能厘米级”，而是在问厘米级结果是否可信、是否抗欺骗、是否能被车端安全状态机接收。

ESA Navipedia 对 Integrity（来源：https://gssc.esa.int/navipedia/index.php/Integrity） 的定义更直接：完整性关注对导航信息正确性的信任，以及系统不应使用时能否及时告警；它比单纯精度更接近车端安全语言。这里面有三个关键词：Protection Level（PL）、Alert Limit（AL）、Time to Alert（TTA）。这三个词，才是自动驾驶车端敢不敢信 RTK Fixed 的关键。

客户对话锚点

核心判断很简单：客户说 RTK Fixed，只说明模糊度固定成功；要判断能不能给车控用，必须继续追问完整性边界。

1. 车端看到 Fixed 后，会直接提高 GNSS 权重，还是先检查 PL < AL？
2. 错误 Fix 持续 0.2 s、1 s、3 s 时，车辆状态机会如何降级？
3. 城市峡谷、多路径、差分延迟、遮挡重捕获下的错误 Fixed，能否在台架里稳定复现？

这类对话的落点，是把 RTK 从一个状态字段，翻译成车端可验证的可信边界。

一、Fixed 到底 Fix 了什么

RTK Fixed 里的 Fixed，主要指载波相位模糊度被固定到整数解。ESA Navipedia 的 Carrier Phase Ambiguity Fixing（来源：https://gssc.esa.int/navipedia/index.php/Carrier_Phase_Ambiguity_Fixing） 页面解释过，载波相位观测比码伪距精得多，通常可达到比码观测高两个数量级的精度；模糊度固定后，载波相位可以像高精度伪距一样参与定位。

所以 Fixed 很重要。没有它，很多厘米级定位做不出来。

但这句话反过来不成立：Fixed 很重要，不等于 Fixed 之后的位置就一定可信。

原因在于，模糊度固定解决的是“算法找到一个整数解”的问题；车端安全系统关心的是另一个问题：这个解如果错了，错多大、错多久、系统什么时候知道它错了。

这就是 false fix 的危险之处。它比“没有定位”更麻烦：定位系统会自信地给出一个错误答案。在自动驾驶里，后者比前者更难处理。没有定位，系统可以降级；错误定位如果伪装成 Fixed，融合系统可能会继续提高 GNSS 权重，把错误喂给定位融合、轨迹预测和横纵向控制。

二、车端真正害怕的是错误持续时间

讨论 RTK false fix 时，很多人习惯问“误差有几米”。这个问题只问了一半。

车端更该问的是：错误持续了多久？在这段时间里，车走了多远？状态机有没有来得及降级？

一个简单计算就够说明问题：

这个表并不表示 GNSS 误差会直接变成车辆位移误差，它提醒的是另一个工程事实：错误状态持续时间本身就是风险暴露量。

在高速或高架场景，0.2 s 听起来很短，但 100 km/h 下已经对应 5.6 m 的车辆前进距离。到了 1 s，就是 27.8 m。如果错误 Fix 持续 3 s，风险暴露距离达到 83.3 m，这已经不是“瞬间跳点”，而是一个连续错误状态。

横向也一样。典型道路车道宽度可以按 3.5–3.75 m 量级理解。对车道级定位来说，0.5–2 m 的横向 false fix 已经足够危险：它可能不一定让车辆立刻压线，但足以改变车道归属判断、车道中心线偏差估计、旁车关系和变道决策。

三、完整性为什么比平均精度更接近车端语言

很多定位汇报喜欢写平均精度、CEP、RMS，或者“开阔天空厘米级”。这些指标有价值，但它们不是自动驾驶最关心的全部。

自动驾驶要问的是：在当前场景下，误差有没有被上界住？如果不能保证，系统多久能告警？

ESA Navipedia 的 Integrity（来源：https://gssc.esa.int/navipedia/index.php/Integrity） 把完整性相关参数拆成几类：Alert Limit、Time to Alert、Integrity Risk、Protection Level。用车端语言翻译一下：

所以，车端不应该只看 fixType = RTK_FIXED，更应该看：PL 是否小于 AL、TTA 是否短于状态机决策窗口、完整性风险是否符合当前功能等级。

举个工程口径：如果某个车道级功能把横向 AL 设在 1.5–2.0 m，那么只有当当前横向 PL < AL，且告警时间 TTA 小于车辆状态机可接受窗口时，这个 GNSS 结果才适合进入高权重融合。否则，即使 RTK Fixed，也只能作为带风险标签的观测源，而不是车端真值。

RAIM 的思路也类似。Navipedia 的 RAIM Fundamentals（来源：https://gssc.esa.int/navipedia/index.php/RAIM_Fundamentals） 强调，保护水平会受到测量噪声、卫星几何、误警概率、漏检概率等因素影响。换句话说，同样是 Fixed，开阔天空和城市峡谷不是同一个风险状态；同样是厘米级输出，卫星几何和多路径环境变了，可信边界也会变。

四、落地路径：不要把 Fixed 当真值源，要把 GNSS 当观测源

工程上更稳的做法，是把 GNSS 当成一个带置信边界的观测源，而不是“Fixed 就可信”的真值源。

第一步，车端融合必须把 RTK 状态、差分龄期、卫星几何、残差、C/N0、周跳、多路径指标、IMU/轮速/视觉/LiDAR 一致性一起看。一个常见危险模式是：RTK 状态显示 Fixed，但 IMU 推算轨迹、轮速里程、视觉车道线、地图匹配残差已经开始不一致。如果融合系统还继续提高 GNSS 权重，false fix 会被“融合得更像真的”。

第二步，测试必须从路测偶发，转向可复现场景。城市峡谷、多路径反射、遮挡后重捕获、差分链路延迟、基站距离变化、低仰角卫星比例上升，这些都应该做成可重复的测试条件。GSS9000/GSS7000 一类 GNSS 场景仿真平台的价值，就在于把“路上偶然出现的一次错误 Fix”，转换成台架里可注入、可回放、可比较的场景。

第三步，验收指标要从“多久 Fix”升级到“错误 Fix 如何被识别”。RTK 首次 Fix 时间当然重要，ESA Navipedia 的 Real Time Kinematics（来源：https://gssc.esa.int/navipedia/index.php/Real_Time_Kinematics） 也说明 RTK 依赖载波观测和基准站/流动站差分链路，典型基准服务范围可按 10–20 km 量级理解。但对自动驾驶来说，Fix 时间只是入口指标；更关键的是 false fix rate、错误持续时间分布、PL/AL 越界率、告警延迟、降级策略触发是否稳定。

第四步，记录要足够细。只保存定位结果不够，至少要保留原始观测、卫星状态、差分数据龄期、融合前后残差、状态机切换时间戳。否则出了问题，只能看到“当时是 Fixed”，却不知道为什么 Fixed、错在哪里、有没有被其它传感器提醒。

行动卡

工程判断

RTK Fixed 是必要条件，不是充分条件。 它回答的是载波相位模糊度有没有被固定；自动驾驶还要回答完整性有没有收敛、错误有没有被上界、告警有没有赶上车端决策。

把这件事想清楚后，测试目标会变得很明确：不要只证明“我能 Fix”，还要证明“我错的时候，系统知道自己错了，并且来得及降级”。

这才是 GNSS 从高精度定位走向自动驾驶可信定位的分水岭。