Apollo 3.5 技术架构详解全程回顾

硬件平台主要是无人驾驶系统的计算硬件和各种传感器硬件，包括GPS/IMU、摄像头、激光雷达、毫米波雷达、HMI设备、黑盒子等。

开源软件平台是自动驾驶系统的核心部分，包括功能模块、运行框架和实时操作系统三部分。功能模块可细分为：

地图引擎：运行高精地图；

定位模块：通过GPS、V-SLAM、L-SLAM、里程计等多种定位源融合，结合高精地图，实现精准定位；

感知：通过激光雷达、毫米波雷达、摄像头，精确感知车辆周围的环境路况，包括车辆、行人、交通标志等等；

规划：主要包括路径规划、运动障碍物的预测等；

控制：实现控制车辆的转向、油门、刹车等操作；

End-to-End：基于深度学习的横向和纵向驾驶模型；

HMI：人机交互模块。

TIPS

本次沙龙课程，我们有请到百度Apollo资深技术布道师——胡旷来详细讲解Apollo3.5技术架构。

胡旷，中科院软件所计算机科学专业硕士，清华大学在读MBA。曾在IBM负责技术研发及创新管理工作，拥有4项美国专利。2014年加入百度担任技术管理岗位，目前是Apollo开源社区技术布道师，负责Apollo平台的车辆／硬件认证，并为生态伙伴提供软硬件解决方案咨询、帮助其落地Apollo解决方案。

在这次的分享中，胡旷将从Apollo3.5整体框架出发，为大家讲解全新版本的Apollo在城市驾驶能力、Apollo Cyber RT框架、硬件平台以及V2X车路协同这四大方面的重大升级，带领开发者更好的认识了解Apollo。

以下，ENJOY

Apollo 3.5是面向城市道路自动驾驶解决方案，能够处理更复杂的环境，具备更全面的能力。相对于以前的版本，Apollo 3.5 做了以下升级。

第一是首次具备处理城市道路自动驾驶能力。

第二是 Apollo 3.5硬件平台全新升级。

第三是实时通信框架Cyber RT。之前使用的是ROS， Apollo 3.5从ROS替换成了Apollo自研的专门应用于自动驾驶应用场景的通信框架 Cyber RT。

最后是应用于智慧交通的V2X。

Apollo 3.5 架构

这是Apollo 3.5的架构图，还是基于经典的四层架构。Apollo 3.5对四大核心能力进行了升级。

首先是底层的车辆认证平台，主要包括两块，第一是符合Apollo标准的线控车辆的需求，第二是满足Apollo线控标准的车辆。

往上是硬件开发平台，硬件开发平台是做自动驾驶相关的硬件，这些蓝色的模块中有些是新增的硬件类型，有些是更新的硬件型号。

再往上是软件开放平台，开源代码大部分是在软件层面。Apollo3.5在定位、感知、规划、还有Cyber RT以及V2X的适配器等模块有变化。

最上层的云端服务在Apollo 3.5主要是仿真以及V2X的路侧服务。

线控车辆是做自动驾驶的第一道门槛。Apollo 3.5的开放车辆认证平台其实就是降低大家的第一道门槛。在Apollo 3.5中，我们联合车厂的伙伴一起做这个事情。

首先我们新增了两款国内车厂的车辆，第一是与广汽合作的GE3的开发者版本，另一个是与长城合作的WEYVV6。开发者可以买到这些车辆，并且比之前的要便宜，降低上车的门槛。此外，我们还升级了乘用车的线控标准，新增了小型车的认证标准。此外，我们还发布了更详细的适配Apollo车辆线控标准的流程以及测试标准。

在Apollo 3.5中，硬件开发平台整体传感器套件变化非常大。在Apollo 3.0的传感器套件方案中，车的顶部是64线主感知雷达，还有前方的一个毫米波雷达以及三个摄像头，还有GPS、IMU惯导系统。

Apollo 3.5的变化非常之大。首先主感知激光雷达从64线升级到了128线，同时还增加了三个16线激光雷达，分别布置在车辆的正前方，以及车后部两侧，毫米波雷达也从之前的正前方的一个变成现在两个，分别是正前方一个，车后部一个，这也是为了支持倒车的场景。摄像头现在也是做环式，增加到10个。

其次我们还新增了很多的适配硬件，大家可以根据自己的场景做更深入的适配，而且还包括一些符合车规级的感知设备，主要是为将来的量产做准备。

第三点是开源软件平台，这一块重点介绍规划、感知模块还和Cyber RT。

