1. 课程导入
在无人机飞控开发中，真正决定系统能否稳定飞行的，往往不是姿态控制算法本身，而是驱动层与仿真验证链路是否可靠。当飞控需要接入自定义传感器、执行机构或通信模块时，驱动代码必须先在 SITL（Software In The Loop，软件在环）中完成逻辑验证，再通过 HIL（Hardware In The Loop，硬件在环）验证真实硬件与飞控固件的协同行为。本课程围绕这一完整链路展开，帮助学习者建立从驱动编写到仿真验证的系统化能力。
一、学习目标：从驱动代码到验证闭环
本课程的学习目标分为四个层次，逐层递进：
- 理解层：掌握 SITL 与 HIL 的边界、适用场景与验证能力差异，能判断一个驱动问题应该在哪一层暴露。
- 实现层：能够为自定义传感器或执行机构编写符合飞控框架规范的驱动，并接入仿真环境。
- 验证层：能够设计测试用例，通过日志、参数和信号注入观察驱动行为，定位时序、协议或状态机缺陷。
- 工程层：建立可复用的驱动验证流程，把 SITL/HIL 纳入日常开发与回归测试。
这四个层次不是孤立的知识点，而是一条从“会写”到“会验”再到“会工程化”的能力路径。很多开发者能写出驱动，却无法证明驱动在边界条件下仍然正确，本课程正是要补齐这一环。
二、核心价值：为什么必须做 SITL 与 HIL
直接在真实飞机上调试自定义驱动，代价高、风险大、复现难。SITL 与 HIL 的价值体现在三个维度：
| 维度 | 真实飞行调试 | SITL / HIL 验证 |
|---|---|---|
| 安全性 | 驱动错误可能导致炸机 | 无物理风险，可反复试错 |
| 可复现性 | 受风、电池、环境干扰 | 场景可脚本化、可重复 |
| 可观测性 | 日志有限，难以断点 | 可注入信号、逐帧观察 |
| 迭代速度 | 每次测试准备时间长 | 分钟级启动，快速回归 |
尤其对于自定义驱动，接口协议、采样时序、状态切换往往存在大量隐含假设。SITL 能在纯软件环境中把这些假设显式化，HIL 则进一步验证真实 MCU 与外设之间的电气与时序约束。
三、整体知识框架：三层验证链路
本课程的知识框架可以概括为“驱动层—仿真层—验证层”三层结构。驱动层关注代码如何被飞控框架调度；仿真层关注 SITL/HIL 如何模拟传感器与执行机构；验证层关注如何设计测试、采集数据并判定通过与否。
图中清晰展示了三层之间的数据流与反馈关系：驱动层产生行为，仿真层提供环境，验证层给出判定，而验证结果又反向驱动代码修正。这一闭环正是本课程要训练的核心工作方式。
四、学习路径：从环境搭建到回归测试
课程整体按“先跑通、再深入、后工程化”的路径组织，建议按以下顺序推进：
- 环境准备：搭建 SITL 运行环境，理解飞控固件编译与启动流程。
- 驱动接入：编写一个最小自定义驱动，注册到飞控框架并观察启动日志。
- SITL 验证：在软件仿真中注入传感器数据，验证驱动采样与状态切换。
- HIL 进阶：将固件烧录到真实飞控，连接仿真外设，验证时序与接口。
- 测试工程化：把验证用例脚本化，形成可重复执行的回归测试集。
每个阶段都配有可运行的代码片段与日志观察点。例如，在 SITL 中启动自定义驱动后，典型日志如下：
[driver] custom_sensor: init ok, rate=100Hz
[sitl] sensor model injected: gyro_x=0.012 rad/s
[driver] custom_sensor: sample seq=1 valid=1
[driver] custom_sensor: state RUNNING -> CALIBRATING
[verify] check rate: expected 100Hz, actual 99.8Hz PASS
通过日志中的 seq、state、rate 等字段，可以快速判断驱动是否按预期运行。这也是后续排障与复盘的基础手段。
五、常见误区与复盘提示
- 误区二：跳过 SITL 直接上 HIL。 HIL 调试成本更高，逻辑错误应在 SITL 阶段消灭。
- 误区三：只验证正常路径。 驱动缺陷多出现在超时、丢包、状态冲突等异常路径，必须主动构造。
- 误区四：验证通过即结束。 没有纳入回归测试的验证，下一次修改就会失效。