第2章故障模式分析

2. 故障模式分析：GNSS信号丢失、多径效应、惯性传感器漂移、IMU故障、时间同步错误

各位同学，咱们今天聊点实在的。做组合导航这么多年，我见过太多系统在实验室跑得好好的，一到实际场景就崩了。为什么？说白了，就是没把故障模式想透。你想想看，一个系统要能在天上飞、地上跑、水里游，它得面对多少种意外？

我个人习惯，做任何组合导航系统之前，先把故障模式列个清单。这不是纸上谈兵，而是血的教训换来的经验。今天我就把这五种最常见的故障模式掰开揉碎了讲给你听。

2.1 GNSS信号丢失

这是最常遇到的故障，没有之一。我在项目中遇到过好几次，无人机飞进高楼林立的区域，GNSS信号说没就没了。为什么会这样？原因其实很简单：卫星信号太弱了。

GNSS信号到达地面时，功率大概只有-160dBW左右，比背景噪声还低20dB。你想想看，这么弱的信号，随便一点遮挡就完蛋。

信号丢失的典型场景：

城市峡谷：高楼反射和遮挡，信号时有时无
隧道/地下停车场：完全遮挡，信号归零
森林覆盖：树冠衰减，信号强度骤降
电磁干扰：人为或自然的射频干扰

我记得有一次做车载导航测试，车开进一个立交桥下面，GNSS直接掉了8颗星。当时系统还没做故障检测，结果定位直接飘出去200米。嗯，从那以后我就在代码里加了个信号质量监测模块。

// GNSS信号丢失检测 - 我常用的方法
typedef struct {
    uint8_t svCount;           // 可见卫星数
    float   hdop;              // 水平精度因子
    float   signalStrength;    // 平均信号强度(dBHz)
    uint8_t status;            // 0:正常 1:警告 2:丢失
} GnssHealth_t;

GnssHealth_t checkGnssHealth(GnssRaw_t *raw) {
    GnssHealth_t health = {0};
    
    // 第一步：检查卫星数量
    health.svCount = raw->svInView;
    if (health.svCount < 4) {
        health.status = 2;  // 直接判丢失
        return health;
    }
    
    // 第二步：检查HDOP
    health.hdop = raw->hdop;
    if (health.hdop > 5.0f) {
        health.status = 1;  // 几何分布太差
    }
    
    // 第三步：检查信号强度
    health.signalStrength = calculateAvgStrength(raw);
    if (health.signalStrength < 30.0f) {
        health.status = 1;  // 信号太弱
    }
    
    return health;
}

我的经验：不要只看卫星数量。有时候能看到8颗星，但HDOP已经到8了，这种数据还不如不用。我一般把HDOP大于5的情况直接降权处理。

2.2 多径效应

多径效应这东西，说白了就是信号走了弯路。GNSS信号本来应该直线从卫星到接收机，结果被建筑物反射了一下，多绕了几米才到。你想想看，这会导致什么后果？伪距测量值偏大，定位自然就偏了。

多径效应最难搞的地方在于：它不像信号丢失那么明显。信号强度看着还行，卫星数量也不少，但定位就是不准。我早期做项目时就被这个坑过，明明在城市里测试，定位误差突然跳到50米，查了半天才发现是旁边玻璃幕墙搞的鬼。

多径类型	延迟范围	典型场景	检测难度
短延迟多径	< 15米	地面反射、墙壁反射	高
中延迟多径	15-100米	建筑物反射	中
长延迟多径	> 100米	远距离反射、水面反射	低

怎么检测多径？我常用的方法有两个：

载波相位与伪距一致性检查：正常情况下，载波相位变化量和伪距变化量应该一致。如果偏差太大，多半是多径。
信噪比异常检测：多径信号会导致相关峰变形，反映在信噪比上就是波动异常。

注意：多径效应没法完全消除，只能缓解。我建议在融合滤波器中，对疑似多径的卫星观测值进行降权处理，而不是直接剔除。直接剔除可能导致卫星几何分布变差，反而更糟。

2.3 惯性传感器漂移

惯性传感器漂移，这是做惯导的人永远的痛。陀螺仪和加速度计都有零偏，而且这个零偏会随着温度、时间、振动等因素变化。你想想看，一个0.1°/h的陀螺零偏，积分10分钟就是0.017°，看着不大对吧？但再积分到位置误差上，那就是平方关系了。

我记得有个项目，用的是消费级MEMS IMU，零偏稳定性大概在10°/h左右。纯惯导导航，30秒位置误差就超过100米。当时客户问能不能纯惯导撑5分钟，我直接说不可能——这不是算法问题，是物理限制。

漂移的数学模型（简化版）：

// 角度随机游走模型
θ(t) = θ₀ + ω·t + σ·√(t)·w(t)

其中：
θ₀ - 初始角度
ω  - 角速率（含零偏）
σ  - 角度随机游走系数
w(t) - 白噪声

检测惯性传感器漂移，我一般用以下方法：

