PX4架构与多机支持：飞行栈、uORB、通信与机载计算机
各位同学，欢迎来到第二章。上一章我们聊了多机协同的宏观图景，今天得把袖子撸起来，看看PX4到底是怎么工作的。说白了，你要玩转多机，就得先懂PX4的骨架和血管——架构、消息机制、通信方式，还有那个越来越重要的机载计算机。
我最早接触PX4时，第一反应是“这代码结构怎么这么绕”？后来才发现，它的设计哲学其实很清晰：模块化、去中心化、实时可靠。今天我们就一层层剥开它。
2.1 PX4飞行栈概述
PX4的飞行栈，你可以想象成一个三层蛋糕：
- 底层：硬件抽象层（HAL）——负责跟传感器、PWM、串口打交道。换飞控板？换驱动就行，上层不用动。
- 中间层：核心模块——姿态估计、位置估计、控制器、导航、混控器。这是飞行的“大脑”。
- 上层：应用层——Commander、Logger、MAVSDK、机载计算机接口。这是跟外界交互的“嘴巴和耳朵”。
每个模块都是一个独立的进程（任务），通过uORB消息总线互相通信。这样做的好处很明显：哪个模块崩了，不会拖垮整个系统。我在项目里见过GPS模块死锁，结果姿态估计照样跑，飞机只是切到定高模式，没炸。
核心要点：PX4不是单线程的裸机程序，而是一个实时操作系统（NuttX）上的多任务系统。每个模块独立运行，通过uORB交换数据。
下面这张图是我自己画的PX4内部数据流，你看一眼就能明白大概：
2.2 uORB消息机制
uORB是PX4的“神经系统”。每个模块想告诉别人什么，就往uORB上发一条消息；想获取什么，就去订阅对应的主题。发布/订阅模式，跟ROS有点像，但轻量得多。
我记得第一次调试多机时，发现一架飞机收不到另一架的位置信息。查了半天，原来是uORB主题名写错了——大小写敏感，一个字母不对就收不到。嗯，这种坑踩过一次就记住了。
实用技巧：在QGroundControl的MAVLink Inspector里，你可以看到uORB消息的实时发布频率。如果某个主题频率异常，说明对应模块可能卡住了。
常用的uORB主题有哪些？我列个表：
| 主题名 | 发布者 | 订阅者 | 数据内容 |
|---|---|---|---|
sensor_combined |
传感器驱动 | EKF2 | IMU加速度、角速度、磁力计 |
vehicle_attitude |
EKF2 | 控制器、Commander | 四元数、欧拉角 |
vehicle_local_position |
EKF2 | 导航、避障 | 位置、速度、协方差 |
vehicle_command |
Commander | 控制器、执行器 | 起飞、降落、模式切换 |
position_setpoint_triplet |
导航 | 控制器 | 期望位置、速度、航向 |
你可能会问：多机场景下，uORB能跨飞机通信吗？答案是不能。uORB只在单机内部生效。飞机之间的通信，得靠MAVLink或RTPS。
2.3 多机模式：MAVLink vs RTPS
这是本章的重头戏。多机通信，说白了就是飞机之间怎么“说话”。PX4给了两条路：MAVLink和RTPS。我两种都用过，各有优劣。
2.3.1 MAVLink——轻量级、广兼容
MAVLink是无人机界的“普通话”。它定义了一堆消息类型（心跳、位置、命令），通过串口或UDP传输。优点是几乎所有地面站和机载设备都支持，缺点是带宽有限、消息结构固定。
多机场景下，MAVLink通常走“广播+转发”模式：一架飞机把自己的位置广播出去，其他飞机收到后转发给机载计算机处理。我在一个4机编队项目里用过，延迟大概10-20ms，够用。
注意：MAVLink的广播模式在Wi-Fi环境下容易丢包。如果飞机数量超过5架，建议用RTPS或者单独的数据链。
2.3.2 RTPS——高吞吐、低延迟
RTPS是DDS（数据分发服务）的实时版本。它比MAVLink重，但能提供更灵活的QoS（服务质量）控制——比如你可以设置“可靠传输”或“尽力传输”。
我去年做的一个10机协同项目，用的就是RTPS。每架飞机以50Hz发布自己的位置和状态，机载计算机订阅后做集群规划。延迟控制在5ms以内，比MAVLink稳得多。
下面这个表格帮你快速对比：
| 特性 | MAVLink | RTPS |
|---|---|---|
| 协议层 | 应用层（串口/UDP） | 中间件（UDP/TCP） |
| 消息定义 | 固定ID + 载荷 | 动态类型（IDL定义） |
| QoS支持 | 无 | 可靠性、时效性、持久性 |
| 典型延迟 | 10-30ms | 1-5ms |
| 多机扩展性 | 5-10架（Wi-Fi） | 20+架（有线/Wi-Fi） |
| 生态成熟度 | 极高（QGC、MAVSDK） | 中等（Fast DDS、Cyclone DDS） |
怎么选？我个人习惯：原型验证用MAVLink，量产部署用RTPS。MAVLink调试方便，RTPS性能好。如果你做的是10架以上的集群，别犹豫，直接上RTPS。
2.4 机载计算机的角色
飞控（STM32）算力有限，跑不了复杂的路径规划、视觉SLAM、集群算法。这时候就需要机载计算机——通常是树莓派、NVIDIA Jetson、Intel NUC之类的Linux设备。
机载计算机在PX4多机系统里扮演三个角色：
- 大脑——运行集群规划、避障、任务分配算法。
- 通信网关——通过MAVSDK或Fast DDS与飞控交互，同时通过Wi-Fi/4G与地面站或其他飞机通信。
- 传感器融合——处理摄像头、激光雷达、RTK-GPS数据，生成高精度状态估计。
我见过一个失败的案例：有人把集群规划直接跑在飞控上，结果CPU占用率飙到90%，姿态控制都抖了。后来把规划挪到树莓派上，飞控只负责执行，问题就解决了。所以记住：飞控干飞控的活，计算机干计算机的活。
硬件选型建议：如果只是做简单的编队（5架以内），树莓派4B就够了。如果要跑视觉SLAM或深度学习，至少上Jetson Orin NX。别省那点钱，炸一次机就亏回来了。
机载计算机与飞控的典型连接方式：
- 串口（UART）——最稳定，速率115200-921600 bps。适合MAVLink。
- USB——方便，但注意供电和线缆松动。
- 以太网——高带宽，适合RTPS。Jetson和NUC都支持。
嗯，第二章的内容就到这。你理解了PX4的模块化架构、uORB的发布订阅机制、MAVLink与RTPS的取舍，以及机载计算机的定位，后面讲多机通信协议和集群规划时，就不会觉得突兀了。