第1章冗余设计概述

1、冗余设计概述：为什么飞控需要冗余？

各位同学，今天咱们聊聊飞控冗余设计。说实话，这个问题我入行时也问过自己：飞控系统又不是造火箭，干嘛搞得这么复杂？直到我亲眼看到一架无人机因为单点故障直接栽进田里，才真正明白——飞控冗余，不是选择题，而是保命题。

先讲个我自己的经历。2018年，我参与一个农业植保无人机项目。那架飞机用的是单IMU（惯性测量单元），单GPS，单磁罗盘。一切看起来都挺正常，直到有一天，飞手报告说飞机在空中突然偏航，然后失控坠毁。

事后分析，原因很简单：磁罗盘受到电机磁场干扰，输出异常偏航角。飞控没有第二个传感器做交叉验证，直接用了错误数据，结果就是炸机。

你想想看，一架植保无人机，载着20公斤农药，在农田上方3米高度飞行。如果突然失控，不仅机器报废，还可能伤到人。这就是为什么飞控需要冗余——单点故障不能导致灾难性后果。

核心逻辑：飞控系统是安全关键系统。任何单一硬件或软件的失效，都不应该导致飞行器失控。冗余设计就是给系统装上「备份伞」。

具体来说，飞控冗余要解决三类问题：

说白了，冗余就是「别把所有鸡蛋放在一个篮子里」。但怎么放、放几个、怎么切换，这里面门道很深。

我个人习惯把冗余设计的目标归纳为三个层次：

目标层次	说明	我见过的反面案例
故障检测	能发现系统出了什么问题	某飞控IMU漂移，但监控逻辑没检测到，导致姿态解算错误持续累积
故障隔离	把故障部件从系统中摘除	双GPS系统，一个坏了但没被隔离，输出错误位置数据污染了融合结果
故障恢复	系统能继续工作（可能降级）	舵机卡死，但飞控没有切换到备份舵机，飞机直接失控

嗯，这里要注意：冗余不是简单的「多一份备份」。如果备份和主件共享同一个电源、同一个总线、同一个软件版本，那这个冗余就是假的。我曾经见过一个设计，双IMU共用同一个SPI总线，结果总线短路，两个IMU同时失效——这就是典型的「共因故障」。

避坑指南：我曾经在项目中吃过「共因故障」的亏。双冗余舵机，用了同一根电源线。结果电源线接头松动，两个舵机同时掉电。从那以后，我要求所有冗余通道必须做到物理隔离——独立电源、独立总线、独立地线。

冗余设计不是只有「多放几个传感器」这么简单。按我的经验，可以分成三大类：

这是最直观的冗余方式。说白了就是「多买几份」。

同构冗余：三块同样的IMU，三路同样的GPS。我参与的一个载人级eVTOL项目，用了四余度IMU，四余度气压计，双余度飞控计算机。
异构冗余：用不同原理的传感器做备份。比如IMU+视觉+激光雷达做姿态估计。为什么？因为同构冗余可能被同样的故障模式击穿——比如三块IMU都是同一批次，温度特性一致，高温下一起漂移。

我个人更倾向于异构冗余。虽然软件复杂度高，但鲁棒性真的强。

很多人忽略软件冗余，觉得「代码写对了就行」。但现实是，软件bug是躲不掉的。

多版本编程：同一个算法，让两个团队用不同语言、不同思路实现。比如姿态解算，一个用EKF，一个用互补滤波。输出结果做交叉比对。
看门狗与监控：软件跑飞了怎么办？硬件看门狗拉回来。任务卡死了怎么办？监控任务定期检查心跳。
数据校验：CRC校验、奇偶校验、超时检测。我见过一个案例，飞控通过CAN总线接收传感器数据，没有做CRC校验，结果总线受到干扰，飞控收到了错误数据，直接导致误判。

小技巧：软件冗余里，我最常用的是「三模冗余」（TMR）。三个独立的任务跑同样的算法，输出做多数表决。虽然消耗CPU资源，但对付软件bug非常有效。我曾在STM32H7上实现过三余度姿态解算，每个余度跑在不同的RAM区域，用不同的堆栈，避免内存踩踏。

这个稍微抽象一点。信息冗余不是多放硬件，而是利用数据本身的冗余性。

时间冗余：同一个数据采样多次，做均值滤波。比如ADC采样，连续采10次，去掉最大最小值再平均。我遇到过ADC受电源噪声干扰，单次采样误差很大，但多次采样后结果就稳定了。
空间冗余：不同传感器测量同一个物理量。比如用GPS和气压计同时测高度，互相校验。
编码冗余：比如汉明码、CRC。在通信链路中，用额外的校验位来检测和纠正错误。

信息冗余的好处是成本低——不需要额外硬件，只需要在软件层面做文章。但缺点是，它只能应对「数据错误」，不能应对「硬件失效」。

下面这张图，是我自己画的冗余设计知识框架。你可以把它当作本章的「地图」：

冗余设计不是堆料，而是系统工程。你得想清楚：

我见过太多项目，冗余做得花里胡哨，但实际效果很差。原因无非是：检测逻辑太慢、隔离不彻底、恢复策略太激进。这些坑，后面几章我会一个一个带你们踩一遍。

一句话总结：冗余设计的本质，是用「可控的复杂度」换取「不可控的风险」的降低。别为了冗余而冗余，也别为了省成本而放弃冗余。平衡点在哪里？嗯，这就是我们接下来要深入探讨的。

公众号:蓝海资料掘金营，微信deep3321