自动驾驶仿真测试场景

自动驾驶仿真测试场景

这篇文章里所提的场景应用范围可以包括模型在环、软件在环、硬件在环、车辆在环，以及实车测试。但现在实车测试往往有相关标准作为支撑，所测的也往往是一些简单的场景，换句话说，复杂场景是支持不了的。所以我平常用场景这个词时，脑海中出现的应用场景往往是仿真。

场景测试对自动驾驶发展的重要性，一言难概。想说清楚它，可以再开一篇文章。粗浅的了解可以阅读朱冰老师写的这篇综述。以我自己的理解，场景是对自动驾驶路测数据的一种总结，是发挥数据价值的必须且高效的途径之一，它属于整个仿真架构的输入端。借助基于场景的测试可以提高系统正向开发效率，也可以通过验证提高产品落地效率。

我自己对场景也有一些个人思考和总结，不过今天这篇文章的主要内容框架来自 Simon Chauvin。他的总结覆盖了我们讨论场景时常关注的几个问题，所以我先对这篇文章进行了翻译，在翻译时也融入了一小部分自己学习过程中的认知和思考。

我们讨论以下几个问题
1. 如何描述交通场景，用什么格式或语言？
2. 如何找到频繁出现的碰撞场景，人类驾驶员通常在哪里失败？
3. 如何生成关键场景来测试边缘用例？
4. 哪些数据集可以用来学习和测试用于预测和决策的算法？

附赠自动驾驶学习资料和量产经验：链接

场景语言格式

为了提高测试的重现性和测试的重现性
Queiroz, Berger, and Czarnecki 2019引入了一种用于场景表示的领域特定语言GeoScenario。该语言构建在开放街道地图OSM原语之上。

GeoScenario的目标类似于文件格式OpenSCENARIO，OpenSCENARIO描述了驱动仿真应用程序中的动态内容，并经常与OpenDRIVE一起用于静态内容。

另一个工具CommonRoad被多次使用，其中一个原因是它从NGSIM US 101数据集中实现了高速公路场景。这一系列应用于道路规划的可组合的benchmark目的是为研究人员提供一种评估和比较他们的规划器的方法。

为了在场景中表示道路网络，LanLets地图(OSM格式的一个开放扩展)被广泛使用(例如GeoScenario和CommonRoad)。

译者注：场景基本上可以分为静态和动态。静态需要地图，对于实际开发中的测试而言，可以把系统中使用的地图作为底层，对于测试阶段而言，需要使用标准地图。OpenDrive当然是目前流传度的最高的，作者这边提的Lanlet有自己的优势，但本质上跟OpenDrive是相同的。对于动态场景，目前的标准比较少，与OpenDrive配套的OpenSCENARIO感觉快一统天下了，GeoScenario基本就是学术界做的东西了。

当然，要重现做一个类似于OpenDrive和OpenSCENARIO的东西是不难的，但正如作者提到的，我们在这里想要的是一个标准化的格式，是可以帮忙减少切换仿真工具的使用开销，方便统一标准化场景库的格式。目前对OpenDrive和OpenSCENARIO支持最好的是VTD，它们是这几项语言的原创者，后来又把这个标准立项交给了标准化组织ASAM。这个转交对长期发展来说是有益的，标准推广开了才有价值。

国内目前也正在推广这里，华为、上汽集团、中汽中心数据资源中心、51VR、腾讯科技、亮道智能有参与C-ASAM的工作，参与的公司都很聪明，一流公司定标准嘛。

另外还有点，OpenDrive、lanlet、OSM都是可以通过解析脚本相互转换的，通过这些转换关系可以复用很多其他软件的建模工作，这里就不多提了。另外，支持OpenSCENARIO的软件，我目前看到的有VTD和Carla，其他仿真软件也可以快点支持这个功能，毕竟写一个解析器也不是太难的事，但却是很有用的事。

OpenDrive和OpenSCENARIO这些标准也带来了一些衍生问题，如大大增加了建场景的时间成本等，这就又需要新的解决方案。关于这个话题，还是有很多可以聊下去的东西的。

经常出现的关键场景
最常见的车祸场景可以从美国国家公路交通安全管理局(NHTSA)的车祸数据中检索到。CARLA AD Challenges使用NHTSA pre-crash来测试面向常见关键场景的agent表现。

Pusse和Klusch 2019使用GIDA分析了德国发生的数千起事故，以此作为基准。然后使用开源的3D驾驶模拟器OpenDS对场景进行虚拟模拟。

