2. 自动驾驶系统基础
自动驾驶系统并不是一个“端到端黑盒”就能完全解释的工程对象。即便在端到端模型逐渐流行的今天，量产系统仍然普遍采用分层解耦的架构：感知负责回答“周围有什么”，预测负责回答“它们接下来会怎么动”，规划负责回答“我该怎么走”，控制负责回答“如何把规划变成方向盘、油门和刹车的具体动作”。理解这条数据流，是理解 Hard Case 从何而来、又该被归到哪一层去闭环的前提。
一、四大模块的核心职责
感知模块把传感器原始数据转换为结构化环境描述。摄像头提供语义与纹理，激光雷达提供精确三维几何，毫米波雷达提供速度与穿透能力，IMU/轮速/GNSS 提供自车状态。感知输出通常包括：障碍物列表（位置、尺寸、朝向、速度）、车道线与路沿、可行驶区域、交通标志与信号灯状态、以及自车定位结果。感知的核心难点在于遮挡、截断、远距离小目标、恶劣天气与传感器不一致。
预测模块接收感知输出的动态障碍物，推断其未来数秒的轨迹分布。它要处理交互博弈（如加塞、汇入）、意图不确定性（是否变道、是否让行）以及多模态未来（可能左转也可能直行）。预测输出往往是多条带概率的轨迹，而非单一确定轨迹。
规划模块结合预测结果、地图、交规与自车状态，生成一条安全、舒适、合法的行驶轨迹。它通常分为全局路由、行为决策（变道/跟车/让行）和局部轨迹优化三层。规划要在“安全”与“通行效率”之间做权衡，是 Hard Case 最集中的战场。
控制模块把规划轨迹转化为横纵向控制指令，通过 PID、MPC 等控制器输出转向角、加速度与制动压力，并处理执行器延迟、标定误差与车辆动力学非线性。
二、数据流与系统架构
四个模块以流水线方式串联，同时存在大量反馈回路：控制的实际执行结果会影响自车状态，进而影响感知与预测的输入；规划若发现轨迹不可行，也会回退请求重新决策。下图展示了这一数据流与 Hard Case 的典型落点。
三、Hard Case 在架构中的位置
Hard Case 不是某一层的专属问题，而是数据流中某个环节的输出与预期发生显著偏差的场景。定位 Hard Case 的第一步，就是判断它发生在哪一层：
- 感知层 Hard Case：目标漏检、误检、位置跳变、车道线断裂。典型如隧道出口逆光、大车遮挡下的行人、雨夜反光。
- 预测层 Hard Case：他车行为与预测分布严重不符，如静止车辆突然开门、旁车连续变道、行人折返。
- 规划层 Hard Case：轨迹不可行、决策犹豫、博弈僵持、违反交规或舒适性骤降。
- 控制层 Hard Case：跟踪误差大、执行抖动、响应延迟导致的安全距离不足。
四、案例：一次“鬼探头”的逐层回溯
假设车辆在城市道路以 40 km/h 行驶，右侧公交车停靠，突然一名行人从公交车前方横穿，车辆紧急制动。复盘时可按数据流逐层检查：
- 感知：行人是否在遮挡解除后的第一帧被检出？检测框是否稳定？
- 预测：行人轨迹是否被预测为横穿？概率是否足够高？
- 规划：是否提前减速？制动决策是否过晚？
- 控制：制动指令是否及时执行？减速度是否达到预期？
若感知在遮挡解除后 200 ms 才检出，则 Hard Case 主因在感知；若感知及时但预测未给出横穿意图，则主因在预测；若前两者正常而规划未减速，则主因在规划。这种分层归因是闭环工程的核心方法。
五、常见误区与复盘要点
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 只看最终表现归因 | 急刹就改控制参数 | 沿数据流逐层回溯，定位最早偏差 |
| 把 Hard Case 当单点 bug | 修一个场景，同类问题反复出现 | 抽象为场景族，批量挖掘与回归 |
| 忽略模块间耦合 | 感知抖动被预测放大 | 关注接口稳定性与置信度传递 |
| 缺少统一数据回放 | 无法复现，争论不休 | 建立带时间戳的全链路数据闭环 |
六、数据闭环中的关键接口
为了让 Hard Case 可挖掘、可复现、可回归，系统需要保留关键中间结果。典型接口数据包括：
perception:
objects: [{id, type, pose, velocity, confidence}]
lanes: [{id, points, confidence}]
prediction:
trajectories: [{id, modes: [{prob, points}]}]
planning:
decision: {behavior, target_speed, trajectory}
control:
cmd: {steer, accel, brake}
feedback: {actual_steer, actual_accel, timestamp}
这些接口不仅是模块间的契约，也是 Hard Case 挖掘的数据金矿。只有把每一层的输入输出都记录下来，才能在复盘时回答“偏差从哪一层开始”。