3、PX4 Offboard控制架构：飞控、机载计算机、通信链路（MAVLink/ROS2）的角色与数据流

在PX4 Offboard控制系统中，飞控（Flight Controller）、机载计算机（Companion Computer）与通信链路共同构成了一个典型的异构计算与实时控制体系。理解这三者之间的角色划分与数据流方向，是设计可靠AI识别驱动控制系统的前提。飞控负责安全、实时与底层姿态控制；机载计算机负责高算力感知、决策与规划；通信链路则承担两者之间的“神经”连接。本章将系统拆解这一架构，并重点分析MAVLink与ROS2两条主流通信路径的适用场景与数据流特征。

3.1 核心角色与职责边界

在Offboard架构中，飞控与机载计算机的分工并非简单的“上下级”关系，而是基于实时性、安全性与算力需求的自然分层。飞控运行在实时操作系统（RTOS）之上，以1kHz甚至更高频率执行姿态控制、状态估计与电机混控，其代码路径必须确定且可验证。机载计算机则运行Linux等通用操作系统，承载深度学习模型、视觉SLAM、路径规划等重计算任务，其执行时间具有不确定性，但提供了极大的算法灵活性。

这种分工的核心原则是：飞控永远保留最终控制权。机载计算机发送的指令只是“设定点”（Setpoint），飞控内部的控制器会结合自身状态估计结果进行跟踪，并在检测到异常（如指令超时、数据跳变、模式切换失败）时自动回退到安全模式（如降落或悬停）。因此，机载计算机的角色是“建议者”而非“决策者”，所有高层的任务决策最终都要转化为飞控可执行的底层控制指令。

3.2 MAVLink通信链路：经典与可靠

MAVLink（Micro Air Vehicle Link）是PX4最成熟的外部通信协议，采用轻量级消息封装，支持串口、UDP、TCP等多种物理传输。在Offboard控制中，机载计算机通过MAVLink发送 SET_POSITION_TARGET_LOCAL_NED 或 SET_ATTITUDE_TARGET 消息，飞控则返回 LOCAL_POSITION_NED、ATTITUDE 等遥测数据。

MAVLink的关键优势在于其协议成熟度与调试工具链。QGroundControl、MAVSDK、MAVProxy等工具均原生支持，且PX4内部通过uORB消息总线与MAVLink模块无缝对接。对于大多数工业应用和科研项目，MAVLink已经足够稳定。但它的局限性也很明显：消息类型固定，扩展自定义数据类型需要修改协议定义；且缺乏现代中间件提供的服务质量（QoS）保障，在弱网环境下可能出现数据丢包或乱序。

from mavsdk import System
import asyncio

async def send_offboard_setpoint():
    drone = System()
    await drone.connect(system_address="udp://:14540")
    
    # 先获取位置信息，确保飞控已就绪
    async for position in drone.telemetry.position():
        break
    
    # 切换到Offboard模式
    await drone.offboard.set_position_ned(
        PositionNedYaw(0.0, 0.0, -5.0, 0.0)
    )
    await drone.offboard.start()
    
    # 持续发送速度指令
    while True:
        await drone.offboard.set_velocity_ned(
            VelocityNedYaw(2.0, 0.0, 0.0, 0.0)
        )
        await asyncio.sleep(0.1)

3.3 ROS2通信链路：现代与灵活

随着PX4对ROS2的原生支持日趋完善，基于DDS（Data Distribution Service）的通信方式正在成为复杂机器人系统的首选。PX4通过 px4_ros_com 和 microRTPS 桥接，将内部uORB消息映射为ROS2话题，使得机载计算机可以直接订阅飞控的传感器数据，并发布控制指令。ROS2的QoS策略允许开发者针对不同数据类型设置不同的可靠性（Reliable/Best Effort）与历史深度（Keep Last/Keep All），这在多传感器融合场景中尤为重要。

ROS2架构的核心优势在于生态整合能力。当AI识别结果需要与SLAM、运动规划、机械臂控制等其他ROS2节点协同工作时，统一的消息接口大幅降低了系统集成复杂度。例如，视觉目标检测节点发布 vision_msgs/Detection2DArray，规划节点订阅后生成目标位置，再通过 px4_ros_com 转换为Offboard指令。这种松耦合设计使得每个模块都可以独立开发、测试与替换。

