vissim免修改时间工具_自动驾驶仿真工具需求

禁止私自转载，转载请联系作者。

2020/01/07 修改“可复现能力”为“稳定性”并增添相应表述。
2020/05/12 将“标准场景格式支持”转为“标准格式支持”，并增添对OSI的描述。

自动驾驶仿真是自动驾驶相关产品落地时的重要辅助。

先看看仿真这两个字，从词义上就可以看到，没有“真”是不行的。仿真的需求离不开真实性的需求。不能满足真实性的坏数据无法训练出真正有效的模型，也不能保证自动驾驶测试的可靠性。再来看“仿”，仿真本质上是完成现实世界到计算机虚拟空间的映射，在转化过程中核心性质已经完全转变，掌握这个具体映射过程的工作原理和细节可帮助我们抽象/表征出关键特征维度。但表现出真实环境中所有特征维度是不现实的，建模成本过高了些。在有限的资源范围内做出高仿真场景应该是未来相关软件迭代的方向之一。

目前市面上与自动驾驶仿真相关的软件很多。第一类是专门的自动驾驶模拟仿真软件，如Prescan、VTD、51sim-one、Panosim、GaiA等等。第二类是基于游戏引擎做的自动驾驶仿真软件，主要代表是基于Unity的Lgsvl Simulator、baidu-Unity，基于Unreal的Carla、Airsim等。第三类是基于一些机器人仿真软件做的自动驾驶仿真器，如基于ROS的Gazebo、rviz开发的仿真平台，基于blender开发的平台等等。

不同类型的软件都有自己的优势和劣势。一般来说，商业软件对自动驾驶仿真各种需求的支持会比较均衡，但一般费用较高，且对于开发者而言，灵活性会受到一定限制。开源软件则会有一些相反的特性。目前市面上还没有一款赢家通吃的自动驾驶仿真器。作为一名开发者，我对“完美”的自动驾驶仿真器有如下的期待。

1. 静态场景建模

静态场景有不同的真实程度，据了解，51VR的L1级别环境是简单的同质化设计，L2等级会基于数据库进行一些分割以及渲染，L3等级的渲染甚至会考虑整体上光能量的守恒，以下是[demo视频](Home-51VR New tech creates new value)

一个典型的交通静态场景需要什么，全局性的因素有天气条件、光照等，好的仿真工具首先需要有强大的图形渲染能力来渲染这些环境。

非全局性的环境因素有道路、交通设施（交通标志、标识牌、红绿灯）、建筑物、篱笆护栏等等。对于他们，我们需要考虑它们的形状、表面材质、反射率等属性。换句话说，感知系统在工作过程中需要考虑的因素都应该被我们主动建模出来。

另外，对于建模而言，开放的权限大小和方便程度是矛盾的，以Prescan和VTD举例，Prescan的GUI做的很好，道路根据特性被参数化并封装成了几个小模块，实际进行道路建模时只需要drag出来相应模块，再修改属性就可以，但一些形状相对特殊的路段，由于不能满足Prescan的约束，所以就无法建模成功。VTD的建模工作量较大，但灵活性更高。理想的建模能力最好兼顾两者，既有封装好的基于GUI拖曳使用的模型库，又需要开放足够的底层设计接口。

另外，自动驾驶仿真软件也需要支持一些业内的标准，如用于生成高精度地图的OpenDRIVE，场景建模语言OpenSCENARIO，以及OpenCRG等。这些标准必将会是未来自动驾驶仿真测试的标准，各公司要提前准备了。

2. 传感器模型

传感器模型是感知系统仿真的核心。好的自动驾驶仿真软件传感器模型应该具有以下几个特点。

• 类型丰富。就视觉传感器而言，需要提供普通的RGB摄像头、深度摄像头、鱼眼摄像头、语义摄像头等，另外还需提供激光雷达(LIDAR)、超声波雷达、毫米波雷达(这个仿真比较困难)、V2X传感器、GPS传感器等。并且提供充足的选项配置。
• 除了一些基本功能外，还需要补充一些特性，如噪声选项、畸变选项、色差选项等，即能对误差进行建模。
• 应该提供适配各公司自用传感器的开发环境。

