2万字长文说清自动驾驶仿真的8大问题

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

交流群 | 进“传感器群/滑板底盘群”请加微信号xsh041388

交流群 | 进“汽车基础软件群”请加微信号Faye_chloe

备注信息群名称 + 真实姓名、公司、岗位

对自动驾驶仿真中的很多知识点排名第一的就是“用真实道路数据做仿真”笔者已经好奇了两年多时间但此前一直没有机会学习。去年4月份的疫情期间偶尔得到了一次跟某仿真公司创始人闲聊的机会笔者便趁机向其请教了许多问题。

此后为交叉验证笔者又陆陆续续向近20位在自动驾驶仿真业务一线的专家请教。

对本系列学习笔记提供支持的专家包括但不限于智行众维CEO安宏伟、深信科创创始人杨子江、智行众维CTO李月、51 World CTO 鲍世强及毫末智行和轻舟智航、车右智能的仿真专家等。在此表示感谢。

问题一场景来源——从合成数据到真实道路数据

据公众号“车路慢慢”的作者李慢慢及智行众维CTO李月介绍仿真测试场景的来源大体上可以有2种思路

第一种思路是由德国PEGASUS项目提出的功能场景-逻辑场景-具体场景三层体系1、通过真实道路数据采集和理论分析等方式得到不同的场景类型即功能场景2、再分析出这些不同场景类型中的关键参数并通过真实数据统计和理论分析等方法得到这些关键参数的分布范围即逻辑场景3、最后选取其中一组参数的取值作为一个测试场景即具体场景。

如下图所示

举个例子功能场景可以描述为“自车被测车在当前车道运行在自车前方有前车加速运行自车跟随前车行驶。” 逻辑场景则提炼出关键场景参数并赋予场景参数特定的取值范围如以上描述的场景可提取自车车速、前车车速以及加速度、自车与前车距离等参数每个参数都有一定的取值范围和分布特性参数之间可能还存在相关性。具体场景则需要选取特定的场景参数值组成场景参数向量并通过具体的场景语言表示。

这其实就是通常所说的“虚拟搭建/用算法生成的场景”尽管对场景的理解仍来自于真实道路场景但实践中更多地是基于这种理解在软件里面“人为地拟定”一个行驶轨迹、一组场景因而这种场景背后的数据也被称为“合成数据”。

在实操中这种思路面临的主要挑战是仿真工程师对车辆的正常驾驶场景的理解是否足够深。如果工程师不理解场景任性地去“拟定”出一个场景那当然是不能用的。

第二种思路是采集自动驾驶车辆预定工作区域内的交通流量数据并将这些数据输入交通仿真工具中产生交通流并使用该交通流充当自动驾驶车辆的“周围交通车辆”实现测试场景的自动生成。

据深信科创创始人杨子江介绍为确保能获得比较准确的“真值”通常工程采集车上的传感器配置要比普通的自动驾驶汽车高许多如定位系统会采用20W以上的设备以及高线束的激光雷达产生的数据会更加精确。

UberACT前首席科学家Raquel Urtasun创办的仿真公司Waabi据说无需激光雷达等高精度的传感器直接用摄像头收集的数据来做仿真。

用真实道路数据做仿真最大的优势是场景的多样性不会受限于工程师对场景的理解不足因而更容易将那些“谁也想不到”的未知场景给“打捞”出来。

此外某自动驾驶公司仿真负责人说为了提高仿真的真实度后面大家就会尽可能地少采用合成数据多采用真实道路数据。实际上现在的仿真已经在往这个方向发展了——真实数据和模块越来越多了。

不过有一线仿真实践的工程师们普遍反映这一思路过于理想化。具体地说用真实道路数据做仿真存在如下几点局限性——

1.数据需要做人工校核

实际上传感器采集到的数据并不能直接用于仿真——数据类型及格式需要转换有很多无效数据需要清洗也要从中辨别出有效的场景某些特定的要素需要进行标注不同传感器之间的数据需要实时同步和融合等等。

正常情况下自动驾驶车辆的感知数据无需经过人工校核而是直接给到决策算法但如果是做仿真对感知数据的人工校核就是必不可少的步骤。

2. 逆向过程的实现难度比正向过程大

某无人驾驶卡车公司仿真工程师说用合成数据做仿真是一个正向的过程即你先知道自己需要去做哪些测试然后再自己主动去设计这样一个场景用真实数据做仿真是一个逆向的过程即你先遇到一个问题然后再去解决这个问题。两者相比较后者的难度要大得多。

3.无法解决交互问题

复睿微电子负责人Jame Zhang在一次公开分享中提到WorldSim用虚拟数据做仿真像在玩游戏而LogoSim用真实道路数据做仿真则更像是电影你只能看没法参与因此LogoSim天然没法解决交互性的问题。

4.无法做闭环

复睿微电子负责人Jame Zhang还提到了这两种仿真方法的另一个区别使用真实道路数据做回放能采集的片段永远是有限的经常是采集开始的时候危险可能已经发生了一段时间了之前的数据你很难获得了但如果用虚拟数据合成数据就无需面对这个问题。

某主机厂的仿真负责人说“上述专家表述的是采集的过程。的确考虑到采集设备的容量以及有效场景的定义采集打点的场景都是有长度的一般都是功能触发前后一段时间尤其是触发前的缓存不会特别长。另一方面在数据采集后用来回灌的时候则只能是功能触发前的场景是有效的而功能触发后的真实场景却是无效的。”

这位主机厂的专家说真实道路数据用来训练感知算法是可以的但要测试整个算法链路的话还是得依赖合成场景数据。

不过这位主机厂的仿真主管最后也强调“所谓的‘没法实现闭环’也是相对的已经有供应商可以把采集到的场景里面的元素都完成参数化这样就可以闭环了但这种设备的价格是非常昂贵的。”

5.数据的真实度仍然难以保障

用真实交通流数据做仿真也被称为“回灌”。

