4. uORB消息机制：发布/订阅模型、消息定义文件（.msg）、消息生成代码、多进程通信原理、性能考量
uORB，全称是 micro Object Request Broker。说白了，它就是PX4内部各个模块之间“传话”的中间人。你想想看，一个飞控系统里，传感器模块、姿态估计模块、控制模块、GPS模块……几十个进程同时跑，它们之间怎么交换数据？总不能每个模块都自己写一套通信协议吧？
uORB就是来解决这个问题的。它提供了一套发布/订阅模型，让模块之间解耦。发布者只管发，订阅者只管收，双方不需要知道对方是谁。我在早期做飞控移植时，曾经试图用全局变量来传数据，结果调试到崩溃——一个变量被谁改了都查不清楚。从那以后，我对uORB这种“去中心化”的设计就特别有好感。
4.1 发布/订阅模型：谁说话，谁听
uORB的核心思想其实很简单：
- 发布者（Publisher）：某个模块产生数据，比如传感器模块读到了加速度计的值，它就调用uORB的发布接口，把数据扔进“消息池”。
- 订阅者（Subscriber）：其他模块如果对这个数据感兴趣，比如姿态估计模块需要加速度计数据，它就提前注册订阅。一旦有新数据发布，uORB会自动通知它。
这里有个关键点：一个消息可以有多个发布者，也可以有多个订阅者。比如“传感器原始数据”这个消息，IMU模块可以发布，虚拟传感器也可以发布；而姿态模块、日志模块、地面站转发模块都可以同时订阅它。
核心优势：发布者和订阅者完全解耦。你新增一个传感器模块，不需要修改任何订阅方的代码。只要它发布的消息类型对，订阅方自动就能收到。
我个人习惯把uORB的通信模型画成下面这张图，每次给团队新人讲时都用它，一目了然：
4.2 消息定义文件（.msg）：通信的“协议”
uORB的消息格式是用.msg文件定义的。这些文件放在msg/目录下，每个文件定义一种消息类型。比如sensor_accel.msg定义了加速度计的数据结构。
一个典型的.msg文件长这样：
# sensor_accel.msg
uint64 timestamp # 时间戳，微秒
uint64 timestamp_sample # 采样时间戳
float32[3] x # X轴加速度，m/s^2
float32[3] y # Y轴加速度，m/s^2
float32[3] z # Z轴加速度，m/s^2
uint32 device_id # 设备ID
float32 temperature # 温度，摄氏度
float32 delta_time # 采样间隔，秒
字段类型支持：
| 类型 | 说明 | 示例 |
|---|---|---|
uint8, int32, uint64 |
整数类型，长度自选 | uint8 flag |
float32, float64 |
浮点数 | float32 velocity |
bool |
布尔值 | bool armed |
类型[N] |
固定长度数组 | float32[3] gyro |
我的经验：定义消息时，timestamp字段一定要带上。很多调试问题最后都追溯到时间戳不对。我习惯在每个消息开头都放一个uint64 timestamp，这是PX4的惯例，也是血的教训换来的。
4.3 消息生成代码：从.msg到C/C++结构体
.msg文件不是直接拿来用的。编译时，PX4的构建系统会调用一个代码生成器，把.msg文件转换成C/C++的头文件和源文件。
生成后的结构体大概长这样：
// 自动生成，不要手动修改
struct sensor_accel_s {
uint64_t timestamp; // 时间戳
uint64_t timestamp_sample; // 采样时间
float x[3]; // X轴
float y[3]; // Y轴
float z[3]; // Z轴
uint32_t device_id; // 设备ID
float temperature; // 温度
float delta_time; // 采样间隔
};
同时还会生成对应的发布/订阅API函数。比如：
orb_advert_t orb_advertise(const struct orb_metadata *meta, const void *data)—— 发布者注册int orb_publish(const struct orb_metadata *meta, orb_advert_t handle, const void *data)—— 发布数据int orb_subscribe(const struct orb_metadata *meta)—— 订阅者注册int orb_copy(const struct orb_metadata *meta, int handle, void *buffer)—— 拷贝数据
我曾经犯过一个低级错误：手动修改了生成的头文件，结果下次编译又被覆盖了。嗯，这里要注意——生成代码永远不要手动改，要改就去改.msg源文件。
4.4 多进程通信原理：共享内存+原子操作
uORB是怎么实现多进程通信的？答案是共享内存。所有uORB消息都存放在一块所有进程都能访问的共享内存区域里。
具体流程是这样的：
- 初始化：系统启动时，uORB在共享内存中创建一块消息池。
- 发布：发布者调用
orb_publish，把数据写入共享内存中对应的消息槽。写入时使用原子操作保证数据一致性。 - 通知：写入完成后，uORB通过一个内部的通知机制（比如信号量或事件fd）告诉所有订阅者：有新数据了。
- 读取：订阅者收到通知后，调用
orb_copy从共享内存中拷贝数据。注意是拷贝，不是直接读指针——这是为了防止发布者覆盖数据时导致订阅者读到一半的数据。
⚠️ 性能陷阱：虽然uORB用了共享内存，但orb_copy是一次内存拷贝。如果消息体很大（比如图像数据），频繁拷贝会带来性能开销。对于大块数据，建议用其他机制（比如单独的消息队列），或者降低发布频率。
4.5 性能考量：延迟、吞吐量与资源占用
uORB的设计目标是在资源受限的嵌入式系统上跑，所以性能是核心考量。我总结几个关键点：
| 指标 | uORB表现 | 说明 |
|---|---|---|
| 单次发布延迟 | ~1-3 µs | 主要是内存拷贝和原子操作的开销 |
| 单次订阅拷贝 | ~1-2 µs | 取决于消息大小，小消息几乎无感 |
| 内存占用 | 固定大小消息池 | 每个消息类型预分配固定数量的槽位 |
| 多订阅者开销 | 线性增长 | 每个订阅者独立拷贝，订阅者越多总拷贝次数越多 |
这里有个容易被忽略的点：消息槽位数量。每个消息类型在共享内存中预分配了固定数量的槽位（默认通常是1个）。如果发布者发布速度远快于订阅者消费速度，新数据会覆盖旧数据。这意味着订阅者可能会丢消息。
为什么会这样？因为uORB设计时假设：订阅者只关心最新数据。比如姿态控制模块，它只需要最新的传感器值，旧值没有意义。如果你需要保证每条消息都被处理（比如日志记录），那就得自己加队列缓冲。
性能优化建议：
- 小消息（<64字节）直接用uORB，延迟最低
- 中等消息（64-512字节）注意发布频率，不要超过1kHz
- 大消息（>512字节）考虑用其他机制，或者降低频率到100Hz以下
- 如果订阅者处理慢，考虑用
orb_check()轮询而不是阻塞等待
我记得有一次调试一个外部传感器驱动，发布频率设到了2kHz，结果CPU占用率飙升到40%。后来把频率降到500Hz，一切正常。嗯，uORB虽然快，但不是万能的，该降频时就降频。