• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件

导读

SensorGnssRelative是 PX4-Autopilot 中承载GNSS 相对定位信息的核心 uORB 消息，它以**参考站（Reference Station）为原点的当地拓扑坐标系（NED）**描述接收机与参考站之间的相对位置、相对位置精度、相对航向以及 RTK 解算状态。本文以 docs/en/msg_docs/SensorGnssRelative.md 为主线，逐字段解析该消息的语义，并结合仓库源码说明它由谁发布、被谁消费，以及如何用于 GNSS 航向（双天线测向）、移动基准（moving base）等实际场景。读完本文，你将掌握该消息的完整字段含义、底层数据流与配置要点，能够在日志分析与二次开发中正确理解和使用sensor_gnss_relative主题。

消息概览：主题名与坐标系约定

该消息对应的 uORB 主题名为sensor_gnss_relative，消息结构定义于 msg/SensorGnssRelative.msg，并被 msg/CMakeLists.txt（第 210 行）纳入构建清单，由 PX4 的 uORB 代码生成器自动生成sensor_gnss_relative_s结构体与发布/订阅接口。

其核心语义声明如下：

GNSS relative positioning information in NED frame. The NED frame is defined as the local topological system at the reference station.

也就是说：

• 坐标系：NED（北东地）局部拓扑坐标系；
• 原点：参考站（Reference Station）所在位置；
• 内容：接收机相对参考站的相对位置矢量、精度、航向，以及解算质量相关的状态位。

该消息特别适合承载RTK（载波相位差分）相对定位和移动基准（moving base）场景下的解算结果，例如无人机相对移动基站（如车载基站、手持基站）的厘米级相对定位，以及基于双天线/多天线接收机的 GNSS 航向测量。

字段详解

以下表格完整列出消息的全部字段（与 docs/en/msg_docs/SensorGnssRelative.md 保持一致），并补充各字段在源码中的实际用途。

时间戳字段的语义差异

• timestamp与timestamp_sample的区分是 PX4 传感器消息的通用约定：timestamp表示消息在系统内被组装/发布的时刻，timestamp_sample表示传感器实际采样的时刻。
• 在 src/drivers/gps/gps.cpp 的publishRelativePosition()（第 1510–1516 行）中，发布时仅设置device_id = get_device_id()与timestamp = hrt_absolute_time()，其余字段由底层的 GPS 驱动解析填充：

  void GPS::publishRelativePosition(sensor_gnss_relative_s &gnss_relative) { gnss_relative.device_id = get_device_id(); gnss_relative.timestamp = hrt_absolute_time(); _sensor_gnss_relative_pub.publish(gnss_relative); }

• time_utc_usec的 0 值语义：在接收机冷启动后 UTC 时间尚未收敛时，该字段为 0，消费方应将其视为"UTC 时间不可用"。

位置与精度字段

• position是 3 分量浮点数组，直接给出接收机相对参考站的NED 位移，单位米；
• position_accuracy对应对位置矢量的 1σ 精度估计；
• position_length与accuracy_length是矢量的标量化表示（水平距离与对应的精度），便于在不关心方向时快速使用——例如 src/drivers/uavcannode/Publishers/RelPosHeading.hpp 中正是使用sensor_gnss_relative.position_length作为 UAVCAN ArduPilotRelPosHeading消息的relative_distance_m。

解算质量状态位

这组布尔字段构成了解算质量的"体检报告"：

• gnss_fix_ok：整体定位是否满足 DOP 与精度掩码；
• differential_solution：本历元是否使用了差分改正（RTK 或 SBAS 等差分来源）；
• carrier_solution_floating/carrier_solution_fixed：载波相位差分解的模糊度状态，fixed表示整数模糊度已固定（RTK 固定解，精度可达厘米级），floating表示浮点模糊度（RTK 浮点解，精度次之）；
• moving_base_mode、reference_position_miss、reference_observations_miss：移动基准模式下，若参考站数据链路中断，接收机可能使用外推的参考站位置/观测值继续结算，此时对应标志置位，消费方应知晓精度会随时间下降；
• heading_valid：相对位置矢量航向是否可用于 GNSS 测向；
• relative_position_normalized：指示相对位置矢量各分量（含高精度部分）已完成归一化处理，避免直接比较量纲不一致的数据。

源码中的数据流：谁发布、谁消费

从仓库源码可以梳理出完整的生产者-消费者链路。

生产者（发布方）

1. 通用 GPS 驱动：src/drivers/gps/gps.cpp 使用uORB::PublicationMulti<sensor_gnss_relative_s>（第 248 行）发布该主题；驱动在解析到相对定位数据后调用publishRelativePosition()填充device_id与timestamp并发布（第 536–537 行可见回调分发逻辑）。该驱动同时负责将移动基准接收机的 RTCM 数据路由到rtcm_moving_baseline主题（第 1480–1507 行），与相对定位消息形成配套。

2. UAVCAN 桥接：src/drivers/uavcan/sensors/gnss_relative.cpp 中的UavcanGnssRelativeBridge订阅 UAVCAN 上的RelPosHeading消息（_sub_rel_pos_heading），将其转换为sensor_gnss_relative并发布，设备类型标记为DRV_GPS_DEVTYPE_UAVCAN。

