百度Apollo7.0 规划算法框架解析

本文来源：智车科技

／ 导读 ／

本篇文章想和大家分享一下Apollo7．0最新的规划算法。由于Apollo的planning整体代码都相当庞大，一开始还是理清其框架，再分算法块逐个击破这样效果更好。

这篇文章希望能带领读者理清planning的整体框架，梳理数据流，以主要场景为例，一直分析到task （apollo planning 的主要算法所在处）逻辑前的准备工作、输入如何构造的，之后再深入看task内部的细节也更容易理解。

特别注意，本文中的流程图均为作者花费了大量时间梳理而来，以便读者能够更易理解planning的整体框架，抓住重点不被细节带跑偏。

1

planning 的输入输出

读懂一个模块，首先必然是了解其的上下游，即输入输出是什么。熟悉Apollo CyberRT框架的小伙伴都知道在该框架下，输入输出由Reader和Writer构成，并定义在每个模块的component文件中。除此之外，CyberRT框架定义了两种模式，分别为消息触发和时间触发，而planning中采用的为消息触发，因此必须接到特定的上游消息后，才会进入内部主逻辑，而消息触发的上游消息，定义为component中Process（）函数的入参。

因此总结来看，planning的上下游关系总结为下图：

这里再重复一下，planning的输入分为Reader和Process（）入参的原因在于，planning依赖于Process（）的三个上游输入，只有同时接到这三个输入，才会触发planning的主逻辑，即是planning正常启动的必要条件。而Reader则不是，其中部分上游还依赖于配置参数是否打开，具体可以查看Apollo的源码。planning的输出就比较简单了，主要是给控制的ADCTrajectory数据，包含了一条带时间、速度的轨迹点集，具体的格式定义可以查看对应的proto文件。

2

planning 整体框架

上面两张流程图是我整理的Apollo规划算法的框架，整体框架和之前并无太大变化。主框架分为两个线程，子线程ReferenceLineProvider以20HZ的频率运行，用于计算planning中最重要的数据结构reference＿line；主线程上还是基于场景划分的思路，多数场景下还是采用基于ReferenceLine的规划算法，对于泊车相关场景，则利用open space算法。目前Apollo的场景划分为了16种，在proto文件中可以查看到。在Apollo 7．0中，新增了deadend＿turnaround场景，用于无人车遇到断头路时，采用openspace的方法进行调头的轨迹规划，后续我会详细看一下里面的算法实现细节。