好文分享|自动驾驶仿真大观！一起聊聊自动驾驶仿真这个行当！

首先说为什么自动驾驶需要仿真。几年前看非诚勿扰，嘉宾黄澜表示要有2/3的人接受自动驾驶她才会接受，体现了普通群众对于自动驾驶安全性的关注。而为了要保证安全性，自动驾驶算法在真正大规模应用之前，就需要经历大量的道路测试。但自动驾驶系统的测试非常“贵”：时间和资金成本巨大，所以人们就希望将尽量多的测试搬到计算机系统中去做，用仿真暴露自动驾驶系统中的大部分问题，减少实地路测的需求，因此，我们的饭碗就出现了。

一、仿真场景

仿真场景即自动驾驶系统的test case。根据中国汽车技术研究中心的分类，自动驾驶测试场景可分为【自然驾驶场景】【危险工况场景】【标准法规场景】【参数重组场景】等四大类：自然驾驶场景来源于汽车真实的自然驾驶状态，是构建自动驾驶测试场景中最基础的数据来源；危险工况场景主要包含大量恶劣天气环境、复杂道路交通以及典型交通事故等场景，如CIDAS数据库；标准法规场景是验证自动驾驶有效性的一种基础测试场景，是通过现有的标准、评价规程构建测试场景，目的是对自动驾驶汽车应该具备的基本能力进行测试；参数重组场景是将已有仿真场景进行参数化设置并完成仿真场景的随机生成或自动重组，具有无限性、扩展性、 批量化、自动化等特点。

场景库搭建流程大致可以分为【收集数据】：即实际道路数据和法规数据等、【处理数据】：即从数据中提取特征并组合形成场景和【应用数据】：场景库测试并反馈。

目前，自然驾驶场景的生成已经基本可以实现自动化：采集车按照一定的格式采集数据，算法筛选可能会有用的关键片段的数据，算法计算片段数据中本车和周围其他车辆的轨迹，再把轨迹写入场景描述文件，例如OpenScenario格式的场景文件，现有的很多仿真软件都可以直接利用这样获得的场景文件进行仿真。需要注意的是，在这种情况下，仿真软件中还原出来的只是实采场景的“逻辑”，场景中的参与者披着仿真软件三维模型库中的车辆模型“马甲”上演着一幕幕真实行为片段。换句话说，这样还原出来的场景当然可以满足规控算法的测试，但这样无法还原当时的传感器感知信息，因为毕竟还是由仿真软件的三维模型来扮演的前景车辆和背景。现在如果想要还原传感器感知信息，可以应用NeRF。

那么，究竟什么样的仿真场景才是有价值的呢？路测车辆采集的自然驾驶数据还原场景被认为是最能接近真实路况且随机性强的，但我们不是说目前路测花费的时间长赶不上趟儿吗？这就需要我们对路测数据进行处理，将交通参与者识别提取出来后再重新排列组合，形成基于真实数据的随机场景。

比如百度19年大火的论文介绍了他们的AADS仿真系统：在该系统中，使用一台安装了激光雷达和双目相机的汽车扫描街道，便可获得自动驾驶仿真的全部素材，然后自动将输入素材分解为背景、场景照明和前景对象。通过视图合成技术，可以在静态背景上改变视点，生成任意视角的真实图像，进而模仿车在不同环境里面行走的动作。那么如何证明这些重组场景的有效性呢？论文中提到了一种通过对比虚拟场景和实际场景中感知算法的识别效果来评价的方法，用被测对象的表现来评价测量工具，也很有意思。后来的一些应用于自动驾驶的NeRF研究中，也使用的是这样的一套思路，比如UniSim。

我个人认为，再有效的自然驾驶数据仿真场景也只适合部分算法的测试：这种方法不管怎样，周围物体的轨迹都是录制好的，是没办法根据本车行为改变的。这就像是电影和游戏的区别，电影中的场景只能播放，而游戏是可以根据交互改变场景的。

也许在不久的将来，结合交通流模拟和真实数据，随机场景生成可以批量建立既符合真实交通状况，也能够随本车行为变化的仿真场景。

二、仿真开发

我们之前谈到的场景库，可以说是在为自动驾驶仿真测试准备数据，那么仿真开发工作就是在创建或者完善工具了。

仿真开发大概包含以下几个方面：