据深信科创创始人杨子江介绍“回灌”需要用到核心技术有两个一个是在仿真环境中还原路采数据的路网结构二是将路采数据中的动态交通参与者行人车辆等在不同坐标系下的位姿信息映射到仿真世界路网下的全局坐标系中。

这个过程中需要使用的工具有SUMO或openScenario——用于读入交通参与者的位点信息。

某主机厂仿真专家说“原始数据的回灌也不能保证百分之百真实因为在将原始数据注入仿真平台后还得加上车辆动力学仿真。但如此一来场景是否还与真实道路上的场景一致就不好说了。”

究其原因现有的交通流仿真软件往往还存在如下几大缺陷

生成的交通流不够保真往往只支持车辆轨迹导入而车辆间的双向交互不够真实

仿真模块自车和交通流模块其他道路参与者之间的数据传输接口受限如路网格式不同需要路网匹配第三方可操作性有限

基于规则的交通流模型是面向交通效率评价的可能会出现过于简化的问题往往采用一维模型假设设立是沿着中心线行驶的较少考虑横向影响难以满足交互安全评价的需求。

某Tier 1的仿真工程师说用真实交通流数据生成仿真场景如何选择交通流模型比如跟驰模型、换道模型怎么定义、如何定义交通流仿真模块接口都是有相当难度的。同时来自自车的数据和其他道路使用者的数据如何做好时间同步也会是一个很大的问题。

6.数据的通用程度低、泛化难度大

智行众维CEO安宏伟和CTO李月都特别提到了仿真数据的“通用性”问题。所谓数据通用性即指车辆及场景的参数是可以调整的。比如在数据是用一辆轿车去采集的摄像头的视角很低但在变成仿真场景之后摄像头的的视角可以调高这组数据可以用于卡车模型的测试。

如果场景是虚拟搭建/算法生成的各参数可根据需要任意调整那么如果场景是基于真实道路数据的呢

某工具链公司的仿真负责人说在用真实道路数据做仿真的情况下一旦传感器的位置或者型号有变更这一组数据的价值就降低甚至会“作废”。

轻舟智航的仿真专家说也可以用神经网络对真实道路数据做调参这种调参的智能化程度会更高一些但可控性会比较弱。

用真实交通流数据做仿真又称为“回灌”而回灌又可分两种直接回灌和模型回灌——

所谓“直接回灌”是指对传感器数据不做处理直接喂给算法在这种模式下车辆及场景的参数是不可调整的用某款车型采的数据就只能用于同款车型的仿真测试

“模型回灌”则是指先将场景数据抽象化、模型化用一组数学公式将其表达出来在这个数学公式里面车辆及场景的参数都是可调的。

按李月的说法直接回灌是无需用到数学模型的“比较简单基本上只要有大数据能力都能做到”但在他们的模型回灌方案中不管是传感器模型还是车辆的行驶轨迹、车速都是要通过数学公式来完成的。

模型回灌的技术门槛很高成本也不低一位仿真工程师说“要把传感器录制的数据转换成仿真数据数据解析的过程非常难。因此当前这一技术主要停留在PR层面上。在实践中各家的仿真测试都是以算法生成的场景为主以采自真实道路集的场景为补充。”

某自动驾驶公司仿真负责人说用真实交通流的数据做仿真目前还是很前沿的技术这些数据的调参难度很大仅可在一个很小的范围内调参。因为路采的都是一堆日志、一条条的记录它记录的是这个车第一秒第二秒怎么运行的而不像人工编辑的一些场景是由一系列的公式组成的。

这位仿真专家说模型回灌存在的最大挑战是在场景比较复杂的情况下要将场景用公式表达的难度极高这个过程是可以通过自动化的方式来实现的但最终做出来的场景能不能用也是个问题。

Waymo在2020年公布了的“通过将传感器收集到的数据直接生成逼真的图像信息来做仿真”的ChauffeurNet其实就是在云端用神经网络将原始道路数据转换成数学模型然后做模型回灌。但一位在硅谷多年的仿真专家说这个还停留在试验阶段距离成为真正的产品还有一段时间。

这位仿真专家说比回灌更有意义的是引入机器学习或强化学习。具体地说仿真系统在充分学习各类交通参与者行为习惯的基础上训练出一些自己的逻辑并将这些逻辑公式化然后在这些公式中调参。

不过智行众维CTO李月和副总经理冯宗磊的说法是他们目前已经能够实现模型回灌了。

冯宗磊认为一个仿真公司是否具备做模型回灌的能力这主要取决于他们所使用的工具及场景管理能力。

“场景管理中切片是非常重要的一环——不是所有的数据都是有效的比如1小时的数据中真正有效的可能只有不到5分钟在做场景管理的时候仿真公司需要将有效的部分切出来这个过程便被称为‘切片’。

“切片完成后仿真公司还需做一个相应的带语义信息的管理环境比如哪个是行人、哪个是十字路口方便下次去筛选。具体地说需要先对数据切片做分类然后再做动态目标列表的精修精修完之后再导入到仿真环境的模型里去如此一来模型就有相应的语义信息了。有了语义信息就可以调参了然后数据就可以复用了。

“多数公司基于真实交通流的数据之所以不能调参是因为他们没有做好场景管理。”

深信科创创始人杨子江说“如果要将路采数据泛化并且要保持数据的真实性可以在场景初始化以及开始阶段回放路采数据在某一时刻由smart-npc模型来接管道路中的背景车辆使背景车辆不会按照路采数据运行。smart-npc接管后通过把泛化后的场景记录下来以做到泛化后的关键场景可回放。”

某主机厂的仿真工程师认为模型回灌尽管听上去“不明觉厉”但实际上“必要性不大”。原因是将数据模型化与回灌的初衷不符——回灌的初衷是想要真实的数据但既然模型化了参数可调了就不是最真实的了费时费力数据格式转换非常麻烦费力不讨好。

这位工程师说“既然你想要更多场景那直接用仿真器大规模生成泛化场景就行了啊大可不必走真实数据模型化这条路。”

