自动驾驶中的传感器技术72——Navigation(9)
自动驾驶中的GNSS问题汇总
1. GNSS Raw Data 原始观测量
一般不仅仅要GNSS模组的SPP定位结果,还原始观测量(伪距、载波相位、频率多普勒等)是高精度定位(RTK、PPP)算法的直接输入,能够在后处理或实时差分中显著降低大气误差和多路径误差,从而把定位误差压缩到厘米甚至亚厘米级别。使用原始数据进行后处理可以得到更可靠的定位结果,尤其在城市峡谷等信号受阻环境中表现更佳。
自动驾驶系统需要将 GNSS 与惯性测量单元(IMU)、摄像头、激光雷达等传感器紧密融合。原始 GNSS 数据提供了时间同步的高频观测,使得卡尔曼滤波或图优化等融合算法能够更准确地估计车辆的姿态、速度和加速度。通过直接使用原始观测,还可以在融合过程中对 GNSS 误差模型进行细粒度校准,提高整体定位鲁棒性。
在城市高楼、隧道或树冠遮挡等复杂场景,GNSS 信号容易出现中断或多路径。原始数据保留了信号强度、卫星可视度等信息,算法可以基于这些细节进行质量评估、异常检测并动态切换到其他传感器或差分方案,保证定位连续。
记录原始观测数据是后期分析和故障排查的重要依据。通过对原始日志进行离线处理,可以验证定位算法的性能、发现潜在的硬件或软件异常,从而提升系统安全性。同时,原始数据可以用于生成高精度地图或更新已有地图,实现车路协同的闭环定位。
2. GNSS模组输出数据格式