3. 动力学仿真

车辆的核心是系统动力学，没有高精度的系统动力学的仿真实用价值较低。IV2018最佳的论文所进行的硬件在环，使用的是ROS，做的很完整，但是动力学模型比较简单，因而也就限制了它的实用价值。

简单思考一下工作过程，如果车辆只能有非常简单的动力学模型，比如单轨模型，这也意味着他和实际的状态相别较大，理想的工作状态是车辆接受环境信息，控制车辆移动，新的车辆位置和角度带来新的感知视角。那么如果车辆不能按照本来的规划决策效果执行动作，后边的一切其实也就失去了意义。

因此，自动驾驶仿真软件必须要有支持高精度动力学模型的功能，直接且高效的方案是与动力学仿真软件进行联合仿真，典型的如Carsim，其提供多自由度的动力学模型。在这一方面，Prescan、VTD等商业软件都做的很好，Carla、Arisim则表现较差，他们只有简单的动力学仿真特性。但基于Unreal可以去开发联合仿真的模型。

4. 交通流仿真

交通流仿真基本可包括车辆仿真和行人仿真，它也是自动驾驶仿真要重点关注的模块，车辆不可能永远跑在实验室和封闭园区内，它要处理的任务终究不会只是非常有限的行人和车辆。自动驾驶车辆一定要能处理很多交互的任务。这时候如果人流和车辆信息流是反常规的，或者是随机的，那这对于算法的训练和实际的测试都是很有害的。

自动驾驶仿真工具应该有自己的交通流仿真功能。可以开发自己的交通流模块，如VTD开发有自己的I-Traffic模块，Prescan有自己开发的Intelligent Traffic Module模块，但跟前文提到的动力学仿真相似，自身开发的模块毕竟总体上不如专业的仿真工具，因此软件最好有自己的仿真接口，目前交通流仿真的主要工具是PTV公司的Vissim，还有开源工具SUMO。（Prescan已经可以和Vissim进行联合仿真，但目前仍有一些局限）

交通流应该尽量与实际交通流保持一致，要有可靠性和准确性，可用的手段有（引自51VR推文）：

• 利用AI技术生成驾驶模型，在虚拟世界中设置AI车辆自动行驶，AI可以学习交通流的特性，尤其在行人仿真方面有比较好的成效。
• 导入交通学中的交通流模型，并引入数学概率分布数学模型。这样的交通流模型包括宏观交通流模型和微观模型，相应的数学概率分布模型应该以高斯模型为主。
• 将真人开车的数据导入其中，主要利用虚拟驾驶模拟器实现，但这在更大程度上是保证单车的真实，对于宏观交通流价值没有想象中大，更多的是形成微观交通流模型。

4. 标准场景格式支持

场景自动化测试、场景复用（场景数据交换）是自动驾驶测试的大势所趋，而这两项都需要标准场景文件的支持。目前国际通用标准是由ASAM主导的OpenX系列，相应地，国内有C-ASAM组织负责相关的标准化工作。OpenX系列包括OpenDRIVE、OpenCRG、OpenSCENARIO、OpenSimulationInterface（OSI）、OpenLABEL、OpenODD等标准。其中，OpenDRIVE主要解决静态场景描述问题，OpenCRG主要解决路面状态问题，OpenSCENARIO主要解决动态场景描述问题，OSI主要解决环境和被测系统之间的仿真数据交换的问题。

OpenX系列标准在飞速发展中，目前商业仿真平台中VIRES Test Drive（VTD）提供对以上标准格式的支持，开源仿真平台中CARLA提供了部分支持。对于其他仿真工具，可参考学习esmini、CarlaScenarioLoader等开源项目学习怎么解析OpenSCENARIO。

以后的各方仿真工具也应该配备相应的场景文件解析接口，这是绕不开的事。

5. 稳定性

目前仿真工具不能保证实验的可复现性，当然这和系统算法的不稳定有关，但也跟算法与系统的信息传送接口的稳定性有关。包括Carla在内的大多数仿真工具不能保证信息发送时频率的一致性，这对试验的可复现性是致命的。进而，大规模的回归测试结果可信度也要被打个问号了。