1. 【场景库】：之前说过很多了，会包括数据处理、深度学习、数据库等技术内容
2. 【感知】：有了仿真环境，需要将环境信息传递给算法，因此需要建立各种传感器模型，如相机、激光雷达、毫米波雷达、超声波雷达等，根据需要建立物理原理级模型和理想模型。传感器建模想要做得好，需要传感器工作原理的理论研究、物理过程的计算机建模和工程落地能力，以及大量实验数据支撑。
3. 【车辆动力学】：算法输出的控制命令需要有控制对象，因此需要车辆动力学模型，这几乎是另外一个学科，会有专门的工程师研究动力学模型，在自动驾驶仿真中需要能够接入专业动力学模型或进行简化。
4. 【中间件】：算法与仿真平台间，不同功能的仿真平台间都需要信息交流，因此需要大量接口开发。自动驾驶研究阶段较常用的中间件如ROS，在应用阶段常用的如基于AUTOSAR的中间件。
5. 【仿真引擎】：有企业喜欢自研仿真平台，那么管运动、碰撞的是物理引擎，常用开源的如ODE、Bullet、DART等，管三维显示的是渲染引擎，开源的如OGRE、OpenGL。Unreal和Unity是常用来制作游戏的既有物理也有渲染的两套引擎。
6. 【仿真加速】：会涉及到并行计算云计算等，自动化测试也可以算在这里吧。
7. 【前端】：我看有很多仿真开发的职位其实都是在招前端，因为仿真的动态可能需要显示交互等。

最后我觉得可能还有更高进阶要求的第8点：“哪里不会点哪里”的能力，比如如果你的被测对象只是自动驾驶功能框架中的一部分呢？你能不能通过开源算法把剩下的补齐，让“闭环”跑起来？

三、仿真测试

有了自动驾驶仿真测试所需的数据和工具，接下来就是仿真测试了。今天主要介绍几个常见仿真测试链路。

1. 【MIL模型在环】：说实话我不是很知道模型在环和软件在环的区别（也许和MBSE方法 论兴起有关）。狭义上来讲，模型在环是在编写编译实际代码之前使用比如MATLAB等工具验证算法逻辑功能的测试。说白了就是用simulink模型实现算法，进行仿真。
2. 【SIL软件在环】：使用实际编译后的代码软件进行测试，按理说模型在环测试通过了，SIL只是检测代码生产上是否有问题。和HIL一样，SIL需要为被测对象提供一系列的运行环境、其他与待测功能无关的前置虚拟信号等。
3. 【HIL硬件在环】：广义地讲，只要是一个硬件在回路中受到测试的方法都可以叫做HIL，所以针对某个传感器做的测试也可以叫HIL测试。狭义地讲，我们一般指控制器硬件在环，是以实时计算机运行仿真模型来模拟受控对象的运行状态，通过I/O接口与被测的ECU连接，对被测ECU进行全方面的、系统的测试。从HIL开始，要求仿真测试具有强实时性。
4. 【VIL车辆在环】：我了解一般有两种车辆在环的方式：一种是搭载自动驾驶系统的车辆安装在试验台上，车轮卸掉替换为模拟负载的拖动电机，地形路面给车辆的激励都通过试验台来模拟，在这种方式中如果加上了很好的显示系统，也能够作为驾驶员在环仿真系统使用；另一种是车辆可以在一个空旷场地内行驶，由仿真系统提供传感器输入，让车辆虽在空场地中，但算法也会认为周围有各种不同的场景，一般可用车载GPS提供位姿反馈给仿真系统。

四、日常工作

前面几节说了那么多，都是在总体介绍我们这个行当，都是我这个盲人摸出来的大象，本节就来说说大体上我们每天都在干什么。这些日常工作当然是包含在第二、三节的内容当中的：

1. 【感知】：搭建传感器模型必不可少，需要关注到每种传感器的一系列参数，如探测距离、探测角度范围、分辨率、畸变参数、噪声参数、安装位置等，还有硬件的通讯协议等。接下来视所用的仿真软件工具不同，看看是“配置”已有类型的传感器，还是要自己基于仿真软件开发新类型的传感器。为了算法模型的训练或评价，仿真往往还需要提供真值，如2D/3D包围框、车道线等地图信息、2D/3D占用栅格等等，如果仿真软件既有功能不能满足，就也需要工程师做二次开发。
2. 【车辆动力学】：需要根据车辆参数在专业的动力学仿真软件中配置车辆模型，也需要能够根据简化公式直接编写简化的运动学、动力学模型。
3. 【中间件】：接口的开发是重要的工作内容，要负责当好被测对象和仿真软件间的“翻译”；另外就是使用软件的api接口实现不同层级仿真平台间的联合仿真，例如场景仿真联合车辆动力学仿真，再加上交通流仿真，再统一放进自动化测试管理软件的调度中去。
4. 【仿真加速】：我把自动化测试也放到了仿真加速里，因为要是能够实现7x24小时不间断测试也是一种提高效率的途径吧！这就涉及了自动化调用仿真平台、自动化脚本编写、录制数据、根据用例要求评价数据等内容。
5. 【软件开发】：有自研仿真软件需求的企业主要就是这方面业务。