NMEA 与 RINEX
| 项目 | NMEA(National Marine Electronics Association) | RINEX(Receiver Independent Exchange Format) |
|---|---|---|
| 定位 | 用于 GNSS 接收机向外部设备(如显示仪、计算机、车载系统)实时输出定位、速度、时间等信息的广播协议。 | 用于在不同厂商、不同接收机之间交换原始观测数据(伪距、载波相位、信号强度、导航星历等),便于后处理和高精度分析。 |
| 数据形式 | 纯文本 ASCII 句子,以 $ 开头,字段用逗号分隔,句尾 *校验和。常见句子有 GGA、RMC、GSV、GSA 等。 | 也是 ASCII 文本,但分为头部块和数据块。头部提供站点、时间、观测类型等全局信息,数据块记录每颗卫星的观测值(伪距、相位、Doppler、SNR 等)。 |
| 传输速率 | 常用 4800 bps(8 N 1),实时流式输出。 | 通常以文件形式保存(.obs、.nav、.met),可压缩(gzip、bzip2)后传输,适合批量或离线处理。 |
| 使用场景 | - 船舶、车辆、移动终端的实时导航显示 | - 大地测量、精密定位、后处理(PPP、RTK) |
| 优点 | • 简单、易解析,几乎所有 GNSS 接收机都支持 | • 完整保留原始观测,支持高精度后处理 |
| 局限 | • 只提供已加工的定位结果,缺少原始观测,精度受限 | • 文件体积大,需后处理软件才能得到位置解算 |
| 典型文件后缀 | NMEA 文本文件常用 .nmea、.txt | RINEX 观测文件 .obs、导航文件 .nav、气象文件 .met |
RTCM NMEA RINEX
| 格式 | 数据类型 | 编码方式 | 主要用途 |
|---|---|---|---|
| RTCM(Radio Technical Commission for Maritime Services) | 差分/实时改正信息(RTK、DGPS) | 二进制(SC‑104 系列) | 为移动站提供高精度实时改正,常用于农业、测绘、航海等需要厘米级定位的场景 |
| NMEA(National Marine Electronics Association) | 实时定位结果、状态信息 | ASCII 文本(NMEA‑0183/2000) | 设备间(天线、接收机、PDA、车载终端等)实时数据传输,便于人眼阅读和通用软件解析 |
| RINEX(Receiver Independent Exchange Format) | 原始观测数据、导航电文、气象信息 | 纯文本(可分为观测文件、导航文件、气象文件) | 统一不同厂商的原始 GNSS 数据,供后处理、科研、数据归档使用 |
-
RTCM:实时传输差分改正数,提升定位精度。适合基站 → 流动站的实时链路。
-
NMEA:把 GNSS 接收机算出的经纬度、速度、时间等结果以标准句子(如 $GPGGA, $GPRMC)发送给上层应用或其他设备。
-
RINEX:保存原始伪距、相位、载波相位等观测值,供后处理软件(如 RTKLIB、GIPSY)进行高精度解算或科研分析。
常见转换需求
| 场景 | 需要的转换 | 常用工具 |
|---|---|---|
| RTCM → RINEX(把实时改正流转为可后处理的观测文件) | 将 NTRIP/RTCM3 流转为 RINEX3 观测文件 | rtcm3torinex(GitHub 项目)、RTKLIB 中的 rtkconv |
| NMEA → RINEX(把实时定位结果保存为原始观测) | 需要原始观测数据,NMEA 本身不含相位信息,通常只能用于低精度记录;若接收机同时输出原始观测,可直接生成 RINEX | RTKLIB convbin、rtkconv |
| RINEX → NMEA(把后处理结果实时输出) | 将解算得到的坐标转为 NMEA 0183 句子供其他系统使用 | RTKLIB rtkrcv 的 NMEA 输出功能 |
| RTCM ↔ NMEA(实时链路中两种协议共存) | 基站发送 RTCM 改正,移动站同时输出 NMEA 位置 | 大多数商业/工业 GNSS 接收机内置双协议支持,无需额外转换 |
应用场景
| 需求 | 推荐格式 |
|---|---|
| 需要厘米级实时定位 | RTCM(配合基站或网络 RTK 服务) |
| 需要把定位结果送给通用软件/显示设备 | NMEA(兼容性最广) |
| 需要进行后处理、精密测量或科研分析 | RINEX(原始观测完整、跨平台) |
RTCM、NMEA 与 RINEX 各自服务于 GNSS 数据链的不同环节——RTCM 负责高精度实时改正,NMEA 负责通用实时定位信息的传输,RINEX 负责原始观测数据的统一存储与后处理。
Ref:https://arxiv.org/pdf/2404.08854
Ref:https://github.com/Stanford-NavLab/gnss_lib_py
3. GNSS首次定位时间
首次定位时间(TTFF,Time‑to‑First‑Fix)是指 GNSS 接收机从上电(或从待机状态恢复)到能够输出满足定位精度要求的首个有效导航解的时间。它是衡量 GNSS 接收机启动速度和用户体验的重要指标。
启动模式
-
冷启动(Cold Start):接收机没有任何卫星信息(星历、时间、粗略位置),需要重新搜索全部可见卫星并下载完整星历。
-
温启动(Warm Start):保留了星历或粗略位置,但缺少最新的星历数据,需要重新获取部分星历。
-
热启动(Hot Start):保留了完整的星历、时间和频率偏差信息,只需重新捕获卫星信号即可完成定位。
典型时间范围
| 启动模式 | 常见 TTFF 范围(典型值) | 备注 |
|---|---|---|
| 冷启动 | 30 – 120 秒(部分高灵敏度模块可低至 20 秒) | 受可见卫星数、信号强度、天线性能影响 |
| 温启动 | 10 – 30 秒 | 需要下载或更新星历数据,A‑GPS 可进一步缩短至 5 秒左右 |
| 热启动 | 1 – 5 秒 | 多数现代模块在良好视野下可在 1 秒内完成定位 |
| 辅助定位(A‑GPS / AGNSS) | < 1 秒(在网络可用时) | 通过移动网络或 Wi‑Fi 预下载星历、时间等信息,实现亚秒级 TTFF |
影响因素
-
可见卫星数量与几何分布:城市峡谷、森林、室内等遮挡环境会显著延长 TTFF。
-
接收机硬件与算法:高灵敏度前端、快速搜索策略、并行多星座处理(GPS + GLONASS + Galileo + BeiDou)均能降低 TTFF。
-
星座配置:使用多星座可在同一时刻捕获更多卫星,常将冷启动时间从 60 秒左右缩短至 30 秒以下。
-
辅助技术:A‑GPS、基于 LTE/5G 的 AGNSS、以及新一代导航电文(如 Galileo E5b、BeiDou B2b)均可在独立模式下把冷启动 TTFF 从数十秒降至约 10 秒左右。
-
功耗与预热:部分低功耗模块在待机期间保持部分星历缓存,可实现“快速热启动”,进一步压缩 TTFF。
最新趋势(2023‑2025)
-
多频、多星座接收机:如 u‑blox、Septentrio、STMicroelectronics Teseo‑LIV3F 等产品,已实现在冷启动条件下 ≤ 30 秒的 TTFF,热启动 ≤ 1 秒。
-
新导航电文结构:针对 GNSS 新一代消息(如 GPS L5、Galileo OS)优化了星历传输频率,使独立冷启动 TTFF 可降至约 12 秒,辅助模式仍保持约 1 秒。
-
AI/机器学习加速搜索:部分厂商在固件中加入基于历史轨道模型的预测搜索,进一步缩短搜索空间,实验数据显示在城市环境下 TTFF 可比传统实现提升约 20 %~30 %。
-
集成惯性导航(GNSS‑IMU 融合):在信号暂时失效期间,惯性测量单元提供短时位置信息,避免因信号遮挡导致的 TTFF 失效,提升整体定位连续性。
4. GNSS灵敏度
GNSS 接收器的灵敏度指的是能够成功捕获或保持跟踪卫星信号的最低功率电平(单位 dBm)。当信号强度低于该阈值时,接收器将无法锁定或维持定位。灵敏度是衡量接收机在弱信号环境(如室内、树荫、城市峡谷)下工作能力的关键指标。
| 类型 | 含义 | 典型测试条件 |
|---|---|---|
| 捕获(Acquisition / 捕获)灵敏度 | 接收机首次锁定卫星信号所需的最小功率。通常比保持跟踪所需的功率更高。 | 冷启动、无任何先验信息(时间、位置、星历) |
| 跟踪(Tracking)灵敏度 | 在已捕获信号后,持续保持锁定所需的最小功率。 | 热启动或已知星历的情况下 |
车载导航:对灵敏度要求更高(捕获 ≤ -145 dBm),以适应高速行驶时的快速信号变化。
Ref:https://www.unicorecomm.com/products/detail/59
5. GNSS通道数
GNSS接收机的通道数指的是接收机能够同时跟踪、解调并处理的卫星信号(每颗卫星的每个频段/信号)数量。每个通道对应一条独立的信号链路,通道数越多,接收机能够同时捕获的卫星数越多,定位精度、可靠性和抗干扰能力也随之提升。
通道数更多意味着
同时跟踪更多卫星可提供更好的几何分布(GDOP),误差更小。
多通道可在遮挡、信号衰减或多路径环境下仍保持足够卫星数,避免定位失效。
支持 GPS、GLONASS、北斗、伽利略等多星座以及 L1/L2/L5 等多频信号,需要相应的通道数。
多通道是实现多路径抑制、信号质量监测、差分/RTK、PPP 等高精度技术的前提。
| 接收机类型 | 典型通道数范围 | 说明 |
|---|---|---|
| 单频单模(仅一种星座) | 12 ~ 16 通道 | 只能跟踪单一频段的卫星,满足最低的 4 颗卫星定位需求。 |
| 双频单模 | 24 ~ 32 通道 | 同时跟踪 L1 与 L2(或等效频段),提升抗多路径能力。 |
| 多模单频(支持两种以上星座) | 24 ~ 48 通道 | 需要为每个星座分配独立通道,常见于消费级多星座模块。 |
| 多模多频(四大星座+多频) | 48 ~ 96 通道 | 支持 GPS、GLONASS、北斗、伽利略的 L1/L2/L5 等多频信号。 |
| 专业测绘/高精度 RTK/PPP 接收机 | 200 ~ 500 通道 | 能同时捕获全部可见卫星的全部信号,常用于测绘、航空、无人机等高精度场景。 |
| 极限高端(数字软件接收机、科研平台) | 600 ~ 900 通道 | 例如某专业机型可达 874 通道,几乎覆盖所有当前与未来计划的信号。 |
标准参考:根据《北斗/全球卫星导航系统(GNSS)测量型接收机通用规范》,单模单频最低 12 通道,单模多频或多模单频最低 24 通道,多模多频最低 48 通道。
-
定位需求:如果仅需普通导航(≈1 m 精度),12‑24 通道已足够。
-
多星座/多频:需要更好抗干扰和更高精度时,建议 ≥48 通道。
-
高精度测绘/RTK/PPP:建议选用 ≥200 通道的专业机型,以保证在复杂环境下仍能跟踪足够卫星。
-
预算与功耗:通道数越多,芯片成本、功耗和体积也随之上升,需综合考虑。
6. GNSS数据更新率
-
定义:指 GNSS 接收机在单位时间内输出完整定位解(位置、速度、时间)的次数,通常以 Hz(每秒次数)表示。
-
影响因素:
-
接收机硬件能力(处理器算力、内部缓存、串口波特率)。
-
配置的 NMEA/RTCM 消息类型(高频率需要更高的波特率)。
-
使用的星座组合(不同星座的信号结构和更新速率不同)。
-
功耗与电池寿命的权衡:高更新率会显著增加功耗,常用于外部电源供电的专业设备。
常见更新率
| 更新率 | 典型硬件/模块 | 备注 |
|---|---|---|
| 1 Hz | 大多数车载导航、手持 GPS(NEO‑6M、u‑blox 6 系列)、基准站实时流(RTCM) | 低功耗、成本最低 |
| 5 Hz | 高动态无人机模块(NEO‑M8N、u‑blox 8 系列)、部分双频 RTK(Emlid REACH M2)在 GPS+GLONASS+QZSS 组合下可达 5 Hz | 兼顾功耗与响应速度 |
| 10 Hz | 专业 RTK/PPP 模块(ZED‑F9P、u‑blox M8P)、可配置的高端 GNSS 模块(LOCOSYS LS2603x‑G)最高 10 Hz | 适用于高速运动或需要平滑轨迹的场景 |
| 20 Hz 以上 | 部分军用/科研专用接收机、定制化高频率模块(如某些 RTK 方案) | 极端动态或高采样需求 |
| 50 Hz | 超高采样 GNSS 传感器(S86 系列)实现 50 Hz 位置更新 | UAV 高速测量、实时姿态控制 |
如何选取更新率
-
定位精度需求:如果仅需米级定位,1 Hz 已足够;若需厘米级 RTK/PPP,建议使用 5 Hz–10 Hz,以获得更平滑的解算。
-
运动速度:车辆(≤120 km/h)一般 1 Hz–5 Hz 即可;高速无人机或赛车(>200 km/h)建议 10 Hz 以上。
-
数据链路带宽:高更新率会显著增加每秒数据量(如 1 Hz ≈ 460 B,10 Hz ≈ 4.6 KB);若使用低带宽无线链路,需要在更新率与带宽之间做权衡。
-
功耗限制:电池供电的移动设备在 1 Hz 与 5 Hz 之间的功耗差异约 10%–30%;10 Hz 以上的模块功耗会显著上升,需评估电源方案。
