如何在无人驾驶的各个模块高速迭代的同时保持整体系统的能够完全应对当前的环境场景?模拟器(又称仿真器)就是为了解决这一问题而诞生的。
随着车辆及测试场景的增多,我们得到的一个实际经验是:“No Simulation, No Scalability”(没有模拟仿真,就没有可扩展性)。
模拟器的优势:
模拟器平台将以两种方式处理每个模块的输出数据,一种是进行多方位多角度的显示,便于开发人员对模块的输出结果进行校验和调试。另一种是基于某种评价标准,自动对输出数据进行评判和打分,并且将评判和打分的结果以详细数据报告的形式呈现。
数据信息在车与外部环境的相互作用中产生了一个闭环。无人车的仿真系统就是寻求在软件环境中重塑这样的一个数据闭环,以测试车上的主要软件算法模块。
基于外部数据的不同,模拟器的驱动方式主要有两类:WorldSim 和 LogSim。
角度 | WorldSim | LogSim | |
---|---|---|---|
0 | 理念 | 虚拟仿真概念 | 数据仿真概念 |
1 | 产生方式 | 计算引擎生成,或者基于特定数据加工后生成 | 实际测试发现问题时的短暂数据落盘 |
2 | 时间长短 | 一般是一个完整的场景,可以比较长 | 往往比较短,集中在一个特定场景的前后约十几秒 |
3 | 障碍物智能 | 可以智能地,或者临时增加一些有简单互动逻辑的障碍物 | 周边障碍物体的运动线路已经进行提前录制 |
4 | 重要性 | 可以预见性地设置并处理一些未曾遇到的问题 | 积累已经解决的问题,保证不会重复出现 |
5 | 特点 | 将系统置于一个完整的虚拟世界或者“游戏场景” | 真实场景,模拟感知的不确定性,以此帮助系统处理这种真实情景,甚至容忍某些感知错误 |
6 | 存在的问题 | 测试有效性存疑 | 在模拟过程中出现异于录制的车辆状态的新的虚拟位置状态 |
模拟器是一个团队或者公司的核心竞争力,因此真正开放给普通开发者和用户使用的无人驾驶模拟器系统屈指可数。
作为最通用简单的机器人操作系统,ROS提供了一套基于Rviz和Gazebo的简单模拟器环境,其具有简单和易用的特点。但也有很多的问题:
线上开放的平台也有很多,像是百度的Apollo平台的模拟器。但是Apollo模拟器在某种意义上更像是一个服务,具有一定的封闭性。
真正进行无人驾驶研究的公司一定需要自行研发一套完整的模拟器系统的,所以模拟器的研发也是一个很重要的任务。
模拟器的主要用户有两类,测试人员(QA)和研发人员(RD)
flowchart TB
qa1["测试时发现问题"]
qa2["原始数据落盘累积"]
re1["发版,重新进行测试"]
rd1["研发人员复现定位问题并加以修复"]
rd2["1. 人工验证:使用发现问题时的数据,\n确认问题已经修复\n2. 机器验证:使用累积的过往历史数据\n集合,确认修复该接管问题后,\n没有导致新的问题"]
rd3["研发新功能"]
rd4["验证新功能不破坏原有其他功能"]
rd5["针对建立新功能的场景"]
re2["提交测试人员测试"]
subgraph 研发人员 RD
rd1-->rd2
rd3-->rd4-->rd5
end
subgraph 测试人员 QA
qa1-->qa2-..->rd1
end
subgraph 循环 RE
rd2-.->re1
rd5-.->re2
end