静止检测法：系统静止时，加速度计输出应该是1g，陀螺输出应该是0。如果偏差超过阈值，说明有漂移。
GNSS/INS一致性检查：有GNSS信号时，对比惯导推算的位置变化和GNSS测量的位置变化。差值持续增大，说明惯导在漂。
零速修正（ZUPT）：检测到零速区间时，对速度误差进行修正。这是我最喜欢的方法，简单有效。

避坑指南：我曾经犯过一个错误——把温度补偿做得太复杂。后来发现，对于消费级IMU，简单的线性温度补偿就够了，搞高阶多项式反而容易过拟合。记住，工程上够用就行。

2.4 IMU故障

IMU故障和传感器漂移是两码事。漂移是性能退化，故障是彻底坏了。IMU故障包括：输出卡死、数据跳变、通信中断、电源异常等。这些故障一旦发生，系统必须能快速检测并切换。

我在项目中遇到过最离谱的一次：IMU的Z轴陀螺输出直接卡在0.5 rad/s，持续了3秒钟。当时系统没检测到，结果姿态估计直接翻了180度。嗯，从那以后我就在代码里加了三个层次的故障检测。

// IMU故障检测 - 三层检测机制
typedef struct {
    uint8_t level1;  // 物理层检测
    uint8_t level2;  // 数据层检测  
    uint8_t level3;  // 逻辑层检测
} ImuFaultLevel_t;

ImuFaultLevel_t checkImuFault(ImuData_t *imu) {
    ImuFaultLevel_t fault = {0};
    
    // 第一层：物理层 - 检查数据更新率
    static uint32_t lastTimestamp = 0;
    uint32_t dt = imu->timestamp - lastTimestamp;
    if (dt > IMU_MAX_INTERVAL_MS) {
        fault.level1 = 1;  // 数据更新异常
    }
    lastTimestamp = imu->timestamp;
    
    // 第二层：数据层 - 检查量程范围
    if (fabs(imu->gyro.x) > GYRO_MAX_RANGE ||
        fabs(imu->accel.x) > ACCEL_MAX_RANGE) {
        fault.level2 = 1;  // 数据超限
    }
    
    // 第三层：逻辑层 - 检查数据合理性
    // 比如：静止时陀螺输出应该接近0
    if (isSystemStatic(imu) && 
        norm(imu->gyro) > GYRO_STATIC_THRESHOLD) {
        fault.level3 = 1;  // 逻辑异常
    }
    
    return fault;
}

重要提醒：IMU故障检测一定要快。我建议在中断服务程序里做第一层检测，发现异常立即标记。等主循环再处理，黄花菜都凉了。

2.5 时间同步错误

时间同步错误，这是组合导航里最隐蔽的故障。GNSS和IMU的数据如果时间没对齐，融合出来的结果就是错的。而且这个错误不会像信号丢失那样明显，它会让你的滤波器慢慢发散，你查半天都找不到原因。

为什么会发生时间同步错误？原因很多：

GNSS接收机和IMU的时钟源不同，存在晶振误差
数据传输有延迟，而且延迟不稳定
CPU处理时间不确定，导致时间戳不准确
多传感器系统里，各传感器的时间基准不一致

我记得有个项目，GNSS用的是PPS秒脉冲，IMU用的是内部时钟。理论上PPS精度在纳秒级，IMU时钟精度在微秒级，应该没问题。但实际测试发现，IMU的时钟会随着温度漂移，一天下来能差几十毫秒。几十毫秒对于组合导航来说，已经足够让滤波器发散了。

时间同步的工程实践：

// 时间同步误差补偿 - 我常用的方法
typedef struct {
    uint64_t gnssTime;      // GNSS时间戳(ns)
    uint64_t imuTime;       // IMU时间戳(ns)  
    int64_t  timeOffset;    // 时间偏移(ns)
    float    driftRate;     // 时钟漂移率(ppm)
} TimeSync_t;

void compensateTimeSync(TimeSync_t *sync, ImuData_t *imu) {
    // 计算时间偏移
    int64_t offset = sync->gnssTime - sync->imuTime;
    
    // 低通滤波平滑偏移
    sync->timeOffset = 0.9f * sync->timeOffset + 0.1f * offset;
    
    // 补偿IMU数据的时间戳
    imu->compensatedTime = imu->rawTime + sync->timeOffset;
    
    // 更新漂移率估计
    static int64_t lastOffset = 0;
    sync->driftRate = (sync->timeOffset - lastOffset) / UPDATE_PERIOD_NS;
    lastOffset = sync->timeOffset;
}

我的建议：如果条件允许，尽量用硬件时间同步。比如用GNSS的PPS信号触发IMU的数据采集，这样时间误差可以控制在纳秒级。软件时间同步虽然灵活，但精度和可靠性都不如硬件方案。

好了，这五种故障模式就讲到这里。每种故障都有它的特点，也有对应的检测方法。做组合导航系统，说白了就是跟这些故障斗智斗勇。你提前想得越周全，系统在实际中就越可靠。

记住一句话：故障不可怕，可怕的是你没发现它。

📚 课程目录

2. 故障模式分析：GNSS信号丢失、多径效应、惯性传感器漂移、IMU故障、时间同步错误

2.1 GNSS信号丢失

2.2 多径效应

2.3 惯性传感器漂移

2.4 IMU故障

2.5 时间同步错误