Apollo ：架构演化

简介

阿波罗是一种高性能、灵活的架构，可加速自动驾驶汽车的开发、测试和部署。官网在此

• Apollo (阿波罗)是一个开放的、完整的、安全的平台，将帮助汽车行业及自动驾驶领域的合作伙伴结合车辆和硬件系统，快速搭建一套属于自己的自动驾驶系统。
• 开放能力、共享资源、加速创新、持续共赢是Apollo开放平台的口号。
• 百度把自己所拥有的强大、成熟、安全的自动驾驶技术和数据开放给业界，旨在建立一个以合作为中心的生态体系，发挥百度在人工智能领域的技术优势，为合作伙伴赋能，共同促进自动驾驶产业的发展和创新。
• Apollo自动驾驶开放平台为开发者提供了丰富的车辆、硬件选择，强大的环境感知、高精定位、路径规划、车辆控制等自动驾驶软件能力以及高精地图、仿真、数据流水线等自动驾驶云服务，帮助开发者从0到1快速搭建一套自动驾驶系统。

华为　vs 百度

• 华为是凭借自己在通信、硬件方面的积累做L2往上的智能辅助驾驶量产，侧重于量产变现；
• 而百度是从软件算法角度打造自动驾驶开源平台，侧重于吸引更多企业加入，形成生态壁垒从而变现

架构演进

Apollo 1.0：循迹功能

2017年7月Apollo 1.0 循迹自动驾驶发布

• 所谓循迹自动驾驶就是人开一段，然后车记录下人开的轨迹，再沿着这个轨迹不停的回放。
• Apollo 1.0里有很多技术框架都没有点亮，在Apollo 1.0里不需要camera，也不需要Sensor，只需要一个GPS。也不需要做规划，有精准的定位就行。
• 这个版本可以在封闭的场地(比如测试跑道或者停车场)工作
• 应用：开发者基于Apollo 1.0做了一个农用场景阿波牛，在田间地头不停地穿梭，因为田埂是不会改变的。

架构如下：

车辆参考平台（Reference Vehicle Platform）

最底下一层是线控车辆平台，执行Apollo无人驾驶平台生成的车辆控制指令，可以实现实现电子化的控制，也就是线控汽车

那么，什么是线控车辆呢？

• 无人驾驶基础车辆必须通过电子控制，被称为线控驾驶车。在线控车中有一个非常重要的模块，它就是CAN总线，也就是控制器区域网络，它是车辆内部通信的网络。CAN和计算机是通过CAN卡进行连接的，计算机通过CAN线发送加速、制动和转向信号。
• 为了能够运行Apollo生成的指令，车辆必须是线控的，例如可以接受一定的指令，比如换挡、加减速、转向，完成对应的操作。
  • 在Apollo 3.0之前，我们称之为车辆参考平台，即推荐的可运行Apollo的几种车。
  • 在3.0之后，我们发布了Apollo对车辆条件的需求，比如需要哪些线控功能，对应的操作耗时是多少等。只要把车改装成具备对应条件之后就可以运行Apollo，现在称为开放车辆认证平台。

那么，什么是Reference呢？Reference的含义是：我提供了一个Specific的东西，但是你可以根据我这个Specific的东西来创建你自己的Specific的东西。

那么对于Reference VehiclePlatform来说，这个特定东西是什么呢？

• 很简单：一个特定的应用层协议以及应用实现代码。
• 对于，车辆与上层控制系统来说，这个应用层协议主要包含三个类型的消息：1）自动与人工模式设定消息；2）油门刹车转向档位灯光等控制消息帧；3）车辆运动状态和运行状态消息帧。
• 基于这个应用层协议，根据选择的应用层以下的协议（TCP/IP、CAN、RS232），结合特定的计算机接口驱动API（CANDriver、Socket、Serial），就可以写代码了，最终形成一个特定应用的代码。
• 是的，这就是一个很简单的东西，唯一的难点是底层车辆上的总线如何规划，如何给自动驾驶系统配置总线资源，不过这个跟百度无关，是车辆提供方的事情。