译者注：对于经常出现的关键场景，这其实就是我们常说的“数据”的价值。有自动驾驶功能（或数据搜集功能）的车辆大规模部署的最直观好处是什么？就是各种各样的数据啊，特斯拉的autopilot之所以能另辟蹊径，让人不容忽视，那已经卖出的车送回来的数据绝对是第一大功。数据能帮我们分析出各种不常见的情况，也能帮助统计不同地区不同行为的参数规律，这些数据经过分析后，凝练成关键场景，也可以针对性地测试系统的表现，提高系统的表现能力。

如何定义经常出现，如何定义关键，也是个很值得说道的问题。这个要具体产品具体分析，没有神器子弹了。定义好了这些，也就定义好了产品开发过程中的场景测试体系，之后可以考虑把这部分做到CI中，形成完整的开发流。

生成边界情况的场景
Klischat和Althoff 提出了一种方法来生成关键场景，用于在复杂的城市交通情况下测试运动规划者。

译者注：上面一节提到的关键场景，更像是从数据角度论述。这节的话，更偏向与从知识分析的角度论述，但是很遗憾，作者都提的很少。但这其实是很重要的一部分。懂得做场景后，是低效率，还是高效率，其实就是看这部分。特斯拉收集的数据也不是完全上传的，也分析不过来呀。对特斯拉而言，可能把“系统做出的决策和当前驾驶员做出决策不同的sitiuation”下的数据上传，这是特斯拉定义的“边界”或“关键”了，是个很好的思路。

对新数据集的需求
在许多论文中，对真实世界的实验都被放在未来的工作中了。其中一个原因是，很难将模拟或手工场景的模型转换到真实的测试中。这就产生了两种需求:

需要更逼真的模拟器。
需要更丰富的流量数据集与关键场景。

但是让我们考虑下那个先有鸡还是先有蛋的问题:验证模拟器可能比验证算法本身更困难。

现实世界中的驾驶数据集对于基于学习的方法非常重要，这些方法试图对人类驾驶风格和行为建模。它们的多样性和完整性对于预测和决策模型的一般化也是必不可少的。

目前存在一些基于真实交通的场景记录集合。但大多数还是主要涉及感知的。

研究与易受伤害的道路用户(即行人和骑自行车者)进行交互的工作可以使用Stanford Drone数据集、清华-戴姆勒TDC数据集、JAAD数据集或Eurocity PersonsECP数据集](Eurocity PersonsECP数据集。

对于高速公路和十字路口场景，highD 和NGSIM经常被提及。HighD的车辆轨迹是用一架无人机在德国高速公路上记录下来的，而NGSIM数据集包含了安装在旧金山湾区一幢建筑物顶部的摄像头45分钟内记录下来的车辆轨迹数据。如果广泛使用这一真实的公路交通数据，SIPD研讨会的参与者认为这些数据“被过度使用”，“完全无聊”，因为它们缺乏复杂的操作。

不同的团队对数据集的需求是不同的。有些人想要全知全能的鸟瞰图，特别是为了提取遮挡。有些人更喜欢从车辆上记录的数据(Pool, Kooij，和Gavrila2019)，这些数据可以捕捉上下文线索，在计划前推断意图，比如骑自行车的人在转弯前举起手臂。这些特殊需求的一个例子是，在IV19上展示的许多工作都是使用自己的运动驾驶模拟器或构建自己的数据集。然而，这些个体的发展使得实验难以复制、比较和基准。此外，大多数手工制作的数据集都非常小，这对于基于学习的模型的培训并不理想，并且不包含许多不同的情况。

结论很清楚了:我们缺少一个数据集，它具有多种多样的、复杂的和关键的情况，且可用于交互感知的预测和决策。

SIPD研讨会的联合组织者Wei Zhan借此机会宣布发布了一个新的数据集，名为Interaction Dataset，用于社会互动预测和决策。以下是一些要点：
- 在不同的地点(如美国、德国、中国)，不同的驾驶文化，不同的交通规则，对于类似的场景(合并、绕行等)，无人机都有记录。
- 包括了一些关键的情况，例如近碰撞情况和轻微碰撞事故，这对于测试边缘情况非常有趣。
- 另一个有前途的特点是，涵盖了带有谈判的复杂的驾驶行为和不明确的路权(通行权)
- 最后，所有场景都带有一个基于lanelet2的带有语义信息的HD-map。模型中也会有遮挡作为ground truth，这是测试社会认知的关键。