编者按:《郭继舜带你读汽车科技》旨在从第一性原理出发,尝试拨开迷雾,解读热点背后的汽车科技真相。
本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品,内容独家授权汽车之心发布。
各位朋友,有挺长一段时间没有更新了,因为这段时间我一直专注于处理一款量产车型的智能驾驶功能问题。
这款车型很快就要量产了,但是智能驾驶功能还有比较大的优化空间,至少还没有到让我们满意。
其实每当到了某个车型智能驾驶配置即将量产的前夕,都是最忙碌的时候,大量的道路测试会反馈回无数多的问题,每天都在不断解决算法 bug 和反复调试系统参数。
因为每款车型我都希望能搭载一些新研发的功能,这些技术的亮点在研发过程中也会是最难做好的问题,所以智能驾驶汽车的研发很像是西西弗斯,每个车型就是一块巨石,痛苦和成就感交替,周而复始。
而最近这款车型,是我从事智能驾驶量产这些年中,最狼狈的一次,因为想上尽可能多的新功能,所以见到了人生里最长的问题列表。
终于,到今晚为止,关闭了 94% 的遗留问题,功能和性能表现达到了不错的水平,赶快来录音频把这几天欠的债补上。
首先,我要把这几天调试的一部分心得给大家做一个梳理,以下主要针对智能驾驶量产的整车系统表现,不包括 L4 及以上智能驾驶:
1. 多传感器融合是非常不好做的,特别是在速度比较高的场景下,更是需要耐心的调教和测试;
2. 我记得 2018 年的 CVPR,在一个智能驾驶的 Workshop 中讨论过一个话题:现阶段什么技术是自动驾驶算法中最难的技术?众多业内大佬经过热烈探讨,结论是感知依然是当前自动驾驶最难做好的技术。
我当时有点不以为然,一群做深度学习和计算机视觉的专家,肯定说自己做的这部分技术含量最高。
经过这几天的历练,我越来越深刻地感受到,感知确实是现阶段最难解决的问题,感知不准确,我们在决策端做再多的算法补偿的效果都是有限的;
3. 行车场景下的各种大货车、模糊不清的车道线、新旧车道线交叠的场景,是最容易影响智能驾驶表现的场景.
泊车场景下,用不同颜色砖块表示泊车线的泊车位、地下停车场柱子旁边的泊车位,这些场景很考验融合泊车系统的鲁棒性;
4. 选择好的执行器件非常重要,特别是 EPS,死区过大往往会让你和工程师们有抱头痛哭的冲动;
5. 智能驾驶开发,仿真平台的作用愈发关键了,实车测试遇到典型场景的密度太低,造成测试效率数量级上的落后。
现阶段,我们在 L4 自动驾驶研发中使用了相对多比例的仿真测试,但因为量产的 ADAS 车型需要兼顾运动学和动力学的系统性能仿真,所以现阶段还不能把各种段整合得足够好。
量产层面,我们还是比较依赖实车的测试验证的。
但大趋势是,整车厂越来越需要智能驾驶仿真了。
其实我们很早就开始尝试使用侠盗猎车手 5、百度 Apollo 平台等来做智能驾驶算法的仿真。
量产上也会使用台架、车辆在环系统进行一部分的仿真工作,但真正让我有深刻触动的,是有一次针对一款旗舰车型的实验样车审批。
因为近年来智能驾驶、车联网功能量产搭载的比例非常大,样车需求也急剧增加,加上智能驾驶的很多功能在量产前的功能验证,动辄数万公里的验证里程,让智能驾驶成为了实验样车需求的大户。
举个例子,去年某款新能源汽车的 AEB 一个功能,我们就验证了 5 万公里。
最终这款旗舰车型的样车需求统计下来,数字惊人,加上实验样车因为量少,零部件成本非常昂贵,样车总计的成本几乎上亿。
所以大家以后在路上看到有伪装的实验样车,可别笑他们破破烂烂,每台车买一两台保时捷 718 是绰绰有余的。
前面讲到仿真的重要性,今天我们就来谈谈自动驾驶的仿真技术。
首先,简单总结自动驾驶为什么需要虚拟仿真技术:
1. 虚拟仿真能够以非常快的遍历速度和极高的场景密度让自动驾驶系统在更多场景下对算法逻辑和功能进行验证,其算法逻辑验证的效率是实车测试的数百、上千倍;
2. 虚拟仿真能够还原极少出现但理论上还是会遇到的 Conner case,甚至是车祸场景,在实际路上故意创造这样的场景的成本很高,也有危险性;
3. 虚拟仿真能够对所有交通参与者的行为进行定量的设定和改变,这样就能够创造出更多的场景,轻松验证场景的覆盖度;
4. 在未来使用量产车型众包的方式来收集场景的过程中,我们需要使用虚拟仿真还原众包数据的结果;
5. 全都用实车测试太贵,算法改进效率也很低;
6. 其实 MPI(Miles Per Intervention),也就是脱离里程,是非常不科学的评测自动驾驶系统能力的手段。
后续我们可以通过收集足够多的场景,使用虚拟仿真系统,快速客观地通过测试不同自动驾驶系统的场景覆盖度来评估优劣。
1、什么是自动驾驶虚拟仿真技术?
实际上仿真技术从计算机诞生之初就已广泛应用在现代工业化大生产的体系中了,从计算机辅助设计(CAD)、计算机辅助工程分析(CAE)到计算机辅助生产制造(CAM),虚拟仿真技术在其中都起到了非常重要的作用。
仅以汽车行业为例,我们常见的就有空气流体力学仿真、车体碰撞仿真、发动机燃烧过程仿真、车身 NVH 声学仿真、车辆动力学仿真以及车辆控制算法仿真等等。
这些仿真技术的类型与应用各不相同,但是其核心原理仍然是计算机建模与应用,大致的过程可以抽象为以下几个步骤(如下图所示):
1)分解过程:根据业务过程闭环,将应用系统划分成为接口明确的子系统。具体到智能驾驶,就是把智能驾驶的各个功能和软硬件模块划分出来。
2)建模过程:根据应用需要,对子系统从原理与数据上进行计算机建模,建立子系统的仿真模型。具体到智能驾驶,就是把智能驾驶的某个功能或者零部件的原理或者特性在计算机上尽可能逼真地建立数字化模型。
3)仿真过程:根据测试需求,将部分子系统替换为虚拟的子系统模型,利用仿真引擎进行虚拟仿真下的业务闭环,必要时可以并发进行;具体到智能驾驶,就是在程序内部或者台架上对功能进行模拟,并且通过改变输入,观察输出是不是和我们预设的一样。
4)优化过程:针对虚拟仿真测试的结果优化被测对象的设计与实现,并通过真实测试来验证仿真系统的有效性,获得更多数据优化仿真模型,实现仿真模型与被测对象的共同进化。具体到智能驾驶,就是把虚拟仿真中发现的没做好的算法或者逻辑,修改后进行反复的迭代和优化,最终达到我们满意的结果。
以上步骤,是我们通过虚拟仿真系统来进行开发的通用的流程,而完整的仿真系统还需要做到对仿真模型、案例数据、仿真过程,输入输出接口的完善管理。
在自动驾驶虚拟仿真测试中,根据真实子系统与虚拟子系统的不同划分,可以分为:
MIL(模型在环仿真)
SIL(软件在环仿真)
HIL(硬件在环仿真)
VIL(车辆在环仿真)
DIL(驾驶员在环仿真)
分别代表了真实子系统为模型、软件、硬件、车辆、驾驶员的情况下的虚拟仿真业务闭环过程。
需要说明一下,如果是我们全部自研算法的智能驾驶系统,从 MIL、SIL 开始到 VIL 都是可以完成的,但是如果你使用的是 Mobileye 的 EyeQ 系列芯片,比较封闭,拿不到代码或者中间数据,我们就只能从硬件在环和车辆在环层面去仿真。
一般来说上述过程闭环所需要的仿真模型通常包括:传感器物理模型,车辆动力学模型,静态虚拟场景模型,天气气候模型,动态虚拟对象模型,动态交通流模型,车辆驾驶行为模型、突发事件模型等等。
这些模型的建模与运算需要非常专业的背景知识技能以及数据积累,并且需要专业的厂商提供的相应的仿真引擎来实现。
例如:车辆动力学建模需要专业的车辆动力学引擎并且需要车厂提供详细的车辆参数,传感器物理建模需要传感器厂商提供电磁学模型,交通流与驾驶行为建模也需要专门的交通流仿真引擎以及更加真实详尽的数据来驱动。
而其中最难的还是如何构建这样的一个虚拟的世界,一方面需要像游戏公司一样进行 3D 模型设计。
虚拟世界中的物体对象,另一方面,需要类似底层的游戏引擎厂商甚至英伟达这样的硬件厂商提供类似于粒子引擎、RTX 实时光线追踪引擎等等底层渲染技术,才能够比较完美的构建一个视觉渲染像更真实,电磁信号反射特性与强度符合真实物理原则的虚拟世界。
目前业内主要通过虚拟游戏引擎来实现上述的功能,最常用的有UnrealEngine4和Unity3D,包括高逼真渲染、模型动作渲染、物理碰撞模拟、天气模拟等等功能,都能够通过这些游戏引擎直接来实现,开发人员可以更多的集中在场景实现与业务逻辑上,提高了开发的效率。
在上述的技术基础上,自动驾驶的虚拟仿真技术才可能通过对采样位置与采样模式的不同设置实现对摄像头、毫米波雷达,激光雷达等传感器输入信号的精确建模,让虚拟仿真系统具备可用行。
至于更进一步的交通流建模,驾驶行为建模,突发事件建模,则更加涉及到复杂系统交互、人类情感波动等等多种因素的影响,已经无法精确建模。
对此我们可以基于实际测试数据,以基本规则加上一定随机化的方式来模拟(例如 Waymo 的模糊化技术,见下图),以最大化测试更多的可能性。
或者直接通过对抗生成网络技术对真实数据的模式进行学习以生成更多接近真实的数据,用以穷尽所有的可能的边缘场景(当然目前看起来仍然遥遥无期)。
此外,虚拟仿真系统并不一定要完整的实现,而是需要根据具体的业务需求与测试目标来进行选择与应用。
例如,如果只测试控制算法,则仅仅需要车辆动力学仿真就可以了;只测试决策规划算法,则可以省略高逼真渲染的模型,仅仅使用事件模型,可以大大节约算力成本与事件成本,获得更好的效率。
由于建模毕竟是对真实世界的简化与抽象(越复杂的模型与真实世界的逼近程度越高,但是需要的算力与时间代价也越大),所以真实世界的数据与案例才是最具有价值的。
为了更好地优化模型以及训练算法,虚拟仿真建模必须支持从真实数据更新模型,优化模型,甚至要支持直接的数据的无损转换与重播,以弥补建模对信息的损失。
2、当前自动驾驶领域虚拟仿真工具以及应用场景
当前自动驾驶领域用到的仿真工具主要分成四类:
1)传统汽车仿真软件:包括CarSim、CarMaker、VTD、PreScan等,特点是与当前汽车 ASPICE 开发流程结合紧密,认证链比较完善,支持台架测试等等 HIL 测试验证,常用于功能验证与车辆动力学验证。
2)机器人开发工具软件:主要包括 ROS 的 Gazebo,特点是开源,功能比较全面,生态好,但是没有进行优化,渲染效果一般,运行效率较低,没有通过行业认证,无法用于功能安全认证。
3)基于游戏引擎虚拟世界仿真软件:包括基于 Unreal 的 Carla、Airsim、腾讯 TAD Sim、51world 的 51Sim 等等,以及基于 Unity 的 LGSVL、DeepDrive 等等。
特点是构建了完善的虚拟世界,渲染效果好,支持插件的方式实现动力学、交通流、场景回放等等联合仿真,能够实现全栈自动驾驶方案的闭环仿真,具有较大的发展潜力。
4)交通流仿真软件:包括 VISSIM 与 SUMO 等等,主要用于决策算法开发,不支持全栈自动驾驶算法仿真测试。
由于各个仿真软件都有其各自的应用场景,这里不再详细说明。
3、未来自动驾驶需要什么样的虚拟仿真系统
由上面的分析我们可以总结一下,未来的自动驾驶需要的虚拟仿真系统需要具备以下的特点:
1. 能够构建完整的虚拟世界,能够整合多种仿真模型,并且支持高逼真的渲染,以实现全栈自动驾驶算法的仿真能力,支持真实与虚幻的场景融合。
例如,百度 Apollo 团队的论文中曾经提到基于 AR/MR 技术,在真实场景的数据中增加虚拟的交通参与者模型的渲染结果,以增加仿真场景的真实程度,这是一个值得探索的方向。
2. 支持场景数据直接转换为事件模型与交通流模型的建模案例,并且通过参数调整能够进行泛化,以实现更多边缘场景的覆盖。
3. 支持开放标准的输入输出接口,包括传感器接口、控制接口、地图数据接口、场景数据接口等等,支持多种引擎的集成与联合仿真,以实现与全栈自动驾驶方案的各个层级的算法与模块的测试。
4. 支持完整的功能安全认证链条,具备 ASPICE 开发流程的测试验证能力与资质,以便能够在实际量产开发中真正用到虚拟仿真技术节约开发成本。
5. 与客户开发的自动驾驶算法方案进行深入整合,简化系统应用难度,加快开发进度。
这就需要虚拟仿真平台拥有较好的生态,具备常用的开发框架的接口,包括 ROS、AutoSAR AP/CP,Apollo 的 Cyber 等等。
6. 具备完好的数据管理功能,辅助分析功能,具备并发仿真的性能,以及友好方便的操作界面与人机交互设计,能够为汽车产品全生命周期的开发人员提供一个全栈式的虚拟仿真测试验证解决方案。
预告:应读者群里的提问,我们将讲讲不同级别智能驾驶系统的传感器方案和相应的传感器融合的算法。
英伟达的仿真系统丰田和大陆用,但国内都是mobileye阵营,应该没用英伟达的吧