2. PX4架构基础：内部模块通信机制与驱动框架
好，咱们直接切入正题。这一章我打算聊聊PX4的“血管”和“骨架”——也就是模块之间怎么说话，传感器数据怎么流，以及驱动层到底长什么样。你想想看，一个飞控系统里跑着几十个模块，姿态估计、位置控制、GPS、IMU……它们要是各说各的，那不乱套了？
我个人习惯，在接触一个新系统时，先搞懂它的通信机制。这就像学一门新语言，语法都不懂，怎么写文章？
2.1 uORB：PX4的“消息总线”
uORB，全称是micro Object Request Broker。名字挺唬人，说白了就是一个轻量级的发布-订阅消息总线。我当年第一次看源码时，也被这名字吓到了，以为是什么分布式中间件。其实没那么复杂。
核心思想：任何模块想发数据，就往uORB上“发布”一个主题（topic）。任何模块想收数据，就去“订阅”这个主题。发布者和订阅者互不知道对方的存在，完全解耦。
关键特性：
- 多对多通信：一个发布者，多个订阅者；多个发布者，一个订阅者。都行。
- 实时性：数据是“最新快照”模式。你订阅一个主题，拿到的是最新发布的那一份数据。不会排队，不会阻塞。
- 跨进程/跨线程：uORB底层用共享内存实现，不同模块（不同进程）也能通信。
举个例子。IMU驱动发布了一个 sensor_accel 主题，里面放着加速度计数据。EKF2模块订阅了这个主题，拿到数据做融合。同时，日志模块也订阅了它，把数据写进SD卡。你看，驱动只管发，后面谁在用，它根本不用管。
我的小技巧：调试时，我经常用 uorb top 命令查看当前系统里有哪些主题在跑，频率多少。这比看代码快多了。有一次客户说飞机姿态不稳，我上去一看，IMU数据发布频率只有200Hz，正常应该是800Hz。嗯，驱动有问题。
uORB的数据结构是用IDL（Interface Description Language）定义的，编译时会自动生成C/C++代码。你写驱动时，只需要包含对应的头文件，然后调用 orb_advertise() 和 orb_publish() 就行。
// 伪代码示例：发布加速度计数据
#include <uORB/uORB.h>
#include <uORB/topics/sensor_accel.h>
struct sensor_accel_s accel_data;
orb_advert_t accel_pub = orb_advertise(ORB_ID(sensor_accel), nullptr);
while (1) {
// 从硬件读取数据
accel_data.x = read_accel_x();
accel_data.y = read_accel_y();
accel_data.z = read_accel_z();
accel_data.timestamp = hrt_absolute_time();
orb_publish(ORB_ID(sensor_accel), accel_pub, &accel_data);
usleep(1000); // 1kHz
}
2.2 传感器数据流：从物理量到控制指令
搞清楚了uORB，咱们再看看传感器数据是怎么一路“流”到执行机构的。我画了一张图，你一看就明白。
你看，整个链路非常清晰：
- 传感器驱动从硬件读取原始数据，发布到uORB。
- EKF2估计器订阅这些原始数据，融合出姿态、位置、速度等状态量。
- 控制器订阅估计结果，计算出控制量（油门、舵量等）。
- 混控器把控制量映射到具体的电机/舵机，输出PWM或DSHOT信号。
注意：我曾经遇到过一个坑。有个第三方GPS模块，它发布的数据里时间戳是错的，用的是驱动启动时的时间，而不是硬件时间。结果EKF2拿到数据后，时间对齐全乱套了，飞机在天上画圈圈。后来我强制要求所有传感器驱动必须用 hrt_absolute_time() 打时间戳，问题才解决。
2.3 驱动框架概览：模块化与分层
PX4的驱动框架，说白了就是一套“模板”。你写一个新传感器驱动，不需要从零开始。框架帮你把uORB通信、参数系统、设备抽象都搭好了。
驱动通常分三层：
| 层次 | 职责 | 典型文件 |
|---|---|---|
| 硬件抽象层 (HAL) | 直接操作SPI/I2C/UART总线，读写寄存器 | drivers/barometer/ms5611/ms5611.cpp |
| 设备驱动层 | 封装传感器初始化、数据采集、校准逻辑 | drivers/barometer/ms5611/ms5611_i2c.cpp |
| uORB接口层 | 将采集到的数据发布到uORB主题 | drivers/barometer/ms5611/ms5611_main.cpp |
嗯，这里要注意。很多新手写驱动时，喜欢把这三层混在一起。结果代码又臭又长，换个总线（比如从I2C改成SPI）就得重写一大半。我个人习惯是严格分层，哪怕多写几个文件也值得。
我的经验：写驱动时，先别急着写uORB发布。先用一个简单的测试程序，确认SPI/I2C通信正常，能读到正确的传感器ID。这一步卡住了，后面全是白搭。我记得有一次调一个激光雷达驱动，折腾了两天，最后发现是SPI时钟极性配置错了。嗯，基础不牢，地动山摇。
驱动启动时，通常通过 module start 命令调用。框架会帮你做设备探测、参数加载、调度循环启动。你只需要实现几个关键回调函数：
init()：初始化硬件，注册uORB主题。probe()：探测设备是否存在，读取ID校验。cycle()：主循环，采集数据并发布。stop()：停止驱动，清理资源。
你看，框架把脏活累活都干了。你只需要关注传感器本身的数据手册和通信协议。这也是为什么PX4能支持那么多传感器——框架统一了接口，大家按规矩办事就行。
最后说一句。搞懂uORB和数据流，是理解PX4的钥匙。后面讲外部传感器融合时，你会发现，不管是激光雷达、视觉里程计还是RTK GPS，接入方式都是一样的：写一个驱动，把数据发布到uORB，然后让EKF2去订阅。就这么简单。
公众号:蓝海资料掘金营，微信deep3321