对此冯宗磊的回应是

“用算法直接生成场景这在开发的早期当然是没问题的但局限性也很明显——那些工程师们‘想不到’的场景怎么办真实的交通状况千变万化你的想象力不可能穷举所有。

“更关键的是在工程师想象出的场景中目标物之间的交互关系往往是不自然的。比如前方有车辆插入它是以多大的角度插入在距离你10米时还是5米时插入在用算法生成场景的实践中场景参数的制定往往带有非常的大主观性、随意性工程师拍脑袋想出了一组参数注入模型但这组参数是否具有代表性呢”

冯宗磊认为在无人驾驶还处于Demo阶段时靠算法生成的虚拟场景能满足需求但在前装量产时代基于大规模的自然驾驶数据真实交通流数据来做场景泛化还是很有必要的。

据一位跟Momenta有过接触的人士说“Momenta已经具备了用真实道路数据做场景泛化调参的能力但他们的技术只给自己用不对外。”

51 World车载仿真负责人鲍世强认为自然驾驶数据做泛化目前还比较前瞻但未来肯定会成为很重要的方向因此他们也在探索。

总结两种路线相互渗透界限越来越模糊

复睿微仿真负责人James Zhang在前段时间的一段分享中提到特斯拉的仿真有两种方法场景完全虚拟算法生成的叫 WorldSim将真实数据回放给算法看的叫LogSim“但WorldSim中的路网也是在对来自真实道路的数据做自动标准的基础上生成的因此WorldSim与LogSim的界限越来越模糊”。

轻舟智航的仿真专家说“真实场景数据转化为标准格式化数据后可通过规则去进行赴泛化从而产生更有价值的仿真场景。”

51 World 车载仿真业务负责人鲍世强也认为未来的趋势是用真实道路数据做仿真和用算法生成的数据做仿真这两种路线会相互渗透。

鲍世强说“一方面用算法生成场景也依赖于工程师对真实道路场景的理解对真实场景的理解越透彻建模就越能接近真实。另一方面用真实道路数据做场景也需要对数据做切片、提取将有效部分筛选出来再设定参数、触发规则再做精细化的分类然后可以将它们逻辑化、公式化。”

问题二场景泛化与场景提取

上面几段反复提到的对场景数据做“调参”又被称为“场景泛化”——通常主要指对虚拟搭建的场景做泛化。用某主机厂系统工程师的话说场景泛化的优势是我们可以“凭空造”一些现实世界当中从来都没有过的场景。

一个仿真公司的场景泛化能力越强对某个场景调参后得到的可用场景的数量就越多因此场景泛化能力也是仿真公司的一项关键竞争力。

不过轻舟智航的算法专家说场景泛化可以通过数学模型、机器学习等方法去实现但关键的问题是如何保证泛化的场景是真实、而且更加有价值。

决定一个公司的场景泛化能力强或者弱的关键要素有哪些

深信科创创始人杨子江认为场景泛化中有一个很大的难点是如何将轨迹抽象为更高级别的语义用一形式化的描述语言来表达。

某Tier 1仿真工程师说主要看该公司所采用的仿真工具是用什么语言比如openscenario来描述不同的交通场景的这门语言对交通环境中各个层次的定义是否合理可表示需要的细节同时又具备可拓展性。

针对功能场景、逻辑场景以及具体场景都有相应的场景语言如针对前两者有M-SDL等高级场景语言针对后者有OpenSCENARIO、GeoScenario等。

还有一个层面可能是对干扰行为的仿真对各种驾驶行为、驾驶“性格”的泛化程度。

△图表摘自孙剑、田野、余荣杰所著《自动驾驶虚拟仿真测试评价理论与方法》一书

深信科技创始人杨子江说“基于交通流的泛化和驾驶员的智能化如果模型足够好由于随机因子的存在场景运行10次就相当于泛化了10个。”

不过智行众维CTO李月认为不能为了泛化而泛化。“我们一定要对被测的功能有深刻的理解然后再去设计泛化方案而不是为了泛化而泛化更不能漫无边际地去泛化。场景泛化虽然是虚拟但也要尊重现实。”

另外一位仿真专家也说“说到底仿真还是要为测试服务的我们是已经在路上遇到了一个问题然后看如何通过仿真解决而不是说我先有了一个仿真的技术然后看用在什么问题上吧”

前文提到的一位仿真专家称据他了解目前还没有多少公司能真正做到场景泛化的自化在大多数情况下调参都是靠人工来完成的。“场景泛化能力尽管很重要但现阶段还没有哪个公司真能做得很好。”

51 World车载仿真业务负责人鲍世强认为做场景泛化最重要的是要对自动驾驶仿真测试需要什么样的场景有一个深刻的理解。事实上现在的问题不是生成的场景太少实在是太多而且有很多并不会真实发生算不上有效的测试场景这就是对需求理解不到位造成的。

有专家称第三方仿真公司面临的最大挑战是由于自己并没有亲自上阵做自动驾驶因而对自动驾驶究竟需要什么样的仿真理解是不足的。

而那些有能力、对仿真需求理解比较深入的L4级自动驾驶公司其实并没有足够的动力把场景泛化做得非常深入。因为Robotaxi通常只在某个城市的一个很小的区域里跑他们只要采集这一个区域的场景数据做训练和测试就行了没有太大的必要去泛化出很多他们在相当长一段时间内都不会接触的场景。

鲍世强认为蔚小理这些主机厂真实道路数据比较多对场景泛化也没有太强的需求。相反对这些公司来说比场景泛化更迫切的是对场景做精细化分类管理筛选出真正有效的场景。

轻舟智航的仿真专家也认为随着车队规模的增加、来自真实道路的数据规模急剧膨胀对仿真公司来说如何充分挖掘出这些数据中的有效场景确实比做场景泛化重要得多。“我们也许会探索出智能化程度更高的泛化手段能更快地对算法做大规模验证。”

