文章目录
- 如何构建自动驾驶仿真系统?
- 场景
- 地图
- 真实场景地图生成
- 游戏地图制作
- 高精度地图制作
- 虚拟场景地图生成
- 车
- 行为
- NPC
- 天气
- 红绿灯
- API
- 部署
- 总结
如何构建自动驾驶仿真系统?
仿真最主要的目的是:通过模拟真实环境和构建汽车模型,找出自动驾驶过程中可能出现的问题。那么如何构建自动驾驶仿真系统呢?目前主流的实现方式是通过游戏引擎来模拟真实环境,通过CarSim等软件构建汽车的动力学模型来实现自动驾驶仿真。下面我们先看下自动驾驶仿真系统的整体结构。
场景
首先我们关注仿真器本身,仿真器无非是模拟支持各种场景,其中场景分为:可以定义的场景和随机场景。可以定义的场景又分为:单元场景和真实场景。下面我们分别介绍下这几种场景:
- 可定义的场景: 主要是针对驾驶过程中遇到的不同情况,比如会车,超车,红绿灯,变道等,这些场景一般都比较简单,类似于单元测试,主要是测试单个场景是否能够满足要求,这一部分业界已经有规范,可以参考openscenario[1]。拿超车的场景举例子,可以创建一辆NPC车辆在本车的前面,在不同的速度和距离条件下,测试本车超车是否成功。
- 真实场景: 复现真实场景中遇到的问题,比如真实路测过程中遇到问题,需要复现当时的情况,并且验证问题是否已经解决,可以回放真实场景的数据来进行测试。
- 随机场景: 这种场景类似于路测,模拟真实环境中的地图,并且随机生成NPC,天气,交通情况等,模拟汽车在虚拟的环境中进行路测,由于可以大规模部署,可以快速的发现问题。
我们可以看到不管是哪个场景,都是”地图+车+行为”的模式,场景的需求复杂多变,因此能够灵活的加载地图,车和行为就成为仿真器易用性的关键。
我们的需求是能够根据不同的要求创建不同的场景,动态的添加地图,车和行为。场景生成器是一个框架,支持通过不同的配置,动态创建不同的场景,来满足我们的要求。除了场景生成器,我们还需要仿真器具备以下几个基本功能:
- 复位 – 在故障发生之后,我们能够复位环境和车辆到初始状态,同时也要求我们能够复位对应的自动驾驶系统。这样再每次故障后,可以不用人工操作,而自动恢复测试。
- 快照 – 能够生成对应帧的信息,保存快照的好处是能够恢复事故现场,同时也可以用于自动驾驶数据集的建设。保存的点云和图片有groundtruth,可以作为机器学习的输入来训练模型。
- 回放 – 回放功能主要是用于故障定位,在发生碰撞之后,回放信息用于定位问题。
- 统计 – 统计主要是用于作为benchmark,来衡量系统的稳定性。
有了这些基础功能还不够,我们还需要关心具体的场景,下面我们分别对地图、车以及行为来详细描述需要实现的具体功能
地图
地图是场景中第一个需要考虑的,地图包括2部分,其中一部分是游戏中的模型,另外一部分是这些模型的高精度地图。换一种说法就是,首先我们需要在游戏中构建一个1:1的虚拟世界,然后再绘制出这个世界的高精度地图。其实游戏中的模型是游戏引擎的需求,游戏引擎是根据模型来渲染游戏画面的,没有模型也就渲染不出地图。而高精度地图是自动驾驶系统所需要的,高精度地图可以采用根据现场绘制的地图,也可以先得到游戏模型,然后在模型中绘制。下面是游戏中的地图和高精度地图的对应关系。
真实场景地图生成
游戏地图制作
- 单个模型制作 – 单个模型包括地图中的建筑物、道路、树木、信号灯、交通牌、以及其他的信息。这些信息如果是要完全模拟真实环境,需要大量的材质和贴图,一般是在maya和3d-max等软件中建模,然后再导入模型到游戏引擎中使用。
- 地图布局 – 有了单个模型,当需要把单个模型组合成地图的时候,首先需要解决的是道路的位置信息,比如这个道路有多长,道路的曲率是多少?比较简单点的方法是直接导入2维地图(百度,高德,OSM),然后对照着2维地图放模型,最后生成整个地图的布局。而实际的问题是2维地图的精度往往达不到要求,国内的地图还加入了GPS偏置,所以生成的地图布局必定会不太准确。
高精度地图制作
- 根据模型生成地图 – 接着上面的地图布局来讲,虽然得到的地图布局不准确,但是我们再根据游戏中的模型布局,绘制出高精度地图,然后把这个高精度地图给自动驾驶系统使用,基本上也能满足我们的要求。
- 根据地图生成模型 – 上述的问题就是游戏中的真实位置和实际道路的位置有轻微的误差。要解决上面的问题,我们可以反其道而行之,先生成高精度地图,即根据真实环境先绘制出高精度地图,然后再把高精度地图导入游戏引擎,动态的生成模型,这个方案的好处是地图100%是真实场景,而且不需要在游戏引擎中重新绘制高精度地图,坏处是建筑的模型无法生成。
关于真实场景的地图生成,目前还没有一个比较完美的解决方案,都需要大量的工作。下面我们再看下虚拟场景的地图生成。
虚拟场景地图生成
虚拟场景的道路生成就比较简单,主要的应用场景是一些园区,或者一些测试场景。这一部分完全可以制作一个地图编辑器,类似游戏中的地图编辑器,玩家可以根据自己的需求创建游戏中的地图,然后再由脚本动态的生成高精度地图。这部分的功能主要是对标Carsim等仿真软件的地图编辑功能。
地图编辑器:
说完了地图,接下来看下车。
车
车主要分为2部分:车的动力学模型,以及传感器。接下来我们详细分析下这2部分:
- 车的动力学模型 – 这一部分是传统仿真软件的强项,由于应用已经非常成熟,游戏中的汽车动力学模型都比较简单,由于CarSim等软件没有开源,所以目前短期内一个比较好的解决方案是,仿真器提供API接口,调用CarSim和Simulink等软件的动力学模型,实现对汽车的模拟。
- 传感器 – 传感器主要是GPS、IMU、LIDAR、RADAR、CAMERA等,涉及到传感器的位置,校准参数等。当然这一部分也可以仿真传感器视野范围(FOV),也可以仿真传感器的校准算法。
行为
现在我们加载了地图,车辆,接着我们需要定义一些行为来模拟真实世界。
NPC
npc包括行人和车辆。
- 行人 – 目前主要是模拟行人过马路,以及在路边行走,以及更加复杂的场景,例如下雨天打伞的行人,对于这些异常场景,感知模块不一定能够正常识别。
- 车辆 – 车辆的行为可以由一些简单的行为来模拟复杂的行为,例如停车,变道,加速,减速,来组合出超车,会车等复杂行为。也可以通过模拟真实情况的交通流数据,来模拟整个行为。前一种测试的行为比较成熟,后一种需要根据实际的情况提取出行为,再加入补全信息,才能够正常工作。
天气
天气主要是影响传感器的感知,最主要的就是摄像头。对LIDAR的影响由于目前没有阅读相关平台是否有加入噪声,这里就先不展开了。
- 天气 – 雨、雪、雾、云层 调整不同的比率来模拟不同的天气情况对传感器的影响,云层主要是会影响光照变化,多云投射的阴影对车道线识别等会有影响。
- 时间 – 白天和夜晚不同光照场景下对传感器的影响。
红绿灯
这一部分可以归纳为交通信号的行为,其中分为:
- 有保护的红绿灯 – 各大城市是最普遍的,即有箭头的红绿灯,根据对应车道的红绿灯直行或者拐弯。
- 无保护的红绿灯 – 即圆形的红绿灯,对面可以直线的同时,你可以拐弯,需要注意对面直行的车辆,选择让车之后再拐弯。
- 无红绿灯 – 这种常见于郊区路口,需要判断有没有车辆经过而让行或者停止,然后再通过路口。
关于仿真器就介绍完毕了,那么我们如何控制仿真器来实现这些呢?
API
目前主要是通过python API的方式来控制仿真器加载模型,控制仿真器的行为。好处是不用图形界面手工操作,可以实现自动化部署。API的主要是根据上述所说仿真器的功能实现统一的接口,实现交互。
部署
为了提高测试效率,我们还需要大规模部署,一个比较好的方式是通过容器化的方式部署。针对于多台机器,一个显而易见的需求就是创建一个管理平台来实现对仿真器的管理。容器部署平台可以监控对应仿真器的状态,并且提供可视化的配置界面,生成和部署不同的场景。
- 监控 – 可以监控仿真器的监控状态,显示正常和有问题的集群,保存日志,维护集群的稳定。
- 可视化 – 首先是配置可视化,可以方便的选择不同的配置(不同的地图,车,行为)来生成不同的场景,其次是通过可视化反馈仿真结果,屏蔽仿真集群的细节,使用起来更加直观方便。
自动驾驶部署集群:
总结
最后根据功能划分,我们可以单独仿真自动驾驶系统的规划控制模块,也可以单独仿真感知模块,可以仿真传感器校准,也可以端到端的仿真所有模块。可以仿真单个受限的场景,也可以仿真整个地图。总之,仿真系统需要提供灵活的场景生成框架,统一的API接口,以及大规模部署的能力。