📚 课程目录第2章自动驾驶研发流程概览

2. 自动驾驶研发流程概览

自动驾驶系统不是单一模型，而是一条从传感器输入到车辆执行的长链路软件栈。理解这条链路上每个模块“实验什么、需要什么数据、如何判定成功”，是实验管理与可复现训练工程的前提。本节先建立模块级实验需求的全景，再说明数据闭环如何驱动模型持续迭代。

2.1 四模块链路与各自的实验对象

典型自动驾驶软件栈可拆为感知、预测、规划、控制四层，每层都有独立的输入输出契约与实验指标：

感知（Perception）：输入摄像头、激光雷达、毫米波雷达、IMU/GNSS 等原始数据，输出目标检测框、语义分割、车道线、可行驶区域、目标跟踪轨迹。实验重点是检测精度、召回、跟踪 ID 稳定性、时延与误检率。
预测（Prediction）：输入感知输出的动态目标历史轨迹与地图语义，输出未来数秒的多模态轨迹分布。实验重点是轨迹误差（ADE/FDE）、多模态覆盖率、交互合理性。
规划（Planning）：输入预测轨迹、高精地图、路由与交通规则，输出本车未来轨迹或行为决策序列。实验重点是安全性、舒适性、通行效率、规则合规与接管率。
控制（Control）：输入规划轨迹与车辆状态，输出油门、刹车、转向指令。实验重点是轨迹跟踪误差、执行时延、平顺性与执行器饱和情况。

四层之间是级联依赖：上游误差会被下游放大。因此实验设计必须区分“模块级离线实验”和“系统级闭环实验”，不能只用单一指标判断整栈质量。

2.2 各模块的实验需求差异

四个模块的实验形态差异很大，不能用同一套评测框架硬套。感知以离线数据集评测为主，预测强调多模态与交互，规划依赖仿真与闭环回放，控制则必须在实车或台架上验证。下表给出典型对照：

模块	主要输入	主要输出	典型实验方式	核心指标
感知	多传感器原始数据	目标框 / 分割 / 跟踪	离线数据集评测	mAP、MOTA、ID Switch、时延
预测	目标历史轨迹 + 地图	多模态未来轨迹	离线 + 交互仿真	minADE、minFDE、Miss Rate
规划	预测轨迹 + 规则 + 路由	本车轨迹 / 行为决策	仿真回放 + 闭环测试	碰撞率、接管率、舒适度、通行时间
控制	规划轨迹 + 车辆状态	油门 / 刹车 / 转向	台架 + 实车标定	横向/纵向跟踪误差、响应时延

2.3 数据闭环与模型迭代的基本流程

数据闭环的本质是：让真实世界中的失败场景，以可复现的方式回到训练与评测环节。一个完整的闭环通常包含六个阶段：

触发采集：通过接管、急刹、影子模式差异、低置信度输出等条件触发车端数据回传。
数据回传与入库：原始包上传至数据平台，完成解包、时间同步、传感器对齐。
清洗与标注：去重、去无效片段，进行自动预标注加人工修正，形成标注版本。
场景切片与数据集构建：按场景标签（如无保护左转、施工区、加塞）切片，构建训练集与回归集。
训练与离线评测：在固定数据版本与代码版本下训练，跑通回归门禁。
仿真与实车验证、发布回灌：通过仿真回放和实车验证后，以 OTA 方式发布，并继续采集新数据。

闭环的关键不是“采得多”，而是“采得准、标得对、复现得了”。如果一次失败场景无法用固定的数据版本、代码提交和随机种子重跑出来，它就无法真正进入迭代循环。

2.4 案例：一次“无保护左转”失败场景的闭环

假设实车在城市道路无保护左转时发生了一次人工接管。闭环处理流程如下：

# 1. 车端触发条件（伪配置）
trigger:
  type: takeover
  min_speed: 5km/h
  pre_seconds: 15
  post_seconds: 5
  sensors: [camera_front, lidar_top, radar_front, gnss]

# 2. 数据平台入库后生成场景切片
scene_id: unprotected_left_turn_20240612_001
tags: [urban, intersection, oncoming_traffic, takeover]
split: regression_set

# 3. 训练配置固定版本
dataset_version: ds_2024_06_15_v3
code_commit: a1b2c3d
seed: 42
config: configs/planner/urban_left_turn.yaml

# 4. 回归门禁
metrics:
  collision_rate: "<= 0.0"
  takeover_rate: "<= 0.02"
  comfort_jerk: "<= 2.5 m/s^3"

这条链路的价值在于：失败场景被固化为回归集中的一个切片，后续任何规划模型改动都必须在该切片上通过门禁，避免“修好一个、退化另一个”。

2.5 常见误区与复盘要点

误区一：只看单一模块指标。感知 mAP 提升不一定带来规划安全性提升，必须做系统级闭环验证。
误区二：数据版本与代码版本脱钩。同一份代码在不同数据版本上结果不可比，实验记录必须同时锁定两者。
误区三：忽略随机性。训练随机种子、数据采样顺序、GPU 非确定性算子都会造成结果漂移，需固定并记录。
误区四：回归集长期不更新。真实世界分布会漂移，回归集需要按周期补充新场景，否则门禁会逐渐失效。

复盘建议：每次模型迭代后，除了看总体指标，还要看“新增失败样本”和“修复样本”两类清单。前者说明模型引入了新风险，后者说明迭代真正解决了问题。

注意：数据闭环中的标注质量与场景切片策略，往往比模型结构更能决定最终效果。若标注版本管理混乱，任何“可复现”都只是表面可复现。

综上，感知、预测、规划、控制四模块各有独立的实验对象与指标，但只有通过统一的数据版本、代码版本、配置与随机种子管理，才能把车端失败场景转化为可复现的训练与评测资产，形成真正可持续的模型迭代闭环。