自动驾驶仿真测试的难点

devtools/2024/12/22 2:57:39/

自动驾驶仿真测试是自动驾驶车辆商业化落地的一道重要关卡,仿真测试技术的发展进步将决定自动驾驶落地的时间点。

仿真测试对自动驾驶的重要性不言而喻,笔者写这些内容希望能够抛转引玉。更希望能够作为一个“呐喊者”让更多的人去关注和重视自动驾驶仿真测试这个领域。

自动驾驶系统现阶段最大的问题是“落地应用难”,之所以“落地应用难”是因为自动驾驶系统的安全问题尚未得到妥善的解决。解决系统安全问题就需要进行大量的虚拟仿真测试和实车道路测试,而仿真测试能够大大加快系统的测试验证进程,因此,如何高效、可信地对自动驾驶进行仿真测试评价是自动驾驶系统商业化落地的关键。

接下来讲一下目前自动驾驶仿真测试的两大痛点问题:仿真测试的置信度和仿真测试场景的覆盖度问题。

1. 置信度存疑

1.1. 仿真软件本身的置信度问题

现在虽然很多仿真平台都具有传感器建模仿真、车辆动力学建模仿真以及交通场景建模仿真的能力,但仿真模型大多都是建立在理想条件的情况下,仿真模拟器模拟出来的结果的置信度到底怎么样,还没有具体可量化的指标去评价。

以激光雷达仿真为例,激光雷达的反射强度与障碍物的距离、激光发射角度以及障碍物本身的物理材质相关。激光雷达探测范围大,发射出去的激光线束又十分密集,且在环境中存在多次反射、遮蔽等影响,计算返回的激光束比较复杂,很难较为真实地对激光雷达信号的回波进行模拟。现有激光雷达模型,大多是根据每一种物理材质的激光反射率直接计算回波信号。如此计算的话,与现实中的回波信号肯定是存在一定的误差。

若是考虑到传感器硬件或软件自身造成雷达的噪点问题,以及雨雪、水渍、灰尘等这些干扰雷达工作性能的环境因素,导致雷达性能减弱或者无法使用的现象。这些问题或现象更是激光雷达仿真模拟的难题。

1.2. 仿真平台复现和泛化出场景的置信度问题

目前通常采用的手段是,基于真实数据通过仿真模拟器去复现和泛化出更多的虚拟仿真测试场景。那么,这些测试场景与真实场景的拟合度能达到什么水平?

什么是场景的泛化呢?即将路采的真实场景数据进行特征提取、数据标注等操作后,仿真平台依据场景特征元素的关联关系或者人工经验等对场景元素进行重新组合或推演归纳处理,从而衍生出更多合理的新场景。

真实场景的泛化存在两个问题:

一是泛化的方向是否符合统计学意义与测试需求。当前的自动驾驶企业都未明确提出其动态场景相对于真实世界的统计学意义。确定仿真场景与真实世界在统计上的映射关系是亟待解决的难题。

二是泛化过程中真实性损失,例如,对密集交通流案例进行泛化,更改一条车辆轨迹后,在实际中会对周边多条轨迹产生影响并扩散开来,单车的行驶扰动有时会造成整个交通流的失稳,现在的泛化技术很难重现这种场景。

复现和泛化出来的虚拟仿真环境与真实环境之间必然存在差异,这种差异会对测试结果造成多大的影响,是否在可接受的范围内?可惜现在也还没有具体可量化的KPI指标去评价这些测试场景的置信度。

1.3. 测试结果评价标准的置信度问题

目前传统的测试手段还是以硬件测试(包括HIL硬件在环、VIL车辆在环)或真实道路测试为主。有调查结果显示,对于纯虚拟仿真测试(如MIL模型在环/SIL软件在环),很多客户认为验证出来的数据不是特别可靠,即真实性没有保证。

一位仿真专业人士曾在他的文章里讲到过:“在自动驾驶仿真中,是很难有‘参数标定’这个过程的,因为‘真实试验’对安全员有高危性,并且很难执行,因此也就很难调整仿真的参数,没有标定好的参数,又很难预测真实结果,就像个死循环。试验-仿真-试验的回路难通,仅靠经验式的仿真,结果如何让人信服?”

是呀,由于“试验-仿真-试验”的回路不通,结果的好坏比较难判定,客户对仿真结果的真实性存在疑问也就在所难免了。那么,又该如何提高自动驾驶仿真测试系统的置信度呢?现在虽然还没有完美的方案,但相关企业已经开始采用不同的方案来提升仿真系统的置信度水平了。

腾讯的自动驾驶仿真平台TAD-Sim采用游戏渲染+真实数据双擎驱动的方式,通过利用大量真实路采数据训练交通流AI模型,再结合游戏渲染引擎技术,自动构建互动性较强,贴近真实世界的测试场景。

百度采用增强现实的自动驾驶仿真系统-AADS,通过使用车辆搭载的激光雷达和高清相机扫描街景,获取车辆周围静态的场景图像和车流移动的动态轨迹数据;利用这些素材,系统再应用增强现实技术直接、自动地创建高逼真度的仿真图像,使得创建出的虚拟场景更加接近真实场景。

