上一次的分享里，我对百度 Apollo 1.0 和 Apollo 1.5 所用到的传感器及控制器进行了介绍。
可以得到一个结论：实现越复杂的功能，所需要的传感器越多，对控制器的性能要求也越高。
今天的分享，我会结合 Apollo 1.0 和 Apollo 1.5 所开放的模块，谈谈我对百度 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 所开放的模块。
首先我必须有一辆开放了底层的线控系统的车（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，新增的模块我用紫色背景标记出来了。
你可以尝试用刚才我提供的思路，想一想「简单城市路况自动驾驶」的功能，为什么需要摄像机（Camera）和雷达（Radar）？
小结
上面的分享其实是正经的「自动驾驶系统工程师」要做的工作，他们需要从「需求」推导出「架构」，进而决定使用什么样的硬件装到车上。
如果你并不擅长写代码，又想从事自动驾驶的工作，不妨多了解一些传感器及系统架构方面的知识。
好了，这篇分享基本上可以让大家对百度 Apollo 的技术架构有所了解了。
后续我在本专栏中对 Apollo 计划中出现的传感器做更加细致的分析，也期待你的阅读～