杨子江说“针对参数层面的泛化例如车道数量、交通参与者的种类数量、天气以及速度、TTC等关键参数各家产生泛化场景的能力都差不多但场景泛化能力的核心在于如何识别有效场景过滤无效场景包括重复的、不合理的而场景识别的难点在于复杂场景需要识别多个对象之间相互关系。”

上述几位提到的“识别有效场景过滤无效场景”又被称为“场景提取”。

场景提取的前提是先搞清楚究竟什么是“有效场景”。据几位仿真专家介绍除法律规定应当测试的场景外有效场景还包括如下两类做系统正向设计时工程师根据算法的开发需求定义的场景测试中被挖掘出的那些“算法搞不定”的场景。

当然有效和无效都是相对的这跟公司的发展阶段、算法的成熟阶段有关——原则上随着算法的成熟、问题的解决很多原来的有效场景都会成为无效场景。

那大家是如何高效地筛选出有效场景的

学术界有一种设想是在感知算法里面设定一些熵值当场景的复杂度超过了这些值感知算法就把改场景标记为一个有效的场景。但这个熵值怎么设存在很大挑战。

某仿真公司采用的是“排除法”即如果一个原本表现非常好的算法在某一些泛化场景中“问题频发”那这个场景大概率就是“无效场景”可以排除了。

某主机厂的系统工程师说“目前还没有很好的做场景筛选的方法。如果吃不准那就放到云仿真上去算总归是能算出来这些极限场景然后再拿这些极限条件在自己的HIL台架上或者VIL台架上做验证那么效率就会高很多”。

问题三仿真究竟难在哪

在跟很多仿真公司的专家及其下游用户交流的过程中我们了解到当下自动驾驶的仿真最难的环节之一是传感器的建模。

按智行众维CTO李月的说法传感器建模可分为功能信息级建模、现象信息级/统计信息级建模及全物理级建模几个级别。这几个概念的区别如下——

功能信息级建模简单地描述摄像头输出图像、毫米波雷达在某个范围内探测目标这些具体功能主要目的在于测试验证感知算法但对传感器本身的性能并不关注

现象信息和统计信息级建模是混合的、中间层级的建模它包括一部分功能信息级建模也包括一部分物理级建模

全物理级建模指对传感器工作的整个物理链路做仿真其目标在于测试传感器本身的物理性能比如毫米波雷达的滤波能力如何。

狭义上的的传感器建模拟特指全物理级的建模。这种建模很少有公司能做好具体原因如下

1.图像渲染的效率不够高

从计算机图形成像原理看传感器模拟包括光线输入、输出模拟、几何形状、材质模拟、图像渲染等模拟而渲染能力和效率的差别则会影响到仿真的真实性。

2.传感器的类型太多&模型精度、效率和通用性的“不可能三角”

仅有单个传感器的精度高还不够你还需要所有的传感器都能同时达到一个理想的状态这就要求建模有很广的覆盖度但在成本压力下仿真团队显然不可能对激光雷达做10个、20个版本的建模吧另一方面又很难用一个通用的模型去将各种不同款式的传感器表达出来。

模型的精度、效率和通用性是一个“不可能三角”的关系你可以去提升其中的一面或者两个角两面但你很难去持续性地把三个维度同时提升。当效率足够高的时候模型精度一定是下降的。

车右智能的仿真专家说“再复杂的数学模型也可能只能以99%的相似度模拟真实传感器而这剩下的1%可能就是会带来致命问题的因素。”

3.传感器建模受制于目标物的参数

传感器仿真需要外部的数据即外部环境数据跟传感器有强耦合然而外部环境的建模其实也挺复杂的并且成本也不低。

城市场景下建筑物的数量太多这会严重消耗用来做图像渲染的计算资源。有的建筑物会遮挡路上的车流、行人及其他目标物体而有遮挡没遮挡计算量是完全不一样的。

此外目标物的反射率、材质很难通过传感器建模搞清楚。比如可以说一个目标是个桶状的但它究竟是铁桶还是塑料桶这个很难通过建模来表达清楚即使能表达清楚要在仿真模型中把这些参数调好又是一个超级大的工程。

而目标物的材质等物理信息不清楚的话仿真的模拟器就难以选择。

4.传感器的噪声加多少很难确定

某Tier 1仿真工程师说“深度学习算法识别物体是一个从真实世界的传感器数据收集到信号去噪的过程相比之下传感器建模则是要在理想的物理模型的基础上合理地加入噪声而其难点就在于噪音如何加得才能跟真实世界足够接近以便既能让深度学习模型识别出来又能有效提升模型识别的泛化。”

言外之意仿真生成的传感器信号既要跟真实世界中的传感器信号“足够像”能识别出对应物体又不能“太像”模拟corner case让感知模型能在更多情况下实现识别——泛化。然而问题在于在真实世界中传感器的噪音在很多情况下是随机的这意味着仿真系统如何去模拟这些噪音是一个很大的挑战。

从传感器原理的角度看相机建模的过程中还需要做相机模糊化先生成理想的模型然后加噪音、畸变模拟、暗角模拟、颜色转换、鱼眼效果处理等而以激光雷达模型也可分为理想点云模型步骤包括场景裁剪、可见判断、遮挡判断和位置计算、功率衰减模型包括对接受激光功率、反射激光功率、反射天线增益、目标散射截面、接口孔径、目标距离、大气传输系数、光学传输系数等子的设定和考虑天气噪点的物理模型等。

5.资源的限制

智行众维CEO安宏伟提到了资源对感知虚拟仿真的限制“我们要对传感器做完全的物理级建模比如摄像头的光学物理参数等都要清楚还需要知道目标物感知对象的材质、反射率等数据这个工程量巨大——在有足够人力的情况下一公里场景的建设周期需要差不多1个月。即使真能建好模型的复杂度也极高很难在当前的物理机上跑起来实在太耗费算力了。”

