产品
首先说为什么自动驾驶需要仿真。几年前看非诚勿扰，嘉宾黄澜表示要有2/3的人接受自动驾驶她才会接受，体现了普通群众对于自动驾驶安全性的关注。而为了要保证安全性，自动驾驶算法在真正大规模应用之前，就需要经历大量的道路测试。但自动驾驶系统的测试非常“贵”：时间和资金成本巨大，所以人们就希望将尽量多的测试搬到计算机系统中去做，用仿真暴露自动驾驶系统中的大部分问题，减少实地路测的需求，因此，我们的饭碗就出现了。
仿真场景即自动驾驶系统的test case。根据中国汽车技术研究中心的分类，自动驾驶测试场景可分为【自然驾驶场景】【危险工况场景】【标准法规场景】【参数重组场景】等四大类：自然驾驶场景来源于汽车真实的自然驾驶状态，是构建自动驾驶测试场景中最基础的数据来源；危险工况场景主要包含大量恶劣天气环境、复杂道路交通以及典型交通事故等场景，如CIDAS数据库；标准法规场景是验证自动驾驶有效性的一种基础测试场景，是通过现有的标准、评价规程构建测试场景，目的是对自动驾驶汽车应该具备的基本能力进行测试；参数重组场景是将已有仿真场景进行参数化设置并完成仿真场景的随机生成或自动重组，具有无限性、扩展性、 批量化、自动化等特点。
场景库搭建流程大致可以分为【收集数据】：即实际道路数据和法规数据等、【处理数据】：即从数据中提取特征并组合形成场景和【应用数据】：场景库测试并反馈。
目前，自然驾驶场景的生成已经基本可以实现自动化：采集车按照一定的格式采集数据，算法筛选可能会有用的关键片段的数据，算法计算片段数据中本车和周围其他车辆的轨迹，再把轨迹写入场景描述文件，例如OpenScenario格式的场景文件，现有的很多仿真软件都可以直接利用这样获得的场景文件进行仿真。需要注意的是，在这种情况下，仿真软件中还原出来的只是实采场景的“逻辑”，场景中的参与者披着仿真软件三维模型库中的车辆模型“马甲”上演着一幕幕真实行为片段。换句话说，这样还原出来的场景当然可以满足规控算法的测试，但这样无法还原当时的传感器感知信息，因为毕竟还是由仿真软件的三维模型来扮演的前景车辆和背景。现在如果想要还原传感器感知信息，可以应用NERF。
那么，究竟什么样的仿真场景才是有价值的呢？路测车辆采集的自然驾驶数据还原场景被认为是最能接近真实路况且随机性强的，但我们不是说目前路测花费的时间长赶不上趟儿吗？这就需要我们对路测数据进行处理，将交通参与者识别提取出来后再重新排列组合，形成基于真实数据的随机场景。
比如百度19年大火的论文介绍了他们的AADS仿真系统：在该系统中，使用一台安装了激光雷达和双目相机的汽车扫描街道，便可获得自动驾驶仿真的全部素材，然后自动将输入素材分解为背景、场景照明和前景对象。通过视图合成技术，可以在静态背景上改变视点，生成任意视角的真实图像，进而模仿车在不同环境里面行走的动作。那么如何证明这些重组场景的有效性呢？论文中提到了一种通过对比虚拟场景和实际场景中感知算法的识别效果来评价的方法，用被测对象的表现来评价测量工具，也很有意思。后来的一些应用于自动驾驶的NERF研究中，也使用的是这样的一套思路，比如UniSim。
我个人认为，再有效的自然驾驶数据仿真场景也只适合部分算法的测试：这种方法不管怎样，周围物体的轨迹都是录制好的，是没办法根据本车行为改变的。这就像是电影和游戏的区别，电影中的场景只能播放，而游戏是可以根据交互改变场景的。
也许在不久的将来，结合交通流模拟和真实数据，随机场景生成可以批量建立既符合真实交通状况，也能够随本车行为变化的仿真场景。
我们之前谈到的场景库，可以说是在为自动驾驶仿真测试准备数据，那么仿真开发工作就是在创建或者完善工具了。
仿真开发大概包含以下几个方面：
最后我觉得可能还有更高进阶要求的第8点：“哪里不会点哪里”的能力，比如如果你的被测对象只是自动驾驶功能框架中的一部分呢？你能不能通过开源算法把剩下的补齐，让“闭环”跑起来？
有了自动驾驶仿真测试所需的数据和工具，接下来就是仿真测试了。今天主要介绍几个常见仿真测试链路。
前面几节说了那么多，都是在总体介绍我们这个行当，都是我这个盲人摸出来的大象，本节就来说说大体上我们每天都在干什么。这些日常工作当然是包含在第二、三节的内容当中的：
另外还有一点6.【需求分析】：作为仿真开发工程师，你理应是最了解你所用工具的那个人，所以一旦客户（内部外部都算）有了新需求，仿真开发工程师应该能够根据需求和被测对象的具体情况设计技术方案、提出软硬件需求和项目计划。所以有的时候，产品和项目管理的活都要干。
“技术栈”这词儿听着挺洋气，但其实就是这个岗位应该都会点啥。很久以前我看过一个电视剧，里边一个急诊科的大夫自嘲：我们是万金油，人家外科大夫才是金不换。我一直认为仿真工程师就像医院里的急诊科大夫，什么都得知道点：测试什么算法，那么除了这个算法之外的所有东西都要准备好，导航定位、控制规划、数据处理、参数标定、天文地理、医卜星象、金批彩挂、评团调柳……可以不求甚解，快速满足算法测试需求是最重要的。
这种所谓的“全局观”是仿真工程师的优势，但只有对算法有真正的了解，才能做出能够真正帮助算法改进的仿真工作，也才能走得更远。扯远了，拉回来：
以上仅仅是我个人的一点总结，欢迎广大同行在此补充！
为了文章的完整性，我也将在这一节简要介绍下市面上常用的一些仿真软件（真的不是广告！没上榜的也不要气馁）。
最后再补充一个lgsvl：本来lgsvl的优势是和Apollo结合得较好，但是我听说lgsvl的官方已经放弃了这个项目，所以我劝你弃掉这个坑。
相信通过我前五节的介绍，聪明的在校同学已经可以从中体会出成为一名自动驾驶仿真工程师的学习路径，而通过批判我前五节的内容，年轻的同行也已可以从中得出进阶之道。但本节我还是写一些在这方面的粗浅理解。
我前边说了那么多，想必大家也能看出来，自动驾驶的仿真是一个多学科交叉的领域，能够接受来自很多专业的同学，包括但不限于：计算机/控制/机器人/机械/车辆/电力电子等等。
经历和技术上，我尝试列举一些任职要求：
当前自动驾驶行业正经历很大波动，但总结起来能用到仿真工程师的主要有以下几类企业：主机厂，以集成应用成型仿真软件为主，但新势力基本上都要做自研；自动驾驶解决方案供应商，也就是算法的Tier1，可能也是自研仿真的居多；仿真软件企业，这方面国内刚刚起步，基本上都是初创企业。
在本节的最后我再谈一点从传统机械“转行”来的体会。我硕士毕业的一个学校具有浓厚的转码风气，我那届入学机械研究生院的中国学生里，大概有十之七八毕业后都从事了计算机行业。有赖于相对宽松的选课制度，同学们的操作是尽量多修计算机学院的课程。于是在那两年，焚膏油以继晷，恒兀兀以穷年是常态。但我不记得当年找工作需不需要刷题了。总之一句话，机械如何转型计算机：去读半个计算机学位。其实当时也不单是机械，各个专业都在转，也不单是中国学生，全世界人民都这样。
不过后知后觉的我并不在当年的这十之七八里边，所以我错失了转型最好的机会。等到靠自学的时候，就难多了：最主要没有时间，这就更要求学习资料和方法要高效。因此相对来讲，还是上网课效率较高，毕竟有老师指导。Coursera的课不错，好像比较贵。最近几年开源的网络资源越来越多了，不过上的课在精不在多，毕竟计算机最注重实践也最容易实践。计算机经典的著作也很多，比如数据结构与算法、c++ primer……我是一本没看过，有些事真的一旦错过就不再。
其实我觉得，一个最容易的转型方式就是，直接从事计算机相关的工作，有了需求提高是最快的，解决了我上面说的学习方向问题和时间问题。不过要是因此产生了绩效不达标的问题，您当我没说。
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是曾经的同学，那时年轻，大家都不懂事。工作后我和她再次遇见，决定再续前缘，如胶似漆两年多，人也过了三十岁，我对她留下一句：我想有更好的发展，就离她而去……现在再见只会说一句：好久不见……
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