参考硬件平台（Reference Hardware Platform）

这一层主要包含计算机硬件和传感器

• 集成各种传感器对汽车周围环境进行感知。包括GPS、IMU、相机、激光雷达、毫米波雷达、超声波雷达等
• 无人驾驶系统对算力的要求非常高，所还需要一个计算平台（computing unit）用于计算传感器传递的各类信息，例如英伟达的芯片Drive PX。
• 除了计算单元和各类传感器之外，硬件平台还包括用于人机交互的HMI Device和用于记录信息、技术迭代的黑匣子。Blackbox是百度开放的一个商业化硬件，它记录一些内部数据，例如关键时刻的执行操作，类似于飞机上的黑匣子。

当然这些都可以买，百度唯一可以做的工作就是像Reference Vehicle Platform层一样，写个软件把这些数据采集进来。

软件开放平台（Open Software Platform）

这一层是核心，也是Apollo要开源的东西

开放式软件平台以RTOS（实时操作系统）为基础，在其上搭建运行框架（runtime framework）和应用层。

• 其中运行框架主要是一些接口，起到承上启下的作用
• 应用层便是大家所熟悉的自动驾驶算法，包括感知、定位、决策、控制等算法都在这里实现

这个框架又叫AUTOSAR架构。AUTOSAR是Automotive Open System Architecture（汽车开放系统架构）的首字母缩写，是一家致力于制定汽车电子软件标准的联盟，基于汽车开发的Apollo系统自然得符合这一标准。而这一标准的目标便是：

• 1）建立独立于硬件的分层软件架构；
• 2）为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU；
• 3）制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同汽车平台复用。

• RTOS

我们来看一看Apollo 使用的RTOS是如何构成的。

• 为节省工时，降低开发难度，百度并未自行研发底层操作系统。很显然，开发一个操作系统也并非想开发就开发的，其难度不亚于搞出个Apollo1.0。因此，百度选择在现有Ubuntu操作系统基础上进行改进。
• 原始的Ubuntu系统其实并不是实时操作系统，因此就需要对其内核进行修改。百度干得就是这事儿，他们把kernel进行了修改，加入Apollo设计的内核，使其成为RTOS，这样，Apollo的操作系统便诞生了。

• runtime framework

运行时框架为操作系统提供运行环境，简单点说就是底层操作系统发出的指令如何传达到应用层，这时候就需要RTE层帮忙传输，他就像个传达室的师傅，把信息传递到位。这个职责看着简单，实则非常复杂，毕竟自动驾驶汽车传递的信号千千万，其中一个都不能岔了，一个都不能传错，当系统复杂度上升到一定数量级之后，再简单的工作也不再简单。故而百度仍旧为稳妥起见采用业界最常用的机器人操作系统（ROS）来承担这一传递信息的重任。视频中为此还特意解释道：“虽然ROS是一个操作系统，但在这里它被用作在Apollo RTOS 上运行的软件框架”。ROS在机器人界非常出名，几乎每一款机器人的开发都会用到这个操作系统或是在此基础上衍生出来的版本。

ROS最大的特点便是按功能划分模块。每个模块都会有输入的数据流、如何处理数据以及输出的数据流，在编写代码时，便可按照功能划分模块，例如定位就会作为一个模块，其下还包含了定位的数据处理、数据融合、更新迭代等多个类，非常便于捋清整体逻辑，从而构建起庞大的代码架构。但是由于这些模块相互独立，因此只能通过RTE这个框架来进行通信。当然，没有任何一种系统能够完全适合新开发的Apollo项目，因此百度在此基础上又进行了一通捣鼓：改进共享内存的功能和性能、去中心化和数据兼容，这个修改后的代码叫做Apollo-platform。

• 共享内存

