3. 传感器冗余（一）：IMU冗余配置（双余度、三余度）、投票机制原理
各位同学，咱们今天聊聊IMU冗余。说实话，IMU是飞控系统里最娇气的传感器。它要是罢工了，飞机基本就瞎了。我见过太多因为IMU故障导致的坠机案例，所以冗余配置这块，必须讲透。
3.1 为什么IMU需要冗余？
IMU包含加速度计和陀螺仪。这两个东西，任何一个出问题，姿态解算就全乱套。你想想看，飞机在天上飞，姿态数据错了，那后果不堪设想。
我在项目中遇到过一件事：某次试飞，飞机突然开始剧烈抖动。排查了半天，发现是其中一个加速度计的MEMS芯片焊点虚焊了。温度一高，输出就开始漂。幸亏当时用了三余度配置，投票机制直接把这个故障通道踢出去了。要是单余度，那架飞机估计就交代了。
所以，IMU冗余不是选择题，是必答题。
3.2 双余度配置
双余度，就是装两个IMU。一个主用，一个备份。听起来简单，但坑不少。
双余度的核心问题：当两个IMU输出不一致时，你没法判断哪个是对的。
举个例子：IMU1报俯仰角5度，IMU2报俯仰角5.2度。这0.2度的差异，是正常噪声？还是其中一个坏了？你没法确定。
我个人的习惯是：双余度只用在低安全等级的系统里。比如一些小型无人机，或者作为辅助参考。真正要上天的载人飞行器，我建议至少三余度。
双余度的典型做法：
- 冷备份：主IMU工作，备份IMU断电。主IMU故障时，手动或自动切换。切换期间会有数据中断，大概几十到几百毫秒。
- 热备份：两个IMU同时工作，但只有主IMU的数据用于控制。备份IMU的数据只做监控。一旦发现主IMU异常，立即切换。
热备份比冷备份好，但依然存在那个核心问题：没法互相验证。
3.3 三余度配置
三余度，才是真正靠谱的方案。三个IMU同时工作，通过投票机制选出最可信的数据。
为什么是三余度？因为三个点可以形成一个平面。三个数据可以互相校验。两个数据一致，第三个不一致，那少数服从多数。这个逻辑很直观。
我的经验：三余度配置里，三个IMU最好来自不同批次，甚至不同厂家。我曾经遇到过同一批次的三块IMU，因为同一个设计缺陷，在高温环境下同时漂移。那叫一个惨。所以，异构冗余才是王道。
三余度的典型架构：
- 三个IMU独立供电，独立通信总线
- 每个IMU输出三轴加速度和三轴角速率
- 飞控计算机同时接收三组数据
- 投票机制实时运行，输出最终可信值
3.4 投票机制原理
投票机制，说白了就是「少数服从多数」。但具体实现上，有很多细节。
最简单的投票：
// 伪代码：三余度投票
float imu1_roll, imu2_roll, imu3_roll;
float threshold = 0.5; // 度，阈值根据传感器精度设定
if (abs(imu1_roll - imu2_roll) < threshold &&
abs(imu1_roll - imu3_roll) < threshold) {
// IMU1和IMU2、IMU3都一致，用IMU1
final_roll = imu1_roll;
} else if (abs(imu2_roll - imu1_roll) < threshold &&
abs(imu2_roll - imu3_roll) < threshold) {
// IMU2和IMU1、IMU3都一致，用IMU2
final_roll = imu2_roll;
} else if (abs(imu3_roll - imu1_roll) < threshold &&
abs(imu3_roll - imu2_roll) < threshold) {
// IMU3和IMU1、IMU2都一致，用IMU3
final_roll = imu3_roll;
} else {
// 三个都不一致，触发故障处理
fault_handler();
}这段代码看着简单，但实际工程里要复杂得多。为什么？
第一，阈值怎么设？设大了，故障检测不灵敏。设小了，正常噪声也会触发投票。我一般会根据传感器数据手册的噪声指标，再乘以一个安全系数。比如噪声是0.1度，阈值设0.3度。
第二，投票不是只投一次。要持续投票。比如连续10个周期都发现IMU2异常，才判定它故障。这叫「去抖」。防止瞬间的干扰导致误判。
注意：投票机制不能解决「共因故障」。比如三个IMU都因为电源浪涌而损坏，投票机制就失效了。所以，独立供电、独立布线、独立接地，这些硬件层面的隔离措施，比投票机制更重要。
3.5 投票机制的进阶：中值投票与加权投票
简单的多数投票有个问题：如果三个数据都不同，怎么办？比如IMU1报5度，IMU2报5.5度，IMU3报6度。三个都不一致，但可能都没坏，只是噪声大。
这时候可以用中值投票。取三个数据的中间值。5度、5.5度、6度，中值是5.5度。这个值往往比任何一个单独的值都更接近真实值。
还有一种加权投票。给每个IMU一个置信度权重。历史上表现好的IMU，权重高。刚发生过小故障的IMU，权重低。加权平均后输出。
我个人比较喜欢中值投票。简单、鲁棒、计算量小。加权投票虽然理论上更优，但权重的更新策略很难调。调不好反而会引入振荡。
3.6 实战中的避坑指南
嗯，这里要注意几个坑，都是我用真金白银换来的教训。
- 时间同步：三个IMU的数据必须时间对齐。如果IMU1的数据是10ms前的，IMU2的数据是5ms前的，投票结果就是错的。我一般用硬件同步信号，或者用高精度时间戳对齐。
- 数据有效性检查：投票之前，先检查每个IMU的数据是否有效。比如检查CRC校验、检查数据范围是否合理。无效数据直接丢弃，不参与投票。
- 故障恢复：被投票踢出去的IMU，不能永久禁用。要定期尝试恢复。比如每100个周期，让它重新参与投票。如果它恢复正常了，就重新加入。
- 降级策略：三余度变成双余度后，系统要自动降级。比如限制最大飞行速度、限制机动幅度。我曾经见过一个系统，三余度坏了一个，还按原来的性能飞，结果第二个也坏了，直接失控。
3.7 小结
IMU冗余配置，双余度是入门，三余度是主流。投票机制是核心，但投票不是万能的。硬件隔离、时间同步、故障恢复，这些配套措施一个都不能少。
下一节我会讲传感器冗余的第二部分：空速管和GPS的冗余配置。到时候咱们再聊。