“未来仿真都是要上云的看起来云端的算力‘无穷无尽’但具体分摊到某个单一节点的单一模型上云端的计算能力可能还不如物理机——并且在物理机上做仿真时如果一台机器的计算资源不够可以上三台一台负责传感器模型一台负责动力学一台负责规控但在云上跑仿真能用在单一场景单一模型上的算力并不是无穷无尽的那么这个就限制了我们这个模型的复杂度。”

6.仿真公司很难拿到传感器的底层数据

全物理级建模需要把传感器的各种表现都用数学模型构建出来。比如将信号接收器的某个具体性能、传播路径中间受空气的影响、反射折射的整个链路用数学公式表达出来。然而在软硬件尚未真正解耦的阶段传感器内部的感知算法是个黑盒子仿真公司无法了解算法究竟是个什么样子。

全物理建模需要获取传感器元器件如CMOS芯片、ISP的底层参数对这些参数做建模而且还需要知道传感器的底层物理原理并对激光雷达的激光波、毫米波雷达的电磁波做建模。

对此有一位仿真专家说“要做好传感器建模得深刻理解传感器的底层硬件知识基本上相当于要知道怎么设计一款传感器。”

然而传感器厂商一般不愿意开放底层数据。

智行众维CTO李月说“这些底层参数你如果拿到了拿着它去做建模那你基本上就能把这个传感器造出来了”

智行众维CEO安宏伟说“通常主机厂在和传感器供应商打交道的时候不要说拿到材质物理参数这些细节能拿到接口协议就已经很不容易了。如果主机厂足够强势传感器供应商也积极配合他们可以拿到接口协议但也不是全部。连主机厂都很难拿到的东西仿真公司就更难了。”

事实上传感器的物理级仿真是只能由传感器厂商去自己去做的。国内很多传感器厂商更多地外采芯片等零部件来做集成因此能对做传感器物理级仿真的实际上是TI、恩智浦这些上游供应商。

某商用车无人驾驶公司的仿真工程师说“传感器的仿真难做导致传感器选型的过程很复杂。我们要做传感器选型基本上都是传感器公司先把样件寄给我我们再把各种类型的都装上到车上去测试。如果传感器厂商能跟仿真公司合作他们之间就可以把接口全部拉通提供精准的传感器建模那我们就可以以很低的成本获知传感器的信息做传感器选型的工作量会大幅度减少。”

不过51 World CTO鲍世强的说法是“感知仿真现在还处在初期还远远没做到需要把传感器里边的建模搞得那么精细的阶段。把传感器里边拆开建模那些东西我觉得毫无意义。”

此外按某无人驾驶公司仿真负责人的说法传感器仿真做不了并不等于感知的仿真完全做不了。

比如硬件在环HIL可以接入传感器实物传感器和域控制器都是实物来测试。接入传感器实物既可以测试感知算法也可以测试传感器本身的功能和性能。这种模式下传感器是真实的相比于传感器仿真仿真精确度更高。

但由于涉及到配套硬件集成起来复杂而且这种方式依然需要传感器模型来控制环境信号的生成成本也更高因而实践中很少使用这种方法。

附自动驾驶仿真测试的两个阶段

摘自公众号“车路慢慢”在2021年3月26日推送的文章《自动驾驶虚拟仿真测试介绍》

考虑到近期的实际情况自动驾驶仿真大致要分为两个发展阶段当然这两个阶段可能并没有明显的时间界限。

1阶段一

在试验室和封闭试验场内对传感器的感知识别模块进行测试在虚拟仿真环境对决策控制模块进行测试仿真环境直接向决策控制模块提供目标列表。

这主要是因为目前对传感器的建模还有很多局限从而不能进行有效甚至是正确的仿真。比如摄像头输出的图片较容易仿真但是污渍、强光等特性仿真难度较大而对于毫米波雷达如果建立精度较高的模型则计算速度较慢不能满足仿真测试的需求。

在试验室和封闭试验场可以对测试环境进行完整的控制和数据记录。比如布置不同类别、位置和速度的行人和车辆甚至可以对雨、雪、雾和强光的环境要素进行模拟并将传感器处理输出的目标列表与真实环境进行对比从而给出对感知识别模块的评估结果和改进建议。

这么做的好处是在传感器建模有很多局限的情况下依然能够在仿真环境下对决策控制模块进行测试提前享受仿真测试的优势。

2阶段二

在虚拟仿真环境进行高精度的传感器建模从而对完整的自动驾驶算法进行测试。

这样不仅可以在同一环境下进行测试从而提高测试效率、测试场景覆盖率和复杂度而且可以对一些基于AI的算法进行端到端的测试。

这一阶段的难点一方面是前面提到的满足测试需求的传感器建模另外一方面是不同传感器厂家和OEM厂家直接交互的接口很可能不一致有些情况下可能并不存在。

问题四较低和较高等级自动驾驶仿真测试的差异是什么

对低等级自动驾驶阶段而言仿真只是一个辅助手段而到了高等级自动驾驶仿真便成为准入门槛了——L3需要做过足够里程的仿真才能上路。

某主机厂仿真专家说通常自动驾驶公司做L4仿真的能力更强一些而第三方仿真公司做的仿真则以L2为主。那么两个阶段的仿真的具体差异有哪些呢

1.功能边界

轻舟智航仿真专家“L2的产品定义成熟功能边界清晰因而仿真服务商提供给各家主机厂的服务通用程度很高而L4的功能边界在哪里大家都还在探索因此客户对仿真的需求有很高程度的定制化。”

2.场景库的规模

深信科创创始人杨子江“从测试场景的角度讲L4因为ODD复杂度更高场景库的数量级远高于L2。”

3.对场景复现度的要求

某主机厂仿真专家说“L4仿真对场景复现度的要求更高即道路中发现的一个问题能不能在仿真场境下去复现但很多做L2仿真的公司还没有思考过这个问题。”

4.对数据挖掘能力的关注度

低等级自动驾驶仿真大家主要拼场景的真实度高等级自动驾驶对数据挖掘的关注度更高了。

5.数据构成

