GeoScenario:用于自动驾驶场景表示的开放式DSL

2019-08-21 23:33:46·  来源:同济智能汽车研究所  
 
编者按:用领域特定语言表示场景可以实现自动驾驶仿真测试的自动化,为大规模仿真测试提供基础,同时可以使测试场景标准化,提高多仿真工具链的测试效率。相比于
编者按:用领域特定语言表示场景可以实现自动驾驶仿真测试的自动化,为大规模仿真测试提供基础,同时可以使测试场景标准化,提高多仿真工具链的测试效率。相比于OpenSCENARIO,GeoSCENARIO保留了场景设计的基本架构,且由于该语言更加简洁,因而也具有更高的可扩展性。

本文摘自 IV2019
原文题目:
"GeoScenario: An Open DSL for Autonomous Driving Scenario Representation"
原作者:
RodrigoQueiroz,Thorsten Berger,Krzysztof Czarnecki
作者单位:
加拿大滑铁卢大学1'3,瑞典哥德堡大学2
 
摘要:自动驾驶系统(ADS)在真实交通场景中运行前,需要对其进行广泛地评估,以确保其达到可接受的安全水平。虽然有许多工具可用于执行仿真测试,但目前仍缺乏一种包含道路交通情况复杂性的测试场景语言,而这不利于测试的可重复性并影响了工具之间的可交换性。本文建议将GeoScenario作为场景表示的领域特定语言(DSL),以便在仿真中验证测试用例。在实践中,作者使用该语言在仿真中测试了一个自动驾驶栈。该语言建立在著名的Open Street Map(OSM)标准之上。
 
1 前言

随着自动驾驶系统(ADS)自动化水平越来越高,产品在发布给客户之前需要进行广泛而严格地评估。随着自动化水平的提高,更多的驾驶任务从人类驾驶员转移到ADS,ADS必须应对真实的交通状况及其所有干扰,包括与人控车辆,行人和其他交通媒介的交互。因此,ADS测试应考虑在真实交通条件下与其他交通媒介的互动,以确保安全性并且符合交通法规。

测试ADS功能(例如尾部避撞)不仅需要仿真工具来执行相关方案,还需要一种语言来正式地表示它们。为了设计和运行自动驾驶汽车的测试场景,工程师需要学习特定工具的语言。在不同的仿真软件之间迁移场景需要很大的成本。

一个设计良好、与工具无关的领域特定语言(DSL),有助于研究人员和工程师设计独立于工具的测试用例,在不同工具之间迁移场景,并在其他测试环境下评估他们的系统。本文提出GeoScenario作为用于场景表示和评估的DSL,确定了构成典型测试用例的相关元素,这些元素需要在仿真测试中定义和执行。此外,本文还提供了一个工具集,可以使用DSL轻松地设计和验证方案。

2 背景和相关工作

2.1 特定于工具的语言

许多工具和研究都创建了自己的语言来定义场景。CommonRoad 基于三个主要组成部分(车辆模型、成本函数和场景)提出了可组合的运动规划基准结构。尽管这项工作没有尝试提出场景描述DSL,但是它创建了自己的文件格式。与GeoScenario类似,这项工作使用Lanelets来表示道路网络,由具有初始状态和若干目标区域(点,形状或特定小巷)的自车车辆以及具有具体轨迹数据的所有其他车辆形成场景布局。除了轨迹之外,没有高级工具支持根据关键位置或度量条件来编排场景。该格式符合基准目标,但目前还不足以适用于其他仿真工具和标准。

仿真工具通常包含用于描述场景的语言。但是,这些语言仅限于其自身的仿真环境,因此难以跨平台进行翻译或解释。

2.2 开放性语言

在场景表示中,可以使用地图格式来表征道路网络。Open Street Map(OSM)是一个众所周知的协作项目,它使用开放XML格式创建并发布免费地图。但是,OSM和其他通用地图标准不包含有关车道级道路拓扑的详细信息。因此,它们不适合在场景语言中使用。Lanelets 是OSM格式的开放式扩展,其可专门用于支持自动车辆的道路网络表示。

