2、故障模式分析：传感器故障、执行器故障、通信故障

各位同学，咱们接着聊。上一章我们把故障诊断的整体框架搭起来了，这一章我带你深入看看那些最让人头疼的故障模式。说白了，飞控系统在天上飞，任何一个环节出问题，后果都可能很严重。我个人习惯是把故障分成三大类：传感器、执行器、通信。咱们一个一个来拆解。

2.1 传感器故障：飞控的“眼睛”瞎了怎么办？

传感器是飞控感知世界的唯一途径。它要是出了问题，飞控就成了盲人骑瞎马。常见的传感器故障有三种：漂移、卡死、数据中断。

2.1.1 漂移故障

漂移，就是传感器的输出值慢慢偏离真实值。比如陀螺仪的零偏随着温度变化慢慢跑掉。嗯，这里要注意，漂移不是瞬间发生的，它像温水煮青蛙。

我在项目中遇到过一次，某款IMU在高温环境下，加速度计的Z轴输出从1g慢慢漂到了1.15g。飞控以为飞机在上升，就开始收油门。结果飞机越飞越低，差点炸机。后来我查了数据手册，发现那个IMU的温度补偿系数没配好。

漂移的典型特征：

• 误差随时间缓慢累积
• 短时间内难以察觉
• 通常由温度、老化引起

2.1.2 卡死故障

卡死，就是传感器的输出值突然固定在一个数值上，再也不变了。这比漂移更危险，因为飞控会以为飞机状态稳定，实际上可能已经失控了。

我曾经调试一架六旋翼时，气压计突然卡死在101.3kPa。飞控以为高度没变，实际上飞机已经掉到地上了。嗯，那次教训很深刻。

卡死的判断逻辑其实很简单：

// 伪代码：卡死检测
if (abs(sensor_value - last_value) < DEAD_THRESHOLD) {
    dead_counter++;
    if (dead_counter > DEAD_FRAME_NUM) {
        // 判定为卡死
        fault_flag = SENSOR_STUCK;
    }
} else {
    dead_counter = 0;
}

你想想看，如果连续100个采样周期数据都不变，那肯定是有问题的。正常传感器总有噪声，不可能纹丝不动。

2.1.3 数据中断

数据中断，就是传感器突然不输出数据了。可能是线断了、芯片挂了、或者通信接口出了问题。这是最直观的故障，但也是最难处理的——因为飞控不知道发生了什么。

故障类型	典型表现	检测方法	我的处理建议
漂移	数据缓慢偏离	滑动窗口均值对比	启用备用传感器，或进行在线校准
卡死	数据固定不变	相邻采样差值检测	切换冗余传感器，或进入降级模式
数据中断	无数据输出	看门狗超时检测	立即切换，并触发紧急保护

2.2 执行器故障：电机和桨叶的“罢工”

执行器是飞控的“手脚”。传感器坏了，飞控还能靠冗余数据撑着。执行器坏了，飞机直接失去控制力。常见的执行器故障有电机堵转和桨叶损坏。

2.2.1 电机堵转

电机堵转，就是电机转不动了。可能是轴承卡死、异物卡住、或者电调烧了。堵转时电流会急剧增大，如果不及时处理，电调会烧毁。

我记得有一次做四旋翼拉力测试，一个电机被线缆缠住。飞控还在拼命给油门，结果那个电调直接冒烟了。从那以后，我都在代码里加了堵转检测。

堵转检测的核心是“电流-转速”关系：

// 堵转检测逻辑
if (motor_speed < SPEED_THRESHOLD && motor_current > CURRENT_THRESHOLD) {
    // 转速低但电流大，大概率堵转
    stall_counter++;
    if (stall_counter > STALL_FRAME_NUM) {
        // 确认堵转，立即降低油门
        set_motor_throttle(motor_id, 0);
        fault_flag = MOTOR_STALL;
    }
}

2.2.2 桨叶损坏

桨叶损坏，比如桨尖断裂、桨叶变形。这会导致拉力下降、振动增大。飞控为了维持姿态，会加大其他电机的输出，导致系统失衡。

桨叶损坏的典型表现：

• 振动值突然增大（IMU的加速度计数据会明显抖动）
• 某个电机的PWM输出异常偏高
• 飞机出现无法消除的偏航

我曾经遇到过一架六旋翼，起飞后一直往左偏。飞控一直在调右舵，但就是调不回来。落地一看，右边一个桨叶缺了指甲盖大小的一块。嗯，有时候问题就这么简单。

2.3 通信故障：CAN和I2C总线的“沉默”

通信总线是飞控的“神经网络”。传感器数据、执行器指令都靠它传输。总线一旦出问题，整个系统就瘫痪了。常见的通信故障有CAN总线异常和I2C总线异常。

2.3.1 CAN总线故障

CAN总线在飞控中很常见，尤其是多传感器、多执行器的系统。CAN总线故障主要有：

• 总线关闭：某个节点错误太多，被总线自动隔离
• 位填充错误：时钟不同步导致数据错位
• 仲裁丢失：多个节点同时发送，优先级低的被覆盖

我个人习惯在CAN总线上加一个“心跳包”。每个节点每隔10ms发送一次心跳。如果连续3次收不到某个节点的心跳，就判定该节点离线。

// CAN心跳检测
typedef struct {
    uint8_t node_id;
    uint32_t last_heartbeat_ms;
    uint8_t missed_count;
} can_node_t;

void can_heartbeat_check(can_node_t *node) {
    uint32_t now = get_system_ms();
    if ((now - node->last_heartbeat_ms) > HEARTBEAT_TIMEOUT_MS) {
        node->missed_count++;
        if (node->missed_count >= 3) {
            // 节点离线，触发故障处理
            can_node_offline(node->node_id);
        }
    } else {
        node->missed_count = 0;
    }
}

2.3.2 I2C总线故障

I2C总线在飞控中常用于连接IMU、气压计、磁力计等。I2C的故障比较隐蔽，常见的有：

• SCL/SDA线被拉低：某个从机故障，把总线锁死了
• 地址冲突：两个设备用了同一个I2C地址
• 时钟拉伸：从机拉低时钟线，导致主机等待超时

我记得有一次调试，I2C总线总是莫名其妙地卡住。用示波器一看，SCL线一直被拉低。查了半天，发现是磁力计的I2C接口短路了。嗯，硬件问题有时候就是这么让人抓狂。

I2C故障的检测方法：

• 每次通信后检查ACK信号
• 设置超时时间（建议5ms以内）
• 如果连续3次通信失败，尝试复位I2C总线

好了，这一章的内容就到这里。传感器、执行器、通信，这三类故障基本覆盖了飞控系统90%以上的问题。下一章我会讲具体的故障诊断算法，包括卡尔曼滤波的残差检测、多传感器投票机制等。到时候咱们再细聊。