4. 机载计算平台
在PX4机载神经网络控制实验中，飞控本身负责姿态稳定与底层执行器输出，而神经网络推理通常运行在独立的机载计算平台上。选型的核心不是“算力越大越好”，而是要在算力、功耗、重量、实时性、接口兼容性之间取得平衡。本节围绕树莓派、Jetson、STM32H7三类典型平台，说明它们的定位差异、性能约束与实时性要求。
一、核心原理：三层计算分工
机载神经网络控制系统通常分为三层：感知与推理层、控制与决策层、执行与稳定层。树莓派和Jetson属于感知与推理层，负责摄像头图像处理、神经网络前向推理、目标检测或端到端策略输出；STM32H7既可以作为独立的高性能MCU运行轻量网络，也可以作为飞控与机载计算机之间的协处理器，承担传感器采集、PWM输出和通信转发。
关键约束在于：神经网络推理是非确定性延迟任务，而飞行控制是硬实时任务。两者不能混在同一时间关键路径上。正确做法是让PX4保持固定周期控制，机载计算机以较低频率输出高层指令（如速度、位置或姿态修正量），通过MAVLink或UART/CAN发送给飞控，由飞控完成最终混控与电机输出。
二、三类平台选型对比
树莓派、Jetson、STM32H7并非互相替代，而是面向不同任务粒度。树莓派适合低成本、低功耗的图像采集与轻量推理；Jetson适合高吞吐GPU推理，如YOLO、语义分割、端到端网络；STM32H7适合确定性控制、传感器融合和轻量TinyML。选型时先明确网络模型规模、输入分辨率、推理频率和功耗预算，再匹配平台。
| 平台 | 典型算力 | 功耗 | 实时性 | 适用场景 |
|---|---|---|---|---|
| 树莓派 4B/5 | CPU 1.5–2.4 GHz，无独立GPU | 3–8 W | Linux 非实时，抖动大 | 图像采集、轻量分类、MAVLink桥接 |
| Jetson Orin Nano/NX | 20–100 TOPS GPU | 7–25 W | Linux + CUDA，需实时补丁 | YOLO检测、语义分割、端到端策略 |
| STM32H743/H750 | 480 MHz Cortex-M7，无GPU | 0.3–1 W | 裸机/RTOS 硬实时 | 传感器融合、TinyML、PWM输出 |
三、性能约束与实时性要求
机载平台的第一约束是功耗与重量。多旋翼每增加100 g负载，续航和机动性都会明显下降。Jetson Orin NX加散热片约100 g，树莓派约50 g，STM32H7核心板仅10 g左右。第二约束是散热，Jetson在高负载下需要主动风冷，否则会降频。第三约束是供电，Jetson峰值电流可达5 A，必须使用独立BEC，不能与飞控共用5 V。
实时性方面，Linux平台默认调度器无法保证微秒级确定性。若必须使用树莓派或Jetson，应配置PREEMPT_RT内核、CPU隔离和实时优先级。更稳妥的方案是让机载计算机只输出高层指令，飞控以固定周期运行，并在通信中断时自动切换至手动或悬停模式。
# 检查Jetson实时内核与CPU隔离
uname -a
cat /proc/cmdline | grep isolcpus
# 设置推理进程实时优先级
sudo chrt -f 80 ./neural_infer
# PX4侧MAVLink超时保护参数
COM_DL_LOSS_T = 5
COM_RC_LOSS_T = 1
四、案例与复盘：Jetson + PX4 视觉跟踪
某实验采用Jetson Orin Nano运行YOLOv8n，输入640×480，推理耗时约18 ms，输出目标框中心偏差。Jetson通过UART以50 Hz向PX4发送SET_POSITION_TARGET_LOCAL_NED速度指令，PX4以400 Hz运行位置与姿态控制。飞行中发现两个问题：一是Jetson散热不足导致推理延迟升至35 ms，二是UART丢包造成指令断续。
复盘措施：增加主动散热，将推理频率降至30 Hz并启用TensorRT加速；在PX4侧设置COM_DL_LOSS_T=3，超时后自动切换至位置保持；同时将Jetson进程绑定至独立CPU核心，减少调度抖动。调整后跟踪误差从0.8 m降至0.3 m，飞行稳定性明显提升。
综上，机载计算平台选型的本质是任务匹配：算力要够用，功耗要可承受，实时性要可保证，接口要兼容。只有把推理延迟与控制周期解耦，并在通信、散热、供电和安全兜底上做好设计，神经网络控制才能稳定飞起来。