第2章 uORB消息机制

2. uORB消息机制：消息发布频率过高导致CPU占用、消息订阅者未及时处理导致数据丢失

uORB是PX4里最核心的通信机制，没有之一。说白了，它就是飞控里各个模块之间传递消息的“快递系统”。但很多新手甚至老手，都在这个环节上栽过跟头。今天我就把最常见的两个坑——发布频率过高和订阅者处理不及时——掰开了讲清楚。

核心问题一句话总结：发布者太快，订阅者太慢，系统就崩了。

2.1 消息发布频率过高：CPU是怎么被吃掉的？

先看一个典型场景。你写了一个传感器驱动，想把数据发出去。你可能会这么写：

// 错误示范：无限制高频发布
while (true) {
    orb_publish(ORB_ID(sensor_data), &data);
    // 没有延时，没有频率控制
}

嗯，这段代码跑起来，CPU占用率直接飙升到80%以上。为什么？

uORB的发布操作不是免费的。每次调用orb_publish()，系统都要做这几件事：

拷贝数据到共享内存区
更新消息的时间戳和序列号
通知所有订阅者（如果有等待机制）
触发调度器检查是否有任务需要唤醒

我在项目中遇到过，有人把IMU数据以10kHz的频率往外发。结果呢？整个飞控的调度周期全乱了，姿态解算模块拿不到CPU时间，飞机直接炸了。

我的建议：每个消息类型都要有明确的发布频率上限。IMU数据一般400-1000Hz就够了，位置信息50Hz都算高的。别贪多。

2.2 频率控制的正确姿势

正确的做法是用定时器或者周期任务来控制发布频率。PX4里推荐用work_queue：

// 正确示范：用work_queue控制发布频率
static void sensor_poll(void *arg) {
    struct sensor_data_s data;
    // 读取传感器数据
    data.timestamp = hrt_absolute_time();
    data.value = read_sensor();
    
    orb_publish(ORB_ID(sensor_data), &data);
    
    // 重新调度，1000Hz = 1000us间隔
    work_queue(HPWORK, &work, sensor_poll, NULL, USEC2TICK(1000));
}

你想想看，这样写的好处是什么？系统不会因为你while循环里忘了加延时就把CPU吃光。work_queue本身就有优先级管理，高优先级任务不会被低优先级的发布操作阻塞。

2.3 订阅者未及时处理：数据是怎么丢的？

这个坑更隐蔽。很多人以为只要发布了，订阅者就一定能收到。错！

uORB的默认行为是：新数据会覆盖旧数据。也就是说，如果订阅者处理得太慢，中间的数据就丢了。

举个例子：

// 订阅者代码
int sub_fd = orb_subscribe(ORB_ID(sensor_data));

while (true) {
    orb_copy(ORB_ID(sensor_data), sub_fd, &data);
    // 假设这里处理数据花了10ms
    process_data_slowly(&data);
}

如果发布者以1kHz（1ms间隔）发布数据，订阅者10ms才处理一次。那么每10次发布中，只有1次被成功拷贝，剩下9次全丢了。

注意：这不是bug，是uORB的设计哲学——它追求的是“最新数据”，而不是“所有数据”。对于控制环路来说，拿到最新的数据就够了，历史数据反而没用。

2.4 如何避免数据丢失？

这里有几种策略，我按推荐程度排个序：

策略	适用场景	优缺点
使用队列（Queue）	需要保留历史数据	不丢数据，但占用内存多
提高订阅者优先级	订阅者处理时间可控	简单有效，但可能影响其他任务
降低发布频率	数据更新速度要求不高	最稳妥，但可能牺牲实时性
使用`orb_check()`轮询	需要精确控制处理时机	灵活，但代码复杂度增加

我个人习惯用队列。PX4从v1.12开始支持uORB队列模式，用法很简单：

// 发布者：使用队列模式
struct orb_metadata *meta = orb_get_metadata(ORB_ID(sensor_data));
int pub_fd = orb_advertise_queue(meta, &data, 10); // 队列深度10

// 订阅者：同样指定队列
int sub_fd = orb_subscribe_queue(meta, 10);

// 使用方式和普通的一样
orb_copy(meta, sub_fd, &data);

这样即使订阅者处理慢，队列里也能缓存最多10帧数据，不会丢。

2.5 避坑指南：我曾经踩过的雷

我曾经在一个项目中，把GPS数据以100Hz的频率发布。GPS本身更新率只有10Hz，我这么干纯粹是浪费CPU。更糟的是，姿态解算模块订阅了这个消息，每次收到数据都要重新计算，结果CPU占用率从30%飙到了70%。

后来怎么解决的？很简单，发布频率和传感器实际更新率保持一致。GPS只有10Hz，我就10Hz发布。IMU是1kHz，我就1kHz发布。别自作聪明去“插值”或者“预测”，那只会让系统更乱。

避坑指南：我曾经在调试日志里看到uORB消息丢失的警告，一开始没在意。后来发现是订阅者任务被更高优先级的任务抢占了。解决办法是把订阅者任务的栈空间加大，同时降低它的处理函数里的计算量。

2.6 核心逻辑：一张图看懂

下面这张图展示了uORB消息从发布到订阅的完整流程，以及高频发布和慢速订阅导致的问题：

2.7 总结一下

uORB消息机制的两个核心坑，说白了就是：

发布太快 → CPU被吃光 → 系统调度紊乱
订阅太慢 → 数据被覆盖 → 信息丢失

解决办法也不复杂：控制好发布频率，用好队列机制。记住，uORB不是万能的，它追求的是“最新”而不是“完整”。如果你的应用场景需要完整的数据流，那就得用队列或者自己实现环形缓冲区。

嗯，今天就聊到这儿。这些坑我当年都踩过，希望你能少走弯路。

📚 课程目录

2. uORB消息机制：消息发布频率过高导致CPU占用、消息订阅者未及时处理导致数据丢失

2.1 消息发布频率过高：CPU是怎么被吃掉的？

2.2 频率控制的正确姿势

2.3 订阅者未及时处理：数据是怎么丢的？

2.4 如何避免数据丢失？

2.5 避坑指南：我曾经踩过的雷

2.6 核心逻辑：一张图看懂

2.7 总结一下