一、场景概述：什么是高速场景轨迹回放？为什么需要做轨迹回放测试？
1.1 先聊聊“轨迹回放”到底是个啥
各位同学好，我是老张，在自动驾驶测试这行摸爬滚打了七八年。
咱们先直白点说——轨迹回放，就是把车在路上跑过的数据录下来，然后在仿真环境里重新放一遍。
你想想看，就像看比赛录像一样。运动员下场后，教练会反复看录像，分析每个动作哪里做得好、哪里有问题。轨迹回放也是这个道理。
但这里有个关键点：高速场景。为什么单拎高速出来说？
我个人习惯把场景分成两类：
- 城区场景：速度慢、路口多、行人复杂，考验的是感知和决策的“细活”
- 高速场景：速度快、车道线清晰、变道频繁，考验的是规划和控制的“稳活”
说白了，高速上120km/h的速度，你每秒钟要跑33米。决策晚100毫秒，车就冲出去3米多。这个容错空间，比城区小太多了。
核心定义：高速场景轨迹回放，是指将车辆在高速公路真实路测中采集的轨迹数据（包含位置、速度、加速度、方向盘转角、油门/刹车信号等），在仿真环境中按时间轴精确复现，用于验证和评估自动驾驶系统的行为表现。
1.2 为什么非要做轨迹回放测试？
这个问题，我当年刚入行时也问过师傅。师傅反问我一句：“你愿意让一辆没经过轨迹回放验证的车，载着你上高速吗？”
嗯，我懂了。
具体来说，有这几个硬核原因：
原因一：真实路测成本太高，跑不起
我算过一笔账。一台自动驾驶测试车，改装费少说几十万。加上传感器标定、维护、保险、油费电费，还有测试员的人工成本。跑一天高速路测，轻轻松松烧掉几千块。
而且高速路测还有个麻烦——场景不可控。你想测试某个特定的危险场景，比如前车急刹、侧方车辆强行加塞，你没法让真实车辆去“演”这个场景。太危险了。
轨迹回放就不一样了。一次路测采集的数据，可以在仿真里回放几百遍、几千遍。成本几乎为零。
原因二：复现问题，是调试的第一步
我在项目中遇到过最头疼的事——路测时系统出了个诡异行为，但当时数据没录全，回去想复现却怎么也复现不出来。
你想想看，问题复现不了，你怎么修？
轨迹回放正好解决这个问题。只要数据录得够全，你就能在办公室里把当时的路况、车辆状态、系统输出全部还原。然后一行一行代码去查，到底是规划出了问题，还是控制没跟上。
我的经验：数据采集时，千万别省存储空间。我建议至少录这些信号——GPS位置、IMU姿态、轮速、方向盘转角、油门开度、制动压力、目标物列表、自车轨迹规划结果。宁可多录，不可少录。
原因三：回归测试，保证改一处不坏一片
自动驾驶系统是个极其复杂的软件栈。你改了规划模块的一个参数，可能变道逻辑好了，但跟车距离又出问题了。
怎么办？
把之前所有跑过的高速场景，全部回放一遍。看看新版本有没有引入新的问题。这就是回归测试。
我见过一个团队，每次发版前要跑2000多个场景的轨迹回放。虽然耗时，但确实大大降低了上路出事故的概率。
1.3 高速场景轨迹回放的核心流程
下面这张图，是我自己总结的高速场景轨迹回放测试流程。你看一眼，心里就有谱了。
1.4 轨迹回放测试的“坑”与避坑指南
做这行久了，踩过的坑真不少。我挑几个典型的说说：
坑一：时间戳不同步
我曾经遇到过一个问题——回放时车辆轨迹和感知目标总是对不上。查了两天才发现，GPS用的是UTC时间，相机用的是系统时间，差了整整200毫秒。
避坑建议：所有传感器必须统一时间基准。推荐用GPS的PPS信号做硬件同步，或者至少用NTP做软件同步。
坑二：坐标转换搞错
有一次回放时，车辆轨迹在仿真里直接“飞”出去了。后来发现是坐标转换时，把经纬度转UTM的带号算错了。
避坑建议：写一个坐标转换的单元测试，每次改完代码先跑一遍。别问我怎么知道的。
我的小技巧：回放时，我会在仿真界面上同时显示“真实轨迹”和“算法输出轨迹”。两条线一对比，哪里有问题一目了然。这个可视化技巧，后面章节我会详细讲。
1.5 本章小结
好了，咱们捋一下这章的核心：
| 知识点 | 核心内容 |
|---|---|
| 什么是轨迹回放 | 把真实路测数据在仿真环境中重新播放，用于验证系统行为 |
| 为什么需要 | 降低成本、复现问题、回归测试 |
| 核心流程 | 数据采集 → 预处理 → 场景提取 → 仿真回放 → 结果分析 → 问题定位 |
| 常见坑点 | 时间不同步、坐标转换错误、数据缺失 |
说实话，轨迹回放测试看起来简单，就是把数据放一遍嘛。但真正做起来，里面的门道不少。数据怎么采、怎么处理、怎么分析，每一步都有讲究。
后面的章节，我会带着大家一步步把这些细节都讲透。咱们下章见。