4. uORB消息机制：飞控的“神经网络”

如果你把PX4飞控想象成一个活生生的人，那uORB就是它的神经系统。传感器是眼睛和耳朵，执行器是手脚，而uORB就是传递这些信号的神经纤维。没有它，各个模块就是孤岛，飞控根本转不起来。

我第一次接触uORB时，觉得它不就是个消息队列嘛，有啥好学的？后来在调试一个自定义传感器驱动时，因为消息字段定义错了，导致姿态解算疯狂跳变，飞机差点翻跟头。嗯，从那以后我再也不敢小看这个“消息总线”了。

4.1 核心概念：发布/订阅模型

uORB的全称是micro Object Request Broker，说白了就是一个轻量级的发布/订阅消息系统。它跟ROS的topic很像，但专为嵌入式环境做了极致精简。

核心思想就两条：

• 发布者（Publisher）：谁有数据，谁就往外发。比如传感器驱动发布原始数据。
• 订阅者（Subscriber）：谁需要数据，谁就来取。比如姿态估计模块订阅传感器数据。

发布者和订阅者完全解耦。发布者不知道谁会收，订阅者也不知道谁发的。你想想看，这多灵活？加一个新模块，只要它订阅需要的消息就行，完全不用改其他代码。

我在项目中遇到过一个问题：两个传感器驱动同时发布同一种消息，结果订阅者收到的数据乱掉了。后来发现uORB默认是最后写入者胜出的机制——同一个消息类型，后发布的会覆盖前面的。所以如果你要处理多个同类型传感器，得用实例化（instance）来区分。

4.2 常用uORB消息：你每天都在用

PX4里预定义了几百种uORB消息。但说实话，日常开发中常用的就那么十几个。我列几个你一定会碰到的：

消息名称	发布者	典型订阅者	核心字段
sensor_combined	传感器聚合驱动	姿态估计、位置估计	加速度、角速度、磁场
vehicle_attitude	姿态估计模块	位置控制器、地面站	四元数、欧拉角
vehicle_local_position	位置估计模块	导航、避障	xyz坐标、速度
actuator_controls	混控器	执行器驱动	油门、滚转、俯仰、偏航
vehicle_status	系统状态机	几乎所有模块	飞行模式、arming状态

拿sensor_combined来说，它把加速度计、陀螺仪、磁力计的数据打包在一起。为什么这么做？因为姿态估计模块需要同时拿到这三样数据才能做融合。如果分开三个消息，时间戳对不齐，融合效果就差了。

再说vehicle_attitude。这个消息里存的是四元数，不是欧拉角。为什么？因为四元数没有万向锁问题，插值也方便。但很多人不习惯看四元数，所以PX4也提供了欧拉角的转换接口。我个人建议：内部计算一律用四元数，只在日志和地面站显示时转成欧拉角。

4.3 自定义uORB消息：当现成的不够用

有时候你需要传递一些特殊数据，比如自定义传感器的原始值、某个算法的中间结果。这时候就得自己定义消息了。别怕，流程很简单，就三步：

1. 定义消息结构：在msg/目录下新建一个.msg文件
2. 生成代码：编译系统会自动生成C/C++头文件
3. 发布和订阅：在代码里用API操作

举个例子。假设我要定义一个自定义的“超声波测距”消息：

// 文件: msg/ultrasonic_distance.msg
uint64 timestamp    # 时间戳，单位微秒
float32 distance_m  # 距离，单位米
float32 confidence  # 置信度，0~1
uint8 sensor_id     # 传感器编号

保存后，编译系统会自动生成ultrasonic_distance.h。你不需要手动写任何序列化代码，uORB的代码生成器全包了。

然后发布消息：

// 发布者代码片段
#include <uORB/uORB.h>
#include <ultrasonic_distance.h>

struct ultrasonic_distance_s dist;
dist.timestamp = hrt_absolute_time();
dist.distance_m = 1.25f;
dist.confidence = 0.98f;
dist.sensor_id = 1;

orb_advert_t pub = orb_advertise(ORB_ID(ultrasonic_distance), &dist);
orb_publish(ORB_ID(ultrasonic_distance), pub, &dist);

订阅消息：

// 订阅者代码片段
int sub_fd = orb_subscribe(ORB_ID(ultrasonic_distance));
struct ultrasonic_distance_s dist;

while (1) {
    orb_copy(ORB_ID(ultrasonic_distance), sub_fd, &dist);
    // 处理数据...
    px4_usleep(10000); // 10ms轮询一次
}

另外，消息字段的顺序也有讲究。uORB的序列化是按字段顺序打包的。如果你把一个大数组放在前面，后面再跟一堆小字段，内存对齐可能会浪费空间。我一般把固定长度的基础类型放前面，变长数组放最后。

4.4 uORB消息的生命周期

你可能好奇：消息在内存里是怎么存的？uORB内部维护了一个环形缓冲区。每个消息类型只有一个最新的副本。新数据会覆盖旧数据。订阅者读到的永远是“当前最新”的数据。

这种设计的好处是：

• 内存占用极小：每个消息类型只占一份内存
• 实时性好：订阅者永远拿到最新数据，不会读到过期数据
• 实现简单：不需要复杂的队列管理

但代价是：如果你订阅频率比发布频率慢，中间的数据就丢了。不过对于飞控来说，这通常不是问题——你只需要最新的传感器数据，历史数据没意义。

下面这张图展示了uORB消息在飞控系统中的流转路径：

从这张图你能看到，uORB就像个数据交换中心。传感器驱动只管往总线上扔数据，姿态估计模块只管从总线上取数据。两者不需要知道对方的存在。这就是解耦的魅力。

4.5 调试uORB消息的实用技巧

最后分享几个我常用的调试技巧：

• 用listener命令：在nsh终端输入listener -n 5 sensor_combined，可以打印5次消息内容，快速验证数据对不对。
• 检查发布频率：用top命令看每个模块的CPU占用，如果某个模块发布频率异常，可能是驱动有问题。
• 消息订阅超时：如果订阅者长时间收不到数据，可以设置一个超时检测。比如姿态估计模块如果500ms没收到传感器数据，就应该触发故障保护。
• 日志分析：uLog里会记录所有uORB消息。飞行后回放日志，看看消息的时间戳是否连续，有没有丢帧。

uORB看似简单，但它是整个飞控系统的基石。理解它，你就能理解PX4的模块化设计哲学。后面我们讲模块开发时，你会频繁用到今天学的这些知识。