上周我们邀请了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资深技术大牛解答,每周整理好发给大家方便查阅。
你来问,大牛答!
领取专属 10元无门槛券
私享最新 技术干货