共享内存降低了需要访问不同模块时的数据复制需求，对于一对多的传输方案，共享内存支持“一次写入 多次读取”的模式，例如我们只收到了一帧的点云，这些点云可以同时运行障碍物检测、定位和GUI工具，而需要点云数据的模块自行读取即可。这一点也非常像MQTT这种发布-订阅模式的协议，一方在一个主题内发送消息，需要该消息的角色订阅该主题即可。

• 去中心化

去中心化解决了单点故障的问题。ROS1.0由许多的节点组成的，每个节点都有对应的功能，例如一个节点可以负责收集摄像头的图像、另一个节点可能负责路径规划，而第三个节点可以负责将控制命令发送到CAN总线上等。但是存在一个问题，上述的节点在ROS中，都需要由单个ROS主节点来控制，问题显而易见，如果这个主节点挂了，那么和他相关的所有节点都无法工作了。

为了避免这种问题，Apollo将所有的节点放在一个公共域中，域中每一个节点都有关于这个域中其他节点的信息，因此就消除了单点故障的风险。如下图所示：

• 数据兼容

• 我们知道无人车这么一个庞大的项目自然会用到各式各样的数据格式，单拿传感器输入来说就会有图像格式、点云格式等等，这些格式下面又能细分成好多种不同格式，简直非常繁杂。
• 怎么处理呢？项目在开始时便要设计好数据兼容问题，确保节点和节点之间传送的ROS message是同一种格式。采用通用格式的消息数据，便能使节点之间互相理解对方想要传达的意图。这种接口语言叫做Protobuf，它是一种结构化数据序列化方法。即使在原传输序列后增添新的数据信息，也不会破坏原本的数据格式。

• 应用层

应用程序主要包括了定位、控制、HMI等应用。每个模块都有自己的算法库，他们之间的联系也错综复杂。

云端服务平台（Cloud Service Platform）

• 云，简单说就是计算资源的一种共享。通过分布式计算机，将计算资源作为一种商品通过互联网进行流通分配。由于能充分协调资源，因此使用效率大大提高
• 车在路上跑需要和云端有一定的交互，云端计算出模型再把它下发到车上。
• 1.0版本提供了数据平台（Data Platform）和智能语音系统（DuerOS）

• 数据平台（Data Platform）

我们知道数据对于无人车而言是非常重要的，Apollo的数据平台提供了非常丰富的数据。仿真场景的数据有两个不同的来源，分别是记录场景和虚拟场景：

• 记录场景：我们可以使用记录的场景数据来重放我们在实际道路测试中已经观察到的传感器的数据。
• 虚拟场景：我们可以借助虚拟场景，使用虚拟编辑器创建新的驾驶场景，这有助于快速检验与验证算法。

除此之外，为了训练像深度学习网络那样的机器学习模型，Apollo 数据平台还提供了带标签的注释数据

目录

从上图中我们可以看出，我们最感兴趣的部分都在modules中：

Apollo 1.5：循航功能

2017年9月发布了Apollo 1.5 固定车道自动驾驶。

• 所谓固定车道自动驾驶，就是指在不变道的情况下处理一个车道内的所有行为，比如跟车、在车道内行进等
• 添加了激光雷达，感知规划模块等，具有该版本的车辆现在可以更好地感知周围环境，并且可以更好地绘制其当前位置并规划其轨迹，从而在车道上进行更安全的操纵。
• 应用：基于Apollo 1.5有专门为老年人或残障人士设计的漫步车。

架构如下，黄色模块是升级或者添加：

可以看到它做了如下改变

参考硬件平台（Reference Hardware Platform）

• 添加了LIDAR，使得有了避障功能

软件开放平台（Open Software Platform）

• 其应用层添加了地图引擎、感知、规划、端对端驾驶模块

云端服务平台（Cloud Service Platform）

添加了高精度地图、仿真环境

• HD Map：高精度地图

• 仿真环境

