Apollo各模块分析

百度的Apollo是国内著名的开源无人驾驶解决方案项目，其主要由商用版本ROS构成，具体组件分为：

1. 定位
2. 感知
3. 预测
4. 路由
5. 规划
6. 控制
   

定位

Apollo是基于高精地图的解决方案，所以重定位，定位也分很多种，该模块主要是提供定位服务，默认下的情况一般有两种方法，
1.基于GPS和IMU融合后的信息再进行RTK校准，可以得到一个厘米级误差的定位信息，定位信息包含航向角、速度、加速度、经纬度、UTM等等。
2.基于GPS、IMU融合激光雷达点云地图的激光定位法，通过基本的GPS和IMU，再配合激光点云图，通过激光雷达进行激光定位，或者相同原理进行视觉SLAM定位，是主流的无人驾驶定位方法之一。
其输入主要有：
输入：
GPS-全球定位系统。
IMU-惯性测量单元。
或者：
GPS-全球定位系统。
IMU-惯性测量单元。
激光雷达-光探测与测距传感器、camera等等。

感知

通过该模块，我们可以利用当下很流行的ＮＮ网络来获取无人驾驶中一系列的障碍物信息、红绿灯等等外部信息，只有拥有了这些外部信息，我们才可以进一步的对当前车辆的状态进行判断和控制，决策出下一帧　无人车应该进行怎么样的动作，以保障驾驶的安全性并顺利到达目的地。
输入:
1、camera传入的视频信息
2、激光雷达、毫米波雷达、超声波等等
输出：
1、带有分类、速度、航向角、位置等信息的障碍物列表、红绿灯信息等等。

预测

预测模块从感知模块接收障碍物，其基本感知信息包括位置、方向、速度、加速度，并生成不同概率的预测轨迹。该模块其实相当重要，这里管理了所有的障碍物的信息和相关的时空推理，能够从该模块轻易的获取到当前甚至几秒钟之后的障碍物信息等等。所以也叫作轨迹预测。
输入：
1.障碍物
2.定位
输出：
具有预测轨迹的障碍物，或者具有预测能力的障碍物列表。
具体主要分为三块，分别是：

容器

容器存储来自订阅通道的输入数据。目前支持的输入是感知模块的障碍物，车辆定位和车辆规划。

评估器

评估器对任何给定的障碍分别预测路径和速度。评估器通过使用存储在prediction/data/模型中的给定模型输出路径的概率来评估路径（车道序列）。

将提供三种类型的评估器，包括：

成本评估器：概率是由一组成本函数计算的。

MLP评估器：用MLP模型计算概率

RNN评估器：用RNN模型计算概率

预测器

预测器生成障碍物的预测轨迹。当前支持的预测器包括：

空：障碍物没有预测的轨迹
单行道：在公路导航模式下障碍物沿着单条车道移动。不在车道上的障碍物将被忽略。
车道顺序：障碍物沿车道移动
移动序列：障碍物沿其运动模式沿车道移动
自由运动：障碍物自由移动
区域运动：障碍物在可能的区域中移动

路由

路由模块其实是高精地图延伸出来的延伸模块，该模块基于高精地图生成全局的导航信息，主要依赖于高精地图、起始点、终点。一般利用A*算法或者Djstela算法来进行计算，但是一般还会考虑各种权重、路口拥堵等等，这里可以看做是高精版的高德地图或者百度地图。
输入：
地图数据
路由请求（开始和结束位置）
输出：
路由导航信息（navigation）

规划

Apollo的之前版本，包含3.0都是用了相同的配置和参数规划不同的场景，这种方法虽然线性且实现简单，但不够灵活或用于特定场景。随着Apollo的成熟并承担不同的道路条件和驾驶用例，我们认为有必要采用更加模块化、适用于特定场景和整体的方法来规划其轨迹。

在这个方法中，每个驾驶用例都被当作不同的驾驶场景。这样做非常有用，因为与先前的版本相比，现在在特定场景中报告的问题可以在不影响其他场景的工作的情况下得到修复，其中问题修复影响其他驾驶用例，因为它们都被当作单个驾驶场景处理。
针对具体的驾驶场景，Apollo3.5主要是聚焦在以下三种场景：

