自动驾驶测试中的Re-simulation技术

       随着自动驾驶技术的发展，自动驾驶仿真的重要性越来越大。一是体现在上路之前可以通过仿真进行初步验证，二是体现在路上遇到问题时，可以通过仿真进行数据回放，改善算法模块性能。

       平时常见的自动驾驶仿真主要是利用软件搭载测试场景，然而，随着data-driven技术的发展，如何利用庞大的道路数据提高仿真性能，成为一个有意思的话题。这两天读到一篇文章，分享一下。原文出处为国外一家公司官网，链接：使用重新模拟来验证 AV 堆栈以防脱离。

        先简单介绍一下背景。

        在早期测试期间，高级驾驶辅助系统 (ADAS) 和自动驾驶汽车 (AV) 工程团队主要使用联合仿真来测试他们的自动驾驶系统。随着 ADAS 和 AV 系统的成熟，需要更多的道路测试来验证车辆（自我）是否能够安全地处理在其操作设计域 (ODD) 中可能发生的大量可能事件。 

     平均接管率（自动驾驶汽车行驶一段距离平均接管的次数）通常作为一个评判性能的指标，但是当遇到危险情况，安全员接管车辆后，这个问题不能就这么过去了。因为安全员是凭借自我主观意识判断当前路况比较危险且需要接管，如果这个安全员比较保守，就有可能在算法做出决策前进行干预，所以就需要将这个事件进行回放，观察算法的实际表现情况，进而进行算法升级。

        在道路测试期间，自我可能会遇到脱离（即，安全驾驶员脱离系统并接管车辆控制的事件）。ADAS 和 AV 工程师通常使用开环日志回放工具来回放脱离事件，了解安全驾驶员干预的原因，并在下一步道路测试之前修复感知、PNC等算法模块的问题。然而，开环日志回放工具无法确定是否真的需要接管，原因是如果安全驾驶员没有干预，自动驾驶车辆有可能也能够避免碰撞。除此之外，他们也无法显示变化的参数（例如，道路上的行人或由于不同天气条件导致的能见度降低）如何影响自动驾驶汽车性能。

         接下来讲述如何利用数据回放和re-simulation来区分必要和非必要接管。原文表达略有晦涩，我做了简单调整。

一、开环日志回放（log-replay）：探索“发生了什么”

        今天，最常见的日志回放类型是开环回放，开环日志回放提供记录的传感器数据以发现问题、分析发生的情况并进行改进。

        例如，假设在道​​路测试中，自动驾驶车接近交通堵塞的尽头，安全驾驶员进行干预以避免碰撞（图 1）。

图1 前方出现车辆，驾驶员进行干预以避免碰撞。

开环日志回放可用于：

• 分析发生了什么：重放驾驶日志，以可视化安全驾驶员干预的原因。在示例中，我们可以看到驾驶员进行干预是因为本车正在高速接近停止的车辆。

• 评估定位和感知性能：重放来自事件的原始传感器数据，并通过将算法模块输出与标定的真值进行比较来评估性能。‍

• 探索解决方案：在进行进一步的道路测试之前，对定位和感知系统进行改进。可以通过使用更新的算法版本重新运行事件来测试对本地化算法模块的改进。

        尽管开环日志回放允许工程师回放和分析脱离接触，但其方法仅限于评估定位和感知堆栈性能。由于开环日志回放无法响应不同的算法行为，它无法评估如果安全驾驶员没有干预，运动规划和控制系统会如何表现。

     

二、重新模拟（re-simulation）：探索“会发生什么”、“应该发生什么”和“可能发生什么”

        闭环log-replay或re-simulation是一种日志重放方法，可消除开环日志重放的限制。re-simulation允许开发团队重新创建一个记录的、真实的驾驶场景，并使用模拟器对其进行更改。

re-simulation可用于：

