百度Apollo平台基于深度学习的端到端自动驾驶方案-36大数据
作者: 郁浩
基于深度学习(以 End to End 为主)的自动驾驶方兴未艾。百度拥有超大规模的训练数据,同时也在 CES Asia 上首次实车展示了这种自动驾驶。那么它与传统的规则式自动驾驶驾驶相比,有哪些区别和优劣势?未来的发展将会如何?百度在这个方向都有哪些实践?本文整理自郁浩在百度技术沙龙上的演讲。
大家好,我叫郁浩,来自百度 IDG 部门。Apollo 这个大项目中有很多垂直子方向和子模块,今天分享的是 End to End 方向的实践。在前面的介绍中,应该已经看到 End to End 开源分为两部分,这一期在 Apollo 项目中会把数据开源出来,接下来会把 End to End 代码一整套方案分享在 Apollo 平台中,到时候敬请关注。今天分享的重点是实践。
传统规则式的无人驾驶系统
在我们深入聊 End to End 之前,有必要大概再看一下,与 End to End 相对应的,传统规则式的无人驾驶系统。无人驾驶系统到现在,实车跑已经有十几年,研究更是有二三十年。业界和学术界主流还是 Rule based 系统,从车辆、传感器感知,最后到 World model,然后进行决策、控制,最后到车辆,形成完整的闭环。
围绕这个闭环,除了刚才提的 Apollo1.0,也有很多人提出了相关的或类似的架构,比如美国的 SAE 部门推荐了这样一个架构。在我们刚才看到的闭环基础上,更细化分出了实时的,分成大环、小环和各个模块之间的关系。
再细化,得到更复杂的功能模块图,但是即使是这张图还是简单的图,真正系统落地的时候要上千模块。Rule based 系统有几个特点,一是系统复杂性,需要人工设计上千个模块,二是高精地图的成本。Rule based 系统对外界有很大依赖,其中一个大的依赖点就是高精地图,要到厘米级精度,要求精度极其高,这样带来更新需要更及时等等问题。三是车载硬件计算能力,每一个模块都有相应的深度学习应用,最终上车部署时,每个模块都对计算资源需求很高,一个车上可能需要运行几个,甚至十几个深度学习网络,这里面的计算能力消耗大家应该能估算出来。
这几个系统难度之大,已经远超一家公司的能力范围,需要一个协作的生态。比如去年百度和 Nvidia 合作框架,到今年已经是百度和整个生态的合作,这需要每个公司,每个人共同尽力来做这件事,不是某一家公司能够搞定的。
人,如何驾驶?
人类驾驶的一个显著特点是不需要知道路面的每一个特点是什么,也不需要精确的位置,比如前面有车和行人路过,我不需要精确知道前车距我有多远,我需要做出多么精准的路线数据。很多时候我们驾驶是靠下意识完成的。
我们在讨论无人驾驶的时候也分成两类,一个标准就是你是否可以边打电话边开车,首先打电话肯定是不建议的,但是事实上确实可以边打电话边开车。有很多自然的行驶、过弯道或者是道路上行驶的时候都可以边打电话边开车,这时候是下意识行为。而另外一个与之对应的行为,我们需要集中注意力判断的行为,比如向右变道,需要考虑到前后车辆的情况,还要考虑到盲区,需要做好充分的深入判断做出决策,这都需要很高等的行为思考能力。
与之对应的是 End to End 系统的效果,或者从功能层面来看所达到的效果。更细化的是输入的是原始的传感器数据,而当然不只是图像数据,所有的传感器数据都可以拿到 End to End 中。以图像为例,当看到这幅图像,经过神经网络可以得到横向的控制,方向盘角度,纵向的控制,加速度的判断。
End to End 历史及现状
早在 1988 年,已经开始有人尝试使用 End to End。当时只能是 30×32 像素,当时还没有 CNN,这样也能在简单道路上实现自动驾驶。
2005 年,LeCun 也做了无人驾驶探索。2015 年,princeton 提出了中间状态自动驾驶,不是从一端到另一端,中间不需要生成各种复杂过程,而是需要把关键点找出来,生成决策控制。2016 年,NVIDIA 在 DAVE2 基础之上,用了相机、卷积网络,更关键的是实车上路,在美国的很多路上进行测试。还做了比较突出的贡献,搭建评估体系和用三目相机采集 End to End 数据。
2016 年至今,Comma.ai,Drive.ai,Auto X 等都相机进行了探索。
在自动驾驶领域出现的 End to End 风潮,并不是自动驾驶这一个领域所特有的,在整个机器人领域也面临着同样的变化。在整个业界,比如去年做的室内无人车自动导航方案。之前很多人肯定畅想过家庭机器人,但是为什么家庭机器人在推广的时候有很大障碍,因为传统规则式机器人需要地图,我们不可能知道千千万万户的地图,但是如果有 End to End,识别出一个家庭的情况之后,自己生成路线,自己执行 End to End 系统,这样就大大降低机器人进入千家万户的成本。当然有人说扫地机器人,那个不属于严格的路径规划,跟这个不一样。
去年下半年谷歌做了一个项目,在机器人之外做了一个机械臂,教会机械臂拿起特定物体。传统的机械臂需要保持精密的操作,而且对环境有操作,一定得是封闭的确定性环境,这也是为什么之前机械臂在车间流水线上,适用面限制在这里。谷歌的机器人操纵应该会把机械臂的应用从封闭区间移到开放的环境中。在去年年底的时候,有人用 End to End 做了路径规划。
说到这里可能大家还会疑惑,到底 End to End 能做什么,End to End 什么都能做吗,究竟它和传统系统有什么区别和联系。
我们对 End to End 现状进行了总结。先从功能角度考虑,我们之前认为人开车的时候有两类行为,一类可以边打电话边开车,我们称之为 Reactive control,无脑操作,相对应的是需要复杂判断,需要集中注意力做出判断的,是 Proactive planning。End to End 系统,到目前为止,我们所看到的相关资料和实践的结果主要实现了 Reactive control,Proactive planning 还在探索阶段。
每一个 message 背后其实都是一个复杂的系统,End to End 是大部分系统自己完成,算法要求都很高。这里可解释性很值得关注,之前我看过很多公司说不做 End to End 系统,一个原因是 End to End 不可解释,而 Rule based 是可解释的,而自动驾驶对安全性要求极高,必须做可解释性的东西。这里确实 Rule based 可解释性高,End to End 可解释性低一些,但是限制 Rule based 往前发展的恰恰就是面临的不确定性因素,尤其是复杂环境,而这些不确定性因素恰恰是 Rule based 系统不可解释的那些不确定性。从这点上考虑,二者的可解释性没有本质的区别。
另一方面深度学习已经深入无人驾驶各个模块,各个系统。如果出一场车祸,前面有一个行人用 Rule based 系统没有检测出来,那么这个模块是不是可以解释,也是不可解释的,或者很难解释。所以从这点上考虑,可解释性不应该成为这两个系统选择或者是评比优劣的点,最终的评比应该是客观的指标性的东西,比如能安全运行多少公里。
广铺成本的问题,Rule based 广铺成本面临的大问题是高精地图,这是非常浩大的问题,目前国家在这个方向上也有比较多的思考。End to End 目前还不需要高精地图,普通地图即可,普通的导航系统给到这儿就足够了。
传感器成本,Rule based 相对高一些,End to End 相对低一些。这里需要补充一点,倒不是说 End to End 系统需要的传感器少,而 End to End 系统对于传感器的利用率高。以摄像头为例,上次在 CSC 期间看到宝马的自动驾驶方案,前档有 3 个摄像头,周围一圈又有不少,每一个摄像头都对应了 Rule based 系统中特定的功能,而 End to End 系统是用神经网络拟合,传统不同的摄像头中所需要的像素级别的融合 End to End 系统可以用机器识别出,或者机器自己判断和加工中所需要的过程,从而可以更高效地利用传感器。
车载计算资源,我们的实践也是差距非常之大。但是二者都有非常核心的问题,Rule based 的研发和广铺成本极高,而 End to End 系统核心问题主要在于数据,它的所有行为需要数据,而目前无论是开源还是闭源很难有优质的数据用于训练。
把二者的优势标出来,这里用黄色部分表示。二者究竟是什么关系?我们认为不是对立的关系,其实是比较明显的互补关系。怎样互补,这里几个特点我们都列出来了,对于普通的,需要边打电话边开车的场合,我们认为 End to End 更适合,但是对于入口和街区,Rule based 更靠谱,尤其是复杂的需要人思考的。当然这也是目前的判断,尤其后续随着各个系统的演进也会有变化。
Apollo 实践:Demo
这是我们用地图采集车采集到的数据,我们的地图采集车每年能采集几百万公里的数据,既有图像数据,也有司机行为,我们用这样的数据训练出来的模型。可以看到在不同驾驶环境下,可以实现近似的驾驶。目前为止,End to End 系统没有明显的主动路径规划,旁边还是有车道线的踪迹可循。本身它是不具备左右拐或者是路线选择能力的,在刚才的时候,在他拐之前绿线是预测出来的结果,他想往前走,后来人又快速适应出来,要沿着新路走。
红线是真值,绿线是预测出来的值。我们选择了几个场景,一个是超车场景,红线采集的是师傅超车了,超车了以后并道,并道的时候绿线不知道他要并道,但是当他压到车道线的时候,模型马上识别出你要进入到新的车道,要做相应的变化。这是基于数据做的结果。
我们的实车也做了相应的展示。我们和长城合作一起做的一辆展示车,这个系统里只是做了一个展示,用一个摄像头做自动驾驶系统,这个场地设计的时候在两端专门设计了一个比较急的弯,看看能不能过来,可以看到它也学会了人的行为,先减速,然后再右靠,这时候工作人员会把交通标志牌放在车道线上,可以看到自动驾驶车会识别出左拐标志,然后做后续的行为。我们的传感器在导航玻璃上,就是一个摄像头。
在本期 Apollo 开放计划中,我们把第一个视频中使用的数据开源出来了,这些数据是目前为止百度拥有的非常宝贵的资产,这是之前在地图采集车中额外的贡献。
目前业界和学界的数据是什么样的?目前数据分两类,一类是真实数据,一类是模拟器数据。真实的数据,Udacity、Oxford、Comma.ai。问题主要有两方面,一方面太少,另一方面是几乎没有中国国情数据。模拟器数据,事实上模拟器数据几乎不可以用到真实的道路上来,模拟器数据都是游戏渲染出来的,它渲染出来的纹理和真实场景的纹理千差万别,比如用机器渲染出来的一棵树。
这次我们用了中国国情的大量数据,数据是通过地图采集车得来的,大家在街上应该经常能看到,我们的地图采集车每年能采集几百万公里,全国有几百辆采集车一直在跑。上面是摄像头,还有雷达,车内还有高精度 GPS。在这么多年地图采集车采集数据中,其实没有看数据,毕竟还没有做这么长远的打算,但是之前高精度的位置数据已经足够了。
看一下我们的原始数据,这次开放的数据主要摘取了前向数据,原始数据是比较高清的数据,从中截出正前方一小块数据,频率是 8 赫兹。除了图像数据,还会开源出采集车不是原生的原始坐标,因为原始坐标是违法的,会根据原始坐标繁衍出一些行为出来,原始坐标是 RTK—GPS20 赫兹。
百度地图有一个复杂的地图工艺处理这些数据,最终会得到非常高精度的轨迹,有了这些轨迹后面的工作会很有趣。我们可以繁衍出横向和纵向指令,比如知道这些轨迹我们会知道它的拐弯半径、曲率,进而推算出方向盘转角。低速场景下是典型的 Ackermann 模型,但是我们在用横向指令的时候,用的不是曲率,曲率或转弯半径二分之一更普适一些。二分之一方向盘之间的转化是车厂的业务,我们之前和很多家车厂合作,几乎每一家车厂都能支持,给它发指令的时候,直接发二分之一就可以执行到。纵向指令是加速度。
数据开有很多文件,每一个数据文件对应着一次采集任务。比如地图采集车师傅,采两个小时数据就是一个文件,一个文件对应一个汽车图像和姿态,我们开源没有开源出精准坐标,而是根据坐标繁衍出它的二分之一和纵向的指令。这两个指令可以和车厂合作,可以直接在路上开。
Apollo 实践:模型
控制方向盘在 2016 年的模型,是比较成熟的方案。问题的定义是从原始的一张图片映射,是基于 CNN 的回归任务。基本方案是 CNN,务必保证计算率很快,能够达到精细的控制,能够达到 30 赫兹,或者网络必须在 30 毫秒以内产出结果发给车。
刚才演示的视频可以看到这样的结果,可以做很多优化,是 CNN 基本的套路。其中两个问题比较关键,一般的 CNN 只能学习到正常的驾驶行为,异常行为很难处理,异常数据怎么处理是很复杂的问题。不同的车辆,每个模型都不一样,其他的参数也都不一样,如何将一辆车的经验迁移到另外一辆车,这也是要思考的问题。
纵向模型,这是去年的模型,我们在探索的实践。一段实际的信息,通过一段视频对应到加速,但是目前还在研究阶段。这个套路变成了视频领域基本套路的问题,很多都可以拿来用,比如 3D 卷积,two-stream 等等。
我们把横和纵向模型结合在一起。对视频领域了解的同学可能知道 LRCN 方面的知识,这样的架构是后面的视频,车运行时主要基于这样的模型。它的关注点是时序处理、横纵向关联关系,因果 VS 轨迹预测,是否需要预测出精准的轨迹来,比如前面有一辆车,或者有几个行人,我需要精准地预测出车和行人的轨迹,还是只需要知道这个人在那个地方,大概朝车道的方向动一下,就判断出危险,这是两个不同的概念。一个是要精准地预测出周围的环境、运动轨迹,另外一个是不预测出运动轨迹,大概知道人在那儿就是潜在的威胁点,是因果的判断。
目前很多研究者或学者会把很多精力放在精准预测上,但其实人开车也不会预测出精准的运动,人开车的时候更多是因果的关系。其中也有很多需要关注的点,Attention 的问题,如何用注意力机制识别出交通标志或者是红绿灯,另外是迁移的问题,关注点其实还有很多。
End.
转载请注明来自36大数据(36dsj.com): 36大数据 » 百度Apollo平台基于深度学习的端到端自动驾驶方案