2. 定位系统架构概览：Autoware定位模块的组成与数据流
好，我们直接进入正题。定位模块是自动驾驶的「眼睛」和「大脑」——它得知道自己到底在哪儿。Autoware的定位系统，说白了，就是一套多传感器融合的方案。我习惯把它拆成五个核心部件：GNSS、IMU、LiDAR、轮速计、地图匹配。它们各自有脾气，但合在一起，才能稳定输出。
2.1 五大传感器，各司其职
先聊聊每个传感器是干嘛的。你想想看，如果只用一种传感器，肯定翻车。比如GNSS进隧道就废了，IMU长时间会飘。所以得组合。
- GNSS（全球导航卫星系统）：提供绝对位置，精度米级到厘米级（RTK）。但信号遮挡就完蛋。我在项目中遇到过，高架桥下GNSS直接跳变3米，差点把车带沟里。
- IMU（惯性测量单元）：测量加速度和角速度，短时精度极高。但积分久了，误差累积。嗯，这里要注意，IMU的零偏是最大的坑。
- LiDAR（激光雷达）：扫描周围点云，用于匹配地图。精度厘米级，但怕雨雪、怕灰尘。我曾经在工地测试，扬尘一起，点云直接糊了。
- 轮速计（Wheel Odometry）：从车轮转数推算速度。简单可靠，但打滑就废。比如冰雪路面，轮速计会给你一个假速度。
- 地图匹配（Map Matching）：将LiDAR点云与高精地图对齐，得到位姿。这是定位的最后一道防线。
核心观点：没有哪个传感器是完美的。融合的目的，就是取长补短。我个人习惯把GNSS和地图匹配当作「长期校正」，IMU和轮速计当作「短期预测」。
2.2 数据流与融合逻辑
数据怎么流？我画了一张图，帮你理清脉络。说白了，就是「预测+观测」的循环。
流程其实不复杂：
- 预测阶段：IMU和轮速计做高频预测（100Hz以上），推算短时间内的位姿变化。我习惯把IMU的角速度积分成姿态，轮速计的速度积分成位置。
- 观测阶段：GNSS和地图匹配做低频校正（10Hz左右）。GNSS给绝对位置，地图匹配给相对地图的位姿。
- 融合：用扩展卡尔曼滤波（EKF）把预测和观测拧在一起。说白了，就是「信谁多一点」的问题。
我的经验：EKF的噪声矩阵调参是个玄学。我曾经在高速场景下，把IMU的噪声设得太小，结果车飘了。建议先跑仿真，再上路。
2.3 融合逻辑的细节
为什么用EKF？因为系统是非线性的。比如车辆的航向角变化，不是简单的加减法。EKF通过线性化近似，解决了这个问题。
具体来说，状态向量通常包含：
| 状态量 | 符号 | 来源 |
|---|---|---|
| 位置（x, y, z） | p | GNSS / 地图匹配 |
| 姿态（roll, pitch, yaw） | θ | IMU 积分 |
| 速度（vx, vy, vz） | v | 轮速计 / IMU |
| IMU零偏 | b | 在线估计 |
嗯，这里要注意：IMU的零偏如果不估计，几分钟后位置误差就能到几十米。我建议把零偏也放进状态向量，在线实时更新。
警告：千万别忽略时间同步！不同传感器的采样时刻不一样，直接融合会出大问题。我曾经因为GNSS和IMU的时间戳差了50ms，导致定位结果来回跳。解决方案是用硬件同步或软件插值。
2.4 代码示例：EKF预测步骤（简化版）
给你看一段伪代码，理解一下预测阶段怎么做的。实际工程中会更复杂，但核心逻辑不变。
// 预测步骤（IMU + 轮速计驱动）
void predictState(State &x, double dt) {
// 用IMU角速度更新姿态
x.roll += imu.gyro.x * dt;
x.pitch += imu.gyro.y * dt;
x.yaw += imu.gyro.z * dt;
// 用轮速计速度更新位置
double v = wheel_odom.speed;
x.x += v * cos(x.yaw) * dt;
x.y += v * sin(x.yaw) * dt;
// 更新协方差矩阵（略）
// P = F * P * F^T + Q
}你看，代码很短。但实际工程里，还要考虑地球曲率、坐标系转换、杆臂效应补偿。我建议你从简单开始，逐步加复杂度。
2.5 避坑指南
- 我曾经在隧道里只靠IMU+轮速计，结果跑了2公里后，位置误差超过10米。后来加了地图匹配，才稳住。
- 我建议：在融合逻辑里加入「传感器健康检查」。比如GNSS信号差时，自动降低它的权重。
- 其实，定位模块的调试，80%的时间花在数据预处理上。时间同步、坐标转换、异常值剔除，这些做好了，融合自然稳。
好，这一章就到这里。记住：定位架构的核心是「多传感器冗余+EKF融合」。下一章我们会深入EKF的数学细节，但今天先把框架搭起来。