3. UAVCAN 节点（cannode）反向发布：src/drivers/uavcannode/Publishers/RelPosHeading.hpp 展示了反向路径——在 UAVCAN 节点侧订阅sensor_gnss_relative，将heading、heading_accuracy、position_length、position[2]（下向分量）转换为弧度制/米制的 ArduPilotRelPosHeading广播出去，供其他 UAVCAN 设备使用。

4. Septentrio 驱动：src/drivers/gnss/septentrio/septentrio.cpp 第 1484 行将接收机上报的参考站 ID 写入_sensor_gnss_relative.reference_station_id = vector.reference_id，印证了reference_station_id字段的直接来源。

消费者（订阅方）

1. GNSS 航向融合模块：src/modules/sensors/vehicle_gps_position/VehicleGPSPosition.cpp 是sensor_gnss_relative的主要消费方。在UpdateGnssHeading()（第 217–249 行）中：

   • 通过device_id反查对应的参数槽位与接收机状态（findParamSlot/findGnssInstance）；
   • 对时间戳做延迟补偿（resolveSampleTimestamp）与 PPS 校时（_pps_time_sync.correct_gnss_timestamp）；
   • 仅当heading_valid时才使用heading，否则置为NAN；
   • 提取position_length作为基线长度（baseline_length）、position[2]作为基线下向分量（baseline_down）。

2. 航向输出与 EKF：handleHeadingSample()（第 251 行起）要求接收机连续上报匹配的航向一段时间（kHeadingSettleTime）后才发布vehicle_gnss_heading，且会校验基线长度一致性（gnss_heading::baselineConsistent）以及配置的最小天线间距gnss_heading::kMinAntennaSeparation；若未配置基线参数，会告警set SENS_GNSSn_HDG。最终vehicle_gnss_heading供 EKF 等下游使用。这段逻辑由编译开关CONFIG_SENSORS_VEHICLE_GNSS_HEADING控制。

3. 飞行日志：src/modules/logger/logged_topics.cpp 将sensor_gnss_relative注册为多实例日志主题（第 245 行默认以 1000 Hz 的日志速率记录，第 423 行另有 10 Hz 的配置项），同时记录vehicle_gnss_heading（第 148 行）。这意味着 ULog 日志中可直接检索到该消息用于事后分析。

典型应用场景

基于字段语义与源码消费链路，sensor_gnss_relative在 PX4 中主要服务于以下场景：

• RTK 相对定位：通过carrier_solution_fixed/carrier_solution_floating判断是否达到固定解，配合position与position_accuracy获取厘米级相对位置；适用于编队飞行、精准降落引导、对接等对相对精度要求高的任务。
• GNSS 航向（双天线/多天线测向）：heading、heading_accuracy、heading_valid是双天线接收机输出航向的关键字段，经vehicle_gps_position模块处理后生成vehicle_gnss_heading供姿态估计使用；前提是通过SENS_GNSSn_HDG等参数配置基线方向与天线间距。
• 移动基准（moving base）：moving_base_mode、reference_position_miss、reference_observations_miss三个状态位用于标识"基准站本身在运动"以及"参考数据是否被外推"，例如无人机跟随移动地面站、车载 RTK 场景，可据此评估解算可信度。
• 跨总线互联：通过 UAVCAN 桥接与RelPosHeading消息，可将相对定位/测向数据在 UAVCAN 设备之间共享，扩展多传感器拓扑。

实际使用与排查要点

1. 确认消息是否产生：在运行 PX4 的平台上可通过uorb top sensor_gnss_relative查看主题发布频率与实例数；若接收机不支持 RTK 相对定位或未配置差分源，该主题可能不会发布。
2. 核对时间戳字段：分析日志时优先使用timestamp_sample（经驱动延迟补偿后的采样时刻）对齐其他传感器数据；time_utc_usec == 0表示 UTC 时间尚未可用。
3. RTK 解质量判断：固定解（carrier_solution_fixed为真）是相对定位精度最高的状态；若长期处于浮动解，应检查差分数据链路（RTCM 是否正常到达）与基站距离。
4. 移动基准模式：当reference_position_miss/reference_observations_miss频繁置位时，说明参考数据依赖外推，相对位置精度会随时间下降，建议在应用中体现该降级状态。
5. GNSS 航向使用前提：vehicle_gps_position模块只在配置了基线参数（SENS_GNSSn_HDG）且基线长度不小于最小天线间距时才输出航向；未配置时会打印告警GNSS heading from ... not used: set SENS_GNSSn_HDG。

参考与进一步阅读

• 消息定义原文：msg/SensorGnssRelative.msg
• 消息文档（本文依据）：docs/en/msg_docs/SensorGnssRelative.md
• 通用 GPS 驱动发布逻辑：src/drivers/gps/gps.cpp
• GNSS 航头消费与融合：src/modules/sensors/vehicle_gps_position/VehicleGPSPosition.cpp
• UAVCAN 桥接与节点侧发布：src/drivers/uavcan/sensors/gnss_relative.cpp、src/drivers/uavcannode/Publishers/RelPosHeading.hpp
• Septentrio 驱动参考站 ID 写入：src/drivers/gnss/septentrio/septentrio.cpp
• 日志主题注册：src/modules/logger/logged_topics.cpp

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件