真实场景数据是怎么应用到仿真环境中的？

上周我们邀请了Apollo的资深架构师毛继明老师，在开发者社群做了有关仿真平台的分享——《适用于无人驾驶的分布式仿真平台》，这里我们将分享中开发者提出的问题汇总，方便大家参考借鉴。

01

开发者

您这里提的场景测试是将采集的数据在分布平台上统统跑一遍吗？还是会利用一些方法抽取出一些关键的场景测试作出测试用例？如果是做场景用例您这里的方法是什么呢？

这个问题的本质在于资源和效果的折中问题。从效果看，肯定是“统统跑一遍”效果最好。实际生产环境中，百万公里数据都跑一遍肯定不现实，因此我们会根据具体回归需求来动态选择场景。

比如只跑上一次fail的cases；比如只跑本周路上/历史路上发生的异常cases；比如在进行场景分类后只跑某类型的case，或者每类型只跑1个case；比如只跑某个区域的case。

实际上在我们内部对实际采集回的场景进行了tag化分类和管理，具体使用时可以直接进行专项测试与回归。

Apollo

大牛

02

开发者

能就Apollo基于感知的算法对动态场景进行重建的方法更具体地展开一下吗？

Apollo的感知算法的输出中包含：各种动态障碍物的位置、速度、朝向、轨迹、类型等信息。因此我们在离线运行感知算法，就可以从海量的场景（原始数据）中抽取出/计算出当前世界的动态障碍物的逻辑表达。

当然，由于感知无法做到完美感知，所以我们需要对结果进行一定的后续处理。使感知的结果更稳定以及更精确，这样就重建了当时环境的所有动态障碍物的状态。

Apollo

大牛

03

开发者

无人驾驶以后随着地图和导航精度的提升，以及实时情景的获取能力，是不是更多的会集中在通讯和控制2个方面，而不是大量的AI算法上呢？

你的意思应该是，利用通讯做感知，在云端做Planning。比如在一些仓储场景，其实很多货运机器人，他们只有运动组件和通讯组件，可以在一个封闭空间以最优方案运行，因为有一个Central Planning。

这个方案当然是可行的，但是他有1个前向依赖：一个区域内的所有动态设备全面V2X化。所以一段时间，他只能落地在一个全封闭的空间内。他的能力域没法做到足够开放。因为一个开放的世界，exception太多太多了。V2X对于exception的处理能力太低。

Apollo

大牛

04

开发者

机器学习的训练数据主要是图像，通过什么途径能触及到体感和心理感受呢？

机器学习的训练数据可以是任何Labelled Data。所以如果我们把体感和心理感受Label在某个场景上呢？这就是我们正在做的。

Apollo

大牛

05

开发者

请问老师，怎么看前段时间 Uber 无人车造成行人死亡的事故，有何预防机制？

其实这个事故正好能充分表达仿真的真正价值。

大家可以想象当这样的一个"昏暗路灯+行人突然出现在非人行道"的case进入到仿真平台，你的算法每次回归都会验证是否能在这样的极端场景下通过，所以你的算法就可以避免这样的问题了。

实际上，我们仿真平台会有相当的Fuzzing功能，会随机的安插一些行人在道路环境中。用来测试无人车算法是否能handle这样的甚至是更极端场景。

Apollo

大牛

06

开发者

百度无人车在虚拟环境中日行百万公里测试，请问百万公里的场景是如何定义的？仅仅基于采集的高精地图数据么？

仅靠人是无法编辑出百万公里的。所以我们的百万公里其实是来自于路采真实场景。

事实上，不是我们的场景来自于高精地图数据，而是高精地图数据来自于我们采集的真实场景。采集的真实场景，隐去动态障碍物，就成为了地图。

Apollo

大牛

07

开发者

在仿真中Apollo有没有针对无人车的行为决策分场景建立仿真环境？如果有，分别都是哪些场景？

你是说对场景进行分类？如前所述，我们的真实场景都是有Tag属性的。Tag属性是4个正交维度的叉乘后的结果。

包括：路型、环境、障碍物行为、主车行为，4大维度。

路型：直路、十字路口、坡路、环岛……

环境：绿植、天气、路面状况…… 障碍物：机动车、自行车、行人、未知……

