第2章传感器数据异常排查

第2章传感器数据异常排查：IMU数据跳变诊断、GPS信号丢失处理、空速管结冰问题

传感器是飞控系统的眼睛和耳朵。这话一点都不夸张。

我做了这么多年飞控，见过太多因为传感器异常导致的坠机事故。有些是硬件本身的问题，有些是软件滤波没做好，还有些纯粹是安装位置不对。今天咱们就聊聊最常见的三类传感器异常：IMU数据跳变、GPS信号丢失、空速管结冰。

2.1 IMU数据跳变诊断

IMU数据跳变，说白了就是陀螺仪或加速度计突然输出一个离谱的值。比如飞机正在平飞，俯仰角突然从0度跳到30度，然后又跳回来。这种问题在eVTOL上尤其危险——飞控会误以为飞机姿态突变，然后给出错误的控制指令。

⚠️ 注意：IMU跳变和IMU噪声是两码事。噪声是高频小幅度波动，跳变是低频大幅度突变。诊断方法完全不同。

2.1.1 跳变特征分析

我个人习惯把IMU跳变分为三类：

类型	特征	常见原因
单点跳变	仅一个采样点异常	电磁干扰、静电放电
持续跳变	连续多个点异常	硬件故障、温度漂移
周期性跳变	每隔固定时间出现	电源纹波、电机干扰

我在项目中遇到过最头疼的是周期性跳变。有一次试飞，IMU数据每隔100ms就跳一次，排查了整整两天才发现是电调PWM频率和IMU采样频率产生了差拍干扰。嗯，这种问题光看数据很难发现，得用频谱分析。

2.1.2 诊断流程

遇到IMU数据异常，我一般按这个顺序排查：

先看原始数据——不要看滤波后的值，直接看ADC原始读数
检查时间戳——有时候是时间戳乱跳，不是数据本身的问题
对比冗余IMU——三冗余IMU里，两个一致、一个异常，那异常的那个基本可以判死刑
做静态测试——把飞机固定住，看IMU输出是否稳定

核心原则：先软件后硬件，先隔离后修复。不要一上来就拆传感器。

2.1.3 软件滤波策略

对于单点跳变，我推荐用中值滤波。别用均值滤波——均值滤波会把跳变值平均到周围点，反而污染了正常数据。

// 中值滤波示例（窗口大小5）
float median_filter(float data[], int len) {
    // 排序后取中间值
    for (int i = 0; i < len - 1; i++) {
        for (int j = 0; j < len - i - 1; j++) {
            if (data[j] > data[j + 1]) {
                float temp = data[j];
                data[j] = data[j + 1];
                data[j + 1] = temp;
            }
        }
    }
    return data[len / 2];
}

你想想看，如果窗口大小选3，遇到连续两个跳变点就失效了。我一般用5或7，具体看你的采样频率。采样率越高，窗口可以越大。

💡 小技巧：可以在飞控日志里同时记录原始值和滤波值。这样排查问题时，一眼就能看出是传感器本身的问题还是滤波算法的问题。

2.2 GPS信号丢失处理

GPS信号丢失在eVTOL上是个大问题。固定翼飞机丢了GPS还能靠惯性导航撑一会儿，但eVTOL在悬停和低速阶段，GPS几乎是位置信息的唯一来源。

我曾经遇到过一架eVTOL在城区试飞，GPS信号突然从12颗星掉到3颗星。飞控立刻切到纯惯导模式，结果位置漂移越来越严重，最后不得不手动干预降落。

2.2.1 信号丢失的典型场景

高楼遮挡——城市峡谷效应，信号反射导致多径效应
电磁干扰——机载大功率设备（比如图传）对GPS频段的干扰
天线安装问题——天线被碳纤维机身遮挡，或者安装角度不对
卫星几何分布差——虽然卫星数量够，但都在同一方向，定位精度很差

2.2.2 处理策略

我的做法是分级处理，不要一丢GPS就慌：

信号质量	处理方式
良好（HDOP < 1.5）	正常使用，融合惯导
一般（1.5 ≤ HDOP < 3.0）	降低GPS权重，增加惯导占比
较差（3.0 ≤ HDOP < 5.0）	仅用于航向参考，位置靠惯导
丢失（HDOP ≥ 5.0 或卫星数 < 4）	纯惯导模式，触发安全策略

⚠️ 重要：GPS恢复后不要立刻切回融合模式。我见过太多飞控因为GPS恢复瞬间的位置跳变，导致控制量突变。一定要做平滑过渡，至少持续1-2秒的渐进融合。

2.2.3 实战代码片段

// GPS信号丢失后的平滑恢复
float gps_blend_factor = 0.0f;

if (gps_healthy && gps_lost_timer > 2.0f) {
    // GPS已恢复超过2秒，开始融合
    gps_blend_factor = MIN(1.0f, gps_blend_factor + 0.1f);
} else if (!gps_healthy) {
    gps_blend_factor = 0.0f;
    gps_lost_timer = 0.0f;
}

// 位置融合：惯导 + GPS * 融合因子
position = ins_position + (gps_position - ins_position) * gps_blend_factor;

2.3 空速管结冰问题

空速管结冰，说白了就是空速管被冰堵住了。这个问题在eVTOL上容易被忽视——很多人觉得eVTOL飞得慢、飞得低，不会结冰。其实不然，尤其是在高湿度、低温环境下，空速管结冰可能发生在任何高度。

我记得有一次冬天在北方做测试，地面温度零下5度，湿度80%。起飞前检查空速管是好的，飞到50米高度时空速突然掉到0。还好我们提前做了冗余设计，用GPS地速和IMU风速估算做了备份，不然那次试飞就悬了。

2.3.1 结冰的典型表现

空速突然下降——冰堵住了动压口，动压变小
空速缓慢漂移——冰逐渐积累，动压口越来越小
空速和地速严重不一致——顺风逆风都不至于差太多，如果差太多基本就是空速管有问题

2.3.2 诊断方法

我一般用三种方法交叉验证：

对比GPS地速——在无风或已知风速条件下，空速应该接近地速
检查静压孔——如果静压孔也结冰，高度和空速会同时异常
加热检测——打开空速管加热后，看空速是否恢复正常

💡 经验之谈：空速管加热不是万能的。如果结冰速度超过加热速度，或者加热丝本身故障，加热也没用。我建议在空速管旁边加装温度传感器，实时监测加热效果。

2.3.3 冗余设计建议

对于eVTOL，我强烈建议做三重冗余：

层级	方案	优先级
主方案	加热式空速管 + 皮托管	最高
备份方案	GPS地速 + 风速模型估算	中等
应急方案	基于电机转速和桨距的推力估算	最低

说白了，空速管结冰不是能不能避免的问题，而是什么时候发生的问题。做好冗余，才能在结冰时安全飞行。

2.4 本章知识体系

下面这张图总结了传感器异常排查的核心逻辑。你可以把它当作排查时的路线图：

这张图把三个传感器异常的核心要点都串起来了。你排查问题时，可以对照着看——先判断是哪个传感器的问题，再按对应的流程走。嗯，说白了就是别乱，一步一步来。

本章小结：传感器异常排查没有银弹。IMU跳变靠滤波和冗余，GPS丢失靠分级处理和平滑恢复，空速管结冰靠加热和备份方案。我做了这么多年，最大的体会就是——别指望一个方案解决所有问题，多留几手准备才是正道。

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

📚 课程目录