吉林大学计算机科学与技术学院教授王健:自动驾驶测试场景库的自动构建方法

大咖车言 2019-09-19

摘要:2019年8月7日,百人会未来出行学院在线直播开课,吉林大学计算机科学与技术学院教授,博士生导师王健博士做了“自动驾驶测试场景库的自动构建方法”的精彩分享。

2019年8月7日,百人会未来出行学院在线直播开课,吉林大学计算机科学与技术学院教授,博士生导师王健博士做了“自动驾驶测试场景库的自动构建方法”的精彩分享。

以下为王健博士直播实录:

王健:各位好!首先非常高兴能在这样一个特别的日子里跟大家一起分享一些我们的研究结果。这次主要是应百人会的邀请,给大家汇报一下自动驾驶测试场景库的自动构建方法。从今年开始我们开始陆陆续续有很多购买场景库的这种需求出来,不管是做Tier1的还是做OEM厂家的,所以对此也是很有幸给大家一起汇报一下。

第一个,我先给大家讲一下我们理解的场景定义,还有它是怎么构成的,场景库是怎么一回事,然后再讲讲怎么自动生成场景,第三个,简单讲一下在环的方法。

首先给大家讲讲场景的定义。“场景库”这个词,我越来越觉得它一个是“场景”、一个是“库”。先说场景,它现在的产品形态存在方式其实是一些Excel表,然后紧跟着是它描述了一个片段,一个Delta T,一个交通流的片段,还有它们所在的道路结构,这样一个片段简单来说就是,每一个毫秒或者每十毫秒为秒数,车辆的位置跟角度、速度,然后存成一个Excel表,这些称之为场景。

紧跟着这个“库”,能够自动化管理这些Excel表,能够将Excel表中非常形式化的描述转达成后续需要用到的测试引擎过程当中能够对得上的东西,能够将第三方的Excel表管理起来,查找、检索,通过检索导出标签,能够把它自动化导到所用的引擎,而不用像现在这样再去手动构建,不需要再通过一个额外的引擎工具手动构建车辆、行人、参数配置、道路结构等等,这样就形成了一个场景库。场景库能够完成从场景数据的管理和场景的测试引擎的桥接,实现从场景的自动产生、管理、存储、检索、匹配、生成注入给测试工具。

这张图我想给大家讲,我们现在场景库的范畴就在第一个方框里面完成整个场景构架,构建之后给到测试环节,测试环节可以用MIL、SIL、HIL,包括现在正在申报的平行测试VIL平台来做,测试结果把直观可量化的、可采集的东西,如刹车距离、制动距离、制动时间、加减速等传给评价系统,评价系统把一些不可以直接量化的东西做出来的。这样的话,场景是数据驱动的,测试是方法驱动的,评价是指标来驱动的,这三个层次构成了我们整个无人驾驶测试产品的三个主要维度。

场景库有几个维度,我们先讲第一个主要的维度是场景。在行驶环境里边有两个特征:静态特征的和动态特征。静态特征就是高精度地图,动态特征就是交通流,也就是除了HV以外的那些RV,加上一个可变化的气象。静态特征在做产品库构建的时候,通常是录补回来的,现在很多公司都在做数据孪生或平行测试搭建,平行测试搭建的道路结构除非用超能广场,不然大多数都是实际道路,很多都是封闭场地,道路结构实际上是路补回来的,或者是开着采集车在开放道路里做采集,得到的道路结构可以把它直接抽象导到我们的场景库里面,它是1:1真实的。

第二个维度是交通。交通是除了主车以外的交通流,主要是驾驶行为。假设路采的时候采集到了100个样本,然后就可以通过这个样本学习到中国驾驶员的习惯,比如打转向灯的习惯,并线的习惯,加减速的习惯。这些是符合中国特征的驾驶流,驾驶行为不同,导致场景库的维度不同,从而能够区分中国场景库和国外场景库。但是我们采集到的只有100个样本,而实际上做场景库的时候我们希望它的覆盖度更大,比如有成千上万的交通流。我们的方法是,用一个训练机构,比如对抗式生成网络,去学习交通流,把它的行为学习到之后可以去训练,产生出一万个来。

所以说交通流一部分是“真”的,一部分是“假”的,初始实际路采回来的是“真”的,剩下那些构建出来的是“假”的,只不过那些构建是基于训练过的神经网络产生的。

