2、PX4与边缘AI基础：PX4架构、MAVLink协议、边缘计算平台（Jetson、Raspberry Pi等）概述
在构建PX4边缘AI低延迟系统之前，必须首先厘清三个核心要素：PX4飞控的软件架构如何组织、MAVLink协议如何在飞控与外部计算单元之间传递数据、以及Jetson与Raspberry Pi等边缘平台在算力、接口和实时性上的本质差异。这三者共同决定了采集、推理、控制回路的延迟瓶颈所在。本章将逐一拆解，并给出可落地的选型与集成判断依据。
上图展示了PX4边缘AI系统的三大核心模块及其连接关系。PX4飞控通过uORB消息总线实现内部模块解耦，MAVLink作为外部通信协议连接飞控与边缘平台，而边缘平台的选择直接决定了AI推理的算力上限与延迟特性。理解这三者的交互是优化低延迟链路的前提。
2.1 PX4飞控架构：模块化与实时性设计
核心原理：PX4采用分层模块化架构，底层为NuttX实时操作系统（RTOS），提供抢占式调度、信号量和消息队列等原语。上层运行着传感器驱动、状态估计（EKF2）、导航与控制、以及MAVLink通信等独立进程。模块间通过uORB（Micro Object Request Broker）消息总线进行异步发布/订阅通信，这种设计避免了全局锁竞争，使得每个模块可以独立调度和重启，同时保证了数据在飞控内部传递的低延迟（通常在微秒级）。
关键模块与数据流：
- 传感器驱动层：IMU（陀螺仪+加速度计）数据通常以1-8kHz的频率发布到uORB话题
sensor_imu，这是整个控制回路的时间基准。 - EKF2估计器：订阅IMU、GPS、气压计等话题，以250-500Hz的频率输出姿态四元数和位置速度估计，发布到
vehicle_attitude和vehicle_local_position。 - 控制器：位置控制器（1-10Hz）和姿态控制器（250-500Hz）级联，最终输出电机指令到混控器。
- MAVLink模块：独立线程，负责将uORB消息打包成MAVLink帧，通过串口或UDP发送给地面站或机载计算机。
判断方法：在调试边缘AI系统时，应首先通过uorb top命令查看各话题的发布频率和延迟。若发现sensor_imu频率低于1kHz，或vehicle_attitude存在明显抖动，说明飞控内部负载过高，此时应优先优化飞控端任务调度，而非盲目增加边缘端算力。
OFFBOARD_CONTROL消息时，飞控会切换到外部控制模式。但必须注意，Offboard模式下飞控仍然运行内部的安全保护逻辑（如地理围栏、电池低电量保护），这些逻辑的优先级高于外部指令。
2.2 MAVLink协议：通信语义与延迟控制
核心原理：MAVLink是一种轻量级二进制消息协议，v2.0版本帧结构包含起始标志（0xFD）、长度、序列号、系统ID、组件ID、消息ID及CRC校验。对于边缘AI场景，最关键的延迟指标是消息从飞控uORB话题到边缘端应用可用的端到端延迟，这包括：uORB发布延迟、MAVLink打包延迟、串口/UDP传输延迟、边缘端解包延迟。
关键消息与频率匹配：
| 消息名称 | 消息ID | 典型频率 | 用途 |
|---|---|---|---|
| HIGHRES_IMU | 105 | 100-500Hz | 原始IMU数据，用于视觉惯性里程计（VIO） |
| ATTITUDE | 30 | 50-100Hz | 姿态四元数，用于控制反馈 |
| LOCAL_POSITION_NED | 32 | 30-50Hz | 本地位置，用于轨迹跟踪 |
| OFFBOARD_CONTROL | 0 | 10-50Hz | 外部控制指令（期望姿态/位置） |
| SET_ATTITUDE_TARGET | 82 | 10-50Hz | 期望姿态四元数+角速度 |
操作流程：在配置边缘AI链路时，应遵循以下步骤：
- 确定控制周期需求（例如视觉位置控制需要50Hz，而姿态控制需要200Hz）。
- 在飞控端通过
mavlink stream命令配置对应消息的流频率，避免不必要的高频发送占用带宽。 - 在边缘端使用MAVSDK或pymavlink设置消息回调，并测量回调时间戳与飞控内部时间戳的差值（需启用TIMESYNC微服务）。
- 若使用UDP传输，需注意MTU（通常1500字节）对消息分片的影响，尽量保持单条消息小于MTU。
2.3 边缘计算平台选型：Jetson、树莓派与替代方案
核心原理：边缘AI平台的选择取决于三个约束：算力（TOPS）、功耗（W）和接口延迟（μs）。NVIDIA Jetson系列（如Orin NX 16GB）提供高达100 TOPS的INT8算力，适合运行YOLO等深度学习模型；Raspberry Pi 5的算力约为0.2-1 TOPS，仅适合轻量级模型（如MobileNet）或传统CV算法；而Intel NUC则适合需要x86生态兼容性的场景。
对比分析：
| 平台 | AI算力 | 典型功耗 | 与PX4连接方式 | 延迟特性 |
|---|---|---|---|---|
| Jetson Orin NX | 100 TOPS (INT8) | 10-25W | UART (1Mbps) 或 USB | 串口延迟约0.5-1ms |
| Raspberry Pi 5 | 0.2-1 TOPS | 5-12W | UART 或 SPI | SPI延迟可低至0.1ms |
| Intel NUC i7 | ~2 TOPS (集成GPU) | 28-45W | Ethernet (UDP) | 网络延迟约0.2-0.5ms |
| STM32H7 + AI | 0.01 TOPS | 0.5-1W | SPI / FDCAN | SPI延迟<0.05ms |
判断方法：若推理任务需要处理高分辨率图像（如1080p）且模型参数量大于50MB，应选择Jetson；若仅处理低分辨率灰度图且模型为轻量级分类器，树莓派+SPI接口可能是性价比最高的方案。关键指标是“端到端延迟预算”：假设控制周期为10ms，那么传感器采集+传输+推理+指令回传的总延迟必须小于5ms，否则系统将失去稳定性裕度。
2.4 常见误区与总结复盘
误区一：认为MAVLink的延迟等同于串口波特率的倒数。实际上，飞控内部uORB到MAVLink打包的调度延迟（通常1-5ms）往往大于传输延迟。解决方法是使用mavlink status查看发送队列积压情况。
误区二：在树莓派上盲目运行高帧率模型。树莓派的CPU/GPU共享内存带宽，当推理占用过高时，会导致MAVLink接收线程被抢占，反而增加控制延迟。建议使用taskset将推理进程绑定到特定CPU核心，并将MAVLink处理线程设置为实时优先级。
误区三：忽略PX4内部的安全模式切换。当边缘端发送的Offboard指令频率低于2Hz时，PX4会立即退出Offboard模式并切换回自稳模式。因此，边缘端必须实现一个独立的看门狗线程，确保指令流持续稳定。
总结复盘：构建PX4边缘AI低延迟系统，本质上是预算管理——将有限的延迟预算（如20ms）合理分配给采集、传输、推理和控制四个环节。PX4的uORB架构决定了内部延迟的下限，MAVLink的配置决定了通信开销，而边缘平台的选型决定了推理能力的上限。在实际工程中，建议先用perf工具测量各环节耗时，再针对瓶颈进行优化，而不是盲目升级硬件。