另外还有一点6.【需求分析】：作为仿真开发工程师，你理应是最了解你所用工具的那个人，所以一旦客户（内部外部都算）有了新需求，仿真开发工程师应该能够根据需求和被测对象的具体情况设计技术方案、提出软硬件需求和项目计划。所以有的时候，产品和项目管理的活都要干。

五、技术栈

“技术栈”这词儿听着挺洋气，但其实就是这个岗位应该都会点啥。很久以前我看过一个电视剧，里边一个急诊科的大夫自嘲：我们是万金油，人家外科大夫才是金不换。我一直认为仿真工程师就像医院里的急诊科大夫，什么都得知道点：测试什么算法，那么除了这个算法之外的所有东西都要准备好，导航定位、控制规划、数据处理、参数标定、天文地理、医卜星象、金批彩挂、评团调柳……可以不求甚解，快速满足算法测试需求是最重要的。

这种所谓的“全局观”是仿真工程师的优势，但只有对算法有真正的了解，才能做出能够真正帮助算法改进的仿真工作，也才能走得更远。扯远了，拉回来：

1. 【代码】：主要是C++/Python，但如果涉及到前端显示的部分我就不了解了。一般来讲要求肯定没有算法开发那么高，不过如果是专做仿真软件开发的另当别论。
2. 【ROS】：单拎出来是因为目前ROS仍是自动驾驶和机器人算法研究领域绕不开的一部分，且ROS社区中提供了很多现成的很多可用工具。
3. 【车辆动力学】：可能不需要像真正的车辆工程师了解得那么多，但基本原理是要知道的。另外就是各种坐标转换需要熟练（这条可能不算车辆的，算数学）。
4. 【传感器原理】：自动驾驶车辆上的相机、激光雷达、毫米波雷达等各种传感器是如何工作的，输出的信号长什么样子，有哪些关键的参数。
5. 【地图】：仿真测试场景使用的文件格式如opendrive、openscenario需要了解，因为有时候需要从其中提取信息作为传感器仿真的输入。

以上仅仅是我个人的一点总结，欢迎广大同行在此补充！

为了文章的完整性，我也将在这一节简要介绍下市面上常用的一些仿真软件（真的不是广告！没上榜的也不要气馁）。

1. CarSim/CarMaker：这两款软件都是强大的动力学仿真软件，被世界各国的主机厂和供应商所广泛使用，也可以做一部分道路场景的模拟。
2. Vissim/SUMO：Vissim是德国PTV公司提供的一款世界领先的微观交通流仿真软件。Vissim 可以方便的构建各种复杂的交通环境，也可以在一个仿真场景中模拟包括机动车，卡车，有轨交通和行人的交互行为。SUMO是开源软件，可以通过交互式编辑的方式添加道路，编辑车道的 连接关系，处理路口区域，编辑信号灯时序等。
3. PreScan：已被西门子收购，用于创建和测试算法的主要界面包括MATLAB和Simulink，可用于MIL、SIL和HIL。
4. VTD：作为商业软件，VTD可靠性强，功能全面，覆盖了道路环境建模、交通场景建模、天气和环境模拟、简单和物理真实的传感器仿真、场景仿真管理以及高精度的实时画面渲染等，说一句VTD是国内主机厂使用率最高的仿真软件应该不为过。可以支持从 SIL 到 HIL 和 VIL 的全周期开发流程，开放式的模块式框架可以方便的与第三方的工具和插件联合仿真。
5. CARLA/AirSim：两款开源仿真平台，都依托UE开发，也推出了Unity版本。CARLA可以制作场景和配套的高精地图，支持传感器和环境的灵活配置，它支持多摄像头，激光雷达，GPS 等传感器，也可以调节环境的光照和天气。微软的AirSim有无人机和车辆两种模式，车辆模式下的功能实在乏善可陈，没法很方便地建立环境和车辆模型，社区也没有CARLA活跃，建议以后招人写JD别把AirSim算进去了，没多大用。另外，国内的深信科创最近推出了基于CARLA开发的OASIS，目前可以看成是开源CARLA的加强版。
6. 51SimOne/PanoSim：这两个都是国产的仿真软件，场景仿真软件该有的主要功能他们都能满足。

