坐标变换基础：为什么自动驾驶需要坐标变换？

大家好，我是这次课程的主讲工程师。咱们直接开门见山——坐标变换，说白了就是自动驾驶系统的“通用语言”。

你想想看，一辆车上装了激光雷达、摄像头、毫米波雷达、GPS/IMU……每个传感器都有自己的“小世界”。激光雷达说“前方5米有个障碍物”，摄像头说“图像右下角有个行人”，GPS说“我在北纬39.9度”。这些数据如果不统一到一个坐标系里，系统根本没法做决策。

我刚开始接触自动驾驶时，就踩过这个坑。有一次调试障碍物融合模块，激光雷达检测到的障碍物位置和摄像头检测到的总是对不上。折腾了两天，最后发现是激光雷达的安装位置没做坐标补偿。嗯，从那以后，我再也不敢轻视坐标变换了。

全局坐标系与局部坐标系

先搞清楚两个基本概念：

• 全局坐标系：也叫世界坐标系。它固定在地球上，通常用经纬度+海拔，或者UTM坐标（通用横轴墨卡托投影）。所有车辆的规划路径、高精地图数据，都在这个坐标系里。
• 局部坐标系：也叫车身坐标系或传感器坐标系。它跟着车动，原点一般在车辆后轴中心、质心或者传感器安装点。x轴朝前，y轴朝左，z轴朝上（符合右手定则）。

举个例子：高精地图告诉你“前方100米有个弯道”，这是全局坐标。但你的车需要知道“我现在相对于这个弯道在什么位置”，这就需要把地图数据转换到车身坐标系下。说白了，全局坐标是“地图视角”，局部坐标是“司机视角”。

为什么需要坐标变换？三个核心原因

1. 传感器融合：不同传感器的数据必须对齐到同一个坐标系，才能做目标检测、跟踪和融合。比如激光雷达的点云和摄像头的图像，需要通过标定矩阵映射到同一空间。
2. 规划与控制：路径规划在全局坐标系下进行，但控制指令（方向盘转角、油门）需要在车身坐标系下执行。中间必须做坐标变换。
3. 时间同步：每个传感器都有不同的采样频率和延迟。坐标变换不仅要考虑空间对齐，还要考虑时间对齐。我遇到过因为时间戳没对齐，导致障碍物位置“跳变”的诡异问题。

Apollo中的坐标变换体系

在Apollo框架里，坐标变换主要由 Transform 模块负责。它维护了一棵“坐标树”，记录了所有坐标系之间的相对关系。

举个例子，常见的坐标变换链：

World -> Localization -> Chassis -> Lidar -> Camera

每个箭头代表一个变换矩阵（平移+旋转）。Apollo用 tf2 库来管理这些变换，你只需要知道两个坐标系的名字，就能随时查询它们之间的变换关系。

坐标变换的数学本质

别怕，这里不讲复杂的公式。你只需要记住：坐标变换 = 旋转 + 平移。

旋转用旋转矩阵或四元数表示，平移就是一个三维向量。Apollo里常用 Eigen::Affine3d 或 math::Quaternion 来封装这些变换。

我个人的习惯是：能用四元数就别用欧拉角。欧拉角有万向锁问题，调试起来很头疼。四元数虽然看着抽象，但计算稳定，插值也方便。

避坑指南

嗯，这些坑你大概率也会遇到。提前打个预防针。

本章知识体系

下面这张图，帮你理清坐标变换在自动驾驶中的位置：

这张图展示了坐标变换的完整链路：从全局坐标系出发，经过局部坐标系，最终服务于感知、规划、控制等应用模块。中间的核心组件就是Transform模块和tf2库。

小结

这一章我们聊了坐标变换的必要性，以及全局坐标系和局部坐标系的概念。说白了，没有坐标变换，自动驾驶系统就是“聋子对话”——各说各的，谁也听不懂谁。

下一章，我们会深入Apollo的Transform模块，看看代码里到底是怎么实现这些变换的。到时候我会带你看几个实际案例，包括我当年调试时踩过的坑。