主车行为：启动、驻车、左拐、右拐、加速、减速……

我们会分门别类为这些场景建立索引，根据这样的场景分类进行定向优化算法。

Apollo

大牛

08

开发者

Apollo有模拟真实场景训练来加快真实路测的功能吗？

我们的地图是真实的地图，我们的障碍物行为也都是基于实采的障碍物真实行为。所以在仿真器里的都是真实的。所以可以认为是，在仿真里通过，就等于在"实采场景"部分也是可行的。

当然，是否能加快真实路测，还取决于用户的算法能力和迭代流程。仿真器是催化剂，真正优化还要依赖用户的生产环境。

Apollo

大牛

09

开发者

CPU+FPGA的硬件组合中，算力如何调度？

这块是离线的硬件资源调度方面的方法问题了。

事实上在研发阶段，无人车算法往往是重CPU-usage，轻FGPA-usage。（当然量产后应该会反过来，大概率会把FPGA切换到ASIC芯片）。所以如果简单的将所有算法构成一个完整包，部署在CPU+FPGA机器上，会使得CPU压力很大，而FPGA压力低，从而浪费FPGA的算力。

因此我们会将车端“融合在一起的算法”剥离成CPU+FPGA部分算法 以及 only-CPU部分算法两块。通过模块在不同配置（CPU+FPGA, only-CPU）的机器上的调度，更充分的使用FPGA卡的计算能力，增加整个集群的吞吐。

Apollo

大牛

10

开发者

在动态环境的真实性这部分提到"用实际路上采集回的海量真实数据，经过Apollo感知算法，做动态场景重建"，麻烦问一下，采集回来的数据是什么形式的？图片还是环境状态数据；这块提到的Apollo感知算法是什么算法？

采集回来的数据是“Lidar、Camera、Radar、GPS”等全部数据的fusion后的数据。

因此包括点云（流）、图片（流）等数据部分。

感知算法的输入是“原始传感器数据”，输出就是这个世界的逻辑化表达。因此百度拥有的强大感知算法使得我们可以对这个世界进行低成本（因为是通过算法自动进行的），高精度的还原和重建。

Apollo

大牛

11

开发者

可以说一下真实场景数据是怎么应用到仿真环境中的吗？真实场景数据是不变的，怎么交互呢？是提取场景中交通参与者的行为模式吗？

其实百度在做的仿真平台的目标是能够提供给，达到商品级别的自动驾驶系统提供更高级的稳定性/安全性保证。所以才有了，我们是基于真实路况的真实数据，供给给算法做测试。

那么这种回放型，其实是一种静态的“环境重建”。此时“重构的环境”与“无人车算法”，是无法实现“与人博弈”的。目前，据我所知，全球只有waymo的无人车驾驶算法里，才有“与人博弈”的概念。

目前来看，支持“与人博弈”的仿真场景，有一种实现方案，我们在内部称之为“多主车平台”，即一个充满着虚拟障碍物（人、车）的虚拟世界。把我们的算法放在“虚拟世界”里，与其他车辆进行博弈运行。

但是这里有一个最大的前提，是，要想达到期望的“博弈效果”，与你博弈的车辆必须是“足够像人的”。否则你会在与一个“机器人”进行博弈。这种“错误博弈”产生的无人车算法，上路会更加危险。当前“足够像人”这个前提，还非常难以证明。我们选择了一个更保守的回放型方案。

所以在百度内部，确实拥有“虚拟世界”这样的产品，还仅仅正在试用阶段。未来我们也会开放这样的仿真器产品给大家。

Apollo

大牛

12

开发者

能详细说说General rule和Rule-based吗？

这里的General rule是指“通用规则”。

简单来讲，碰撞、到达目的地、交规违规等等这些可以认为是“最基础的无人车能力”的判定。

1）他们是通用的，在各个场景都应当存在且适用；

2）他们可以用简单的规则加以描述，来判断无人车算法是否异常。所以称之为Rule-based。

Apollo

大牛

hello，Apollo

为了让大家更快更好的了解Apollo，每周一班Apollo直答号收集开发者们针对Apollo平台的各种疑问，欢迎大家踊跃提问，可后台留言，我们会筛选典型问题由Apollo资深技术大牛解答，每周整理好发给大家方便查阅。

你来问，大牛答！