51 WORLD 车载仿真业务负责人鲍世强“L2对功能定义得比较明确仿真可以以合成数据为主以真实道路数据为辅而到了L4阶段数据驱动的重要性会更高因此需要以真实道路数据为主以算法生成的数据为辅。”

6.感知

高等级自动驾驶车辆摄像头数量多、像素高对仿真系统的图像渲染能力、数据同步能力及仿真引擎的稳定性都提出了更高的要求。

7.高精地图

智行众维CTO李月“低等级自动驾驶基本都不需要高精地图但高等级自动驾驶在目前阶段则高度依赖高精地图这也是构建场景的时候就需要建数字孪生的原因之一跟真实世界做对比。”

8.决策

智行众维CTO李月“L2的方案对决策的策略逻辑及执行机构的测试关注比较多但并不会把重点放在规划算法上但到了L4方案中对如何避障、如何绕路等路径规划算法的考虑就比较多。”

9.是否需要驾驶员模型

对低等级自动驾驶来说系统不会完全控制车辆的行为而只是起到辅助作用因此仿真公司在做场景设计的时候还要去设计很多驾驶员模型而对高等级自动驾驶来说车辆控制通过自动驾驶来实现因此仿真场景设计中就不需要设计驾驶员模型。

10.是否事先设定测试过程

对这个逻辑公众号“车路慢慢”在一篇文中更详细的解释

较低等级的自动驾驶面对的工况复杂度和工况范围比较小或者说由于驾驶行为主要由人类驾驶员负责自动驾驶系统仅需处理有限数量的、确定的工况即可较高等级的自动驾驶的驾驶行为主要由自动驾驶系统负责其处理的工况复杂度和工况范围很大甚至不能提前预知。

基于两者的这个差异较低等级自动驾驶可以使用基于用例的测试方法较好的进行测试而较高等级自动驾驶则需要使用基于场景的测试方法。

基于用例的测试方法即是预设测试输入和测试过程通过查看被测算法是否实现预期的功能来评价是否通过测试。比如对ACC的测试预先设定被测车辆和前车的初始车速以及前车减速的时刻和减速度查看被测车辆是否能够跟随减速停车。

基于场景的测试方法即是预设测试输入但不预先设定测试过程只设定交通车辆的行为给予被测算法较大的自由度通过查看被测算法是否达成预期的目标来评价是否通过测试。比如对直线道路行驶的测试预先设定被测车辆和前车的初始车速以及前车减速的时刻和减速度但是不限定被测车辆是通过减速还是换道超车的方式避免与前车相撞。

造成对于不同等级的自动驾驶功能需要使用不同的测试方法的一个原因是低等级的自动驾驶一般能够分解为简单而独立的功能可以把单一功能作为被测对象而高等级的自动驾驶较难分解成简单而独立的功能只得把整个自动驾驶系统或其相对较大的一部分作为被测对象。

11.产业生态

深信科创创始人杨子江“从产业生态的角度讲对L2车企基本不会自研而是直接采用外购方案测试会以HIL甚至道路测试为主而对L4的仿真许多车企会倾向于从SIL开始自研。”

问题五仿真中的“一天多少万公里”该怎么理解

跟真实道路测试类似的是一些仿真公司也强调“行驶里程”比如每天“几十万公里”那这个数字背后的真实含义究竟是什么呢它跟真实道路上的行驶里程有何区别呢

虚拟里程是指一个海量仿真平台在单位时间内并行仿真节点行驶里程的总和。单位时间内的仿真里程数取决于整个平台算力支持并行运行的节点数和不同仿真场景复杂度下的超实时指数。

简单来讲一个仿真节点就是一辆车就是仿真平台能支持同时并行跑多少辆“测试车”。

据智行众维CEO安宏伟解释简单来讲假如一个仿真平台有100台GPU服务器的算力每台部署8个仿真实例则这个仿真平台就拥有同时并行800个仿真的能力。仿真里程就取决于每个实例每天跑的里程数了。

一台GPU服务器上能跑多少个实例取决于GPU的性能和仿真求解器能不能在一台服务器上并行仿真。

安宏伟说“我们云仿真平台的仿真节点实现了多种部署方式能够灵活满足客户的各种云资源的状况都能实现大规模、弹性的节点部署。目前我们在苏州相城建设的云仿真平台已实现过超过400节点的部署。”

结合每个实例每天跑的里程就可以大致计算出仿真平台上每日的仿真总里程。如果一个实例虚拟车平均每小时跑120公里每天跑24小时那每日就是将近3000公里如果有33个实例那该台服务器上每天就差不多有10万公里。

但据安宏伟的说法业界平时所说的仿真“每天多少万公里”其实是不太严谨的。“需要结合合理的仿真测试方案和海量的场景作为支撑在场景的覆盖度和有效性上进行不断地扩展最后能够跑出来有效的场景才是根本。”

问题六超实时仿真

在采访中笔者反复问到一个问题仿真平台上跑的车跟真实世界中的车是在同一个时间维度上的吗换个说法仿真平台上的1小时等于真实世界中的1小时吗会有“人间一年天上十年”的情形出现吗

答案是可以等于实时仿真也可以不等于超实时仿真。超实时仿真又可分为“时间加速”和“时间减速”两者情况——时间加速即仿真平台上的时间比真实世界中的时间快时间减速即仿真平台上的时间比真实世界慢。

仿真比真实世界的时间快是为了提高效率那么比真实世界的时间慢又是为了什么

安宏伟的解释是“举个例子有一些仿真测试对图像渲染的精度要求非常高为了追求精度单帧图像的渲染可能无法在实时情况下完成。这种比真实时间慢的仿真不是做实时的闭环测试而是做离线测试。”

具体地说在实时仿真中图片在生成后直接发给算法去识别这个过程也许能在100毫秒内完成但在离线仿真下图片在生成后先保存在离线条件下发送给算法处理。

根据安宏伟的解释在仿真平台上做超实时仿真需要满足如下两个前提条件服务器的算力资源足够强大被测算法能接收虚拟时间。