第三个维度是气象。气象的连续量离散化之后可以在它的值域空间里任意改变,没有必要跟真实的情况相对应,这个就完全是假的。

所以道路结构和交通设施,比如交通灯、交通标志线、停止线这些可以完全用真实道路的样子。相对来讲这些的样本空间并不是很大,是一个有限可储集合,你就可以把它穷举出来,把真实的道路纳进来,百分之百是真的。交通流是半真半假的,气象百分之百是假的,这三个维度就构成了一个典型的场景构成:真的道路,半真半假的交通,加上全假的气象。

这三个维度放在一起,虽然道路结构是有限集合,但其中有两个维度是无限的,所以合在一起依然是无限的。因此我们不得不去做一个无限世界里的有限映射。我们需要怎么做呢?把我们有限的场地、有限的道路和无穷的交通、无穷的气象,在它的每个维度上面做映射,比如它的集合特征、颜色、纹理、反射率等等这些方面,做一个映射。映射之后就把它变成了一个场景的元素,一个基本结合的元素,我们再分成两大类,一个是驾驶情景,一个是行驶场合。

简单来说,驾驶情景就是跟主车HV有关的,比如说主车的驾驶任务是什么,车辆状况是什么样子的,我们把主车有关的东西都统称为驾驶情景。然后把除了主车以外的东西,交通流、道路、气象都放到行驶场合里去,这样大家就比较好理解了。

这就是我们行驶场景的映射。我们把行驶环境分成了四个映射。交通参与者(如交通流、道路、交通灯等)的高度、轮廓称为几何映射。材质对反射率的影响,比如铁矿、LED屏对毫米波雷达就会有很大的影响,这是物理映射。颜色的特征值会对单目相机和光敏相机有一些影响,这是图像映射。概率映射可能不太好理解,在我们的所有交通参与者里面,行为的发生是有一个概率的,比如说换道行为,正常换道是要打灯的,但是打灯不是一个强制条件,所以打灯就是概率事件。在场景库存储的时候,概率会一起存储。在场景进行重构的时候,这个概率值就会伴随着它,场景会有一定的概率进行复现。这就是一个场景的四个维度的重构。

右面这个雷达、相机跟无线通信什么意思呢?对于一个客观存在的课题,要对它进行场景重构、场景建模的时候,实际会有非常多的维度,它可能在一个集合特征里面,比如说重量、面积、密度,这些东西都可以在场景库里面存在。但是这些细的维度要还是不要,就需要分析这些要素对于被测件的影响。如果它对被测件有影响,就要放进去,如果对于备测件没有太多影响,那就不要放进去了。比如说,传感器对于密度来讲都是一样的,密度在场景库里面就可以不存在。这就需要明白哪类东西对传感器有影响,这样的话就需要对传感器很熟才可以很好的构建场景库。

这是我们的几个技术过程,首先形成行驶环境,由道路场地、交通及设施、气象条件构成。然后把行驶环境通过百分之百真的道路、半真半假的训练、百分之百假的离散化这三种方法形成场景数据构成。当场景数据构成以后,再去形成针对这个场景数据开发的引擎,然后用这个引擎去管理数据。什么意思呢?你通过前面的有形映射,能够把百分之百真的道路、半真半假的交通流和百分之百假的气象,形成可能是你自定义格式的一个东西,百分之百的一个形式化的语义描述。现阶段很多主机厂希望得到的就是仅仅停留在Excel这样的产品形态上。但是这些形态里边有成千上万的场景,要把这么多Excel文件在VTD这类工具里重构出来,这是一个非常耗人力的,需要有一个额外的工具管理场景的这一堆文件,就是我们现在要的这个场景库文件。

场景库文件能够把成千上万个场景在一个可视化界面里面管理起来,然后通过不同的标签进行检索,然后将第三方格式转换成你使用的场景格式文件,因为目前来讲还没有一个标准化的格式文件。

另外这里面还要再说明的一个问题,目前每一个测试工具,对于同样的雷达或者同样的摄像头,比如都是威尔登的雷达的建模都是完全是不一样的。只有其中的一些参数是一模一样的,可以做自动化导入,而有一些东西是模型里面所特有的,这些东西就没有办法做自动化导入,只能在场景文件里额外标识出来,这几列是专门给VTD用的,这几列是专门给Panosim里面的雷达模型用的,即便他们两个雷达模型是一模一样的,都是给同一个雷达做建模的,但是他们的内参和外参依然可能是不一样的,所以要注意到这样一个细节。