• 仿真环境平台是Apollo开放软件平台提供的非常重要的工具，该平台可以允许每个开发者出于自身的需求，来构建仿真环境。
• 除此之外，该平台还有大量的驾驶数据，开发人员可以检验和验证无人驾驶软件系统。仿真环境可以使Apollo车辆不仅可以查看环境，还可以了解道路情况和场景。仿真环境平台支持开发者配置不同的驾驶场景，比如障碍物、路线和交通灯状态。执行模式为开发者提供了一个在多场景中运转的完整设置，在执行模式中，开发者可以在Apollo环境中上传和验证模块，当前的自动评分系统，从几个指标对场景进行评估，其中包括碰撞检测、交通灯识别、速度限制、障碍物检测和路线逻辑，
• 最后，三维可视化可以去描述实时路况，在显示无人驾驶车状态的同时，使模块输出可视化。

Apollo 2.0： 城市避障换道信号灯停车

• 支持在简单的城市道路上自动驾驶的车辆。 车辆能够安全地在道路上行驶，避免与障碍物碰撞，在交通信号灯处停车以及在需要时改变车道以到达目的地
• 这个版本中加入了Camera、Radar、Security、OTA等。

架构如下，红色模块是升级或者添加：

Apollo 2.5：高速车道保持

• 允许车辆通过摄像头在障碍物高速公路上自主行驶，以进行障碍物检测。 车辆能够保持车道控制，行驶并避免与前方车辆发生碰撞。
• 长沙智能研究院结合 Apollo 2.5 限定区域高速自动驾驶发布了高速物流卡车自动驾驶解决方案。

架构如下

Apollo 3.0：封闭园区低速控制

• 主要重点是为开发人员提供一个在封闭场所低速环境中进行构建的平台。 车辆能够保持车道控制，行驶并避免与前方车辆发生碰撞。
• 其车辆参考平台升级为车辆认证平台，硬件参考平台升级为硬件开发平台，云端服务平台增加量产服务套件，在此基础上提供自主泊车（Valet Parking）、无人作业小车（MicroCar）、自动接驳巴士（MiniBus）、小度车载OS四大量产解决方案
  • 在升级后的硬件开发平台上，阿波罗首次发布阿波罗传感器单元（Appollo Sensor Unit，简称ASU），包括激光雷达、车载摄像头、毫米波雷达、组合导航系统、超声波等设备，能够使多种产品在阿波罗平台上即插即用。
  • 同时，硬件开发平台还添加了底层软件抽象层，该软件抽象层能够适配多种数据格式，定义通用API接口，实现传感器时间同步，并提供硬件设备实时监控，从而无缝衔接上层软件和设备驱动。
  • 至于升级后的车辆认证平台，则从线控系统和车辆系统两个层面，开放了包括功能、性能、安全、能耗等一系列共计17个指标。同时开放包括DBC file转化工具、动力学曲线标定工具、指令安全测试工具、接口需求文档等工具和文档。

Apollo 3.5：市区360环视

• 能够导航复杂的驾驶场景，例如住宅区和市区。 该汽车现在具有360度可视性，并具有升级的感知算法，可以应对不断变化的城市道路状况，从而使汽车更安全，更醒目。 基于场景的计划可以在复杂的场景中导航，包括未保护的转弯和狭窄的街道，这些街道通常出现在居民区和带有停车标志的道路中。

架构分析

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

• 首先是底层的车辆认证平台，主要包括两块，第一是符合Apollo标准的线控车辆的需求，第二是满足Apollo线控标准的车辆。
• 往上是硬件开发平台，硬件开发平台是做自动驾驶相关的硬件，这些蓝色的模块中有些是新增的硬件类型，有些是更新的硬件型号。
• 再往上是软件开放平台，开源代码大部分是在软件层面。Apollo3.5在定位、感知、规划、还有Cyber RT以及V2X的适配器等模块有变化。
• 最上层的云端服务在Apollo 3.5主要是仿真以及V2X的路侧服务。