算法能接受虚拟时间这个怎么理解安宏伟的解释是有一些算法在结合硬件运行平台的条件下可能需要读取硬件上的授时或网络授时而无法读取仿真系统提供的虚拟时间。

某Tier1的仿真专家说在仿真系统的工程框架PoseidonOS里做到精确的时间对齐和同步然后就可以把算法部署在集群服务器上进而仿真空间的时间可以跟真实物理世界的时间解耦解开了就能“随意加速”了。

那么在做时间加速的的时候能加速2倍还是3倍这个加速倍数又取决于什么呢

安宏伟的答案是服务器的算力资源、测试场景的复杂度、算法的复杂程度、算法的运行效率等。即理论上在同等场景复杂程度、同样算法的条件下服务器的算力资源越强大可实现的加速倍数就可能越多。

时间加速倍数的上限是多少呢这个问题我们得结合时间加速的原理来回答。

据某自动驾驶公司仿真负责人解释由于算法复杂度不一致等原因训练模块、车辆控制模块等各模块的计算速度是不一样的而超实时最常规的方法就是通过对各个参与计算的模块做统一调度。所谓加速就是计算速度比较快的模块“取消等待时间”——不管你另外一个模块又没有算完时间到了我就同步。

如果各模块之间计算周期的差异太小这个被取消的等待时间就很小因此加速倍数会很低另一方面如果各模块的计算周期差异特别大比如这个需要1秒而另外一个需要100秒那也没法“取消等待”。

因此时间加速的倍数往往是有限的——能达到2-3倍就算很高了。

甚至有不少专家说在实践中要真正做到时间加速很难。

深信科创创始人杨子江称如果自动驾驶系统的算法已被编译部署到了域控制器或工控机中在HIL阶段就是如此则它在仿真系统中就只能以实时的方式运行——此时超实时仿真行不通。

安宏伟也说“硬件在环HIL半实物仿真本身必须是实时仿真不存在‘超实时’的概念也不适用‘并行仿真’或者‘时间加速’的提法。”

鲍世强说“时间加速的前提是对时间的精确控制以及时间同步。感知很难加速因为不同传感器的频率不一样摄像头可能是30 Hz,然后激光雷达是10Hz类似于这种你如何保证不同传感器的信号可以强同步”

此外一位在硅谷供职多年的仿真专家认为现在还没有哪个公司能真正做到超实时仿真“能做到实时就不错了”。在这位专家看来要提高仿真效率大规模并行仿真是更可取的方案。

而安宏伟认为时间加速能力取决于每个实例上的超实时水平、总实例数及场景的质量。“实际上对于云算力仿真而言单实例上的超实时水平并不很重要核心还是关注该实例上仿真的质量需要。”

轻舟智航仿真专家甚至认为“加速倍数”这个说法其实不太成立。因为仿真中的时间跟真实世界的时间之间并不是一个简单的倍数关系它们甚至没有关系。在实践中更多地是用技术的手段来降低算力的占用提升时序调度效率来达到运算时间的提升。

在真实路测中车辆行驶的连续的你不会说这是个corner case我跑一下那里不是corner case我就不跑了而是跑了很长一段路再在其中筛选出corner case在仿真平台上工程师们通常只截取了跟corner case有关的那些片段即“有效场景”处理完这个事情后时钟就会跳到下一个时间段而不需要在无效场景上浪费时间。

因此在做仿真时如何高效地筛选出有效场景是比时间加速倍数更重要的事。

说到这里我们便可以发现尽管时间加速看上去不明觉厉但要增加在仿真平台上的虚拟行驶里程其实不能主要依赖时间加速关键还是得靠“多实例并发”其实就是要做云算力仿真增加服务器和仿真实例的数量。

问题七大规模并发测试

可否支持在云端的高并发、支持多大规模的并发这个难点到底在哪里是不是只靠堆服务器就行了

听起来没错但问题在于服务器的规模每增加一个数量级就会带来新的问题——

1服务器的成本挺高的每台服务器几十万如果有一百台服务器直接成本就是几千万理想的解决方案是上公有云但国内的主机厂接受公有云还需要一段时间

2大规模并发的情况下传感器的原始数据极其庞大这些数据不仅存储成本很高而且传输也很难——在不同的服务器上做数据的同步会出现延迟进而影响到智行效率

3每一路跑的并不是连续交通流场景而是很某个很简短的片段可能只有30秒但通常是上千路并行如果1000路有1000个算法在1000个场景上跑这对仿真平台的架构设计提出了很严峻的挑战。某仿真公司CEO

不过针对上述最后一条安宏伟的说法是这是云算力仿真的基本需求对我们来说并不算挑战苏州相城区的云仿真平台早在2019年就已解决了这个问题。此外云仿真平台跑的场景也会有数公里的连续的复杂/组合场景相城的Robo-X仿真测评体系里就包括这类组场景。基于这类场景可以进行虚拟仿真下“接管”的测试。

问题八衡量一个公司的仿真能力强弱最关键的指标是什么

在目前阶段不同公司的仿真从工具链到使用的场景数据、从方法论到数据的来源都有较大差别。大家说的都是“仿真”但实际上说的未必是同一个概念。那么衡量一个公司的仿真能力强弱最关键的指标有哪些呢这一轮访谈下来我们得到的答案有如下几点——

1. 可复现性

即真实道路测试中发现的问题能否在仿真环境下复现。轻舟智航毫末智行

关于这个问题本文后半部分会有更详细的解读。

2. 场景定义能力

即该公司定义的仿真场景能否真正帮助提升自动驾驶的实际通过能力。

3. 场景数据获取能力

场景数据的获取、生产能力数据通用和可复用性。

4. 场景数据的质量和数量

即仿真场景跟真实场景的接近程度有多高场景数据的精度、置信度、鲜度以及有效场景的数量暨是否有足以支撑多实例并行仿真所需要的海量仿真场景数据。