所以我们现在通常会认为,我们作为一个场景库的提供商,提供给大家的场景库仅仅是一个有限的集合,大概是70%,就是你的用例里面70%是从我们这里买到的,余下的30%是要靠主机厂或者Tier1供应商自己构建出来的,是通过我们的场景库工具自动产生出余下的30%的场景,这30%的场景是能够产生产品差异化的。虽然都是用的基础场景库,但是因为每家的产品在功能定义上和性能上是有差异的,这个自动工具能够帮你产生场景,而不需要天天拍脑袋想场景了。我们期待未来的产品形态是,我们的场景库提供70%的测试用例,同时我们提供一个场景库工具,这个工具可以按照你的需求去产生场景,弥补余下的30%的差异化服务。

这是我们场景构建的具体案例。首先,最左边的是每一个场景里面已经分析好的对于控制器和处理器的影响以后,把场景的形状描述出来,因为这只是一个形状描述,本身是没有符号化的,相当于一个场景库的定义,再把这个定义传给第二部门进行场景要素参数化。比如要对一个树木进行建模,它的高度、遮挡、颜色等在第一部分里面只有文字描述,第二部分用计算机语言表达描述出来,使得计算机能够自动化处理。

有了这部分之后才能到第三部分,这个就非常有意思了,就是我们用一个场景自动生成工具,生成出来了1万个场景,有一个人用另外一个工具,也生成一万个场景出来,就要比较这一万个和另外一万个,总要有一个量化的评定方法,到底哪个更符合你的要求。所以我们为了做场景库还要再提出一套跟它匹配的场景的评估指标出来。这套指标现在看来,通过我们和OEM的一些讨论发现大家最关心的是你的场景到底有多少覆盖度?我通过这一万个场景来测的功能,因为我们现在谈功能都是L2以下的,比如说L1、L2我们认为具有什么功能,但是当你是连续驾驶的话,可能就不太区分功能了,可能L3、L4你只是一段连续的道路开就好了,不再区分到底是AC还是EB了。

到了那个时候我们最关心的就是,我经过这一万个场景的应用来测一个L3或者L2以下的东西,到底可不可以盖章、可不可以出去,就是我们所关心的覆盖度。除了覆盖度以外,大家还关心的就是危险度,相对来讲危险度比较好衡量了。还有一个是大家所关心的复杂度。在我们现在的方法里边,如果你的场景是能够自动产生的,实际上你就是能够覆盖住的,因为场景是你自动产生出来的,不是你拍脑袋想出来的。既然自动产生的意味着你肯定有依据,肯定有某一个去遴选它成为场景的依据,有了这个依据你才能够去产生场景,有了依据你就能够知道在这个依据的标尺下有多少场景是符合的、有多少是不符合的,所以你能够正向的给出它的覆盖度。

举个简单的例子,在我们现在的产生方法里,危险度是一个很重要的指标,危险度大家简单的理解成它是一个纵向TDC跟横向TDC的加权平均,这是一个衡量标尺。通过一个工具能够产生出一万个测试用例后,你用这个标尺去画一条线,大于它的留下来,小于它的拿掉,这样的场景出来这8000个你要的就是符合你对于危险度刻画量化指标之后的场景,这些场景自然而然能够给出这8000个场景,在你最终根据危险度这样一个驱动力,能产生出来的场景里边它到底占了百分之多少,自然而然给出一个覆盖度。

只不过到目前来讲,这个覆盖复杂度我们还没有很好的去量化。去衡量什么叫复杂度,这个并不容易,因为复杂度是相对而言的,很难讲一个绝对的物体有多复杂。比如讲一个人有多漂亮的,这个是相对的,绝对的说一个人有多美丽,是很难衡量的,因为太过主观了。

复杂度也是一样的,一个场景相比于另外一个场景你能很容易说出它有多复杂,但是只给你一个固定的场景,你很难去说,它到底是0.2还是0.3的复杂度,这个是不容易的,这个不像覆盖度、危险度那么容易做出来。

随机也是一样的,一个场景到底有多随机,也是相对的。目前我们也没有一个较好的方法进行很好的刻画。

