4. 组合导航系统故障分类

做组合导航这么多年,我最大的体会就是:故障不会等你准备好了才来。它往往在你最放松的时候,给你来个措手不及。

所以,搞故障诊断的第一步,不是学算法,而是先搞清楚——故障到底长什么样?

我个人习惯把故障分类当作「故障画像」。就像警察破案要先给嫌疑人画像一样,我们诊断故障,也得先知道它属于哪一类。下面我就从三个维度,给你讲讲我这些年总结的分类方法。

组合导航故障分类 按故障来源 传感器故障 算法故障 通信故障 按故障性质 硬故障 软故障 按时间特性 突变故障 缓变故障 间歇性故障 故障诊断 = 来源定位 + 性质判断 + 时间特性分析 三者结合,才能精准锁定问题根源

4.1 按故障来源分类

这是最直观的分类方式。说白了,就是问一句:问题出在哪个环节?

4.1.1 传感器故障

传感器是组合导航的「眼睛」和「耳朵」。它们一旦出问题,整个系统就瞎了。

常见的传感器故障包括:

  • IMU 故障:陀螺仪漂移、加速度计偏置突变。我记得有一次在跑车实验,IMU 的 Z 轴陀螺突然跳了 0.5°/s,结果航向角直接飞了。
  • GNSS 故障:卫星失锁、多路径效应、周跳。城市峡谷里,GNSS 信号被高楼遮挡,定位误差能到几十米。
  • 磁力计故障:硬磁/软磁干扰。你想想看,地铁站附近测出来的磁航向,能信吗?
  • 气压计故障:温度漂移、堵塞。无人机飞着飞着高度突然跳变,多半是它。
💡 我的经验: 传感器故障有个特点——数据会「反常」。比如 IMU 输出突然变成常数,或者 GNSS 定位结果跳来跳去。我一般会先看原始数据的时间序列,有没有毛刺、有没有死区,一眼就能看出来。

4.1.2 算法故障

算法故障比较隐蔽。传感器没问题,但算法算错了,结果照样不对。

常见的算法故障有:

  • 滤波发散:卡尔曼滤波的协方差矩阵非正定,或者量测噪声设置不合理。我曾经调一个 EKF,调了三天,最后发现是 Q 矩阵设小了,滤波器「过于自信」,结果直接发散。
  • 初始化错误:初始姿态、位置给错了,后面再怎么滤波也救不回来。
  • 时间不同步:IMU 和 GNSS 的时间戳没对齐。嗯,这里要注意,差 10 毫秒,对于高动态场景,误差就能到米级。
  • 坐标系转换错误:导航系和载体系搞反了。我见过最离谱的,是把 ENU 当 NED 用,结果高度反了。
⚠️ 避坑指南: 我曾经在项目里遇到一个「幽灵故障」——传感器数据正常,滤波也不发散,但定位结果就是不对。查了两天,最后发现是算法里一个矩阵转置写错了。所以,算法故障往往比传感器故障更难排查

4.1.3 通信故障

通信故障是「连接」的问题。数据传不过去,或者传错了,系统照样罢工。

常见表现:

  • 数据丢包:串口、CAN 总线、以太网,哪个环节都可能丢。丢一帧还好,连续丢就完了。
  • 数据延迟:实时性要求高的系统,延迟 100ms 就是灾难。
  • 数据错位:帧头帧尾解析错误,导致数据错位。我遇到过 IMU 的加速度和角速度字段互换,结果解算出来的姿态完全不对。
  • 总线冲突:多传感器共享总线时,优先级设置不当,导致关键数据被挤掉。

4.2 按故障性质分类

这个分类角度,关注的是故障的「严重程度」和「可恢复性」。

4.2.1 硬故障

硬故障,说白了就是物理损坏。传感器坏了、线断了、芯片烧了。

特点:

  • 故障明显,容易检测(比如数据直接没了)
  • 不可恢复,必须更换硬件
  • 通常表现为数据中断或固定值

