写点什么

百度 Apollo 平台基于深度学习的端到端自动驾驶方案

2017 年 9 月 07 日

基于深度学习(以 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 的问题,如何用注意力机制识别出交通标志或者是红绿灯,另外是迁移的问题,关注点其实还有很多。

问答环节

提问:端到端训练模型,CNN 是在线训练还是离线训练?我之前在百度 AI 大会上看到的视频,无人车在一个封闭场地内行走,刚开始不会转弯,后来经过一段时间学习学会了转弯行为,有点类似于强化学习。我想了解一下端到端训练模型中是否有强化学习的算法在里面?

郁浩:目前还没有,我们也在调研,强化学习在真实的车上很难应用,有很多限制条件,在模拟器上很容易,但是车上很难。

提问:刚开始不会转弯,后面如何学会转弯的?

郁浩:调参。

提问:百度现在做端到端的实验目的是什么?是为了给出一个 Demo,还是希望有很好的实用价值?

郁浩:所有价值一定以实用价值为出发点,这个方向从 2016 年上半年才起来的一个方向。我刚才在这里列了一个表格,有一点我没有说,End to End 系统和 Rule based 系统是互补关系,但是如何融合,到目前为止我们也在探索。我们相信 End to End 系统一定会给自动驾驶带来很大收益,而且是融合的关系。但是它在每一个功能点上,在每一个模块上怎么融合是需要持续探索的。

提问:你们现在用端到端,包括引入持续的模型,现在也在处理并线和转弯这样的问题吗?

郁浩:转弯分两类,Reactive 和 Proactive,目前做的重点是 Reactive,你可以想一下哪些是可以边打电话边开车的行为。

提问:郁老师,如果用深度学习,在商业落地过程中,End to End 想要解决的关键,我们可以直接跳过复杂的 Rule based 闭环的流程。你刚才也提到现在面临的一个问题,可能你学习出来的一个经验,在商业落地过程中,和车厂合作的时候怎么解释这个领域的知识,你训练出来的模型怎么用领域知识解释?我也是百度的,我想问一下现在做到什么程度,因为我觉得领域知识的解释在商业过程中是非常重要的。

郁浩:这个问题很关键,从我们过去将近一年多和车厂打交道的经验来看,不可能动摇别人的根本观念。你和车厂聊之前他们已经有初步判断,是不可能动摇的,或者很难动摇,动摇思想是很难的,这是一方面。另一方面,其实没有你想像的那么难,我们接触的很多车厂也在做。你说的问题我们在和大量车厂聊的时候都不是问题,他们也在探索。

提问:我们有没有研究可以用专业模型来解释领域的研究?有没有哪些可解释性的指标给别人看?

郁浩:从两方面来看。一方面,指标上更倾向于用统一的,像业界通用指标,这样的指标是最客观的。另一方面,你说的后面的问题,就是刚刚提到的 Proactive,目前也在想,也还没有想明白,欢迎大家探讨和交流。

提问:关于 End to End 网络,最后 loss 定义的问题,是不是驾驶员预测和机器预测的差值?在不同情况下应该有不同权重,比如在高速情况下,稍微有一点差就对损失很大,但是在低速情况下,稍微偏离一些影响并不大。如果我旁边一个人都没有,就是一个空的场地,我随便转也没有什么损失。但是如果旁边有老人,这种情况可能损失很大。对于不同的 step,或者对于不同状态,loss 是怎么定义的?

郁浩:确实不一样,我们会根据不同速度、不同拐角有相应不同的权重训练模型。更具体的场景,计划在 12 月份的时候会出来。

提问:郁老师您好,我做无人驾驶有一段时间了,有一个问题一直没有想明白。Rule based 这种方式和 End to End 这种方法,他们在无人驾驶中哪一个更重要?或者说在百度角度来看,哪个更适用于现阶段?从长远来看,哪个方案会走到最后。当然,End to End 只解决了无人驾驶中某一个重要环节,或者驾驶环节,高精度定位和车联网根本没有涉及到,或者说 End to End 这种驾驶行为只是有点像特斯拉这种表现形式而已,可不可以理解百度在现阶段也没有完全把这两个方案应该走哪条路完全制定出来,或者是想成熟。在您的报告中,我也没有听到太明确的答案,所以我想请教一下。

郁浩:我理解一下你的问题,一是当前看哪个更重要,二是长远看是怎样的应用。

提问:长远看没有人能说得很清楚,但是现阶段应该有一个明确答案了,百度做无人车有很长时间了,而且整个行业也发展很长时间了,现在火起来大概有四到五年时间,现阶段应该是有明确答案的。

郁浩:现阶段的重要性,刚才 Apollo 那个大架构中已经说了这样一个关系,目前大的 Apollo 是一个平台,还有很多垂直的应用方向,感知决策等等。目前 End to End 是一个子方向,二者之间有一个融合的点,我们目前的态度一定是相互融合的,然后这个融合的点目前还在探索中。远期我回答不了,我也就能看到一两年之后。

提问:郁老师您好,现在很多做端到端只是以图像作为输入,您这边是否有考虑过结合其他传感器的输入做端到端的过程?

郁浩:这都是我们的考虑选项,但是目前精力主要在图像上。暂时有没有想法或者是思路。但是我们也关注整个行业,谁做了相关传感器 End to End 的方案,也欢迎在 Apollo 平台上贡献出来,我们一起交流。

提问:大家普遍觉得 End to End 这种方法不是很靠谱,您这边有没有考虑过和一定程度的规则进行结合,去构建我们这个网络?

郁浩:这就是我说了半天的那个表格,我们的观点是融合的,一定是可检测的。去年 9 月份,白宫发了一份《无人驾驶指南》,对于涉及到安全的部分一定是可解释的,这也是我们比较认同的一点,End to End 没问题,但是一旦涉及到安全一定要可解释,这也是为什么说一定是融合的方案。

提问:刚才您展示的 Demo 中,无人车识别路牌后可以根据路牌转弯,当然路牌在样本中是小样本数据,在训练神经网络的时候把样本数据作为错误样本丢掉了,您对这个问题是如何理解的?

郁浩:不理解,为什么是错误的样本。

提问:大部分样本并不包含路标信息,可能少量样本包含这种信息,神经网络找的是更大概率的规律,这种小概率事件,我之前也有师兄在做这个事,他发现这种小概率样本会当做错误样本信息丢掉了,不知道您是不是有注意到这个问题?

郁浩:包括我们这个系,整个机器学习领域都是这样,80% 的工作都是在做你所说的那些事情,做很多数据的处理,比如数据倾斜的问题,如何设置好,采的时候可能 95% 都是常规的路,1% 到 2% 是特殊的路,但是训练的时候不能拿来训练,会出问题的,训练的时候就会做很多策略在里面,我们大部分工作都是在做这些事情。

我们开放了地图采集车数据,我们相当于原样不动地把数据呈现出来,大家用的时候建议做相应的数据工作,因为我们采的路大部分是直行,或者拐弯很小,这时候需要在用数据的时候自己做好相应的数据处理工作。

提问:如果我们想自己训练一个有独特效果的模型,大概需要多少数据训练?需要多长时间?

郁浩:跟你问题的定义、指标有关系,一个点在于看你怎么评价或评估你所说的模型。如果根据现有数据回归到稳定的阶段,我们目前的经验,差不多十几个小时,不到一天。如果说你的评估标准改了,用多少小时,多少公里的数据,要看你跑的路面和你之前的数据是什么关系。

提问:传统的控制方法一般都是基于反馈,现在 End to End 的方法有没有什么问题,或者需不需要反馈来加强最后的控制效果。

郁浩:你说的没错,所以会碰到问题,End to End 会遇到两个问题,其中一个问题是异常恢复的问题。所谓异常恢复,传统的闭环中,始终绕着闭环走,开环一旦到了之前位置的场景,怎么能够闭回去,这是要注意的问题。这也是为什么之前那个方案中用了三部相机的原因。

提问:现在用相机问题会严重吗?

郁浩:这个问题是一个大问题,有些手段可以,当数据量大的时候也就不是问题了。这次 Apollo 平台上接受一些开发者的建议,之前只是提供数据,后来很多开发者提出能不能提供一些云上的资源,直接在云上训练,而不用把一万公里下载下来。这次 Apollo 的亮点是把数据放在平台上,不用下下来,可以直接在云上训练,杨老师也介绍了怎么在云端上看训练的效果。

刚才提到的开放的数据,在 8 月份到 11 月份的时候会有一个开源的比赛,数据开源出来以后一起进行训练,看效果怎样。这次也有一个这样的比赛,区别点在于基于中国数据,而且对于成绩比较好的会提供实车的验证,提供场地,提供车,在虚拟机上训练好,直接给你车验证。也欢迎关注我们具体的规则,最终排名把车的模型在车上跑得好是最好的。

讲师介绍

郁浩,百度智能驾驶事业部资深架构师,无人驾驶算法方向,重点关注基于深度学习的无人驾驶系统,从算法到工程再到项目落地,拥有丰富的经验。

2017 年 9 月 07 日 17:552888

评论

发布
暂无评论
发现更多内容

基于Jira的产品需求全生命周期管理实践

YY哥-杨勇

需求管理

第三周作业

南宫煌

极客大学架构师训练营

插入排序

wjchenge

插入排序

深入理解JVM垃圾回收机制 - 引用类型

NORTH

深入理解JVM 强引用 软引用 弱引用 虚引用

我嗅到了数据开发工程师的危机

无箭的丘比特

大数据 数据仓库 数据分析 数据开发

组合模式

俊俊哥

设计模式 组合模式

架构师训练营第三周总结

王鑫龙

架构师训练营第三周学习总结

whiter

极客大学架构师训练营

都在讲DevOps,但你知道它的发展趋势吗?

陈琦

DevOps 自动化

架构师week3总结

平淡人生

一周信创舆情观察(6.15~6.21)

统小信uos

新基建 信创 matlab 舆情

架构师训练营 -Week 03 命题作业

华乐彬

极客大学架构师训练营 作业

作业一

Thrine

架构师 0 期第三周作业(命题作业)

何伟敏

架构师训练营第三周学习总结:面向对象设计和设计模式

hifly

设计模式 极客大学架构师训练营 OOD SOLID 策略模式

组合模式实现树结构

新世界

如何编写高质量代码之设计模式

imicode

设计模式-单例与组合

ashuai1106

架构师 极客大学架构师训练营

架构师第三周作业

G小调

架构师week3作业

平淡人生

Week3学习总结

熊威

第三周设计模式作业

开源项目中的设计模式

dony.zhang

架构师训练营-第三周-20200624-学习总结

丁亚宁

极客大学架构师训练营

设计模式示例

imicode

架构师训练营第三周总结

架构师 极客大学架构师训练营

架构师训练营-第三周-20200624-单例模式和组合模式

丁亚宁

极客大学架构师训练营 课程作业

第三周作业:设计模式

Larry

第三周作业

架构师训练营第三周 - 总结

Larry

第三周学习总结

G小调

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

百度Apollo平台基于深度学习的端到端自动驾驶方案-InfoQ