这是我们对于场景的多维度衡量,最左边这一栏就是行驶场景,右边是跟主车有关的驾驶情景,下边是环境,构成了几个维度。

这是我们地图的构建,能够形成行驶场景的四个子构成,道路结构、静态物体、动态的影响、动态的场景。

前面大量的篇幅都是跟非主车以外的行驶场景有关的,这个讲的是跟主车有关的驾驶情景本身,你到底执行了什么样的任务?到底行驶什么样的速度?大家可能知道将来L3以上的无人车可能都不会采用同样的模式,可能都会有驾驶员人机共驾模式在里边,都会有一个驾驶员自己的模式在里边,这三个东西形成了在场景库里边的另外一个大的维度就是驾驶场景。所以我们一个场景的case就包含两个大的维度,一个就是行驶,一个叫驾驶,行驶的环境就是我们刚刚看到的那四个层次。第二个大的维度就是驾驶,驾驶里边就包括三个子的维度,就是驾驶任务、驾驶速度、驾驶模式。然后把这两个再拆开,那就是行驶场合,这就是我们的三个构成,最左面那个就是我们的维度,用来评价场景的维度。

我们现在讲讲量化指标,刚刚已经讲过了,复杂度、随机性是我们现在做不了的,危险性和覆盖度是我们可以做的。当然做不了也不代表着不能做场景库,只不过不能更好地刻画场景库。因为我们可能对于同样一个事物可能每一个人在将来的研究中可以有更多的研究可以去堆同样的数据去量化的话,可以对同样一个事物的理解或者评判可以更方便,因为我们将来做场景库筛选的时候可能会做的更细,现在如果说你只有覆盖度做或者只有危险度做的话,你对于筛选,只能有这样的筛选和评价,但是你没有办法去做,你想知道一些复杂度跟随机化的话做不了,但是并不影响到你现在场景库的使用,因为那个是来做评判的。

我们目前来讲在L3以上主要的措施的对象都是传感器和传感器对应的处理器,对于控制器的测试反而不多,现在主要就是传感器和它对应的那个,这里面要想做的话必须要对处理器和传感器要有很好的理解,就是它到底对于雷达、对于激光和对于光场和对于相机单目、双目的东西,到底哪些因素是有影响的,这些东西才有意义把它们放到你的库里面去,才会显得这个变成离散化有界的。之前有厂家会问我就是,这样一个属性把哪些东西要放进去?第二个问题是放进去之后这些东西的离散化要做成多么的细粒度?其实这个问题问的就很好。什么东西应该放进去?放进去之后,因为大多数量都是连续量,放进去之后很多东西怎么变成离散化,就要看这些东西对于传感器的影响,如果说有影响就放进去。那么力度就看你这个东西对于传感器的影响的力度是心里样子的。比如说我对于一个64线的激光雷达的影响和对于一个4线的激光雷达的影响,对于同样一个是外观、同样是轮廓,你的力度的刻画到底是什么样子的,其实是跟你的被测对象是有很密切关系的,所以你可以这样去决定你到底要放什么东西进去和你放多少东西进去、什么样的力度进去。

下面我们就来讲一下虚拟场景的构建技术。现在我再讲一下我们的数据来源,我们现在场景来源的数据实际上有两大类,第一大类就是你从实际数据中获取的,第二大类就是你自动产生的,一个是纯粹的从实际数据里面得到的,一个是你自动产生出来的,靠一堆算法产生出来的。如果你是从实际中产生出来的,比如说路补,开个采集车道路上跑采集回来的,路补回来的数据,要么就是拿到大量的事故的数据,因为事故的数据当然是大量的小概率事件了,那些东西可能很有意义,因为那个东西量很小,所以你可以完成你的重构。要么就是在封闭场地里面,通过大量的客户测试出来得到的数据,要么就是在半开放的道路里面你得到的数据,这些东西都可以称之为是从实际中得到的数据。要么就是自动按照产生的,自动产生的目前来讲还很少的,主要都是一些大学在做,包括我们在做。这样一个特别有规矩可循的一个过程,能够把它变成一个算法让它产生出来。如果说你对场景有很好的定义的话,自然而然你就会有一套规则,场景自然而然就能够自动产生了。因为前期它已经不再是一个非常定性的描述了,它已经变成一个你可以把它定义很好,到底怎么构成,什么有关系,然后可以用一个平滑指标去衡量它,就可以把它做成自动算法了。这也是我希望能够去做的事情,就是对于实际获取的那些数据有了一定的理解以后,你可以根据它去形成一个算法,通过这个算法才是我们大量的东西,产生出70%的数据出来之后,余下30%的那些场景库里面的内容我可以辅助一些工具,通过这个工具把这些东西再造出来,这样我们就形成这样一个七三开的局面。这就是我刚刚讲过的我们现在数据构成的来源了。

