设计故障注入:让学生安全地失败一百次

Robavionix 最难的设计约束,从来不是控制理论本身——而是让“失败”变得便宜。一个学生需要能够在一堂课里,把一个控制器弄失效、看着它发生、复位、再试一次,重复几十遍,既不损坏任何值钱的东西,也不用让任何人离开房间。

为什么“直接飞一架无人机”解决不了这个约束

一个真正能飞的平台,解决的是另一个、在某些方面反而更容易的问题:让飞行器飞得好。它解决不了这个问题。每一次真实飞行都伴随着对真实硬件、真实空域规则、房间里真实的人的真实风险——这意味着在一个能飞的平台上,每一次故障注入实验,再做一次都是有代价的。而这个代价,恰恰决定了一个学生在这堂课结束前,能看着控制器失效多少次。

Robavionix 从不离开桌面。控制器跑在真实的 STM32 硬件上,对付 HIL 实验台内的真实物理测试平台,所以每一个故障——电机衰减、噪声突增、执行器卡死——的注入与解决,都不需要任何东西真的离开地面。

“故障注入”在机制上到底得是什么

它不是 GUI 里的一个滑块。故障总线位于 Simulink 的被控对象模型里,实时驱动真实的硬件行为:按电机独立的健康系数,用来缩放推力输出;注入到 IMU 通道的传感器噪声与零漂;执行器卡死与饱和状态。标准故障库里的每一个故障都可以按需触发或随机触发,每一次试验都会自动记录下产生的状态轨迹——因为正是这份记录,把“控制器失效了”这句话,变成了一个学生可以写进报告里的、测量出来的、可复现的结果。

这个约束如何塑造了整个课程

一旦失败变得便宜,课程体系就可以围绕“刻意反复看着它发生”来搭建:L1 故意把 PID 推过它的极限。L4 专门构造一个过渡失稳案例,让学生亲眼看着一个调得很好的控制器在两个稳定点之间失效。L5 的毕业项目干脆完全隐藏故障脚本,只依据结果打分。如果重新跑一次实验意味着要重新组装、重新配平或者维修,这一切都不可能实现。