• 分析和分类：查看安全员的接管是否有必要，以及如果未接管会发生什么。重新模拟工具可以对主车算法模块进行响应，来实现闭环日志回放。重新模拟结果包括数值分析和观察是否主车通过测试，来验证接管操作是否是必要的。在图2所示例子中，可以看到接管确实是必要的，如果不接管，就会发生碰撞。                                                               说明：下图2的白车为re-simulation中主车，黄色为真实数据中主车，可以看到如果没有接管，白车会撞到前方车辆。

图2 re-simulation可以确定本车在无干预情况是否会造成碰撞

• 修复根本问题：通过在记录的事件上运行运动规划和控制算法，确定如何改进算法来避免接管。使用re-simulation结果来确定场景失效的根本原因，并制定解决方案。修复完成后，使用改进的算法重新进行re-simulation，以确认问题已得到解决。
• 增强记录数据：查看同一场景的不同交通参与者可能采取的行动，以评估整个算法的性能，并增加长尾事件的覆盖范围。工程师可以添加或删除演员（例如，路上的行人），修改演员的行为（例如，增加自我或其他车辆的速度），更改场景的其他参数（例如，下雨或一天中的时间），注入故障到 AV 软件或硬件（例如，传感器重新启动、子系统暂时脱机或传感器硬件故障），或向传感器数据（例如，嘈杂的激光雷达数据）添加噪声。图 3 显示了一个修改 actor 行为的示例，该示例通过将记录的 actor 替换为可以通过一组航路点编辑其行为的合成 actor。

                                   图 3 从记录的参与者中提取行为并对行为进行编辑

        架构这一块略显复杂，为了避免误导，我直接放上原文。个人总结如下，感觉理解略不太透彻，欢迎讨论。

• 原始数据喂到感知，提取交通参与者信息；
• 主车由算法闭环控制，与log记录不一致，需更改raw data中的感知数据；
• 记录的交通参与者一般是相对主车坐标信息，由于主车信息相对log做了改变，需要对参与者进行坐标转换；
• 最终主车和参与者的信息传送到评估层，根据指标进行评估。

三、重新模拟（re-simulation）架构

        整体架构如图4所示。

图4 re-simulation架构

        First, raw sensor data is fed into the perception stack in an open-loop log replay and the detected actors are extracted. Then, the motion planning stack runs in a closed loop. To do this successfully, the outputs of the perception stack need to be modified to account for ego divergence. In a drive log, detected actors may be reported relatively to the ego. To get from the open-loop reference frame to the re-simulation reference frame, different actor positions thus need to be adjusted to align with the simulated ego pose (coordinate transform). Throughout the entire process, the metrics and observers framework collects signals to compute an evaluation of the ego’s performance (pass/fail).

技术挑战

• 导致工程师需要手动调查和修复代价高昂的故障；
• 需要能够相信重新模拟是准确且可重复的，这可以通过在非接管的情况下对日志部分运行重新模拟，并验证误差是否很小。
• 算法在实车上的表现和仿真中的表现可能不完全一致。 如果在非车载硬件上运行算法，它可能会落后于重新模拟，尤其是在云上运行时。如果堆栈落后，它可能会延迟响应事件，由此产生表现是不确定的（即，每次重新模拟运行时都会发生变化）。

应用的方法

        开环日志回放和闭环重新模拟对于全面评估 AV 堆栈的道路性能是必要的。

• 开环日志回放允许工程师探索脱离期间发生的事情并评估定位和感知堆栈性能。
• 重新仿真使他们能够区分必要和不必要的脱离，并修复运动规划和控制堆栈中的根本原因问题。

        这两种方法共同帮助开发团队验证他们的整个 AV 堆栈，并更快地将安全的自主系统推向市场。

         从大方向来讲，log-sim和world-sim都有各自特点，技术细节也比较多。大胆设想一下，等技术成熟了，仿真端也许就可以和车端成为一个闭环。车端遇到的问题传到云上的仿真端，仿真端分析问题，改进算法，再通过云下发给车端改进后的算法，美滋滋~

        是故酒驾而不兴，交通事故而不作，故百姓上街而不忧，是谓大同。