赞
踩
上一次的分享里,我对百度Apollo 1.0和Apollo 1.5所用到的传感器及控制器进行了介绍。
可以得到一个结论:实现越复杂的功能,所需要的传感器越多,对控制器的性能要求也越高。
今天的分享,我会结合Apollo 1.0和Apollo 1.5所开放的模块,谈谈我对百度Apollo技术框架的理解。并告诉大家不写代码,如何成为自动驾驶工程师。
先上一张百度Apollo的技术架构图。
Apollo 技术框架图
可以看出除了第一排在云端工作的的模块,剩下的模块都是需要实时跑在车上的。来分析每一层的功能。
Open Software Platform
自动驾驶系统最为重要的软件层。
这一层包含了最底层的RTOS(Real Time Operation System)和第二层的运行软件所需的框架环境(Runtime Framework),再到第上层的各个子模块(地图引擎、定位、感知、规划、控制、端到端、人机界面)。
Reference Hardware Platform
自动驾驶系统所依赖的硬件层。
这里不仅包含了控制器、GPS/IMU、HMI Device(其实就是显示器)和LiDAR,还有即将在18年1月开放的Camera、Radar、和Black Box(还猜不到这个黑盒的功能)。
Drive-by-wire Vehicle
线控的底层,不开放这个接口,就无法控制汽车。
看过百度Apollo发布会的童鞋想必都清楚,Apollo 1.0能实现封闭场地循迹自动驾驶的功能,Apollo 1.5能实现定车道昼夜自动驾驶的功能。
我们从Apollo 1.0和Apollo 1.5开放的角度来看一下“功能实现”与“模块开放”之间的关系。(暂不谈云端,仅谈车端)。
Apollo1.0 封闭场地循迹自动驾驶
先上图,下图中红色块是Apollo 1.0所开放的模块。
Apollo1.0 封闭场地循迹自动驾驶
首先我必须有一辆开放了底层的线控系统的车(Drive-by-wire Vehicle),才能实现这个功能;
自动驾驶程序要运行,控制器(Computing
Unit)、显示屏(HMI Device)都是不能少的;
实现循迹功能,需要解决一个很重要的问题——我在哪?因此作为定位所需要的关键模块GPS/IMU 被选中;
硬件配齐后,来看看软件。操作系统(RTOS)和软件所需的运行环境(Runtime Framework)是必须的,没有他们,软件是跑不起来的。
最后是软件层的子模块,定位(Localization)用来处理GPS/IMU的数据。
有了定位和需要跟随的轨迹线,那么就要开始控制(Control)了。
循迹时工程师需要控制自动驾驶系统,所以就有了人机交互界面(HMI)。
这样一套从工程师角度挑选所需模块的工作就完成了。
Apollo1.5 固定车道昼夜自动驾驶
同样的操作,我们来分析Apollo 1.5实现的“固定车道昼夜自动驾驶”的功能。先看图,图中蓝色块为新增模块。
Apollo1.5 固定车道昼夜自动驾驶
固定车道,意味着必须有车道线信息。
Apollo使用了高精度地图提供的车道线信息,这样有了高精度的定位(经纬度)和我需要行驶的车道的经纬度区域(这么说不是很专业,主要是让大家好理解,以后会详细聊定位和地图的关系),自动驾驶车就知道自己要在哪个范围内行驶了。
所以需要有处理高精度地图数据的模块——地图引擎(Map Engine)。
知道了自己要在哪个车道内行驶,车道内有障碍物怎么办?
这时候就需要有传感器能感知到这些东西。其实Camera、LiDAR、Radar都可以检测障碍物,Apollo 1.5开放的是激光雷达(Lidar)模块。
有了传感器,必然有对应的感知软件(perception)。
感知到了障碍物,该刹车刹车,该加速加速,该避让避让,所以需要对无人车的行为有个规划(planning)。
Apollo 1.5还开放了End-to-End,这是另外一种使用深度学习的方法实现“固定场景的自动驾驶”的方法,这里暂不讨论。
Apollo2.0 简单城市路况自动驾驶
下面这幅图是18年1月百度将公布的Apollo 2.0,新增的模块我用紫色背景标记出来了。
Apollo2.0 简单城市路况自动驾驶
你可以尝试用刚才我提供的思路,想一想“简单城市路况自动驾驶”的功能,为什么需要摄像机(Camera)和雷达(Radar)?
上面的分享其实是正经的“自动驾驶系统工程师”要做的工作,他们需要从“需求”推导出“架构”,进而决定使用什么样的硬件装到车上。
如果你并不擅长写代码,又想从事自动驾驶的工作,不妨多了解一些传感器及系统架构方面的知识。
好了\(^o^)/~,这篇分享基本上可以让大家对百度Apollo的技术架构有了了解。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。