51WORLD采用数字孪生测试技术来增加仿真测试结果的置信度,即利用数字孪生技术构建一个与真实场景一致的虚拟场景模型。实车在真实场景测试的过程中,会以车辆在环方式将车辆实时状态数据实时映射到虚拟场景中,同时虚拟场景的测试数据和评价结果也会反馈给现实世界,作为指导和优化现实世界中真实车辆进行决策的重要依据。

2. 场景的覆盖度问题

2.1. “Corner Case”难以穷尽

现在自动驾驶仿真测试另一大痛点便是如何构建一个高覆盖度水平的场景库(覆盖几乎所有的“Corner Case”),若有这样完美的场景库,系统只需把场景库中所涵盖的测试用例都验证一遍,满足要求后便能够达标。

自动驾驶仿真测试来讲,最大的挑战在于去收集到所有Corner Case,来覆盖不同的道路环境、天气环境以及交通状况,这几乎是不可能完成的任务。单从收集自动驾驶Corner Case这方面来讲,Waymo的实车路测里程比较长,从统计学角度讲,它碰到的Corner Case相对就多一些(截止到2020年,仿真系统里的模拟测试里程累计超过150亿英里,实际道路测试里程累计超过2000万英里)。尽管如此,其工程师们仍然发现有层出不穷的新长尾场景待解决。

其中国外一遍论文《Corner Casesfor Visual Perception in Automated Driving: Some Guidance on Detection Approaches》,对自动驾驶视觉感知中的Corner Cases进行分析,并提出了一些方法论。论文中根据检测出“corner cases”的复杂程度,由浅到深,由易到难划分了5个级别:

  • Pixel level:由数据上的错误造成;比如风挡上出现了污垢遮挡了摄像头的部分视野,或者夜里对向驶来的车辆开着的大灯让摄像头出现眩光等场景,导致摄像头采集的数据出现错误。
  • Domain level:数据表现出的对世界的观测产生了整体偏移;比如冬天到处覆盖着白色积雪的场景。
  • Object level:数据中存在未曾“见”过的实例;比如在居民区的道路中央出现了一只骆驼。
  • Scene level:单帧数据中出现了与预期不一致的场景模式;表现为熟知的物体出现了大量未知的聚集或者熟知的物体出现在异常的位置;比如大风过后,倒在路中间的树。
  • Scenario level:连续帧数据中出现了与预期不一致的场景模式;比如“鬼探头”,旁边静止的车辆前突然出现一个行人。

对于不同级别的Corner Case需要采用不同的方法,对于前3个级别相对简单的场景类型:pixel level、domain level、object level,可以抽取特征元素通过参数重组的方式来构建;然而对于Scene level和Scenario level这两种复杂级别的场景,数量也比较庞大,很难完全穷举。所以最好的办法还是需要进一步提升系统的感知能力,需要通过深度学习方法让系统从“感知”进化到“认知”,让系统也具备接近人一样的知识推理和泛化能力。

机器学习是解决自动驾驶长尾问题的一种有效工具。利用Machine Learning技术可以实现从数据采集、标注、训练、车端部署的闭环循环流程,从而实现Case的不断积累,模型的不断完善。但机器学习模型不能解决所有的问题,可通过采用机器学习和非机器学习混合系统,利用专家系统来弥补机器学习的不足。

对于消费者来说,是否使用自动驾驶汽车,安全肯定是其考虑的第一位的要素。同样,对于主机厂来说,能够让测试车辆能够应对各种“Corner Case”,进而保证量产车辆上路后的安全性也是他们的立命之本。

2.2. “Corner Case”的地域性特征

“Corner Case”的地域性特征主要表现在测试场景在不同国家和地区存在较大的不同。因为各个国家的道路环境、交通习惯、交通规则以及驾驶习惯都可能存在较大的差异。

  • 道路环境不同:不同国家的道路设计规范不同,如道路结构、交通标志、交通信号灯等形态各异。
  • 交通状况不同:在中国的城市道路上,人车混流的交通状况随处可见。无论在哪个城市的大街上,你都能看到快递小哥、外卖骑士驾驶着他们的坐骑与机动车并驾齐驱的场景;这种交通场景在北美和欧洲一些国家是很少见的。
  • 交通规则不同:国内红灯默认可以右转,很多地方在没有导向车道的路口是默认允许的,但德国默认不能右转。还有高速限速问题,国内的高速限速120,但德国高速的很多路段一般是不限速的,在那样的道路上飚个200是很正常的事,但是如果在中国这样做,那不仅是自己找死,也很有可能连累到无辜的人。
  • 驾驶习惯不同:在德国,先行权概念意识比较强,大家基本都是严格按照先行权逻辑开车;国内交规几乎没有这套逻辑,有红绿灯的路口相对还好一些,对于没红绿灯的路口,尤其是到了晚上,基本是谁胆大谁先过。国内还有一个不好的现象,就是加塞情况比较严重,尤其是在车辆拥堵时,你左右两边的车可能随时不打转向灯,便如幽灵般见缝插针地切入到你前面的空当位置。

