116、飞控中的状态机设计模式

飞控中的状态机设计模式

从一次炸机事故说起

去年夏天，我在调试一架四轴飞行器的自主降落功能。代码跑了两百多次仿真都没问题，结果真机测试时，飞机在离地30厘米处突然“抽风”——电机转速剧烈波动，机身像触电一样抖动，然后侧翻炸机。事后分析日志，发现是降落检测状态和悬停状态之间的切换逻辑出了bug：传感器噪声导致高度估计短暂跳变，状态机在“降落中”和“悬停”之间来回切换，每次切换都会重置积分项，最终导致控制输出震荡。

那次之后我彻底明白：飞控这种实时性要求极高、状态耦合复杂的系统，状态机设计不是“写几个case语句”那么简单。今天聊聊我在飞控开发中积累的状态机设计经验，全是踩坑换来的。

状态机不是if-else的升级版

很多初学者把状态机理解成“用switch-case代替if-else”，这是大错特错。飞控里的状态机本质是有限状态自动机，核心在于三个要素：状态、事件、转移条件。但实际工程中，我们往往还要考虑状态进入时的初始化、退出时的清理、以及状态内部的持续行为。

以最常见的飞控状态机为例，至少包含：初始化、待解锁、解锁、悬停、飞行、降落、紧急停止等状态。每个状态都有明确的进入动作和退出动作。比如进入“解锁”状态时，要执行电调校准、检查传感器偏置；退出时，要保存当前姿态估计的协方差矩阵。

这里踩过坑：我早期设计时，把状态转移条件直接写在主循环里，结果状态切换的瞬间，传感器数据还没更新，导致进入新状态时读到的是上一帧的旧数据。后来改成在状态切换时强制进行一次传感器数据同步，问题才解决。