我记得有一次在野外测试,IMU 被太阳晒得温度过高,直接保护性关机了。这就是典型的硬故障——数据直接归零。

4.2.2 软故障

软故障就「狡猾」多了。硬件没坏,但数据不准。

特点:

  • 故障隐蔽,数据看起来「好像还行」
  • 可恢复(比如重新标定、重启算法)
  • 通常表现为精度下降、漂移、偏置

你想想看,IMU 的零偏从 0.01°/h 漂到 0.1°/h,你从数据上看不出异常,但导航误差会慢慢变大。这种故障最头疼。

🔑 关键区别: 硬故障是「有和无」的问题,软故障是「好和差」的问题。诊断软故障,需要更精细的统计方法。

4.3 按故障时间特性分类

这个维度,关注的是故障的变化速度。我个人觉得,这是最实用的分类方式,因为它直接决定了你用什么诊断方法。

4.3.1 突变故障

突变故障,就是瞬间发生的故障。数据在某个时刻突然跳变。

典型场景:

  • GNSS 周跳:载波相位突然跳几个整数周
  • IMU 数据毛刺:受到强电磁干扰,输出瞬间跳变
  • 通信中断:数据流突然停止

诊断方法:一般用残差检测卡方检验。我习惯在卡尔曼滤波里加一个「新息检测」模块,一旦新息超过 3 倍标准差,就报警。

4.3.2 缓变故障

缓变故障是慢慢恶化的。数据一点点偏离正常值,很难察觉。

典型场景:

  • IMU 温度漂移:随着温度升高,零偏慢慢变大
  • GNSS 多路径效应:在城市峡谷中,误差逐渐累积
  • 传感器老化:性能逐年下降

诊断方法:需要用趋势分析机器学习。我曾经用 LSTM 网络检测 IMU 的缓变漂移,效果还不错。

⚠️ 注意: 缓变故障是最危险的。因为它「温水煮青蛙」,等你发现的时候,导航误差已经大到不可接受了。我建议在系统里加一个长期监控模块,定期评估传感器性能。

4.3.3 间歇性故障

间歇性故障,就是时好时坏。故障出现一会儿,又自己恢复了。

典型场景:

  • GNSS 信号遮挡:过桥洞时信号丢失,出来又恢复
  • 通信干扰:偶尔丢一帧数据
  • 电源波动:电压不稳导致传感器偶尔异常

诊断方法:需要事件记录模式识别。我一般会记录每次故障发生的时间、持续时长、频率,然后分析有没有规律。

💡 小技巧: 间歇性故障最难复现。我建议在系统里加一个「黑匣子」——循环存储最近 10 分钟的所有原始数据。一旦故障出现,立刻冻结数据,方便事后分析。

4.4 三种分类的综合运用

实际工作中,我不会只用一种分类。我会把三种分类结合起来,给故障做一个「三维画像」。

故障实例 按来源 按性质 按时间特性
IMU 零偏突然变大 传感器故障 软故障 突变故障
GNSS 信号被遮挡 传感器故障 软故障 间歇性故障
卡尔曼滤波发散 算法故障 软故障 缓变故障
串口线断了 通信故障 硬故障 突变故障
IMU 温度漂移 传感器故障 软故障 缓变故障

你看,同一个传感器故障,可能是突变(零偏跳变),也可能是缓变(温度漂移),还可能是间歇性(信号遮挡)。所以,分类不是目的,诊断才是

我个人习惯,在系统设计阶段就把这三种分类考虑进去。比如,我会在软件里同时部署:

  • 突变检测模块(卡方检验、残差分析)
  • 缓变检测模块(滑动窗口均值、趋势拟合)
  • 间歇性检测模块(事件计数器、时间戳记录)

这样,不管什么故障来了,我都能第一时间知道它「是谁、从哪来、怎么变」。


好了,这一章的内容就到这里。故障分类是诊断的基础,就像盖房子要先打地基一样。下一章,我会讲讲具体的故障诊断方法——怎么用这些分类去定位问题。

专注资料整理