2、核心冗余策略：硬件冗余与软件冗余

各位同学，今天我们聊聊冗余策略。说白了，就是给飞控系统上「双保险」。我做了这么多年飞控，见过太多单点故障导致的坠机事故。嗯，冗余不是锦上添花，是保命用的。

2.1 硬件冗余：三取二才是王道

硬件冗余，我习惯把它分成三类：传感器、执行器、计算单元。这三类各有各的坑，我们一个一个说。

2.1.1 传感器冗余

传感器是飞控的眼睛。眼睛瞎了，飞机就完了。所以，我们通常用三冗余IMU（惯性测量单元）。

为什么是三冗余？不是双冗余？

双冗余有个致命问题：两个传感器读数不一致，你信谁？我曾经在项目中遇到过，两个IMU一个报0.5g，一个报1.2g，飞控直接懵了。三冗余就好办，三取二表决，少数服从多数。

这里有个避坑指南：我曾经见过一个设计，三个IMU装在同一个减震板上。结果一个振动冲击，三个IMU同时漂移。嗯，这叫共因失效，白费功夫。所以物理隔离很重要。

2.1.2 执行器冗余

执行器，说白了就是舵机、电机这些。我建议执行器采用双余度设计。为什么不是三余度？因为执行器体积大、重量重，三余度代价太高。

双余度执行器怎么工作？

• 主执行器正常工作时，备用执行器处于待命状态
• 主执行器故障时，切换电路在5ms内完成切换
• 切换时不能有位置跳变，否则飞机会抖一下

我记得有一次调试，切换瞬间舵面抖了3度，飞机直接偏航。后来加了平滑过渡算法才解决。你想想看，5ms内既要检测故障，又要平滑切换，这活儿不简单。

2.1.3 计算单元冗余

计算单元是飞控的大脑。我习惯用双余度或三余度CPU架构。双余度成本低，三余度可靠性高。

双余度CPU的工作模式：

模式	主CPU	从CPU	适用场景
热备份	运行控制律	同步运行，输出待命	高可靠性要求
冷备份	运行控制律	休眠，故障时启动	低功耗场景
温备份	运行控制律	低功耗运行，定期同步	平衡方案

我个人推荐热备份。冷备份有个问题：主CPU挂了，从CPU启动需要时间，这期间飞机可能已经失控了。我见过一个项目用冷备份，切换时间花了200ms，飞机掉了50米高度才拉回来。嗯，太悬了。

2.2 软件冗余：通道同步与表决算法

硬件冗余是骨架，软件冗余是灵魂。硬件摆在那，软件得让它们协同工作。

2.2.1 通道间同步

三个IMU的数据，如果时间不同步，表决就是扯淡。我要求通道间同步误差小于1ms。

同步方法有两种：

1. 硬件同步：用同一个时钟源，所有通道同时采样。精度高，但布线复杂。
2. 软件同步：每个通道用自己的时钟，通过时间戳对齐。灵活，但精度受限于时钟漂移。

我建议混合使用。硬件同步为主，软件同步为辅。我曾经在项目中只用软件同步，结果两个通道的时钟漂移了5ms，表决结果乱七八糟。后来加了硬件同步信号，问题解决。

2.2.2 表决算法

表决算法，说白了就是「三个和尚怎么取水」。我常用的算法有三种：

• 中值表决：取三个值的中间值。简单粗暴，抗单点故障。
• 均值表决：取三个值的平均值。精度高，但抗干扰能力弱。
• 加权表决：根据每个通道的历史可靠性加权。复杂，但效果好。

我习惯用中值表决。为什么？你想想看，如果有一个传感器坏了，输出一个离谱的值，中值表决直接把它过滤掉。均值表决就不行，会把坏值拉进来。

举个例子：

// 三冗余IMU中值表决
float median_vote(float a, float b, float c) {
    // 排序取中间值
    if (a > b) swap(&a, &b);
    if (b > c) swap(&b, &c);
    if (a > b) swap(&a, &b);
    return b;  // 中间值就是表决结果
}

这段代码看着简单，但实际工程中要考虑浮点数精度问题。我曾经遇到过两个值非常接近，排序时因为精度问题导致误判。后来加了容差判断才解决。

2.3 冗余架构的核心逻辑

说了这么多，我画张图帮你理清思路。

这张图展示了冗余架构的核心逻辑。硬件冗余是三层：传感器、计算、执行。软件冗余贯穿其中，负责同步和表决。最终输出可靠的控制信号。

我做了这么多年，最大的体会是：冗余不是堆硬件，而是让硬件和软件协同工作。硬件冗余解决「坏了怎么办」，软件冗余解决「怎么知道坏了」和「坏了怎么切换」。两个问题都解决了，系统才真正可靠。

嗯，这一章就到这里。冗余策略是飞控系统的基础，后面我们会深入每个模块的具体实现。

---