2. 自动驾驶系统概览

自动驾驶系统并不是一个“从摄像头直接输出方向盘转角”的黑箱，而是一条由多个模块串联、彼此约束的实时数据链路。理解这条链路上每个模块的职责边界，是后续做路径规划调优与验证的前提：只有知道规划模块“能拿到什么、必须输出什么、不能替谁做决定”，才能判断一次轨迹抖动究竟该归因于感知噪声、预测误差，还是规划自身的代价函数设计问题。

一、核心原理：五模块的分工与数据契约

典型的自动驾驶软件栈可划分为感知、定位、预测、规划、控制五个核心模块，它们以固定的频率和明确的数据契约协同工作：

• 感知（Perception）：把原始传感器数据（摄像头、激光雷达、毫米波雷达）转换为结构化环境描述，输出障碍物列表、车道线、可行驶区域、交通标志与信号灯状态。它回答“周围有什么、在哪里”。
• 定位（Localization）：融合 GNSS、IMU、轮速计与高精地图匹配，输出自车在全局坐标系下的位姿（位置、姿态、速度）。它回答“我在哪里、朝向如何”。
• 预测（Prediction）：基于感知到的动态障碍物历史轨迹与地图语义，推断其未来数秒的可能运动轨迹及概率。它回答“别人接下来可能怎么动”。
• 规划（Planning）：在自车位姿、静态地图、动态障碍物预测结果和交通规则约束下，生成一条安全、舒适、合法的行驶轨迹。它回答“我该怎么走”。
• 控制（Control）：把规划轨迹转换为油门、刹车、转向的具体执行量，并通过闭环反馈跟踪轨迹。它回答“如何精确执行”。

关键点在于：规划模块是“决策与几何”的交汇点。它不直接处理像素或点云，也不直接输出扭矩，而是消费上游的语义结果、向下游输出带时间戳的轨迹点序列。这条边界一旦模糊，例如让规划去补偿定位漂移，系统就会变得难以调试。

二、方法流程：一次规划周期的数据流转

以城市道路跟车场景为例，一个典型规划周期（约 100 ms）内的数据流转如下：

1. 感知输出前方 60 m 内目标车辆的位置、速度、朝向，并给出置信度；
2. 定位给出自车在当前车道内的横向偏移与航向角；
3. 预测模块基于目标车辆历史 2 s 轨迹，输出未来 5 s 的 3 条候选轨迹及概率；
4. 规划模块结合地图限速、跟车时距约束与舒适度代价，生成一条平滑的纵向减速轨迹；
5. 控制模块将轨迹离散为参考点，通过横向 LQR 与纵向 PID 计算执行量。

可以看到，规划模块的输入是“语义化、带不确定性的世界描述”，输出是“带时间维度的几何轨迹”。它既不负责识别目标，也不负责执行精度，因此调优时必须区分：轨迹抖动是预测轨迹跳变引起的，还是规划自身优化器不稳定造成的。

三、案例场景：职责边界模糊导致的典型问题

某项目在路口右转时出现“轨迹反复横摆”。排查发现：感知对路沿的检测在逆光下间歇丢失，规划模块为保持安全距离不断重新生成绕行轨迹，而控制模块又忠实跟踪这些跳变轨迹。问题根因并不在规划算法本身，而在于感知置信度未被显式传递到规划层，规划无法判断“这个障碍物是否可信”。

四、误区与复盘：规划不是“万能补偿器”

常见误区包括：

• 让规划补偿定位漂移：定位误差属于状态估计问题，规划补偿会引入额外横向偏移，反而破坏安全性；
• 让规划预测他车意图：预测与规划耦合过深会导致接口混乱，应保持“预测给分布、规划做决策”的分工；
• 用控制参数掩盖规划不平滑：控制层滤波只能缓解抖动，无法消除轨迹本身的曲率突变。

下表给出五模块的职责边界与典型输出，可作为接口评审与问题归因的检查清单：