这是一个很有辩证法的东西,我们的场景获取,这个场景本身发生的概率越低的它在场景库里面存的量越小,发生越容易的它的量越大。比如说,第一部分我们虚拟仿真,虚拟仿真我们叫做场景自动产生,就是它量是很大的;第二部分,是我们开放道路的,就是我们这种拿道路测试牌照的;第三部分,是我们这种封闭测试场的,就是在有心的空间下面进行场景的柔性化构建的;第四部分,就是我们在实际真的运营跟生活中遇到的一些事故数据。这是我们四大类数据的构建组成部分。纵轴就是我们在场景库里面公里数里面占的公里比例。

有了场景之后,从场景到场景库,从场景库到你的工具的这个过程就是你怎么去把你的场景建立出来。很大的一部分就是我们场景的数字重构,就是我们通过给到备测件,不管是搭纯粹的MIL还是搭HIL台架。右面这部分就是我们的实验室构建了,就是你可以在实验室里面去搭一个,比如说搭一个暗室,然后搭上你的轮毂电机,再搭一个或者是在一个大棚里面去搭出一个下雨下雪的环境,这是我们目前的两大类。

下面讲的是现在所追求的能够去把不同厂家的场景库,因为目前在国内能够提供场景库的并不多,掐指可数,现在大家能见到的一个手就能数得过来这种厂家。现在所去追求的,例如你花了一百多万买了一个场景库回来,准确说它是一堆数据,只能叫做场景的集合,不能称之为一个库。我们这些东西你是希望它能够变得可持续发展,因为你不想说你买了2万个case回来,这2万个case就放在这儿当死的了,将来3万个、4万个怎么办呢?你肯定希望有一种方法对这2万个case加以综合利用,能够让它再有新的鸡蛋出来,这样我们现在所追求的就是,要能够去做你的自动化标注,然后自动的入库,然后和自动的测试,然后能够做自动化生成,这就是我们认为那个场景库它的意义所在。因为现在本身已经有很多工具了,大家可以买到,而且工具现在来讲大家的竞争也比较稳定下来,就是大家对于模型、大家对于场景渲染的理解,都已经没有差异化那么大了,相对来讲各自的水平已经比较接近。但是这仅仅是个工具,后续能够驱动这个工具能够更好使用起来的是那个数据部分,现在各个厂家对于数据部分反而没有那么的重视,用户很重视,这些数据产生出来本来就是一个比较难的课题,所以反而没有那么多、没有那么大的可选择的余地,所以这就是现在我们要做的,就是怎么能够更好的去产生出数据出来,就是大量的自动产生,是能够看出一个场景库的厂家跟另外一个它的水平的高低,将来可能是希望大家能够自动的产生,在有限的场景集合下面能够产生新的数据出来。

这是我们现在对于场景库构成比例的一个理解,就是事故的集合最小,然后外面就是我们的法规测试,再外面就是我们路补的数据,整个集合是我们自动产生出来的,大的圆圈是我们全都产生出来的,然后你通过你的场景刻画的维度,就是复杂度跟危险度,在这样一个无穷可数集合里面通过这样两个尺子或者三个尺子把想要的东西检索出来就是这样一个过程。

这是我们实验室模拟场景构建的相当于技术框架,就是你可以通过强光模拟、可以通过雨淋或者喷淋,可以通过你的一个线控底盘小车,能够把你上面的那些车辆跟其他的自行车、交通参与者放进去,可以通过灯光去打出一个可变的交通标志牌和车道线,因为现在很多技术能够打出可变的车道线出来了。就是通过这种可变灯光,根据你上位机场景库里面的内容,把这次用的车道线打出来,这样可以在有限的空间下面可以一直去动态的变化你的场景的路线。在实验室里可以把我们一个相当于是有点像你构建了一个虚拟的世界,就像那种大的卖场里边,然后你没有任何东西,但是你通过上位机的控制、通过灯光、通过雨淋、通过喷淋、通过线控车,把它全都变化出来。

