适用于无人驾驶的分布式仿真平台.docxVIP

《适用于无人驾驶的分布式仿真平台》， 本次分享主要为以下五个方面的内容： 一、仿真产品的业务价值 二、如何达到真实性 三、如何完成更全面异常检测 四、智能辅助驾驶和全自动无人驾驶的区别 五、全面的无人车能力判定 { ?一 ?} 仿真产品的业务价值 仿真器，顾名思义，就是用软件模拟真实。但在 Apollo 中，对仿真平台的定位是不仅仅是真实，而是要能够进一步：能够发现无人车算法中的问题。因为在整个算法迭代闭环中，光有拟真是不够的，还需要能够发掘问题，发现了问题后才能去 fix 问题，也就是回到了开发过程。 如此这样，从开发到仿真再回到开发，仿真平台同我们的开发过程串联成一个闭环。只有闭环的东西才能构成持续迭代和持续优化状态。所以仿真平台在整个无人车算法迭代中的地位非常重要。 如上所述，仿真平台的功能。 发现问题，进行功能拆解的话，可以拆成有因果关系的两部分： 先要能够真实，接下来要能够进行全面的异常检测。真实性，就是说要能够对世界进行数学建模；全面的异常检测，其中最难的是“全面”二字，这要看我们对“全面的异常”的定义。 { ?二 ?} 真实→客观世界的数学建模 客观世界的真实性表达依赖于三部分：静态环境的真实性、动态环境的真实性、车辆行为（也就是主车）真实性。 准确来说，对于静态环境的真实建模本身并不难，比如游戏画面中，我们能经常看到“照片画质”的渲染，看着都很真。最难的是“成本”两个字，这个成本指的是：单位公里上全部环境建模的时间成本。无人车的场景重建跟游戏中不一样。游戏中是艺术家造出的场景，它不考虑真实。而真实仿真器中的场景是要跟真实世界做 diff 的，需要做到毫厘不差。 1静态环境的真实性 静态环境是相对于动态障碍物而言的，比如道路（包括各种地面元素）、栅栏、红绿灯、路旁的路灯和绿植两侧的高楼。对于自动驾驶来说，它们属于背景元素。当然大家能够理解这跟行人、车辆等动态障碍物的不同。 大家都有过这样的经验，我们自己得到一个结果，这很简单，但若要让自己得到一个跟别人一模一样的结果，这个成本就大太多了。百度内部有成熟的百度高精地图制作流水线，在厘米级精度的世界刻画能力的基础上，成本做到非常低。 那么大家会问，讲了这么多地图生成的事，这跟仿真有什么关系？其实，Apollo 仿真器的静态世界的表达，正是直接使用了 Apollo 高精地图数据。所以它是真实的，且是具有足够低成本的。 2标题内容 然后是动态环境，也就是各种障碍物的行为真实性了。动态障碍物引入了人的因素，相对静态场景重建更难，因为人的行为“难以捉摸”。对于 Apollo 而言，最快和直接的做法，不是拟真，而是直接“真”。 用实际路上采集回的海量真实数据，经过 Apollo 感知算法，做动态场景重建。一方面，我们通过 Apollo 数据生态，会得到更多的数据用来补充场景，另一方面我们利用自身持续迭代的感知算法可以更精准的还原世界。从量和质上都得到持续的提升。 3车辆行为的真实性 主要分传感器模拟和车辆动力学模拟。由于传统的商业仿真软件在这两个领域已经进行了数十年的研发，成果已经被各大车厂所认可。Apollo 倡导开放能力、合作共赢，所以这两块功能 Apollo 仿真平台是以直接 involve 商业仿真软件的方式实现这两块 feature。后面在讲开放性的时候会提到。 { ?三 ?} 全面的异常检测 在满足了真实性后，我们来看看如何完成下一个需求：更全面异常检测。 其实大家都知道，尤其是搞 IT 的同学可能会更清楚。所谓异常检测，就是先给一个条件，再给一个预期输出。就是大家写的 UnitTest 的常用版型。方法论上都是一样的。那么对于无人车的异常检测，什么是条件呢？就是车辆运行的场景。什么是预期输出？就是要有一整套判定准则或者说判定算法。 显然，要做到全面的异常检测，这里重点或者说难点，肯定不在后四个字，而在于前面两个字“全面”。场景，要是全面的场景；判定，要是全面的判定。 全面的场景。全面这两个字很虚，而且“100% 全面”在理论上也无法达到。所以，唯一可行的做法是：在受限场景下逼近 100%。这个“受限场景”，换种说法，就是我们无人车算法的问题域定义，也就是说这个算法要解决哪一种受限场景。不同的应用场景，仿真器的设计可能会大有不同。目前以我的理解，能够对仿真器设计产生革命性变化的，只有一种问题域的划分方式，就是智能驾驶 vs 无人驾驶。具体怎么个革命性变化，后面会讲。 全面的判定。这个取决于算法能力域的设计。什么叫算法能力域？就是指算法能达到的上限，也就是说，是 just work，还是 work well。对于判定算法而言，如果仅仅是做“just work”级别的判断其实并不难，难在对“work well”做判断。所以这里，也有一个对仿真器算法产生重大影响的