搞飞控的人，一开始大多对“神经网络控制”这东西是既向往又戒备的。向往的是它那种不依赖精确建模、直接数据驱动出策略的能力；戒备的是，网上十个讲神经网络飞控的教程，九个跑完Python仿真就没了下文，剩下那一个也没有真正把模型塞进飞控芯片里跑起来——而“从仿真到嵌入式部署”恰恰才是这个领域最扎心的那段路。去年我带着同样的疑问，在PX4的SITL仿真里把一个不到7000参数的小神经网络接进了控制链路，让它替代姿态环上层的部分映射，接着又把它压成定点模型，部署到STM32级别的芯片上集成回PX4固件。整个过程踩了不少坑，也把“PX4飞控神经网络控制”这条链路彻底跑通了。这篇就按我实际踩坑的顺序，把从仿真环境搭建、神经网络控制器设计与训练，到嵌入式部署和稳定性调参的完整过程记录下来，给正在搞PX4二次开发或准备把算法往飞控上落的工程师做个参考。
1. 为什么非要把神经网络塞进飞控：传统控制环路的边界在哪
1.1 串级PID确实够用，但够用的前提太苛刻了
PX4多旋翼的底层控制，往简单了说就是一条“位置—速度—姿态—角速度”串级链路。外环位置误差经过P控制器生成速度设定值，速度环再生成期望加速度，加速度分解成期望姿态角，姿态环和内环角速度环用PID去跟踪这些设定值。这套东西经过十几年工程打磨，在线性工作区间内的表现其实很稳，而且参数整定方法成熟，很多人拿默认参数微调就能飞。
但它的前提是：模型参数基本保持不变，工作点在线性区间附近，耦合被当成扰动处理。四旋翼一旦进入大机动、强风扰、重心偏移、负载变化这类场景，串级PID的调试成本会快速上升——因为不同的缺陷会混叠在一起，你很难分清是位置环增益不够，还是角速度环阻尼过大。
1.2 神经网络在这条链路里能做哪几件事
神经网络控制并不是什么玄学，它在这个场景里能落地的位置大致有三类。
第一类是端到端控制，输入状态量甚至图像，直接输出控制量。这种炫酷但对训练数据和仿真逼真度要求极高，而且很难保证安全性，我建议新手不要一上来就挑战它。
第二类是残差补偿，也是我这次采用的思路。底层保留PID和混控器不动，神经网络只负责补偿模型误差或做一些前馈映射，比如把期望加速度和当前状态映射成更平滑的姿态设定值和油门补偿量。这样NN出问题的时候，底层PID还能兜底。
第三类是策略映射，比如学习从感知信息到控制指令之间的非线性关系，替代传统导航层。这类任务在仿真里验证起来很直观，也方便做数据采集。
1.3 为什么选PX4而不自己从零写
选PX4做载体有几个现实原因。它开源程度高，控制链路完全透明，你可以从uORB消息层面干净地截断或插入自己的算法，不需要改底层驱动；PX4的SITL仿真链路非常成熟，Gazebo里跑起来之后，你可以低成本采集训练数据、验证神经网络的效果；再加上PX4的模块化设计，像“px4_create_module”这类工具可以直接生成自定义模块骨架，集成的工程量比想象中小很多。
当然，PX4的代码更新很快，接口版本变动也频繁，这算是它最大的缺点——但只要你锁定一个固件版本，把官方文档当成“字典工具”而不是“教程”，这套方法论是可复现的。
2. 先跑通仿真链路：PX4 + Gazebo 的搭建与端口迷思
2.1 版本搭配：不要把全家桶都升到最新
很多人一上来就“px4开发环境搭建”，结果被一堆版本冲突搞到怀疑人生。我建议的搭配是：Ubuntu 22.04 + PX4 v1.14.3 + Gazebo Classic 11 + QGroundControl 4.x。PX4在v1.14之后主推Gazebo，Ignition的迁移还不太稳定，没必要当小白鼠。
官方推荐的“无脑安装脚本”其实是：
git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot git checkout v1.14.3 git submodule update --init --recursive bash ./Tools/setup/ubuntu.sh依赖装完以后，编译SITL版本：
make px4_sitl gazebo-classic这一步会自动编译固件、启动Gazebo、加载四旋翼模型。编译时间大约20到40分钟，取决于CPU。
2.2 “模拟器怎么连接”这个经典问题，几乎全是端口没对上
网上搜“ubuntu px4模拟器怎么连接”能搜出一堆帖子，其实核心就是端口分配。PX4 SITL默认的网络端口关系如下表：
| 通信方向 | 端口 |
|---|---|
| PX4 -> QGroundControl | UDP 14550 |
| PX4 -> MAVROS / MAVSDK | UDP 14557 |
| MAVROS -> PX4 | UDP 14540 |
| PX4 -> Gazebo仿真器 | UDP 14560 |
QGroundControl如果没自动发现仿真，手动添加“UDP 14550”通信链路即可。用MAVROS连接时，命令是：
roslaunch mavros px4.launch fcu_url:="udp://:14540@127.0.0.1:14557"踩坑提示：如果你本地装过MAVProxy或其他飞控工具，它可能会抢先占用14550端口，导致QGC只显示一条灰色连接。这种情况先杀掉占用端口的进程，再重新启动仿真就行。
2.3 仿真发散的排查链路
“仿真发散”是我在群里被问得最多的问题，也是让很多人从零开始到放弃的最快路径。现象一般是：Gazebo里的飞机起飞后疯狂翻滚，或者飞机在缓慢漂移中开始“抽搐”，最后直接飞到天边。排查链路我整理过很多次，最有效的顺序是：
- 先看PX4日志（Flight Review导出）里roll/pitch角速度有没有爆表。如果爆表，说明是控制器或混控问题。
- 检查控制增益是否异常。PX4仿真的默认参数在真机上可用，但如果你改过MC_ROLL_P、MC_PITCHRATE_P等参数后忘了还原，很容易发散。
- 检查模型文件（sdf）里的质量、惯性张量是否和默认机型差距过大。很多人把载重加到模型上，却没同步改PID，导致内环振荡。
- 检查仿真更新频率。Gazebo如果跑在低性能机器上，物理更新步长不稳定，飞控的400Hz姿态环和仿真的物理步长如果错配，发散几乎是必然的。
其中第3条最隐蔽，因为飞控日志里看起来像“参数没调好”，实际是物理模型改了但控制参数没跟上。这类问题不是神经网络控制特有的，但会直接干扰后续训练数据的质量，必须先处理干净。
2.4 训练数据采集前的仿真环境“体检”
在正式采集数据之前，我建议做一次仿真环境体检：用PX4自带的位置控制器，让飞机自动起飞并飞行一段预设航线，然后从Flight Review里看位置跟踪误差、姿态角跟踪误差是否在合理范围内。如果纯PID都飞不稳，后面采的数据也是“脏”的——神经网络会把控制器的缺陷也一并学进去。
3. 设计一个能被飞控吃进去的神经网络控制器
3.1 输入输出设计：尽量输出“设定值”而不是“PWM”
神经网络控制器要接进PX4，首先要决定它的边界在哪。我这次选的位置是：让神经网络输出姿态设定值和油门，替代传统位置环中“加速度→姿态映射”这一段。这样底层的姿态环、角速度环和混控器全部保留，既保证了安全性，也让模型训练时不需要考虑电机混控的细节。
输入向量我用了12维：
- 期望加速度：a_x，a_y，a_z（来自轨迹规划或位置环）
- 期望速度：v_x，v_y（来自前馈速度环）
- 当前姿态：roll， pitch（来自vehicle_attitude）
- 当前角速度：p，q，r
- 当前期望航向角速度：yaw_rate_sp
输出是4维：roll设定值、pitch设定值、yaw_rate设定值、油门百分比。
这里有一个很重要的原则：任何神经网络都不能直接输出PWM或电机转速，因为不同机型的电机特性和混控矩阵完全不同，直接学PWM等于把机型的个性也学进去了，换个机架就废。输出“设定值”是最稳妥的中间表示，也是PX4这类飞控生态最自然接纳的信息形态。
3.2 训练数据：最稳的路线是让PID当“老师”
端到端神经网络控制最难的不是模型结构，而是数据从哪来。实飞采集风险高、成本大；纯仿真数据又怕分布偏移。我用的最保守的办法是模仿学习：先用PX4自带的PID控制器在Gazebo里飞出一批高质量轨迹，记录输入状态和对应的控制输出，把PID的控制策略当成“老师”，训练神经网络去拟合它的行为。
采集数据用SDLog就行，在QGC里把日志导出，提取uORB消息字段：trajectory_setpoint、vehicle_local_position、vehicle_attitude、vehicle_attitude_setpoint。四个消息分别对应输入状态和输出标签。建议采集至少20分钟的不同轨迹数据，包括悬停、匀速直线、S形转弯、避障绕飞，数据越多样，后面模型泛化越好。
有条件的话，还可以在状态量上叠加高斯噪声做数据增强，模拟传感器噪声。这一招对后面真机部署的帮助很大，因为仿真里传感器的“过于干净”是真实世界最大的陷阱。
3.3 网络结构：真的不需要很深
很多人想到神经网络就自动往ResNet、Transformer方向走，但在飞控这种实时性极高的嵌入式场景里，这完全是过设计。我这次用的就是一个两隐藏层的MLP，结构是12 → 64 → 64 → 4，激活函数用tanh。
为什么用tanh不用ReLU？因为控制输出需要平滑且有界。ReLU虽然训练方便，但输出会出现硬截断，生成的姿态设定值不会平滑过渡，飞控上很容易引起高频振荡。参数量大概6500个左右，float32权重只有26KB，int8量化后7KB——这个体量对STM32F4系列来说几乎可以忽略。
训练的时候用PyTorch或TensorFlow都行，关键是输入标准化。计算训练集的均值和标准差，把输入变换到0均值、单位方差的范围再训练，推理时在C代码里同样做标准化。这一步如果漏了，模型在飞控上基本是废的，因为数值范围完全不在训练区间。
3.4 损失函数设计：控制量平滑比跟踪精度更重要
神经网络的损失函数如果只看输出误差，训练完的模型大概率在飞控上用不了。原因很简单：飞机是一个动力学系统，控制量微小的高频抖动，经过动力学积分后会变成肉眼可见的机体振荡。
我的损失函数是三项加权：
- 输出误差项：NN输出与标签（PID输出）的MSE，保证跟踪效果。
- 输出平滑项：相邻时间步输出差值的L2范数，抑制抖动。
- 边界惩罚项：输出超过预设物理范围时给一个大的惩罚项，防止网络输出非物理量。
三个权重分别是1.0、0.2、0.2，实测下来效果不错。训练完成后，先用预留的验证轨迹做开环测试——也就是把仿真日志里的输入回放给网络，看它的输出和标签的匹配程度，确认平滑性和范围，再进入闭环测试。
4. 部署前奏：嵌入式平台上的模型瘦身与定点化
4.1 目标平台：别一上来就想着上CPU板
常见的Pixhawk系列飞控，主控通常是STM32F427（180MHz，256KB RAM）或STM32F765（216MHz，512KB RAM）。这个算力跑一个6500参数的MLP完全可行——每次推理大约5000次乘加，在最坏情况下1ms以内算完。真正需要操心的是内存和数值精度。
如果你要跑的模型参数量超过几百万，那MCU就不合适了，建议考虑协处理器方案，比如在STM32旁边挂一个K210、ESP32-S3或者树莓派Zero，通过UART或CAN和主控通信。但我的建议是：先把模型缩小到MCU能跑的范围，整个系统复杂度会低一个量级，飞控稳定性会好很多。
4.2 纯C部署还是TFLite Micro
TFLite Micro在STM32上勉强能跑，但解释器本身占用几十KB到上百KB内存，激活缓冲区还得另算。对于6500参数这种量级的小模型，手写矩阵乘反而更可控，没有任何运行时依赖，编译出来干净利落，内存占用精确到字节级。
我的做法是：用训练脚本导出权重为C数组，然后手写一个C推理函数。核心代码大致长这样：
// 权重导出示例 const float nn_w1[12 * 64] = { ... }; const float nn_b1[64] = { ... }; const float nn_w2[64 * 64] = { ... }; const float nn_b2[64] = { ... }; const float nn_w3[64 * 4] = { ... }; const float nn_b3[4] = { ... }; void nn_forward(const float *x, float *out) { float h1[64], h2[64]; // 第一层 for (int i = 0; i < 64; i++) { h1[i] = nn_b1[i]; for (int j = 0; j < 12; j++) { h1[i] += x[j] * nn_w1[j * 64 + i]; } h1[i] = tanhf(h1[i]); } // 第二层 for (int i = 0; i < 64; i++) { h2[i] = nn_b2[i]; for (int j = 0; j < 64; j++) { h2[i] += h1[j] * nn_w2[j * 64 + i]; } h2[i] = tanhf(h2[i]); } // 输出层 for (int i = 0; i < 4; i++) { out[i] = nn_b3[i]; for (int j = 0; j < 64; j++) { out[i] += h2[j] * nn_w3[j * 4 + i]; } } }如果你嫌纯C手写麻烦，可以用nnom这类为MCU设计的神经网络推理库，也可以直接用CMSIS-DSP的arm_mat_mult_f32代替手写矩阵乘。实测在STM32F427上，手写循环用-O2优化后，推理一次大约0.3ms，完全满足400Hz控制频率的需求。
4.3 定点量化：float32够用，但int8更稳
网络部署到飞控上，最怕的是浮点运算时序抖动。STM32F4有FPU，float32运算本身没问题，但如果你同时跑多个任务，浮点运算是会增加上下文切换压力的。另一种更彻底的做法是量化成int8定点。6500参数量的模型量化误差非常小，对控制精度的影响往往在噪声范围内。
int8量化的关键是确定每个tensor的缩放因子（scale）和零点（zero point）。计算公式是：
- scale = (max_true - min_true) / 255
- zero_point = round(-min_true / scale)
推理时每一步都是“反量化到float再算”的变体，或者用纯整数乘加。但说实话，在STM32F427这种带FPU的芯片上，float32直接跑就够稳，int8更多是为低端MCU或省电场景准备的。如果你要把模型部署到F103这种不带FPU的芯片上，再考虑定点化。
4.4 一个常被忽略的坑：tanh查找表
tanhf()在STM32上虽然能算，但速度不算快，而且由于库函数实现原因可能导致时序抖动。我的做法是把它做成256点的查找表，运行时线性插值。误差在1e-3量级，对控制量来说完全够用，速度能快将近10倍。很多人部署时死在激活函数上，这是非常容易被忽略的细节。
5. 深度集成到PX4：uORB消息、自定义任务模块与安全切换
5.1 先搞懂你要插入的控制流位置
PX4的控制流是这样的：外环位置控制器（mc_pos_control）订阅轨迹设定值，输出期望姿态和油门，发布到vehicle_attitude_setpoint；内环姿态控制器（mc_att_control）订阅这个设定值和当前姿态，计算力矩，发布到vehicle_torque_setpoint和vehicle_thrust_setpoint；混控器再根据这些值分配电机PWM。
我们插入的位置是：让神经网络读取外环的输入状态，自己计算vehicle_attitude_setpoint然后发布出去。这样姿态控制器、混控器完全不动，风险面控制到了最小。
5.2 自定义模块的骨架：px4_create_module帮你省一半时间
PX4提供了一个模块生成脚本，在固件目录下运行：
make px4_create_module输入模块名nn_control，它会自动在src/modules/nn_control下生成模块骨架，包括CMakeLists.txt和主程序框架。之后要做的主要是三件事：
- 在
module.json里声明依赖库。 - 在CMakeLists.txt里添加编译选项和链接库。
- 在任务主循环里写uORB订阅、发布和神经网络推理逻辑。
5.3 核心消息的订阅与发布
我使用的关键uORB消息如下：
| 方向 | 消息名 | 作用 |
|---|---|---|
| 订阅 | vehicle_attitude | 当前姿态四元数和角速度 |
| 订阅 | vehicle_local_position | 当前位置、速度 |
| 订阅 | trajectory_setpoint | 轨迹规划器的期望位置/速度/加速度 |
| 发布 | vehicle_attitude_setpoint | 覆盖给内环的期望姿态和油门 |
主循环的伪代码逻辑是：
while (!should_exit()) { // 轮询最新数据 if (vehicle_attitude_sub.updated()) { vehicle_attitude_sub.update(&att); vehicle_local_position_sub.update(&lpos); trajectory_setpoint_sub.update(&traj_sp); // 构造NN输入 float nn_in[12]; nn_in[0] = traj_sp.acceleration[0]; // ax 期望 nn_in[1] = traj_sp.acceleration[1]; // ay 期望 // ... 填充其余状态量 // 推理 float nn_out[4]; nn_forward(nn_in, nn_out); // 发布姿态设定值 vehicle_attitude_setpoint_s att_sp{}; att_sp.roll_body = nn_out[0]; att_sp.pitch_body = nn_out[1]; att_sp.yaw_body = yaw_sp_from_nav; // 航向用外部设定 att_sp.thrust_body[2] = nn_out[3]; // 油门映射到Z轴推力 att_sp.timestamp = hrt_absolute_time(); att_sp_pub.publish(att_sp); } // 400Hz运行 px4_usleep(2500); }需要注意PX4版本差异：v1.13之前的版本用actuator_controls，v1.13之后改成了vehicle_torque_setpoint和vehicle_thrust_setpoint。你用的固件版本决定消息结构体字段，统一以该版本的头文件为准。
5.4 参数开关与安全备份：发生意外要能一键退回
直接让NN接管姿态设定值，风险不小。我给这个模块设计了一个三位参数NN_CTL_MODE：0表示关闭（完全用原始PID），1表示开环测试（NN推理但不发布，只记录日志），2表示闭环启用（NN发布的设定值生效）。先用1验证推理时间和日志输出，再切到2，能大幅降低试错成本。
其次是看门狗机制。NN模块每次发布前更新一个时间戳，另一个监控线程——或者直接在主姿态控制器里——检查这个时间戳是否在50ms内更新过。如果超时，说明NN任务卡死或退出，立即把控制权交还给原始PID通道。我在PX4里实现这一步用的是现有vehicle_command接口，接到MAV_CMD_DO_FLIGHTTERMINATION或自定义命令时触发模式回退，也可以在任务退出时由should_exit()分支主动发布一个回退命令。
5.5 混控器适配：不是所有机架都适合默认参数
PX4默认混控器是四旋翼的quad_x.main.mix，如果你用的机架不是标准X型，或者电机布局有特殊角度，需要重新生成混控器文件。这一步和神经网络本身关系不大，但很多人在部署完NN后遇到“飞控输出怪异”的问题，最后查出是混控器文件没换。原因很简单，NN输出的姿态设定值需要混控器正确分配才能变成电机转速，混控器错了后面全是白搭。
6. 从仿真到真机：稳定性问题排查与调参经验
6.1 抖动问题：从头到尾排查信号链
真机上的第一个常见问题是高频抖动，飞起来像“筛糠”。这种现象的核心原因是神经网络把输入的噪声放大了。在仿真里传感器数据干净，你不会察觉；真机上IMU噪声、振动、气压计毛刺全部灌进网络输入，经过两层非线性变换，噪声被扁平滑地放大到输出端。
解决思路分三层：
- 输入端加低通滤波。对
vehicle_attitude的角速度做一阶低通，截止频率设在15Hz左右。 - 输出端加滑动平均或限幅。我用了20ms滑动窗口，让NN输出变化率不超过每周期最大变化量，防止突变。
- 训练阶段加噪声数据增强，让网络学会忽略输入噪声。
这三层一起上之后，抖动量下降了大概一个数量级。
6.2 切换瞬间的突变问题：需要软着陆
NN闭环和原始PID切换时，如果两个控制器输出的设定值差异很大，飞机会突然“顿一下”，严重时直接翻。这个问题我在SITL里试了几次没注意，真机上第一次切的时候就差点炸。
解决方法是线性插值过渡：切换命令生效后的100ms内，实际生效的姿态设定值从旧控制器的输出线性过渡到NN的输出。用代码表示就是：
float blend = (t - t_switch) / 0.1f; if (blend > 1.0f) blend = 1.0f; roll_effective = roll_pid * (1.0f - blend) + roll_nn * blend;这100ms的缓冲区让飞控有足够时间适应新的控制策略，不会产生阶跃响应。
6.3 仿真稳真机飘：sim2real gap的根本来源
在Gazebo里飞得挺好，真机上却飘得厉害，这是所有从仿真到现实都会遇到的问题。我总结下来最主要的原因是电机延迟差异。仿真里电机响应几乎是瞬时的，真机上电调和电机本身有几十毫秒的延迟，而神经网络的推理周期是2.5ms，它输出的是高频控制量，遇到电机延迟会产生相位滞后。
缓解办法有两个方向：一是在仿真环境里给电机模型加延迟，让训练环境更接近真实；二是给NN的输出加预测补偿，也就是把电机延迟建模成一阶惯性环节，在控制量上做一个前馈补偿。第二种方法虽然简单，但实际效果很明显，航向通道尤其明显。
6.4 电压波动与油门漂移：推力归一化是个好习惯
电池从满电4.2V到没电3.6V，同样的油门百分比对应的拉力差别很大。神经网络是从仿真数据里学出来的，仿真里电池电压是恒定不变的，真机上一旦电压下跌，NN给出同样的油门，实际推力却不够，飞机会慢慢下沉。
解决办法是先把推力做归一化。飞控里的vehicle_attitude_setpoint.thrust_body本身就是归一化值，1.0对应最大推力，因此要保证训练数据里的推力标签也是归一化后的。同时，在NN的输出端对油门做一个下限保护，避免低电压下系统自动追加油门导致的振荡。
6.5 调试工具组合：日志比肉眼管用
飞控调试不能靠肉眼在QGC里看3D画面，太滞后了。我的标准做法是：开环模式下记录NN输出和标准PID输出的差值，在Flight Review或Jupyter里画出来，对比趋势是否一致。只有两条曲线趋势接近、噪声量级可接受时，才允许切入闭环。
有一个很实用的技巧：把NN的部分中间层输出（比如第一层隐藏层的激活值均值）通过MAVLink的DEBUG_VECT通道发到QGC的MAVLink Inspector里实时监控。如果中间层输出出现明显的饱和或突变，说明输入状态已经跑出训练分布了，这时候要及时切回PID，而不是指望网络自己“纠正回来”。
6.6 真机首次飞行的安全纪律
最后聊几个保命的习惯。首次真机测试时，把NN的输出限幅设为标准PID输出的50%——限制滚转、俯仰设定值的上限，这样即使NN完全错乱，飞机也只是反应迟钝，而不会瞬间翻转。测试场地必须空旷，周围用安全绳固定机架或者绑在测试台上先做解锁测试，确认所有控制输出正常后再松绑。
我个人强烈建议：不要在第一天就挑战端到端神经网络全权接管飞控，那不是进阶，那是给自己挖坑。先用残差补偿或设定值映射这种小步快跑的方式跑通链路，积累部署经验，再逐步扩大NN的权限范围。任何情况下，“底层PID兜底 + 上层NN增强”的架构都比“全权交给NN”稳得多，这也是目前嵌入式神经网络控制从实验室走向真机最现实的一条路径。
