2万字长文说清无人驾驶仿线大问题

  由德国PEGASUS项目提出的功能场景-逻辑场景-具体场景三层体系：1）、通过真实道路数据采集和理论分析等方式，得到不同的场景类型（即功能场景）；2）、再分析出这些不同场景类型中的关键参数，并通过真实数据统计和理论分析等方法得到这些关键参数的分布范围（即逻辑场景）；3）、最后选取其中一组参数的取值作为一个测试场景（即具体场景）。

  举个例子，功能场景可以描述为，“自车（被测车）在当前车道运行，在自车前方有前车加速运行，自车跟随前车行驶。” 逻辑场景则提炼出关键场景参数，并赋予场景参数特定的取值范围，如以上描述的场景可提取自车车速、前车车速以及加速度、自车与前车距离等参数，每个参数都有一定的取值范围和分布特性，参数之间可能还存在相关性。具体场景则需要选取特定的场景参数值，组成场景参数向量，并通过具体的场景语言表示。

  第二种思路是：采集无人驾驶车辆预定工作区域内的交通流量数据，并将这一些数据输入交通仿真工具中产生交通流，并使用该交通流充当无人驾驶车辆的“周围交通车辆”，实现测试场景的自动生成。

  ACT前首席科学家Raquel Urtasun创办的仿真公司Waabi，据说无需激光雷达等高精度的传感器，直接用摄像头收集的数据来做仿真。

  某主机厂的仿真负责人说：“上述专家表述的是采集的过程。的确，考虑到采集设备的容量以及有效场景的定义，采集打点的场景都是有长度的，一般都是功能触发前后一段时间，尤其是触发前的缓存不会特别长。另一方面，在数据采集后用来回灌的时候，则只能是功能触发前的场景是有效的，而功能触发后的真实场景却是无效的。”

  “切片完成后，仿真公司还需做一个相应的带语义信息的管理环境（比如哪个是行人、哪个是十字路口），方便下次去筛选。具体地说，需要先对数据切片做分类，然后再做动态目标列表的精修，精修完之后再导入到仿真环境的模型里去，如此一来，模型就有相应的语义信息了。有了语义信息，就可以调参了，然后，数据就可以复用了。

  深信科创创始人杨子江说：“如果要将路采数据泛化，并且要保持数据的真实性，可以在场景初始化以及开始阶段回放路采数据，在某一时刻由smart-npc模型来接管道路中的背景车辆，使背景车辆不会按照路采数据运行。smart-npc接管后通过把泛化后的场景记录下来，以做到泛化后的关键场景可回放。”

  复睿微仿真负责人James Zhang在前段时间的一段分享中提到，特斯拉的仿真有两种方法：场景完全虚拟（算法生成）的叫 WorldSim，将真实数据回放给算法看的叫LogSim，“但WorldSim中的路网也是在对来自真实道路的数据做自动标准的基础上生成的，因此，WorldSim与LogSim的界限越来越模糊”。

  在跟很多仿真公司的专家及其下游用户交流的过程中，我们了解到，当下，无人驾驶的仿真，最难的环节之一是传感器的建模。

  按智行众维CTO李月的说法，传感器建模可分为功能信息级建模、现象信息级/统计信息级建模及全物理级建模几个级别。这几个概念的区别如下——

  从计算机图形成像原理看，传感器模拟包括光线（输入、输出模拟）、几何形状、材质模拟、图像渲染等模拟，而渲染能力和效率的差别则会影响到仿真的真实性。

  仅有单个传感器的精度高还不够，你还需要所有的传感器都能同时达到一个理想的状态，这就要求建模有很广的覆盖度，但在成本压力下，仿真团队显然不可能对激光雷达做10个、20个版本的建模吧？ 另一方面，又很难用一个通用的模型去将各种不同款式的传感器表达出来。

  模型的精度、效率和通用性是一个“不可能三角”的关系，你可以去提升其中的一面或者两个角两面，但你很难去持续性地把三个维度同时提升。当效率足够高的时候，模型精度一定是下降的。

  车右智能的仿真专家说：“再复杂的数学模型也可能只能以99%的相似度模拟线%可能就是会带来致命问题的因素。”

  传感器仿真需要外部的数据，即外部环境数据跟传感器有强耦合，然而，外部环境的建模其实也挺复杂的，并且成本也不低。

  城市场景下建筑物的数量太多，这会严重消耗用来做图像渲染的计算资源。有的建筑物会遮挡路上的车流、行人及其他目标物体，而有遮挡没遮挡，计算量是完全不一样的。

  此外，目标物的反射率、材质，很难通过传感器建模搞清楚。比如，可以说一个目标是个桶状的，但它究竟是铁桶还是塑料桶，这个很难通过建模来表达清楚；即使能表达清楚，要在仿真模型中把这些参数调好，又是一个超级大的工程。

  某Tier 1仿真工程师说：“深度学习算法识别物体是一个从真实世界的传感器数据收集到信号去噪的过程，相比之下，传感器建模则是要在理想的物理模型的基础上合理地加入噪声，而其难点就在于噪音如何加得才能跟真实世界足够接近，以便既能让深度学习模型识别出来，又能有效提升模型识别的泛化。”

  言外之意，仿真生成的传感器信号既要跟真实世界中的传感器信号“足够像”（能识别出对应物体），又不能“太像”（模拟corner case让感知模型能在更多情况下实现识别——泛化）。然而，问题就在于，在真实世界中，传感器的噪音在很多情况下是随机的，这在某种程度上预示着，仿真系统如何去模拟这些噪音，是一个很大的挑战。

  从传感器原理的角度看，相机建模的过程中还需要做相机模糊化（先生成理想的模型，然后加噪音）、畸变模拟、暗角模拟、颜色转换、鱼眼效果处理等而以激光雷达模型也可分为理想点云模型（步骤包括场景裁剪、可见判断、遮挡判断和位置计算）、功率衰减模型（包括对接受激光功率、反射激光功率、反射天线增益、目标散射截面、接口孔径、目标距离、大气传输系数、光学传输系数等子的设定）和考虑天气噪点的物理模型等。

  智行众维CEO安宏伟提到了资源对感知虚拟仿真的限制：“我们要对传感器做完全的物理级建模，比如摄像头的光学物理参数等都要清楚，还必须了解到目标物（感知对象）的材质、反射率等数据，这个工程量巨大——在有足够人力的情况下，一公里场景的建设周期需要差不多1个月。即使真能建好，模型的复杂度也极高，很难在当前的物理机上跑起来（实在太耗费算力了）。”

  “未来，仿真都是要上云的，看起来，云端的算力‘无穷无尽’，但具体分摊到某个单一节点的单一模型上，云端的计算能力可能还不如物理机——并且，在物理机上做仿真时，如果一台机器的计算资源不够，可以上三台，一台负责传感器模型，一台负责动力学，一台负责规控，但在云上跑仿真， 能用在单一场景单一模型上的算力并不是无穷无尽的，那么这个就限制了我们这个模型的复杂度。”

  全物理级建模需要把传感器的各种表现都用数学模型构建出来。比如，将信号接收器的某个具体性能、传播路径（中间受空气的影响、反射折射的整个链路）用数学公式表达出来。然而，在软硬件尚未真正解耦的阶段，传感器内部的感知算法是个黑盒子，仿真公司无法了解算法究竟是个什么样子。

  全物理建模需要获取传感器元器件（如CMOS芯片、ISP）的底层参数，对这些参数做建模，而且，还必须了解到传感器的底层物理原理，并对激光雷达的激光波、毫米波雷达的电磁波做建模。

  对此，有一位仿真专家说：“要做好传感器建模，得深刻理解传感器的底层硬件知识，基本上相当于要知道怎么设计一款传感器。”

  智行众维CTO李月说：“这些底层参数你如果拿到了，拿着它去做建模，那你基本上就能把这个传感器造出来了”

  智行众维CEO安宏伟说：“通常主机厂在和传感器供应商打交道的时候，不要说拿到材质物理参数这一些细节，能拿到接口协议就已经很不容易了。如果主机厂足够强势，传感器供应商也积极努力配合，他们能够拿到接口协议，但也不是全部。连主机厂都很难拿到的东西，仿真公司就更难了。”

  事实上，传感器的物理级仿真是只能由传感器厂商去自己去做的。国内很多传感器厂商更多地外采芯片等零部件来做集成，因此，能对做传感器物理级仿真的，其实就是TI、恩智浦这些上游供应商。

  某商用车无人驾驶公司的仿真工程师说：“传感器的仿真难做，导致传感器选型的过程很复杂。我们要做传感器选型，大多数都是传感器公司先把样件寄给我，我们再把很多类型的都装上到车上去测试。 如果传感器厂商能跟仿真公司合作，他们之间就可以把接口全部拉通，提供精准的传感器建模，那我们就可以以很低的成本获知传感器的信息，做传感器选型的工作量会大幅度减少。”

  不过，51 World CTO鲍世强的说法是：“感知仿真现在还处在初期，还远远没做到需要把传感器里边的建模搞得那么精细的阶段。把传感器里边拆开建模那些东西，我觉得毫无意义。”

  此外，按某无人驾驶公司仿真负责人的说法，传感器仿真做不了，并不等于感知的仿真完全做不了。

  比如，硬件在环（HIL）可以接入传感器实物（传感器和域控制器，都是实物）来测试。接入传感器实物，既可以测试感知算法，也可以测试传感器本身的功能和性能。这种模式下，传感器是真实的，相比于传感器仿真，仿真精确度更高。

  但由于涉及到配套硬件，集成起来复杂，而且这样的形式依然需要传感器模型来控制环境信号的生成，成本也更高，因而，实践中很少使用这种方法。

  考虑到近期的真实的情况，无人驾驶仿真大致要分为两个发展阶段（当然这两个阶段可能并无显著的时间界限）。

  在试验室和封闭试验场内对传感器的感知识别模块来测试，在虚拟仿真环境对决策控制模块来测试，仿真环境直接向决策控制模块提供目标列表。

  这主要是因为目前对传感器的建模还有很多局限，从而不可以进行有效（甚至是正确）的仿真。比如摄像头输出的图片较容易仿真，但是污渍、强光等特性仿真难度较大；而对于毫米波雷达如果建立精度较高的模型，则计算速度较慢，不能够满足仿真测试的需求。

  在试验室和封闭试验场可以对测试环境进行完整的控制和数据记录。比如布置不同类别、位置和速度的行人和车辆，还可以对雨、雪、雾和强光的环境要素进行模拟，并将传感器处理输出的目标列表与真实环境作对比，从而给出对感知识别模块的评估结果和改进建议。

  这么做的好处是，在传感器建模有很多局限的情况下，依然能够在仿真环境下对决策控制模块来测试，提前享受仿真测试的优势。

  在虚拟仿真环境进行高精度的传感器建模，从而对完整的无人驾驶算法进行测试。

  这样不但可以在同一环境下来测试，来提升测试效率、测试场景覆盖率和复杂度；还能够对一些基于AI的算法进行端到端的测试。

  这一阶段的难点，一种原因是前面提到的满足测试需求的传感器建模，另外一种原因是不同传感器厂家和OEM厂家直接交互的接口很可能不一致（有些情况下可能并不存在）。

  轻舟智航仿线的产品定义成熟，功能边界清晰，因而，仿真服务商提供给各家主机厂的服务通用程度很高；而L4的功能边界在哪里，大家都还在探索，因此，客户对仿真的需求有很高程度的定制化。”

  深信科创创始人杨子江：“从测试场景的角度讲，L4因为ODD复杂度更高，场景库的数量级远高于L2。”

  某主机厂仿线仿真对场景复现度的要求更高，即道路中发现的一个问题，能不能在仿真场境下去复现；但很多做L2仿真的公司还没有思考过这样的一个问题。”

  51 WORLD 车载仿真业务负责人鲍世强：“L2对功能定义得比较明确，仿真可以以合成数据为主，以真实道路数据为辅；而到了L4阶段，数据驱动的重要性会更高，因此，需要以真实道路数据为主，以算法生成的数据为辅。”

  智行众维CTO李月：“低等级无人驾驶基本都不需要高精地图，但高等级无人驾驶在目前阶段则高度依赖高精地图，这也是构建场景的时候就需要建数字孪生的原因之一，跟真实世界做对比。”

  智行众维CTO李月：“L2的方案对决策的策略逻辑及执行机构的测试关注比较多，但并不会把重点放在规划算法上，但到了L4方案中，对如何避障、如何绕路等路径规划算法的考虑就比较多。”

  ，但不预先设定测试过程，只设定交通车辆的行为，给予被测算法较大的自由度，通过查看被测算法是否达成预期的目标来评价是否通过测试

  比如对直线道路行驶的测试，预先设定被测车辆和前车的初始车速，以及前车减速的时刻和减速度，但是不限定被测车辆是通过减速还是换道超车的方式避免与前车相撞。

  深信科创创始人杨子江：“从产业生态的角度讲，对L2，车企基本不会自研，而是直接采用外购方案，测试会以HIL甚至道路测试为主；而对L4的仿真，许多车企会倾向于从SIL开始自研。”

  一台GPU服务器上能跑多少个实例，取决于GPU的性能和仿真求解器能不能在一台服务器上并行仿真。

  仿真平台上每日的仿真总里程。如果一个实例（虚拟车）平均每小时跑120公里，每天跑24小时，那每日就是将近3000公里，如果有33个实例，那该台服务器上每天就差不多有10万公里。

  需要结合合理的仿真测试方案和海量的场景作为支撑，在场景的覆盖度和有效性上进行不断地扩展，最后能够跑出来有效的场景才是根本。”

  在采访中，笔者反复问到一个问题：仿真平台上跑的车，跟真实世界中的车，是在同一个时间维度上的吗？换个说法：仿线小时，等于线小时吗？会有“人间一年，天上十年”的情形出现吗？

  答案是：可以等于（实时仿真），也可以不等于（超实时仿真）。超实时仿真又可分为“时间加速”和“时间减速”两者情况——时间加速即仿真平台上的时间比真实世界中的时间快，时间减速即仿真平台上的时间比真实世界慢。

  安宏伟的解释是：“举个例子，有一些仿真测试对图像渲染的精度要求非常高，为了追求精度，单帧图像的渲染可能没办法在实时情况下完成。这种比真实时间慢的仿真，不是做实时的闭环测试，而是做离线测试。”

  具体地说，在实时仿真中，图片在生成后直接发给算法去识别，这样的一个过程也许能在100毫秒内完成，但在离线仿真下，图片在生成后先保存，在离线条件下发送给算法处理。

  根据安宏伟的解释，在仿真平台上做超实时仿真需要满足如下两个前提：服务器的算力资源足够强大；被测算法能接收虚拟时间。

  算法能接受虚拟时间，这个怎么理解？安宏伟的解释是，有一些算法在结合硬件运行平台的条件下，在大多数情况下要读取硬件上的授时或网络授时，而无法读取仿真系统提供的虚拟时间。

  某Tier1的仿真专家说：在仿真系统的工程框架PoseidonOS里做到精确的时间对齐和同步，然后就可以把算法部署在集群服务器上，进而仿真空间的时间能跟真实物理世界的时间解耦，解开了就能“随意加速”了。

上一篇：【48812】传感器龙头名单一览（2023125）

下一篇：磁致伸缩位移传感器原理及特征