OpenScenario是一种新兴的开放文件格式,用于描述驾驶模拟应用程序中的动态内容。该项目由自动化与测量系统标准化协会(ASAM)管理,目前处于早期阶段。该项目计划涵盖仿真的动态内容,例如驾驶员行为、交通、天气、环境、事件和其他功能。静态内容由另一种格式OpenDRIVE 支持。

虽然OpenScenario和GeoScenario具有相似的目标,但它们的结构和抽象级别各不相同。OpenScenario更接近逻辑层。OpenScenario和OpenDRIVE这两个规范都是开放的,但没有免费的库或工具来解释和处理数据。

3 设计一种驾驶场景语言

GeoScenario设计基本原则:

(i)重用性:利用现有的开放格式在知名且已使用的结构之上构建新语言。该方法只需对现有工具进行微小调整即可达到重用支持新语言的目的。

(ii)简单性:对简单的场景进行建模,该语言非常简单,可读性强。工具可支持复杂的场景。

(iii)覆盖范围:能够表达场景的主要组成部分。

(iv)可扩展性:可以通过其标准组件的新特性和专业化轻松地进行扩展。

(v) 系统独立性:支持不同ADS设计的测试用例,可在不同的自动化级别上运行。

(vi)工具独立性:可以通过其他仿真和测试环境进行解释和执行。

(vii)可执行性:可以表征在没有其他语言的情况下在仿真中运行的具体场景。

4 GeoScenario构架

GeoScenario格式基于XML,OSM标准构建。

主要组成部分包括:自车开始位置和目标,道路网络,交通参与者(车辆和行人),路径,触发器和动作。

4.1 GeoScenario基础知识

所有GeoScenario元素都基于两种OSM原始类型:节点和路线。节点是GeoScenario的核心元素,代表地球表面的特定点。每个节点包括ID号和一对坐标(纬度和经度)。路线是定义多段线的节点的有序列表,用于定义线性要素,例如路径和区域边界(表示路障的实心多边形,或动态元素放置的命名区域)。要定义区域,路线的第一个和最后一个节点必须相同(闭环路线)。

所有元素(节点和路线)都具有描述元素属性的标签,即文本字段对。我们使用标签gs来定义场景中元素的角色,即GeoScenario模型中元素的功能(例如,gs = vehicle)。没有gs标记的元素在场景中没有特定角色,但可以用于组合其他元素。

具有角色的所有元素还必须包含标记“name”(除了少数例外)。该名称是唯一的字符串,用于标识方案中的一个元素。节点在WGS84坐标系中具有坐标(作为OSM标准的一部分)。GeoScenario规范中记录了固定的标签词典。

4.2自车和驾驶任务

在一个场景中,自车是代表自动驾驶系统操作车辆的实体。在本文中,作者决定不为自车定义动作或策略,而是仅指定初始条件和目标。在测试用例执行期间,自动驾驶系统是一个黑箱,它负责根据交通状况(道路网络,静态物体,路径上的动态交通参与者等)决定最佳路线和策略。作者决定采用这种方法,使语言独立于系统并反映真实世界的驾驶场景。在实际运行中,一个长期的驾驶任务可以以一个全局位置的形式被赋予驾驶员或自动驾驶汽车。初始条件定义为表示自车起始位置和方向的节点。

我们假设自车总是在一个固定的位置开始一个场景,目标被定义为一个自车目标节点,一个场景中可以具有多个有序目标位置。它们代表了自动驾驶系统应该实现的中级和高级任务。驾驶任务的最终目标是完成最高级别的任务。这些节点可用于为系统组成一个全局路径,或在系统的内部映射上创建一个目标点。

4.3 布景和道路网络

本文使用Lanelets 来表示场景道路网络,因为其具有紧凑的轻量级结构。道路网络存储在单独的XML文件中,以便于替换。然而场景只能在路网中进行呈现。因此GeoScenario必须始终与其关联的道路网络文件一起发布。

为了表示不属于道路网络的静止障碍物,我们引入静态物体。静态对象可以通过某种方式或封闭方式定义为单个节点。封闭方式可以采用任意形状,但为了保证有效性,必须具有指向同一节点ID的第一个和最后一个节点。

4.4 动态元素