在以前的自动驾驶场景中间，使用同一个配置来处理不同用户场景的问题。在Apollo 3.5中，我们要面临复杂城市道路，有更多的用户场景，我们提出了基于Scenario的规划。

Planner是解决自动驾驶的局部规划，Routing是解决全局规划。具体而言，规划就是基于地图、全局导航路径、定位、车辆状态（包括：位置、速度、加速度、底盘）、障碍物的感知及预测信息，计算出可供控制模块（Controller）执行的一条安全且舒适的行驶路径。

基于Scenario的规划架构

如图所示，从顶部的输入开始，通过Planner的Dispatcher生成Planner。

这个规划框架带来了以下优点：

架构可扩展且灵活

可以订制自己的Scenario

可以根据每一个Scenario精调性能

可以复用决策器和优化器

下面给大家看一个例子，这是一个很常见的车辆行驶场景，这个场景由四个Scenarios来组成，第一个Scenario车辆会做前面的跟车，车道保持，Lane Follow，探测到的行人在一定时间内保持静止状态，这个时候可能选择侧道超车，超完车之后继续做Lane Follow，后面有一个Stop Sign来继续行进，这是一个很常见的场景。

一个场景由连续多个Scenarios组成

再细看下刚才场景中间的某一个Scenario。Scenario是由多个Stages组成的，再来看Side Pass有哪些Stages，前面有障碍物要减速，生成减速的轨迹线，之后第二个Stages停在离前方障碍物的安全距离内，观察情况确保安全。第三步在确保安全的前提下，生成了Side Pass的轨迹线，这就是Side Pass所经历的三个Stages。

一个Scenario由连续多个Stages组成

Apollo 3.5默认支持这些道路场景、隔离带道路、小巷道，减速带、禁停区、人行道还有旁边有车辆停的道路，以及交叉路口、全向停止标志。还有像开放空间对于停车、倒车、泊车这些场景的支持。

在Apollo 3.5 中，感知套件的变化非常大，主要表现在：第一新的感知系统能够帮助Apollo系统看得更全，实现360度无死角，无盲区的覆盖。第二基于128线的激光雷达能看得更远。第三是更灵活，根据场景以及硬件配置融合的机制。

多视角感知架构

这个是新的感知的架构图，主要还是三类感知设备。从图中看出，使用深度网络解决交通信号灯检测、车道检测以及障碍物的问题和点云的分割。之后再做后向的融合、输出。交通信号灯是基于两个摄像头来做的，而其他的功能我们会基于三类感知设备。

开源软件的另一重点，也是Apollo四个核心开放能力里面的一个重点，即Cyber RT。

Cyber RT是系统应用层和操作系统层的一个中间件， Apollo之前是使用ROS，为什么Apollo 3.5要替换成Cyber RT呢？

大家都知道ROS是基于在机器人行业用得非常的广泛的实时通信系统，但是把它用在自动驾驶场景里会面临很多的挑战。

1)ROS调度的不确定性。ROS的调度依赖linux的通用系统调度，不清楚业务逻辑。自动驾驶是专用系统，任务需要按照业务优先级调度。其低延迟要求比高吞吐要求更高。

2)ROS通信的开销。Apollo前期曾经使用共享内存去降低ROS原生的通信开销的问题。

3)非自动驾驶领域专用，存在其他问题等。

使用Cyber RT有以下优势：

1)非常简易的部署体验，不用关注其调度机制与通信机制，就能提供非常好的性能，且不需要复杂的配置。

2)加速自动驾驶开发，自研减少了很多底层的依赖，迁移到不同的计算平台的时候就会相对容易。

3)专注自动驾驶，为自动驾驶解决方案赋能。它是相对独立的开源实时计算框架，并且专为自动驾驶设计的组件模块，基于Cyber，简化搭建自动驾驶应用的流程。

Apollo Cyber RT运作流程

Cyber中通过Components来封装每个算法模块，通过有向无环图（DAG）来描述Components之间的逻辑关系。对于每个算法模块，也有其优先级、运行时间、使用资源等方面的配置。系统启动时，结合DAG、调度配置等，创建相应的任务，从框架内部来讲，就是协程，调度器把任务放到各个Processor的队列中。然后，由Sensor输入的数据，驱动整个系统运转。

V2X是推动自动驾驶另外一条技术路线，跟自感知相比是另外一种路线。当然它与自感知技术协作的话能更快地帮助自动驾驶落地，Apollo 3.5提供了V2X的解决方案。

Apollo 3.5 智能车辆基础设施协作系统（IVICS)架构图

这是Apollo V2X的架构图，其包括硬件平台的OBU，软件平台的Adapter，以及云端的路侧服务。