3. PX4 MAVLink架构：uORB消息总线、MAVLink模块与数据流管理
这一章，我们来拆解PX4里MAVLink通信的核心骨架。说白了，就是搞清楚“消息从哪来、经过谁、怎么发出去”。
我刚开始接触PX4源码时，最头疼的就是搞不清uORB和MAVLink模块之间的关系。后来跟了几次实际飞控的日志分析，才慢慢理清这条链路。今天我把这些经验整理出来，希望能帮你少走弯路。
3.1 uORB消息总线：模块间的“快递员”
uORB（micro Object Request Broker）是PX4内部模块通信的基石。你可以把它想象成一个消息总线——所有传感器数据、状态估计、控制指令，都通过它来传递。
每个模块只负责发布（publish）或订阅（subscribe）特定的主题（topic）。比如，GPS驱动发布vehicle_gps_position，位置估计器订阅它，然后发布vehicle_local_position。模块之间不直接调用，完全解耦。
核心概念：uORB是一种发布/订阅（Pub/Sub）模式的消息总线。任何模块都可以发布消息，任何模块都可以订阅消息，发布者和订阅者互不知晓对方的存在。
我个人习惯把uORB主题看作“数据管道”。每个管道有固定的数据类型（结构体），比如：
sensor_accel：加速度计原始数据vehicle_attitude：飞行器姿态四元数actuator_controls：执行机构控制量
嗯，这里要注意：uORB不保证消息的可靠性。如果订阅者处理太慢，消息会被覆盖。这在高速传感器场景下尤其需要留意。
3.2 MAVLink模块（mavlink_main）：通信的“外交官”
MAVLink模块是PX4对外通信的窗口。它负责把uORB消息打包成MAVLink协议格式，然后通过串口、UDP或TCP发送出去。
它的核心入口是mavlink_main.cpp。启动时，它会创建多个MAVLink实例（instance），每个实例绑定一个物理通道。比如：
- 实例0：串口（连接数传电台）
- 实例1：UDP（连接QGroundControl）
- 实例2：第二个串口（连接机载计算机）
每个实例独立运行，有自己的发送/接收线程、消息缓存和速率控制。
我的经验：我曾经在调试一个多链路场景时，发现地面站收不到某些消息。查了半天，原来是两个MAVLink实例的mavlink_id冲突了。每个实例必须分配唯一的ID，否则消息会串线。
3.3 数据流管理：谁在什么时候发什么
MAVLink模块不会一股脑把所有消息都发出去。它有一套精细的流控机制，叫“数据流管理”（Data Stream Management）。
每个消息类型都有对应的发送频率配置。比如：
| 消息类型 | 默认频率（Hz） | 说明 |
|---|---|---|
HEARTBEAT |
1 | 心跳包，必须保持 |
ATTITUDE |
10 | 姿态信息 |
LOCAL_POSITION_NED |
10 | 本地位置 |
BATTERY_STATUS |
2 | 电池状态 |
GPS_RAW_INT |
5 | GPS原始数据 |
这些频率可以通过参数调整。比如MAV_ATT_RATE控制姿态消息的发送速率。
为什么会这样设计？因为带宽是有限的。尤其是数传电台，速率可能只有几十kbps。如果所有消息都全速发送，信道会瞬间饱和。
我记得有一次在野外测试，数传链路突然变得极慢。后来发现是某个调试消息被误设为100Hz发送，把带宽全吃掉了。从那以后，我每次调参都会先算一下总带宽预算。
3.4 模块间通信流程：一条完整的数据链路
现在我们把所有环节串起来，看一条完整的数据链路：
- 传感器驱动（如GPS驱动）读取硬件数据，填充uORB结构体，调用
orb_publish()发布到vehicle_gps_position主题。 - EKF2模块订阅
vehicle_gps_position，结合其他传感器数据，计算出姿态和位置，发布到vehicle_attitude和vehicle_local_position。 - MAVLink模块订阅这些状态主题。在它的主循环中，检查每个消息的发送计时器是否到期。如果到期，就调用
mavlink_msg_attitude_encode()打包，然后通过串口或UDP发送。 - 地面站收到MAVLink包，解析并显示在界面上。
整个过程是异步的。每个模块独立运行，通过uORB耦合。MAVLink模块只负责“拉取”最新数据，不关心数据是谁产生的。
避坑指南：我曾经遇到一个bug：地面站显示的GPS数据总是滞后。排查后发现，MAVLink模块订阅的是vehicle_gps_position，但GPS驱动发布频率是20Hz，而MAVLink模块的发送频率只有5Hz。这意味着每4个数据中只有1个被发送，其余3个被覆盖。解决方案是提高发送频率，或者在MAVLink模块内部加一个环形缓冲区。
3.5 整体架构图
下面这张图展示了uORB、MAVLink模块和外部设备之间的数据流向。我建议你对照源码一起看，效果更好。
3.6 关键代码路径
如果你想去源码里验证，可以关注这几个关键文件：
src/modules/mavlink/mavlink_main.cpp：MAVLink模块入口，负责初始化和主循环src/modules/mavlink/mavlink_stream.cpp：数据流管理，控制每个消息的发送频率src/modules/uORB/uORB.cpp：uORB核心实现，包括发布和订阅逻辑
一个典型的MAVLink发送流程，简化后大致是这样：
// MAVLink模块主循环（伪代码）
while (!should_exit()) {
// 检查每个订阅的消息
for (auto &stream : streams) {
if (stream.should_send()) {
// 从uORB获取最新数据
orb_copy(stream.topic, stream.fd, &data);
// 编码为MAVLink消息
mavlink_msg_attitude_encode(system_id, component_id, &msg, &data);
// 通过物理通道发送
channel->send(&msg);
}
}
// 休眠一段时间，避免忙等
usleep(1000);
}
嗯，这里要注意：orb_copy()是阻塞的，如果数据还没准备好，它会等待。但在MAVLink模块中，我们通常使用orb_check()先检查是否有新数据，避免阻塞主循环。
我的建议：如果你需要自定义MAVLink消息，不要直接修改mavlink_main.cpp。更好的做法是创建一个新的uORB主题，然后在MAVLink模块中订阅它。这样既保持了模块化，又方便后续维护。
好了，这一章的内容就到这里。uORB和MAVLink模块的配合，是PX4通信的核心。理解了这条链路，你就能更自信地调试通信问题，也能更灵活地扩展自定义功能。