赛事定位
摆脱以往依托真实车辆的智能车比赛模式，转入开放世界驾驶智能体与能力边界挑战：高效测试驾驶智能体在高危、长尾工况下的交互预测、行为决策、轨迹规划能力，突出状态层面的不确定性识别，降低驾驶智能体能力边界的检验门槛。
核心模式：统一环境、标准接口、算法容器提交、服务器集中评测。参赛队只开发并提交算法容器；仿真环境、隐藏场景和正式评分均由组委会统一控制。
大组内分工：设计公开示例任务、隐藏任务难度分级、参数与场景。
大组任务内容
- 位姿恢复：从事故视频/场景数据中恢复自车及关键参与者的位姿信息，建立统一坐标表达，为后续 CARLA 注入提供基础。
- 行为表达：将位姿、行为、时序等信息转换为 CARLA 中可执行的动态 Actor、行为脚本和场景逻辑，实现统一行为表达。
- 难度分级：基于采集数据和场景参数，制定 L1/L2/L3/L4/L5 五级场景标准，定义难度边界和参数范围。
- 采集与复核：在 CARLA 中采集不同场景下的数据，纠正和复核不同事故场景以及对应的五级场景生成结果。
我负责第 4 项：在 CARLA 中采集不同场景下的数据，纠正和复核不同事故场景以及对应的五级场景生成结果。
我的任务（按优先级排序）
1. 先和上下游把接口定死（最优先）
我卡在中间环节，接口不清楚后面全返工：
- 对上游（位姿恢复组）：约定输入格式——坐标系定义（原点在哪、朝向、右手/左手系）、时间基准（频率、时间戳单位）、参与者清单（类型、尺寸、哪些算"关键参与者"）、轨迹采样间隔、置信度字段。
- 对场景标准组：拿到 L1~L5 的量化定义，而不是文字描述——每个参数的范围（车速、TTC、遮挡程度、参与者数量、光照天气等）和难度边界判据。
- 对评测组：确认数据交付格式（目录结构、metadata 字段、命名规范）。现在的 pipeline 输出的
metadata.json已经是个不错的雏形。
2. 把采集脚本工程化成"场景驱动"
现在的 data_collection_test.py 是硬编码单场景，下一步要改成：
- 场景配置文件驱动：一个 JSON/YAML 描述一张图 + 一组 actor（类型、初始位姿、轨迹/行为脚本、触发）→ 采集器读配置自动生成，不再改代码。
- 批量运行能力：循环跑 N 个场景 × M 个随机种子，无人值守，失败自动记录跳过。
- 确定性保证：同步模式 + 固定种子，同一场景重放结果一致（这是"复核"工作的前提）。
3. 补齐"轨迹注入"能力（和现有 TM 方式不同）
事故复现的核心难点：NPC 不能交给 Traffic Manager 自由发挥，必须精确复现源数据轨迹。要准备两种模式：
- 确定性回放：每帧
set_transform()按采样轨迹硬摆位（最精确，但无物理）。 - 轨迹跟踪控制：
apply_control+ 速度/航向闭环跟踪轨迹点（有物理、可被自车交互影响，但会跑偏）。
两种都要验证精度：位置误差、到达关键时刻（碰撞点）的时间误差。
4. 建立"复核"的量化标准（核心职责）
"纠正和复核"不能靠眼睛看视频，要有 checklist 和自动校验：
- 轨迹保真度：CARLA 内实际轨迹 vs 源数据轨迹的逐帧位置/航向误差，定阈值（如位置 < 0.3 m）。
- 关键事件核验：碰撞是否发生、碰撞时刻、最小 TTC、最小间距——可以写脚本从
ground_truth.csv自动算。 - 五级定级核验：用同一脚本从 GT 提取难度指标（车速、TTC 分布、交互次数），检查是否落在该级的参数范围内。
- 传感器数据质量：已有的文件数校验 + 图像抽查（遮挡、曝光异常）。
5. 环境与工具链固化
- 版本统一：我现在是 0.9.16 Server，组里其他人可能用 0.9.15——尽快统一，并把 Server 安装包、egg、地图包（Town10HD 是额外下载的）存档分发。
- 场景库选型：确定用哪些地图、是否引入 OpenSCENARIO（
scenario_runner是 CARLA 官方场景工具，值得评估，比赛方很可能用它做标准接口）。 - 存储预算：RGB 1280×720 PNG 约 1
2 MB/帧，15 秒场景约 500 MB1 GB，批量前规划好磁盘。
6. 近期行动顺序
- 找场景标准组要 L1
L5 量化定义草案（没有就推动先出 35 个示例任务的定义）。 - 现有脚本重构为"配置驱动 + 批量运行 + 自动校验"的采集器 v1。
- 用 1 个真实事故恢复数据走通"位姿 → 注入 → 回放 → 误差核验"全流程。
- 用同一配置连跑 3 次验证确定性。
- 输出一份《场景采集与复核规范》草案给大组评审。