一、定位系统架构概览：Autoware定位模块的组成

大家好，我是这次课程的主讲工程师。今天咱们来聊聊Autoware定位模块的整体架构。

说实话，定位模块是自动驾驶系统里最容易被低估的部分。很多人觉得「不就是知道车在哪吗」，但真正做过实车测试的工程师都明白——定位一旦漂移，整个系统就像丢了魂一样。我在早期做路测时，就遇到过定位跳变导致车辆急刹的惊险场面。从那以后，我对定位架构的每个环节都格外较真。

1.1 定位模块的核心任务

先问大家一个问题：自动驾驶定位到底要解决什么？

说白了就三件事：

• 我在哪 —— 全局坐标系下的位置和姿态
• 我周围有什么 —— 相对于道路、障碍物的位置关系
• 我接下来会到哪 —— 速度和航向的预测

Autoware的定位模块，就是通过融合多种传感器，来回答这三个问题。嗯，这里要注意，单一传感器永远靠不住，这是我在项目里摔过跟头才明白的。

1.2 五大传感器组成

Autoware定位模块主要依赖以下五个信息来源。我习惯把它们分成两类：绝对定位源和相对定位源。

传感器	类型	输出频率	精度特点
GNSS	绝对定位	10 Hz	室外精度米级，RTK可达厘米级
IMU	相对定位	100-200 Hz	短期精度高，长期会漂移
LiDAR	相对定位	10-20 Hz	点云匹配精度可达5cm
轮速计	相对定位	50-100 Hz	纵向速度准确，横向误差大
地图匹配	绝对定位	1-10 Hz	依赖高精地图质量

你想想看，如果只用GNSS，进隧道就完蛋。只用IMU，跑个几百米就开始飘。所以必须融合——这是定位架构设计的底层逻辑。

1.3 各传感器在架构中的角色

GNSS：全局锚点

GNSS提供最直接的全局坐标。但我在项目中遇到过一个问题：城市峡谷里多路径效应严重，定位能跳出去十几米。所以Autoware里GNSS通常只作为初始化参考，或者作为卡尔曼滤波的观测输入，而不是直接拿来用。

IMU：高频骨架

IMU提供角速度和加速度。我个人习惯把IMU看作定位系统的「骨架」——它决定了100Hz以上的姿态更新。但IMU的零偏会随时间变化，嗯，这里有个坑：温度变化会导致零偏漂移，我曾经在夏天路测时吃过这个亏。

LiDAR：环境匹配器

LiDAR通过点云匹配（NDT或ICP）来修正位置。这是Autoware定位模块的亮点。我记得第一次看到NDT匹配效果时，确实被惊艳到了——在特征丰富的场景下，精度能到厘米级。

但LiDAR匹配也有弱点：

• 空旷场景下特征稀疏，匹配容易发散
• 动态物体（车辆、行人）会干扰匹配结果
• 计算量大，对算力有要求

轮速计：低成本速度源

轮速计提供车速信息。虽然精度不如IMU，但它不会漂移。我在项目中常用轮速计来约束IMU的纵向积分误差。说白了，轮速计就是给IMU「踩刹车」的。

地图匹配：先验约束

地图匹配利用高精地图中的路标、车道线等特征，对定位结果进行约束。这相当于给定位系统加了一个「地理围栏」——你不可能跑到马路牙子外面去。

1.4 架构核心逻辑：多传感器融合

Autoware定位模块的架构，本质上是一个松耦合的扩展卡尔曼滤波（EKF）框架。我画了一张图来展示这个流程：

从这张图可以看到，整个流程分三步：

1. 传感器数据预处理 —— 每个传感器都有自己的「小脾气」，需要单独处理
2. EKF融合 —— 用IMU+轮速计做预测，用GNSS+LiDAR+地图做观测修正
3. 位姿输出 —— 最终得到6自由度的车辆位姿

1.5 避坑指南：我踩过的三个坑

1.6 小结

Autoware定位模块的架构，说白了就是「多源互补、融合为王」。GNSS给全局锚点，IMU撑高频骨架，LiDAR做环境匹配，轮速计约束漂移，地图匹配提供先验——五者缺一不可。

理解了这个架构，你就能明白：定位漂移不是某一个传感器的问题，而是融合逻辑出了问题。后续章节我们会深入每个传感器的细节，以及如何诊断和修复漂移问题。