2、多源融合思想：为什么需要多源融合、传感器互补性、融合架构概述

各位同学，咱们今天聊一个核心问题——多源融合。

说实话，我刚入行那会儿，也觉得单靠GPS就能搞定一切。直到有一次在北京国贸附近做路测，定位直接飘了30多米，车子在导航上“飞”到了楼顶上。嗯，从那以后，我再也不敢迷信单一传感器了。

2.1 为什么需要多源融合？

城市峡谷场景下，卫星信号被高楼遮挡、反射、吸收。你想想看，一辆车在CBD穿行，GPS卫星可能只能看到3颗，甚至更少。这时候单靠GNSS，定位精度能到50米就不错了。

我个人的习惯是，先问自己一个问题：“如果GNSS失效了，我的系统还能撑多久？”

答案往往很残酷——几秒钟都不行。所以我们需要多源融合，说白了就是给定位系统上“双保险”，甚至“多保险”。

多源融合不是简单的“1+1=2”，而是让不同传感器互相弥补短板。我在一个项目中遇到过，车辆进入隧道后GNSS完全失锁，但IMU+轮速计的组合还能维持10秒的亚米级定位。这就是互补性的价值。

2.2 传感器互补性分析

不同传感器就像不同性格的人，各有长处和短处。我们来看看它们怎么互补：

传感器	优势	劣势	互补对象
GNSS	绝对定位、无漂移	易受遮挡、更新率低	IMU（高频填补）
IMU	高频、短时精度高	长期漂移	GNSS（校正零偏）
视觉	语义信息、特征丰富	光照敏感、计算量大	激光雷达（深度辅助）
激光雷达	精确测距、3D感知	雨雾退化、成本高	视觉（语义理解）
轮速计	低成本、稳定	打滑、无方向信息	IMU（航向约束）

你可能会问：“这么多传感器，怎么协调它们？”

嗯，这就是融合架构要解决的问题了。

2.3 融合架构概述

融合架构，说白了就是决定“谁听谁的”、“什么时候听谁的”。我习惯把架构分为三种：松耦合、紧耦合、深耦合。它们各有适用场景，没有绝对的好坏。

2.3.1 松耦合（Loosely Coupled）

松耦合是最容易理解的方式。每个传感器独立处理自己的数据，然后输出结果，最后在决策层融合。

举个例子：GNSS输出位置，IMU输出位置，然后取加权平均。简单粗暴，但有效。

优点：实现简单、计算量小、模块独立

缺点：信息利用率低、无法处理传感器失效

2.3.2 紧耦合（Tightly Coupled）

紧耦合就高级一些了。它不是在结果层面融合，而是在观测层面融合。

比如，GNSS的伪距、载波相位观测值，直接和IMU的加速度、角速度一起送入滤波器。这样即使可见星少于4颗，也能利用部分观测信息维持定位。

优点：信息利用率高、抗干扰能力强

缺点：实现复杂、计算量大、需要精确的传感器模型

2.3.3 深耦合（Deeply Coupled）

深耦合是最高级的融合方式。它把GNSS的基带信号处理也纳入融合框架。说白了，IMU不仅辅助定位，还辅助GNSS的信号跟踪。

比如，在高动态场景下，IMU可以预测多普勒频移，帮助GNSS接收机更快锁定信号。这种架构在城市峡谷中特别有用——信号频繁中断，深耦合能实现“秒级重捕”。

我记得在深圳做测试时，车辆经过深南大道的高架桥下，GNSS信号断了3秒。深耦合系统在信号恢复后0.5秒就重新锁定，而普通接收机花了近5秒。这就是差距。

优点：极致性能、高动态适应

缺点：实现难度极高、需要定制硬件

2.4 三种架构对比

特性	松耦合	紧耦合	深耦合
融合层级	结果层	观测层	信号层
实现难度	低	中	高
计算开销	小	中	大
抗干扰能力	弱	中	强
适用场景	开阔环境	城市峡谷	高动态/强干扰

2.5 核心知识体系

下面这张图，是我自己总结的多源融合知识框架。你可以把它当作一张“地图”，后续章节都会围绕它展开。

嗯，这张图基本概括了本章的核心内容。你可能会发现，“为什么需要融合”和“传感器互补性”其实是同一个问题的两面——因为单一传感器有缺陷，所以需要互补；因为互补，所以需要融合架构来协调。

好了，这一章就到这里。记住一句话：城市峡谷里，没有万能的传感器，只有聪明的融合策略。

---