冗余架构设计：硬件冗余、解析冗余与信息冗余
各位同学，今天我们来聊聊冗余架构设计。说实话，这是整个飞控系统里最让我「又爱又恨」的部分。爱的是它能让系统变得极其可靠，恨的是——设计不好反而会引入更多故障点。
我刚开始做飞控那会儿，总觉得冗余就是「多备份几套硬件」。后来在一次试飞中，双余度系统竟然同时失效了...嗯，那次经历让我明白：冗余不是简单的堆料，而是一门系统工程的艺术。
今天我把冗余架构拆成三个层面来讲：硬件冗余、解析冗余和信息冗余。这三者缺一不可，就像三脚架一样，少一条腿都站不稳。
一、硬件冗余：最朴素的可靠性保障
硬件冗余，说白了就是「多买几套传感器装上去」。但怎么装、怎么切换，这里面的门道可不少。
1.1 双余度架构
双余度是最常见的方案。两套IMU、两套GPS、两套空速管...我见过很多初创公司上来就搞双余度，结果发现比单余度还容易炸机。为什么？
因为双余度最大的坑在于——当两个传感器读数不一致时，你该信谁？
双余度表决逻辑：
- 两路数据一致（误差在阈值内）→ 取平均值
- 一路失效（数据跳变/超时）→ 切换到另一路
- 两路不一致但都「看起来正常」→ 进入降级模式
我曾经在项目中遇到过这种情况：两路IMU的加速度计读数差了0.3m/s²，但各自的自检都通过了。结果飞控在两者之间反复切换，导致姿态估计震荡。最后查出来是其中一路的安装支架有微小松动。
我的建议：双余度系统一定要设计「交叉验证」机制。不要只看传感器自身状态，还要看它们之间的相对关系。我习惯在代码里加一个「互差监控」模块，当两路数据偏差超过阈值时，直接触发系统降级，而不是盲目切换。
1.2 三余度架构
三余度就优雅多了。三路传感器，两两比较，少数服从多数。就算坏掉一路，剩下两路还能继续工作。
三余度的核心是表决器。我见过最经典的实现是「中值选择」——三路数据排序，取中间那个。这比取平均值更鲁棒，因为极端值会被自动排除。
// 三余度中值表决示例
float select_median(float a, float b, float c) {
// 简单但高效的中值选择
if ((a >= b && a <= c) || (a >= c && a <= b)) return a;
if ((b >= a && b <= c) || (b >= c && b <= a)) return b;
return c;
}
// 实际项目中还要考虑：
// 1. 时间戳对齐
// 2. 数据有效性标志
// 3. 故障历史记录注意：三余度不是万能的。如果三路传感器来自同一批次、同一型号，它们可能共享相同的「共模故障」——比如温度漂移特性一致，高温下全部漂移。我建议至少使用两种不同原理的传感器（比如MEMS IMU + 光纤陀螺），或者来自不同供应商。
二、解析冗余：用数学模型替代物理备份
硬件冗余成本高、体积大、重量重。解析冗余（也叫虚拟传感器）就是通过数学模型，用已有的传感器数据「推算」出缺失的测量值。
举个例子：如果你有GPS和空速管，理论上可以推算出气压高度。如果你有IMU和磁力计，可以推算出航向角。这就是解析冗余的思想。
2.1 运动学约束
无人机在飞行中遵循基本的物理规律。比如：
- 水平加速度 + 重力 = 总加速度（IMU测量值）
- 角速度积分 = 姿态角
- 空速 + 风速 = 地速（GPS测量值）
利用这些约束，我们可以构建「虚拟传感器」。我在一个项目中，GPS信号被干扰了，就是用IMU积分 + 光流传感器推算出了位置，撑了整整3分钟直到GPS恢复。
2.2 卡尔曼滤波中的解析冗余
卡尔曼滤波本身就是一种解析冗余工具。它把多个传感器的测量值融合在一起，同时输出「最优估计」和「残差」。残差就是解析冗余的黄金指标——当某个传感器的残差突然增大，说明它可能出问题了。
// 解析冗余的残差检测
// 假设我们使用卡尔曼滤波融合IMU和GPS
float innovation = z_measured - z_predicted; // 新息/残差
float normalized_innovation = innovation / sqrt(S); // S是创新协方差
if (abs(normalized_innovation) > 3.0) {
// 3-sigma准则，超出范围说明可能故障
// 此时可以：
// 1. 降低该传感器的权重
// 2. 完全剔除该传感器
// 3. 切换到纯预测模式
}避坑指南：我曾经在调试时发现残差一直偏大，以为是传感器坏了。折腾了两天，最后发现是模型参数错了——把无人机的转动惯量写成了固定翼的参数。所以解析冗余的准确性，高度依赖模型的精度。模型不准，解析冗余就是「垃圾进，垃圾出」。
三、信息冗余：多源数据融合的艺术
信息冗余和前面两种不太一样。它不关心你用了多少硬件，也不关心你建了多少模型，它关心的是——如何从多个信息源中提取出最可靠的状态估计。
3.1 异构传感器融合
不同传感器有不同的特性：
| 传感器 | 优点 | 缺点 | 冗余价值 |
|---|---|---|---|
| GPS | 长期稳定，无漂移 | 更新率低，易受遮挡 | 修正IMU漂移 |
| IMU | 高频，短时精度高 | 长期漂移 | 填补GPS空白期 |
| 视觉 | 特征丰富，无漂移 | 光照敏感，计算量大 | GPS失效时的替代 |
| 激光雷达 | 精确测距，不受光照影响 | 点云稀疏，成本高 | 提供深度信息 |
信息冗余的核心思想是：用不同传感器的优势互补，掩盖各自的劣势。比如GPS+IMU融合，GPS负责长期校准，IMU负责短期插值。就算GPS掉了，IMU还能撑几十秒。
3.2 故障检测与隔离（FDI）
信息冗余的另一个重要应用是故障检测。当你有多个信息源时，可以通过一致性检查来发现故障。
我常用的方法是奇偶方程法：
- 建立传感器测量值之间的数学关系（比如：空速² = 地速² - 风速²）
- 实时计算这个关系是否成立
- 如果偏差超过阈值，说明至少有一个传感器出问题了
- 通过组合不同的奇偶方程，可以定位到具体哪个传感器故障
实战经验：我在一个物流无人机项目中，用信息冗余检测出了空速管结冰。当时空速管读数突然下降，但GPS地速和IMU加速度都正常。通过奇偶方程发现「空速² + 风速² ≠ 地速²」，判断空速管异常。切换到IMU+GPS推算的空速后，飞机安全返航。
四、三种冗余的协同工作
讲到这里，你可能会问：这三种冗余到底怎么配合？
我个人的设计习惯是这样的：
- 硬件冗余作为第一道防线：物理备份，直接切换
- 解析冗余作为第二道防线：当硬件全部失效时，用模型推算
- 信息冗余作为第三道防线：通过多源数据融合，提升整体估计的鲁棒性
举个例子：假设三余度IMU全部失效（比如电源故障），硬件冗余失效。此时解析冗余启动，利用GPS+空速+磁力计推算姿态。而信息冗余则在后台持续监控所有传感器的健康状态，一旦发现某个传感器恢复，立即重新接入融合。
重要提醒：冗余不是越多越好。每增加一层冗余，系统的复杂度就指数级上升。我见过一个项目搞了五余度，结果故障切换逻辑比飞控本身还复杂，最后调试了半年都没搞定。我的原则是：够用就好，多一层冗余就多一层风险。
好了，关于冗余架构设计就讲到这里。这三种冗余方式，说白了就是「硬件备份、软件推算、数据融合」三位一体。下次当你设计飞控系统时，不妨想想：如果这个传感器突然坏了，我还有什么办法能继续飞？
记住，好的冗余设计不是让系统「永不故障」，而是让系统「故障后依然可用」。
公众号:蓝海资料掘金营，微信deep3321