由于不同国家和地区的车辆行驶环境的差异化,导致测试场景数据的具有很强的地域属性。测试车辆面对的极端工况场景在数量和内容形式上也会有很大的不同。大家可以想象一下,在美国地区测试完全安全的自动驾驶系统,如果放在中国这样交通环境更加复杂的国家去测试,系统必然会碰到之前没有遇到过的“Corner Case”,那么车辆的安全性将依然是没有保障的。

一个企业的自动驾驶系统如果想要在一个国家商业化量产应用的话,必然需要先通过当地的测试场景评价考核,即保证它能够应对当地的所有的极端工况场景。

然而,中国本土仿真企业具有“近水楼台”的先发优势,更容易设计开发出适合中国自动驾驶方案的仿真测试软件。首先,他们比国外企业更了解国内的道路环境、交通法规以及驾驶习惯;其次,更容易优先获得中国的路采场景数据。

3. 数据成本和路测里程要求

首先,自动驾驶作为人工智能技术的“皇冠”,其感知算法的训练需要采集大量的数据,这些数据集需要涵盖不同的天气、路况等交通条件,但是训练数据采集和标注的成本非常高昂,每年全球的自动驾驶开发者仅在第三方数据服务这一领域的资金投入就超过十亿美元。

其次,数据的采集和标注存在很明显的“重复造轮子”现象。每个公司都有自己的自动驾驶数据集,虽然已经有部分对外开放,但是比例很少,而且开放数据集只能满足通用的训练数据,国外数据集也很难完全满足国内的感知算法训练需要。

最后,在算法的测试验证上,行业普遍认为一套自动驾驶算法需要至少110亿英里的测试,才能达到量产应用的条件,这个距离相当于在太阳和地球之间往返50余次。而且110亿英里测试距离是针对特定一个版本的自动驾驶算法来说的,一旦算法升级,还需要重新测试,任何公司都无法承受这个成本。”

参考文献

自动驾驶仿真测试的两大痛点问题-有驾

突破自动驾驶测试瓶颈 腾讯模拟仿真平台详解 


http://www.ppmy.cn/devtools/2072.html

相关文章

呼叫系统的技术实现原理和运作流程,ai智能系统,呼叫中心外呼软交换部署

呼叫系统的技术实现原理和运作流程可以涉及多个组成部分,包括硬件设备、软件系统和通信协议。以下是一般情况下呼叫系统的技术实现原理和运作流程的概述: 硬件设备: 服务器:用于承载呼叫系统的核心软件和数据库。电话交换机&#…

【数学建模】最优旅游城市的选择问题:层次分析模型(含MATLAB代码)

层次分析法(The analytic hierarachy process,简称AHP)是一种常用的决策分析方法,其基本思路是将复杂问题分解为多个组成部分,然后对这些部分进行逐一评估和比较,最后得出最优解决方案。(例如&a…

SpringBoot整合Nacos

文章目录 nacosnacos下载nacos启动nacos相关配置demo-dev.yamldemo-test.yamluser.yaml 代码pom.xmlUserConfigBeanAutoRefreshConfigExampleValueAnnotationExampleDemoApplicationbootstrap.yml测试结果补充.刷新静态配置 nacos nacos下载 下载地址 一键傻瓜试安装即可,官…

成都百洲文化传媒有限公司开启智慧营销新篇章

在电商行业风起云涌的今天,成都百洲文化传媒有限公司以其独特的视角和专业的服务,成为了行业中的一股清流。专注于电商服务,百洲文化不仅为客户提供了一站式的解决方案,更以其创新的思维引领着行业的发展方向。 一、百洲文化的独…

【5】DongshanPI-Seven 应用开发_网络编程TCPUDP

目录 1、网络编程概念2、网络编程的API2.1 网络通信交互示意图2.2 主要API 3、编程测试3.1 TCP 测试3.1.1 server 程序3.1.2 Client 程序3.1.3 测试结果 3.2 UDP 测试3.2.1 udp server3.2.2 udp client3.2.3 测试结果 1、网络编程概念 1.数据传输三要素:源、目的、…

Leetcode - 周赛393

目录 一,3114. 替换字符可以得到的最晚时间 二,3115. 素数的最大距离 三,3116. 单面值组合的第 K 小金额 四, 3117. 划分数组得到最小的值之和 一,3114. 替换字符可以得到的最晚时间 本题是一道模拟题,…

阿里云服务器怎么更换暴露的IP

很多客户阿里云服务器被攻击IP暴露,又不想迁移数据换服务器,其实阿里云服务器可以更换IP,今天就来和大家说说流程,云服务器创建成功后6小时内可以免费更换公网IP地址三次,超过6小时候就只能通过换绑弹性公网IP的方式来…

Linux网络服务器编程:TCP与UDP详解

文章目录 一、TCP与UDP概述1.1 TCP的原理1.2 UDP的原理1.3 数据流动 二、Socket的使用2.1 TCP Socket示例2.2 UDP Socket示例 三、数据流动时序图3.1 TCP通信详解3.2 UDP通信详解 四、异常情况处理4.1 服务器ACK丢失4.2 第三次握手的ACK丢失 五、总结推荐阅读 Linux网络服务器编…