驾驶场景

车道保持 - 默认（keeplane）

车道保持场景（我们的默认驾驶场景）包括但不限于在单车道（如巡航）或换道行驶，遵循基本的交通约定或基本转弯。

Side Pass

也就是超车变道，在这种情况下，如果在自动驾驶车辆（ADC）的车道上有静态车辆或静态障碍物，并且车辆不能在不接触障碍物的情况下安全地通过车道，则执行以下策略：

1、检查邻近车道是否接近通行
2、如果无车辆，进行绕行，绕过当前车道进入邻道
3、一旦障碍物安全通过，回到原车道上

停止标识

停止标识有两种分离的驾驶场景：
1、未保护：在这种情况下，汽车预计会通过具有双向停车位的十字路口。因此，我们的ADC必须爬过并测量十字路口的交通密度，然后才能继续走上它的道路。
2、受保护：在此场景中，汽车预期通过具有四向停车位的十字路口导航。我们的ADC将必须对在它之前停下来的汽车进行测量，并在移动之前了解它在队列中的位置。
为了安全地通过受保护和未受保护的停止标志，执行逻辑如下：
1、到达停车标志处：感知正等待在其他停车标志处的所有汽车或障碍物；
2、完全停止：Monitor检查之前停在其他停车标志处的汽车是否已经移动。以前到达的汽车必须全部离开；
3、稍微向前移动(爬行)：检查是否有其他车辆正在移动或在无保护停车的情况下，检查车道两侧是否有迎面而来的车辆
4、安全通过十字路口

Planning模块架构

Apollo 3.5 Planning模块的架构已经改变，以反映我们针对不同驾驶场景的模块化方法。

如下图所示，在规划器中，是上面讨论的各个驾驶场景及其处理逻辑。

每个驾驶场景都有其独特的驾驶参数集，这些参数使该场景更安全、高效、更易于定制和调试，并且更加灵活。每个阶段可配置的，且被划分为 任务，并且可以通过编辑该场景的config文件来移动或创建每个任务。

部分重要特性包含如下：

Apollo FSM（finite state machine）:一个有限状态机，与高清地图确定车辆状态给定其位置和路线。
Planning Dispatcher: 根据车辆的状态和其他相关信息，调用合适的Planner
Planner:获取所需的上下文数据和其他信息，确定相应的车辆意图，执行该意图所需的规划任务并生成规划轨迹。它还将更新未来作业的上下文。
Deciders & Optimizers :一组实现决策任务和各种优化的无状态库。优化器特别优化车辆的轨迹和速度。决策者是基于规则的分类决策者，他们建议何时换车道、何时停车、何时爬行(慢速行进)或爬行何时完成。
黄色框：这些框被包含在未来的场景和/或开发人员中，以便基于现实世界的驱动用例贡献他们自己的场景

控制

该模块主要是无人驾驶功能代码和车控信息的交汇处，通过该模块可以通过车控接口对车辆下发车控请求，例如转动方向盘、加速、减速、油门、刹车、转向灯、喇叭等等。
此外该模块目前主要采用的方法有 PID、模糊PID、MPC等等。看上去这和自动化相关性很大，但其实上的确如此，这本质上其实就是对车辆状态的控制。
输入：
规划轨迹
车辆状态
定位
Dreamview自动模式更改请求
输出：
给底盘的控制指令（转向，节流，刹车）。（这里的输出是给了车辆的底盘或者对应的ECU，这里已经不再是无人驾驶控制代码的事情了，而是汽车内部的处理流程，对于无人驾驶这块来说，我们可以暂时将其看作是黑盒，对于这些车辆或者Tire1 Tire2供应商更加熟悉，我们无需过多关注）

最后

以上就是认真绿草为你收集整理的Apollo各模块分析Apollo各模块分析的全部内容，希望文章能够帮你解决Apollo各模块分析Apollo各模块分析所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。