车辆认证平台

线控车辆是做自动驾驶的第一道门槛。Apollo 3.5的开放车辆认证平台其实就是降低大家的第一道门槛：

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

硬件开发平台

在Apollo 3.5中，硬件开发平台整体传感器套件变化非常大。

• 在Apollo 3.0的传感器套件方案中，车的顶部是64线主感知雷达，还有前方的一个毫米波雷达以及三个摄像头，还有GPS、IMU惯导系统。

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

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

软件开放平台

包括规划、感知模块、Cyber RT等

（1）基于场景的规划：

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

（2）多视觉感知

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

（3）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，简化搭建自动驾驶应用的流程。

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

（4）基于智慧交通的V2X

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

Apollo 5.0：360全面感知深度学习模型

• 支持地理围栏自动驾驶的批量生产。 该汽车现在具有360度可视性，并具有升级的感知深度学习模型，可以处理复杂路况的变化情况，从而使汽车更加安全和感知。 基于场景的计划已得到增强，以支持其他场景，例如，过马路和穿越交叉路口

Apollo 5.5: 点到点城市自动驾驶

• Apollo 5.5通过引入路边对道路的驾驶支持，增强了先前Apollo版本中复杂的城市道路自动驾驶能力。有了这一新功能，阿波罗现在已接近自动驾驶城市道路驾驶的飞跃。该汽车具有完整的360度可视性，以及升级的感知深度学习模型和全新的预测模型，可应对复杂道路和交汇处场景的变化情况，从而使汽车更安全，更醒目。

Apollo 6.0: 迈向无人化自动驾驶

Apollo 6.0在功能上主要有5个方面的升级。

• Apollo 6.0在算法模块上，引入了三个新的基于深度学习的模型。
  • 在感知上，Apollo 6.0 实现了基于PointPillars的激光点云障碍物识别模型，线上采用了TensorRT来对模型进行加速，每个周期的识别速度优于70毫秒。
  • 在预测上，Apollo 6.0 发布了基于语义地图的低速行人预测模型，针对于低速园区的场景，继承了语义地图对于环境的丰富表达，更精准的预测行人低速轨迹。
  • 在规划上，Apollo 6.0 首次引入了基于语义地图的模仿学习，通过大量的真实路测数据，模仿人类司机在一些特定场景下动态避障的能力，与已有基于优化的规划相结合，显著增强了行车的安全性和舒适性。

• 集成了无人驾驶的相关内容

  • DreamView提供了远程平行驾驶的接口模块，它不仅定义了压缩车端视频和音频的信号格式，也定义了完整的远程操纵命令格式，让车端可以接受远程操作员指令，并把指令转换成相应的规划和控制命令，来实现对车辆的远程操作。
  • 无人驾驶需要对紧急车辆，如救护车、消防车、警车等进行识别处理，6.0 中增加了紧急车辆检测，通过多声道麦克风来捕捉车辆周围的声音，采用深度学习的方法来检测紧急车辆，准确率达到95%以上，同时通过算法来判断紧急车辆的方位，以及是否逼近或者远离自动驾驶车辆

• 对系统进行了升级

  • 将主要工具、依赖库都升级到了最新版本：此次系统升级的内容包括全面支持C++14、Python 2.6升级到了Python 3.6、编译工具升级到了Bazel 3.4 和 GCC 7.5，主要的依赖库譬如PCL TensorTR PyTorch 等也做了全面的升级
  • 对5.0发布的云服务（（Apollo数据流水线服务，搭配Apollo教育和开发者套件））也进行了全面升级
    • 首先，数据流水线与仿真平台完成了整合，开发者可以在同一界面中进行无缝的访问；其次，在能力上，Apollo也新增了多个云服务，其中有开发者最为期待的control profiling来帮助开发者了解控制算法的性能，也有感知开发者很期待的PiontPillars模型训练服务，用户可以使用这个服务来产出符合自己场景需求的障碍物识别模型。
    • 其余的新云服务还包括低速行人预测模型训练服务、车辆动力学模型训练服务。
    • 特别值得一提的是，在6.0中Apollo特别增强了云端服务的联动性，与以往离散的云端服务不同，这次推出的许多云服务都可以串联起来，在云端处理更为复杂的任务。