本文将所有能够移动(具有动能)或能够改变其状态的GeoScenario元素定义为动态元素。在GeoScenario中,停放的车辆也被定义为动态元素。能够移动的动态元素称为交通参与者,并分为两种类型:车辆和行人。两者都表示为节点并具有相似的属性。车辆用标签gs = vehicle定义,行人用标签gs = pedestrian定义。使用方向标签来定义参与者的初始方向。方向以度为单位,原点在东方,顺时针方向。不同类型的车辆(例如,汽车,卡车,公共汽车)用相同类型表示,并使用可选的属性模型指定车辆模型。本文不指定车辆动力学或3D网格的细节,因此,测试结果必须考虑运行场景的模拟基础架构的其他详细信息。

速度属性(以km / h为单位)用于定义参考速度。为了实现运动,车辆和行人需要被分配到一个路径。路径被定义为Way元素,可同时用于车辆和行人。路径应解释为由有序连接节点组成的样条线。当一个交通参与者被分配一个路径时,它将沿着路径以其参考速度行进。

为了支持更真实车辆运动学表现,或从记录的交通数据再现场景,可以为一个参与者分配一个速度文件。当一个路径具有一个速度文件时,它必须包含带有参与者速度的标记节点,以便在到达该节点后指定代理的目标速度。参与者必须始终尝试以恒定的加速度匹配路径中的下一个节点的速度。

通过高密度路径(即更多节点)和速度配置文件,GeoScenario模型可以表示各种交通情况。各种交通情况可以由专家手动设计,也可以通过传感器从实际交通中提取,或从自然驾驶数据库导入。某些属性可以通过固定值或值范围来描述。

4.5 触发和动作

在GeoScenario中,作者引入触发器和动作来协调场景的演变。基本的概念是在道路网络的决策位置添加触发节点,并在触发节点处激活对动态元素的不同动作。每个触发器都有所有者和目标。所有者激活触发器,而目标执行动作。所有者可以是自车或其他交通参与者(车辆,行人)。目标可以是任何动态元素,其状态可以随场景的变化而变化,但不能是自车。我们的假设遵循这条规则,将自动驾驶系统假设为一个黑箱,仅限制它的初始条件和驾驶任务。动作则可以更改参与者的状态或决策本身。

触发器可以通过三种类型的条件激活,或者通过它们的组合激活:

时间:当场景执行到达给定时间t时激活。一组定时触发器允许设计者按时间顺序控制具有定时事件的场景。

位置:当所有者到达触发节点位置时激活。触发点必须放在道路网络的决策关键点上。

度量条件:当基于度量的给定条件为真时激活。该触发器允许不依赖特定位置而是在相对条件之后的任何位置执行动作。例如,一辆汽车在道路上行驶时,只有当本车和一辆汽车之间的距离小于100米时,它才开始减速停车。为了支持度量条件触发,GeoScenario需要在参与者之间跟踪给定的度量。

通过显式声明跟踪哪些参与者,度量也被定义为GeoScenario中的一个元素。因为可以使用不同的方法计算度量,我们建议场景中包含对度量如何计算的引用。例如,TTC可以被多种方法使用,从而导致不同的结果
本文仅对我们的模型进行了概述。所有细节(包括示例)都可以在我们的项目存储库中找到。此外,可以使用新的特性和属性轻松地扩展模型,以支持特定于工具的需求(例如,支持模型之间的转换)

4.6 工具集

可访问的工具集非常重要。由于作者的场景格式是基于OSM开发的,因此作者采用了OSM的标准地图编辑工具:JOSM。通过添加一组自定义的预设和样式表,作者现在可以在道路网络(Lanelet层)和其他地图图层(例如Bing地图,ESRI地图)的顶部轻松地设计和构建一个GeoScenario。

5 结论

本文提出了GeoScenario,一种用于场景表示的领域特定语言,作者确定了组成典型测试用例的关键要素,这些要素需要在自动驾驶车辆测试中正式声明和执行。这种语言构建在著名的Open Street Maps语言之上,设计简单,易于扩展。一个使用本文的DSL设计和验证场景的工具集已公开发布,在更多研究人员的贡献下,未来作者计划发布一个独立于仿真工具的自动驾驶汽车测试场景共享数据库。

 
 
分享到:
 
反对 0 举报 0 收藏 0 评论 0
沪ICP备11026620号