5. 仿真效率

即如何自动化高效率做数据挖掘去产生仿真所需要的环境模型从而快速发现真问题。

6. 技术架构

即是否有适合被测对象需求的完整技术闭环体系。IAE智行众维李月

7. 是否具备大规模并发测试的能力

只有在大规模的测试中实例及场景的数量都足够多一个公司才能去对模型精度、系统稳定性等进行评价体系的建设这考验了一家公司的数据管理、数据挖掘、资源调度等能力。轻舟智航

8. 仿真的精度

面向规控的仿真和面向感知的仿真对精度要求不同——前者可能要看车辆动力学模型是怎样的有哪些抽象层次交通流中的干扰行为颗粒度后者可能要看不同传感器根据不同成像原理加的噪音等。

通常用户出于成本的考虑希望技术架构能通用。然而过于通用的方案在某些方面会牺牲掉精度——模型的精度、模型的效率和模型的通用性是三角互搏的关系。

说到仿真数据的真实度我们还有必要再追加一个问题毫末的 MANA在仿真系统中引入了真实交通流场景毫末称通过与阿里以及德清政府合作利用路端设备将路口处每时每刻的真实交通流都记录下来再通过log2world的方式导入到仿真引擎里面加上驾驶员模型之后就可以用于路口场景的调试验证。那么这种数据的精度如何保障

对此毫末的仿真专家说“目前这种数据当前主要还是用来做认知模块的研发测试所以我们需要的是尽量真实的交通动态行为数据本身就是对连续世界做了离散化只要采集频率满足认知算法计算的需求就可以了我们不需要去将这个数据去和真值做比较也没有办法获取绝对真值,简单来说就是我们追求的是动作的合理性和多样性并不是精度。”

9. 仿真测试与实车测试的一致性

有商用车无人驾驶公司的仿真工程师说他们经常会发现SIL测试的结果跟真实路测相反——在真实路测中没问题的场景在SIL中有问题而在真实路测中有问题的场景在SIL中却没有问题。

有主机厂自动驾驶仿真负责人称他们在做HIL测试时发现车辆在仿真场景中的性能跟其在真实道路上的性能或多或少会有点差异。出现这种差异的原因可能在于1虚拟传感器、EPS等并没有做得跟实车上完全一致2虚拟场景跟真实场景没做到完全一致3车辆动力学的标定做得不准。

10. 仿真在公司研发体系中的地位

仿真在实际业务的渗透率也就是在研发流程中仿真数据在整个业务使用数据中的占比仿真是否被作为研发和测试的基础工具。毫末仿真专家

11. 是否形成商业闭环

某自动驾驶公司仿真专家说“对仿真公司来说率先构建起商业闭环比技术本身的优势更重要。”

51 World车载仿真负责人鲍世强称客户在选择仿真供应商时关注的点主要有A.仿真模块是不是足够全该有的都有吗B.你能给他提供什么样的工具链。C.仿真平台的开放性。

提到开放性鲍世强说“整体的趋势是用户其实并不希望直接买一个软件去解决某个具体的问题而是希望搭自己的平台因此他们更希望仿真供应商的技术模块能够赋能他们去搭建自己的仿真平台。所以仿真供应商需要考虑API接口怎么设计、跟客户已有的模块怎么集成甚至是开放一部分代码给客户。”

附如何提高场景的可复现性

“道路中发现的一个问题能不能在仿真环境下去复现”被轻舟智航等公司视为衡量一个公司仿真能力强弱的最关键指标之一。那么究竟哪些因素会影响到场景的可复现性呢

带着这一问题笔者对多位专家进行反复追问得到的答案如下

1. 车辆模型、传感器模型、道路模型、天气模型会跟真实情况有出入。

2. 云端和车端的评价标准可能不一致。

3. 仿真系统中的通信时序、调度时序跟实车上的时序不一致。比如接收一个消息如果不小心早接收一帧或者晚接收一帧最后在蝴蝶效应下差别就会很大。

4. 仿真系统中的车辆控制参数跟实车不一致。实车测试中油门、刹车、方向盘、轮胎这些都是以物理的形态存在的而仿真系统中并没有这样的物理部件因而只能用模拟手段如果车辆动力学的问题处理不好模拟的真实程度就会打折扣。

5. 仿真系统中的场景数据不完整。在做仿真时我们可能只会截取场景的某一片段如红绿灯前后几秒的数据是没有的。

6. 问题可能被描述环境的逻辑语言覆盖语言定义的层次和覆盖度可能不够完善。

7. 仿真软件本身跟各种场景的适配性不够好语言之间的切换不流畅难以支持大规模、多节点运行。

8. 真实道路中的数据变量很多在做仿真的时候为了尽快地发现问题工程师们需要“假定”某几个参数不变以减少对某个关键变量的干扰。

9. 对自动驾驶的感知、预测、定位等模块之间的计算顺序可能在云端跟车端是不一样的也可能车端并没有把某些信息严严实实地记录下来——只要有一帧的差异就可能导致一个结果出现问题。

10. 如果是感知层面的问题场景复现需要将三维场景做到比较好的逆向生成再通过泛化和视角变换对数据进行增广这里每一步都是有点难度的。如果是规控层面的问题那么想要准确地复现场景需要识别场景的交互行为以及关键参数从而准确地生成场景并触发场景。深信科创创始人杨子江

触发场景指的是本场景希望测试的内容是否实现。比如要测一个行人突然在主车前穿马路如果主车都开过去了行人才走那么就没有起到测试效果也就是没有触发场景。例如一个行人穿马路又折返行走的速度、折返的时间点、主车的速度都很关键这是单车单人。多交通参与者就复杂得多互相的关系是耦合的甚至一个参数稍有偏差仿真的效果就大打折扣。

本文写作中引用了大量来自微信公众号“车路慢慢”的干货知识。该公众号的作者李慢慢是仿真工程师该号聚焦于仿真专业知识的梳理推荐对这个赛道感兴趣的朋友关注。