• 对v2x车路协同方案做了重大升级，首发对象级别的车端感知与路侧感知融合。
  • 在V2X设备通信上，新方案执行《基于车路协同的高等级自动驾驶数据交互内容》标准，该标准是由百度牵头，联合32家单位共同制定，是国内首个面向高级别自动驾驶领域的车路协同交互标准。
  • 同时，为了让开发者更快速的把车路协同标准运用起来，Apollo也推出了搭配V2X车载单元的开发套件，并联合政府相关部门推动开放包括长沙、广州、北京、沧州、重庆、阳泉等测试城市进行V2X路侧测试合作，进一步降低开发者使用Apollo开源车路协同方案的门槛。

• 在开发套件云端服务方面，提供了涵盖传感器标定、车辆标定、控制闭环仿真、虚拟车道线、控制评测五大服务，全面提升研发效率。

Apollo 7.0: 共创汽车机器人连接

自动驾驶开放平台作为百度多元汽车机器人落地的重要支撑，本次升级发布的Apollo7.0实现了从代码到工具、从开源平台到工具化平台的里程碑式完整进化。在云端服务、开源软件、硬件开发、车辆认证四大开源平台基础上，Apollo 7.0提供了包括一站式实践云平台Apollo Studio、业内领先仿真服务、高效新模型在内的一系列升级，不仅代码全能力开放，更能提供自动驾驶全栈工具链，更易用、更领先、更高效的帮助开发者运用平台能力。

• 云端服务平台层面，Apollo 7.0将6.0版本中深受开发者欢迎的“数据流水线”服务正式升级为Apollo Studio，涵盖开发者从上机到上车实践的全流程云端工具链，为开发者提供一站式实践平台体验。
• 仿真平台层面，Apollo 7.0推出业界首个PnC强化学习模型训练与仿真评测平台，具有数据真实、功能强大、评测标准全面、架构可扩展等多重优势，有望为强化学习研究提供统一的验证标准。
• 开源软件平台层面，Apollo7.0对感知和预测算法模块升级，引入MaskPillars、SMOKE、Inter-TNT三个基于深度学习的模型，有效减少漏检、抖动等问题。
  

源码分析

代码结构

软件开放平台（Open Software Platform）在此， 包括下面几个东西

（1）apollo-kernel是个什么？

• Apollo-kernel=开源linux+一个免费的RT-OS补丁+显卡驱动+CAN卡驱动。

（2）apollo-platform干了啥？

• ROS：它是后操作系统，构建在操作系统之上，能够为各个应用程序之间的交互提供runtime framework的功能。这个Apollo-platform就是这个runtime framework
• Apollo-platform“深度”修改了ROS，可以称之为Apollo-ros，可以算作是Ros的一个版本，但与原生Ros不兼容

（3）Apollo里有什么

• apollo就是一个自动驾驶的功能框架了，各种模块的源码，当然也包含一些算法。在这个Apollo里还是看到了一些高大上的东西，比如Factory、Adapter、Observer等软件架构范式，并且采用了Google的一个叫做docker的工具用于提供进程粒度的运行管理，当然也包含了一个代码管理编译工具bazel

参考

• 自动驾驶系列：从Apollo1.0探索Apollo系统架构和代码设计
• 百度Apollo 1.0-7.0各版本框架概述
• Apollo 6.0发布！无人化自动驾驶迎来新篇章
• Apollo7.0 重磅发布，百度多款汽车机器人集体驶入元宇宙
• 节俭的百度：给自动驾驶阿波罗计划算个账（附Apollo技术框架）