最后再补充一个lgsvl：本来lgsvl的优势是和Apollo结合得较好，但是我听说lgsvl的官方已经放弃了这个项目，所以我劝你弃掉这个坑。

六、学习路径

相信通过我前五节的介绍，聪明的在校同学已经可以从中体会出成为一名自动驾驶仿真工程师的学习路径，而通过批判我前五节的内容，年轻的同行也已可以从中得出进阶之道。但本节我还是写一些在这方面的粗浅理解。

我前边说了那么多，想必大家也能看出来，自动驾驶的仿真是一个多学科交叉的领域，能够接受来自很多专业的同学，包括但不限于：计算机/控制/机器人/机械/车辆/电力电子等等。

经历和技术上，我尝试列举一些任职要求：

1. 代码能力：做仿真的云计算、云服务器等相关开发的同学可能会需要熟练使用C++/Go/Java任何一门语言的开发，有良好的编程习惯，掌握常见的设计模式、数据结构和算法，熟悉Linux系统、Docker技术及Kubernetes的相关知识，有云端服务开发经验，这些是奔着高并行高复用高自动化的自研仿真测试平台去的。另外，自研仿真软件的岗位除扎实的计算机基础外，可能会需要游戏引擎的开发经验，所以做游戏开发的同学也可以转行到自动驾驶仿真上（包括技术美术）。目标是应用已有的仿真软件进行二次开发和集成的同学可能会需要熟练使用C/C++和Python，熟悉Linux/ROS的开发，如果能够有AUTOSAR等车规级中间件的开发经验更好。
2. 软件经验：任何的自动驾驶仿真软件的实际使用经验当然都是加分项，但是由于商业软件大多非常贵，因此在这点上很依赖学校实验室或者公司的实力。在没有商业软件支持的情况下，我认为现在CARLA是开源软件的最优解。
3. 领域知识：我个人认为，作为自动驾驶仿真工程师，对于自动驾驶算法怎么深入了解都不为过，包括算法的原理实现的方方面面，只有更好地了解算法，才能更好地做好仿真。另外，如果是非计算机专业出身的同学，学好本门儿的专业课也十分重要，比如机械、车辆、力学、电子等等等等，守正才能出奇，总会用到。

当前自动驾驶行业正经历很大 波动，但总结起来能用到仿真工程师的主要有以下几类企业：主机厂，以集成应用成型仿真软件为主，但新势力基本上都要做自研；自动驾驶解决方案供应商，也就是算法的Tier1，可能也是自研仿真的居多；仿真软件企业，这方面国内刚刚起步，基本上都是初创企业。

在本节的最后我再谈一点从传统机械“转行”来的体会。我硕士毕业的一个学校具有浓厚的转码风气，我那届入学机械研究生院的中国学生里，大概有十之七八毕业后都从事了计算机行业。有赖于相对宽松的选课制度，同学们的操作是尽量多修计算机学院的课程。于是在那两年，焚膏油以继晷，恒兀兀以穷年是常态。但我不记得当年找工作需不需要刷题了。总之一句话，机械如何转型计算机：去读半个计算机学位。其实当时也不单是机械，各个专业都在转，也不单是中国学生，全世界人民都这样。

不过后知后觉的我并不在当年的这十之七八里边，所以我错失了转型最好的机会。等到靠自学的时候，就难多了：最主要没有时间，这就更要求学习资料和方法要高效。因此相对来讲，还是上网课效率较高，毕竟有老师指导。Coursera的课不错，好像比较贵。最近几年开源的网络资源越来越多了，不过上的课在精不在多，毕竟计算机最注重实践也最容易实践。计算机经典的著作也很多，比如数据结构与算法、c++ primer……我是一本没看过，有些事真的一旦错过就不再。

其实我觉得，一个最容易的转型方式就是，直接从事计算机相关的工作，有了需求提高是最快的，解决了我上面说的学习方向问题和时间问题。不过要是因此产生了绩效不达标的问题，您当我没说。

七、关于NeRF

NeRF正伴随着“数据闭环”、“大模型”、“端到端”这些新兴热门词汇一起在自动驾驶领域“兴风作浪”。仅仅几年的时间，NeRF已经再也不是出道时单纯的MLP+体渲染，储存空间信息的载体五花八门：哈希表、体素网格、多维高斯函数……新的成像方式也层出不穷：U-net、CNN、光栅化……自动驾驶方向只是NeRF一个很小的应用分支。

NERF应用到自动驾驶仿真方向，主要会面临以下这些问题：

