1. 飞控状态机与飞行模式管理导论
在无人机、eVTOL、固定翼自驾仪等飞行控制系统中，"飞控状态机"并不是一个可有可无的软件装饰，而是决定飞行器"此刻是谁、能做什么、下一步允许变成谁"的核心骨架。飞行模式管理则是这套骨架在用户与飞控之间的可见接口：操作手拨动遥控器开关、地面站下发指令、任务脚本触发条件，最终都要落到状态机的迁移判断上。本课程的目标，是让读者从"知道有几种飞行模式"进阶到"能设计、实现、调试并验证一套可用的飞控状态机与模式管理逻辑"。
一、核心概念：状态、事件、迁移与动作
状态机（Finite State Machine, FSM）由四个基本要素构成：状态（State）、事件（Event）、迁移（Transition）和动作（Action）。在飞控语境下，它们有非常具体的对应物：
- 状态：如 DISARMED（未解锁）、STABILIZE（自稳）、ALT_HOLD（定高）、AUTO（自动任务）、RTL（返航）、LAND（降落）、FAILSAFE（失控保护）。每个状态代表一组被允许的控制律、传感器融合策略与输出限制。
- 事件：遥控器通道跳变、解锁开关动作、GPS 定位质量变化、电池电压越限、链路丢失、任务航点到达、内部定时器超时。
- 迁移：在"当前状态 + 事件 + 守卫条件（Guard）"三者同时满足时，从源状态切换到目标状态。守卫条件是迁移能否发生的布尔判断，例如"GPS fix_type ≥ 3 且卫星数 ≥ 8 才允许进入 AUTO"。
- 动作：迁移发生时或状态驻留期间执行的操作，如切换控制律、重置积分项、记录日志、点亮 LED、发送状态消息。
需要特别强调的是：状态不是变量，而是离散的、互斥的运行模式。飞控在同一时刻只能处于一个主状态，但可以同时维护多个正交的子状态（如"是否已解锁""是否在返航中""是否处于地理围栏内"）。把主状态与子状态混为一谈，是初学者最常见的建模错误。
二、状态机在飞控中的角色
飞控软件通常分为感知、估计、控制、执行四层，状态机横跨控制与执行之间，扮演三个角色：
- 仲裁者：决定当前由哪一套控制律接管输出。例如手动模式下姿态环直接响应遥控杆量，AUTO 模式下则由航线跟踪器生成姿态目标。
- 安全守门人：任何迁移都必须经过守卫条件检查。解锁前必须确认传感器校准完成、电池电压正常、遥控器已连接；否则拒绝迁移并给出明确拒绝原因。
- 可观测性载体：状态机的当前状态、上次迁移时间、迁移原因，是地面站、日志分析和事故复盘的第一手依据。一个设计良好的状态机，应当能回答"为什么此刻处于这个状态"。
三、飞行模式管理的基本问题
模式管理要解决的核心问题可以归纳为四类：
- 优先级冲突：遥控器请求切换到 LOITER，但此时电池已触发低电量保护，谁优先？通常安全类事件（FAILSAFE、低电量、地理围栏）优先级高于用户指令。
- 迁移合法性：从 DISARMED 直接跳到 AUTO 是否允许？多数飞控要求必须先 ARM，再进入 AUTO，避免未解锁状态下执行任务。
- 状态一致性：迁移过程中若事件连续到达（如开关抖动），需要去抖或锁存，防止状态在毫秒级反复跳变。
- 可恢复性：进入 FAILSAFE 后，当链路恢复，是自动回到原状态，还是停留在 FAILSAFE 等待人工确认？这属于设计决策，必须在需求阶段明确。
四、整体学习路径
本课程后续章节将沿着"建模—实现—验证—排障"的主线展开。建模阶段关注状态划分、迁移表与守卫条件；实现阶段关注代码结构、事件队列与去抖；验证阶段关注状态覆盖测试与迁移路径测试；排障阶段关注日志中状态跳变序列的解读。下图给出本节知识点的整体关系：左侧是状态机四要素，中间是飞控中的三类角色，右侧是模式管理要处理的四类问题，三者共同构成后续学习的地图。
从这张地图出发，后续每一章都会落到具体对象上：如何写出可读的迁移表，如何用 C++ 或 Python 实现事件队列，如何用日志验证一次 RTL 迁移是否按预期发生。本节只需要建立两个基本认识：第一，状态机是飞控行为的骨架，不是附属功能；第二，模式管理的难点不在"有哪些模式"，而在"何时允许切换、谁说了算、切换后如何被观察和验证"。