这是我们实验室模拟里边的其他的另外一个维度,我们需要去构建出我们的道路、交通、底盘车辆、线控车辆、隧道等测试指标,都在这个虚拟场景里复现出来。

我们本身同时做场景库也做工具,所以在场景库到工具的这个我们涉及到的几个关键的地方,就是对于测试引擎比较关键的地方,它是跟你的场景库绑在一起的。场景库里面存的是行驶场景、驾驶场景、交通流,主要就是道路、交通流、气象三个维度。这就意味着你的引擎里面比较关键的地方就是要有一个比较多维度的交通建模,以便于当一个第三方的场景库导进来的时候你的工具能够把场景库里边的交通流维度复现出来。第一个是高逼真的交通流,这是比较重要的。第二个气象,我们交通流另外一个大的维度就是气象,能够对下雨下雪、沙尘暴这种气象的变化有一个柔性的模型,对场景库给出的要求能够把它复现出来。如果说测试工具选的不好,场景库里面有很好的内容,场景库本身对一个场景刻画的很好、雨刻画的很好,什么样的雨,雨的密度分布什么样子的、它的风力什么样的,这个刻画得很好,但是这个场景离被测对象中还间隔着一个测试工具,这个测试工具你要能够有办法给定一个场景放到测试工具里面去,测试工具能够把非常细腻的场景产生出来、能够把下雨重构回来,然后再给到我的被测对象。比如说能量进行吸收或者进行反射,这个场景才真正的起作用,否则的话只是很好的一个文件没有办法把它产生出真正的测试作用出来这就比较可惜了。所以说对于中间测试工具的要求就比较高了,最好是这个场景库跟工具目前来讲实际上是不需要他们匹配的,没有要求说都必须是由一家公司提供的,因为场景库是场景库、场景是场景、测试工具是测试工具,这三个全都是剥离开的,希望大家能够区分开。

下面是我们的数字虚拟化场景构建,就是第三个和第四个是我们的场地建模,另外一个维度,场地是真实的可以通过路补数据回来的,直接做导入就可以,这个很简单并不难。

前面那几个是我们几个场景对于引擎起到的作用。第五个是希望我们的场景库能够做自动生成技术,简单理解就是生成一个大的集合通过我们的评判标准在大的集合里面去做筛选,留下来的就是我要的。比如说危险度,0.5以上的或者0.2以上的是我要的,余下的是我不要的就拿掉,这样的话剩下的那些就是我们能够判断出覆盖率,是我们需要的。

典型场景的重建技术现在来讲就看大家对于测试工具的理解了,想要什么样的工具?比如说同样的场景库,给到不同的工具这个复现起来场景是不一样的,这个希望大家真的要理解。

场景库买了以后,工具可能是二次招标的。这个招标可能是不在一起的,场景库是一次招完的,测试工具是一次招完的,这两个工具是不匹配的。有的时候发现可能会先买工具或者先买数据,可能会导致两个合不上,有的场景库放在这儿,有的工具放在这儿,但是你发现它们两个没有办法匹配,匹配不到一起去就会遇到问题。所以当你去买场景库的时候要想好未来用哪个测试工具去做测试,比如说Panosim或者VTD测试要提前想好。如果那个时候才能知道这个数据能不能够做自动化导入,买了一堆数据还要靠人工的在工具里面做人工的重构是非常麻烦的。例如这个场景里面有一百台车,你可能要在场景库里面去搭出一百台车出来,道路在Open drive就可以很容易导进来,但是辆车辆的行驶轨迹还要一百台车在VTD里边或者Panosim手动编辑它的Trees文件,那个是非常大的工程了。这里面就涉及到能够变成一个第三方独立的工具,这个工具能够针对于后续要用到的测试引擎格式能够做自动化的格式匹配,能够导成我要的格式,能够导进去是最好的,这样非常适合我们后续的使用。

现在场景除了能够用来做测试以外对于我们现在的L3以上的自动驾驶中的学习跟训练也是起到非常大的作用。可以用我们现在自动标注的,是自动产生的,这个场景库里边所有的数据是你自动产出来的,你自然而然能够知道它们所有的真值,知道真值自然而然能够对你的训练非常有帮助了。