自动驾驶数据采集的方式导致场景的范围“不闭合”：室外的场景会包含大量远景，这对NeRF的空间信息储存是很大挑战；自动驾驶场景包含大量的动态物体，NeRF需要能够处理动静态物体（或曰前景背景）的分离；NeRF模型普遍不具有迁移能力，可能每个场景都需要训练单独的NeRF模型，而NERF的训练又仍然比较慢，所以NERF在自动驾驶数据上的大规模应用仍然会存在问题。

不过我仍然期待着，同时也相信，NeRF会给自动驾驶仿真带来颠覆性的发展，最终消除仿真在感知算法上的domain gap，甚至做的更多。从我了解到的信息来看，NeRF至少会带来以下这些突破：

NeRF新视角图像合成的能力可以增强感知算法训练数据集：可以产生新传感器内参（相当于改变了传感器配置）、外参（修改了自车轨迹）下的图片、激光雷达点云等数据，给感知算法更多训练数据，这方面可以参考StreetSurf、UniSim等研究。在动态物体可编辑的情况下，将来NeRF可以产生有针对性的极端情况、随机情况场景，补充单纯路测和WorldSim的不足。如果NERF可以同时很好地解决城市级场景的训练重建和实时渲染，那么NeRF就完全可以做为一个XIL在环仿真测试的平台，而不会有感知数据domain gap的问题，也会推动端到端算法的发展。另外，NeRF的模型甚至也可以作为一个插件放入游戏引擎（如3d Gaussian Splatting的UE插件已经问世），这样就可以把NeRF的街景重建纳入到原有的WorldSim体系中去。如果考虑与AIGC方向的大模型结合，NeRF在新场景生成上就会有更多的可能性：将可以任意编辑光照、天气、物体外观和行为等等。

所以作为仿真工程师，我强烈建议广大同行密切关注NeRF方向的进展，尽管NeRF的各研究项目还都只是初具雏形，但现在深度学习方向在硬件的加速下进展已经越来越快了。

八、写在最后

杂七杂八写了这么多，最后还有一些感想。

仿真开发有什么坑。技术上的坑不在此讨论，在这里只说一点整体上的感想。那就是要警惕你是否在过多地陷入到毫无意义的工作中去：给不同人做类似的项目不算，完成好每个项目就是价值；不使用现成工具非要自研长期看也不算，脱离对特定工具的依赖是有价值的；研发上很多事后被证明不通的尝试也不能算，研发的失败也有价值的。那么具体什么是“毫无意义”的工作呢？这就见仁见智了，我总结不好。

还有从这个岗位出发能干嘛。如果你在工作中对被测对象有了深入的了解，那么也许可以尝试转向某个方向的算法开发岗；还有就是机器人、无人机的仿真开发也可以考虑。

移动机器人和自动驾驶的相通性自不必说，这里提一下无人机。无人机行业的体量肯定没有汽车这么大，但是也已经有了落地点，比如巡检、航拍、测绘等。无人机也需要自动操控算法来进行避障、路径规划等，无人机使用的传感器也和无人驾驶车车辆类似，因此可以说仿真测试有相通之处：无人机也需要丰富的视觉图像、雷达点云等感知输入，需要更加精细的动力学模型等等。

有兴趣了解机器人和无人机仿真的同学，可以从开源的仿真平台Gazebo（https://classic.gazebosim.org/）入手，其对计算资源的需求不会像Nvidia的Isaac那么高。

今年是OSRF从柳树车 库独立出来的第十一年，而机器人操作系统ROS和Gazebo至今已经有了二十多年的发展历史。Gazebo从最初一个研究生课题组的科研工具，逐步发展成了今天有11个发行版，以及二代ignition 7个发行版的独立仿真软件工具。

Gazebo支持ODE、Bullet等物理引擎，使用OGRE作为渲染引擎，可以创建三维环境，模拟相机、激光雷达等多种传感器的信息，具有丰富的机器人模型：从机械臂到轮式机器人，再到人形机器人。更重要的是，Gazebo天然地对ROS平台下的算法提供全面的支持：毕竟如果你下载安装一个desktop full的ROS版本，Gazebo是自带的。当然了，Gazebo作为一个开源软件，只提供了一个起点，它的功能均衡，但是各方面都比较粗糙，不够深入。不过就像太祖长拳，乔峰在聚贤庄使出来还是会不一样的。

我上学的时候就接触过Gazebo，后来工作做机器人仿真，一直在用Gazebo，直到改行做自动驾驶。这就好像，我和Gazebo是曾经的同学，那时年轻，大家都不懂事。工作后我和她再次遇见，决定再续前缘，如胶似漆两年多，人也过了三十岁，我对她留下一句：我想有更好的发展，就离她而去……现在再见只会说一句：好久不见……