飞控系统冗余设计：硬件与软件冗余
从一次坠机说起
去年夏天，我在调试一架六轴无人机时遇到了一个诡异的问题。飞行器在悬停状态下突然失控，翻滚着砸向地面。黑匣子数据回放显示，IMU的Z轴陀螺仪在某个瞬间输出了一个异常值——不是噪声，不是漂移，而是直接跳到了满量程的80%。更诡异的是，这个异常只持续了不到10毫秒，但飞控已经根据这个错误数据发出了错误的控制指令。
拆机检查后发现，那颗MPU9250的Z轴陀螺仪确实已经物理损坏。但问题在于，飞控上明明焊了两颗IMU，为什么冗余切换没有生效？翻看代码才发现，当初写冗余逻辑的同事只做了“数据有效性检查”，没有做“数据一致性校验”。两颗IMU的数据都在各自的有效范围内，但一个输出0.5度/秒，另一个输出80度/秒，系统居然认为这是正常的。
这个教训让我意识到，冗余设计不是简单地把硬件堆上去就完事了。从那天起，我开始重新审视飞控系统的每一个冗余环节。
硬件冗余：不是简单的“多一份备份”
硬件冗余最容易犯的错误就是“对称冗余”——两颗同样的传感器，同样的供电，同样的通信总线，同样的安装位置。这种设计在理论上看起来很完美，但在实际工程中往往会在同一个故障点上同时失效。
我见过一个案例，飞控上用了两颗同样的气压计，共用同一个LDO供电。结果LDO输出纹波异常，两颗气压计同时开始跳变，高度数据直接崩了。这就是典型的“共因失效”。
真正的硬件冗余应该遵循“异构冗余”原则。以IMU为例，我现在的做法是：
主IMU用MPU9250（消费级，便宜，响应快），备份IMU用ADIS16470（工业级，贵，抗振动