3.4 数据流全景与延迟预算

一个典型的AI识别驱动Offboard控制数据流包含以下环节：传感器采集 → 飞控状态估计 → 遥测上传 → 机载计算机感知 → AI推理 → 决策规划 → 指令下发 → 飞控指令解析 → 控制器跟踪 → 执行器输出。每个环节都会引入延迟，而总延迟必须满足控制系统的实时性要求。

以视觉目标跟踪为例，假设飞控内部状态估计延迟为5ms，MAVLink遥测上传延迟为10ms，AI推理耗时30ms，规划计算5ms，指令下发延迟10ms，飞控指令解析与控制器更新5ms，则总延迟约为65ms。对于悬停或低速跟踪场景，这个延迟可以接受；但对于高速机动或近距离避障，延迟需要压缩到30ms以内。此时应考虑：将AI推理放到更靠近传感器的边缘设备、使用共享内存通信、或者将部分感知任务（如光流）下沉到飞控内部。

3.5 实战案例：基于视觉识别的目标跟踪系统

我们设计一个无人机视觉跟踪系统，要求无人机锁定并跟踪地面移动的红色小球。系统硬件为：Pixhawk 6C飞控（PX4 1.14）、NVIDIA Jetson Orin Nano机载计算机、RGB摄像头（30fps，640×480分辨率）、数传模块（915MHz，115200bps）。

初始现象与目标：系统启动后，机载计算机能够识别小球并输出像素坐标，但无人机无法稳定跟踪，出现明显的滞后和振荡。通过日志分析发现，从摄像头采集到Offboard指令生效的总延迟高达120ms，远超预期。

关键参数与日志分析：使用 ros2 topic hz 检查各话题频率，发现 /camera/image_raw 为30Hz，/detection_result 为15Hz（AI推理耗时约66ms），/px4_ros_com/offboard_velocity 为20Hz。进一步使用 ros2 topic delay 测量，发现从图像发布到检测结果输出的延迟为70ms，从检测结果到Offboard指令发布的延迟为15ms，加上MAVLink传输和飞控内部处理，总延迟超过100ms。

分析判断过程：瓶颈在于AI推理速度过慢（66ms），且图像分辨率过高导致传输延迟。此外，MAVLink链路使用115200bps串口，实际有效带宽仅约10KB/s，传输30Hz的遥测数据已经接近饱和。

实际操作步骤：

1. 将摄像头分辨率降至320×240，帧率保持30Hz，图像传输延迟降低40%。
2. 使用TensorRT对YOLOv5s模型进行FP16量化，推理时间从66ms降至22ms。
3. 将MAVLink遥测频率从30Hz降至10Hz，仅上传位置和姿态关键数据。
4. 在机载计算机上使用共享内存（Shared Memory）替代ROS2话题传输图像，减少序列化开销。
5. 调整PX4 Offboard参数：COM_OF_LOSS_T 设为0.5s，MC_VEL_P 的P增益从2.5提高至3.2，增加前馈项。

结果对比：优化后总延迟降至45ms，无人机跟踪误差从±1.2m缩小至±0.3m，振荡现象消失。在目标快速转弯时，系统仍能保持稳定跟踪。

风险与代价：降低遥测频率会削弱地面站的监控能力；模型量化可能降低小目标检测精度；提高P增益在强风环境下可能引发振荡。因此，实际部署时需要根据任务场景权衡。

3.6 总结与架构设计要点

PX4 Offboard控制架构的本质是“实时内核+智能外脑”的协同。飞控提供确定性的底层控制与安全兜底，机载计算机提供灵活的感知与决策能力。在设计系统时，应遵循以下原则：

• 安全边界清晰：所有安全关键逻辑（如避障急停、电量不足降落）必须放在飞控内部或通过飞控可执行的指令实现，不能依赖机载计算机的软件判断。
• 通信冗余设计：同时保留MAVLink和ROS2通道，当ROS2链路异常时，可通过MAVLink发送紧急降落指令。
• 延迟预算管理：在项目初期就明确端到端延迟预算，并分配到每个模块，避免后期集成时才发现性能瓶颈。
• 数据流可视化：使用 ros2 graph 或MAVLink Inspector工具实时监控数据流，便于快速定位故障节点。