我们现在用场景库的自动生成工具就能够自动化生成出来大量的海量数据出来,这些数据就省去了大量采集的工作量,这些大量的自动产生的就可以做自动化标注的数据就可以去用于它们后续的训练跟测试,这是我们研究用场景库的两大目的。

这个是我们现在做的一个很典型的在环系统,就是把我们的场景库、测试引擎全都搭在一起的这样一个总的例子。最左边大家能看到的是我们的场景库,是我们的数据跟我们的场景管理在一起的管理库,它是一个完全隔离的一个工具、是完全隔离的一个系统,它里面管控着我们所有的数据,然后把这些数据放在一个库里边进行管理,这个库本身是可以检索的。它是可以根据每一个场景检索,每个场景是有标签的。比如这个场景的标签是什么,比如说它是什么样的道路,比如说十字路口或者说停车场这样的标签,然后加上它的车辆的数量,加上主车的姿态这些东西,这些标签能够检索出来之后我们把这些场景、引擎,选择的引擎注到上位机里面去,上位机会把这样一个场景的实例,实际上它是一个实例集合。要做闭环测试,首先是一个片段加上一个片段,不是说只是一个片段,一个片段太简单了,可能你要有很多很多片段合在一起要做闭环测试。一个功能可能需要测2000个到3000个case,凡是符合标签的全都检索出来放到上位机里面去。上位机会把这样的片段全都组合起来,需要把这1000个case连在一起连成一个大的序列,把这些大的序列在场景库里面根据你的被侧对象剥出来。比如说你的被测对象是相机或者是毫米波雷达或者是体的直接的控制器,根据你的被测对象把它再重放出来。

现在这是一个V2X在环的例子,这个例子里面就会给到我们的发射器,通过网口会得到我们发射器发出来的信号,我们要通过网剖转成我们LTE—V信号,上位机是没有办法发出LTE—V信号,把它转成LTE—V信号,把LTE—V信号再注给我们的信道衰落的设备再通过我们的信道衰落设备给到我们的备测件,备测件就是我们在车上面的LTE—V的盒子或者是你的控制器。比如说你有控制的功能还只是ADAS报警,会把信号给到HMI,HMI就在下面的弹窗显示出来。如果它只是ADAS开环就需要另外的一个设备把这样的一个信号采集到,采集到之后再回到上位机判断它到底是漏报的还是误报的。如果它是控制功能的再把这个信号引到我们右边的实时仿真器里面去,来控制我们实时仿真器里面的主车动力学,主车动力学做出响应把响应再回到上位机,然后再控制着上位机的主车的行走就可以了。这样就形成了针对V2X目前针对开环盒子的测试和未来在我们Date 1(音),现在Date 1现在都是没有任何控制指令的,但是在Date 2里面新的应用里面是含控制的,针对于Date 1和Date 2的,在这个场景下,这个台架就能够实现我们场景库的使用跟我们引擎的使用了。

今天的讲座就到此结束,大家后续可以加我的微信,关于场景库跟场景、自动生成、测试用力这些东西都可以发微信跟我聊一聊沟通一下。一个小时很短很难去讲很多,只能考虑到后续大家一起交流,因为现在来讲场景库还没有非常明确的一个标准和大家非常统一的认识。每个人可能国内的几家公司和几家大学都有一些自己的理解跟认识,只不过慢慢现在大家我们跟主机厂的场景库慢慢越来越多开始慢慢趋同了,开始趋向于自动化产生场景库的理解了。今天讲课到此结束,谢谢大家!

注:本文由中国电动汽车百人会未来出行学院授权时点汽车转载发布。

作者:王健,来源:未来出行学院


【版权提示】本文为转载内容,时点汽车(www.autombiz.com)倡导尊重与保护知识产权,转载内容都已标明出处与作者,如发现本站文章存在版权问题,烦请提供版权证明及联系方式等发邮件至tougao@autombiz.com,我们将在24小时内进行处理。

   

微信扫一扫,分享到朋友圈

微信公众号

猜你喜欢

关注我们的公众号

微信公众号
吉林大学计算机科学与技术学院教授王健:自动驾驶测试场景库的自动构建方法-海报

分享海报