转自Apollo开发者社区

Apollo系统中的Planning模块实际上是整合了决策和规划两个功能，该模块是自动驾驶系统中最核心的模块之一（另外三个核心模块是：定位、感知和控制）。本章主要讲解自动驾驶系统中最核心的模块——决策规划模块。

下面是由社区开发者—强波提供的文章，对百度Apollo之决策规划模块进行详细讲解（Apollo 3.5之前版本），希望这篇文章能给感兴趣的开发者带来更多帮助。

下图是Apollo系统的整体架构图。从这幅图中我们可以看出，整个系统可以分为5层。从下至上依次是：

我们可以再将最核心的开放软件平台这一层放大近看一下。

下面这幅图描述了这其中的模块和它们之间的交互关系。

这其中的黄线代表了数据流，黑线代表了控制流。

Planning模块负责整个车辆的驾驶决策，而驾驶决策需要根据当前所处的地理位置、周边道路和交通情况来决定。Planning不直接控制车辆硬件，而是借助于控制模块来完成。

从上幅图中可以看出，对于Planning模块来说：

它的上游模块是：定位、地图、导航、感知和预测模块。 它的下游模块是控制模块。

决策规划模块的主要责任是：根据导航信息以及车辆的当前状态，在有限的时间范围内，计算出一条合适的轨迹供车辆行驶。

这里有好几个地方值得注意：

1、车辆的行驶路线通常由Routing模块提供，Routing模块会根据目的地以及地图搜索出一条代价尽可能小的路线。关于Routing模块在上期《入门必看丨解析百度Apollo自动驾驶平台》中详细讲解过，这里不再赘述。

2、车辆的当前状态包含了很多因素，例如：车辆自身的状态（包括姿态、速度、角速度等等），当前所处的位置，周边物理世界的静态环境以及交通状态等等。

3、Planning模块的响应速度必须是稳定可靠的（当然，其他模块也是一样）。正常人类的反应速度是300ms，而自动驾驶车辆想要做到安全可靠，其反应时间必须短于100ms。所以，Planning模块通常以10Hz的频率运行着。如果其中某一个算法的时间耗费了太长时间，就可能造成其他模块的处理延迟，最终可能造成严重的后果。例如：没有即时刹车，或者转弯。

4、“合适的轨迹有多个层次的含义。首先，”轨迹“不同于“路径”，“轨迹”不仅仅包含了行驶路线，还要包含每个时刻的车辆的速度、加速度、方向转向等信息。其次，这条轨迹必须是底层控制可以执行的。因为车辆在运动过程中，具有一定的惯性，车辆的转弯角度也是有限的。在计算行驶轨迹时，这些因素都要考虑。最后，从人类的体验上来说，猛加速、急刹车或者急转弯都会造成非常不好的乘坐体验，因此这些也需要考虑。这就是为什么决定规划模块需要花很多的精力来优化轨迹，Apollo系统中的实现自然也不例外。

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

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

Apollo 3.5中Planning模块的架构如下图所示：

这其中主要的组件包括：

有相关专业知识的人都会知道，决策规划模块的主体实现通常都是较为复杂的。

Apollo系统中的实现自然也不例外，这里先通过一幅图说明其整体的Pipeline。然后在下文中我们再逐步熟悉每个细节。

这里有三个主要部分需要说明：

PncMap：全称是Planning and Control Map。这个部分的实现并不在Planning内部，而是位于/modules/map/pnc_map/目录下。但是由于该实现与Planning模块紧密相关，因此这里放在一起讨论。该模块的主要作用是：根据Routing提供的数据，生成Planning模块需要的路径信息。 Frame：Frame中包含了Planning一次计算循环中需要的所有数据。例如：地图、车辆状态、参考线、障碍物信息等等。ReferenceLine是车辆行驶的参考线，TrafficDecider与交通规则相关，这两个都是Planning中比较重要的子模块，因此会在下文中专门讲解。 EM Planner：下文中我们会看到，Apollo系统中内置了好几个Planner，但目前默认使用的是EM Planner，这也是专门为开放道路设计的。该模块的实现可以说是整个Planning模块的灵魂所在。因此其算法值得专门用另外一篇文章来讲解。读者也可以阅读其官方论文来了解：《Baidu Apollo EM Motion Planner》（链接见文末）。

05基础数据结构

Planning模块是一个比较大的模块，因此这其中有很多的数据结构需要在内部实现中流转。

这些数据结构集中定义在两个地方：

proto目录下的文件如下所示：

我们在Routing模块讲解的文章中已经提到，通过proto格式定义数据结构好处有两个：

common目录下的头文件如下：

这里有如下一些结构值得我们注意：

在下文中大家会发现，Planning模块中有很多处的逻辑是通过配置文件控制的。通过将这部分内容从代码中剥离，可以方便的直接对配置文件进行调整，而不用编译源代码。这对于系统调试和测试来说，是非常方便的。

Apollo系统中，很多模块都是类似的设计。因此每个模块都会将配置文件集中放在一起，也就是每个模块下的conf目录。

Planning模块的配置文件如下所示：

这里的绝大部分文件都是.pb.txt后缀的。因为这些文件是和上面提到的proto结构相对应的。因此可以直接被proto文件生成的数据结构读取。对于不熟悉的读者可以阅读Protocal Buffer的文档：《google.protobuf.text_format》（链接见文末）。

读者暂时不用太在意这些文件的内容。随着对于Planning模块实现的熟悉，再回过来看这些配置文件，就很容易理解每个配置文件的作用了。下文中，对一些关键内容我们会专门提及。

Apollo 3.5废弃了原先的ROS，引入了新的运行环境：Cyber RT。

Cyber RT以组件的方式来管理各个模块，组件的实现会基于该框架提供的基类：apollo::cyber::Component。

Planning模块自然也不例外。其实现类是下面这个：

在PlanningComponent的实现中，会根据具体的配置选择Planning的入口。Planning的入口通过PlanningBase类来描述的。PlanningBase只是一个抽象类，该类有三个子类：

PlanningComponent::Init()方法中会根据配置选择具体的Planning入口：

目前，FLAGS_open_space_planner_switchable和FLAGS_use_navigation_mode的配置都是false，因此最终的Planning入口类是：StdPlanning。

下面这幅图描述了上面说到的这些逻辑：

所以接下来，我们只要关注StdPlanning的实现即可。在这个类中，下面这个方法是极其重要的：

方法的注释已经说明得很清楚了：这是Planning模块的主体逻辑，会被timer以固定的间隔调用。每次调用就是一个规划周期。

很显然，接下来我们重点要关注的就是StdPlanning::RunOnce方法的逻辑。该方法的实现较长，这里就不贴出代码了，而是通过一幅图描述其中的逻辑：

请读者尽可能仔细的关注一下这幅图，因为它涵盖了下文我们要讨论的所有内容。

在最新的Apollo源码中，一共包含了5个Planner的实现。它们的结构如下图所示：

每个Planner都会有一个字符串描述的唯一类型，在配置文件中（见下文）通过这个类型来选择相应的Planner。

这5个Planner的说明如下表所示：

RTKReplayPlanner基于录制的轨迹，是比较原始的规划器，所以不用多做说明。最新加入的两个规划器（NaviPlanner和OpenSpacePlanner）目前看来还需要更多时间的验证，我们暂时也不会过多讲解。

Apollo公开课里对两个较为成熟的Planner：EM Planner和Lattice Planner做了对比，我们可以一起来看一下： 后面的内容中，我们会尽可能集中在EM Planner算法上。对于Lattice Planner感兴趣的读者可以继续阅读这篇文章：《Lattice Planner规划算法》（链接见文末）。

Planner的配置文件路径是在planning_gflags.cc中指定的，相关内容如下：

接下来我们可以看一下planning_config.pb.txt中的内容：

这里设置了两个Planner，最终选择哪一个由下面这个函数决定：

open_space_planner_switchable决定了是否能够切换到OpenSpacePlanner上。但目前这个配置是false：

PublicRoadPlanner是目前默认的Planner，它实现了EM（Expectation Maximization）算法。

Planner的算法实现依赖于两个输入：

在Frame中有一个数据结构值得我们重点关于一下，那就是LocalView。这个类在前面我们也已经提到过。它的定义如下：

从这个定义中可以看到，这个结构中包含了这些信息：

每个Planner来说，其主要的逻辑都实现在Plan方法中。PublicRoadPlanner::Plan方法的实现逻辑如下：

这段代码的几个关键步骤是：

Scenario是Apollo 3.5上新增的驾驶场景功能。前面在模块架构中我们已经提到过，接下来我们就详细看一下这方面内容。

Apollo3.5聚焦在三个主要的驾驶场景，即：

车道保持

车道保持场景是默认的驾驶场景，它不仅仅包含单车道巡航。同时也包含了：

Side Pass

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

停止标识

停止标识有两种分离的驾驶场景：

1、未保护：在这种情况下，汽车预计会通过具有双向停车位的十字路口。因此，我们的ADC必须爬过并测量十字路口的交通密度，然后才能继续走上它的道路。

2、受保护：在此场景中，汽车预期通过具有四向停车位的十字路口导航。我们的ADC将必须对在它之前停下来的汽车进行测量，并在移动之前了解它在队列中的位置。

场景的实现主要包含三种类：

所有场景都是通过配置文件来进行配置的。很显然，首先需要在proto文件夹中定义其结构。

其内容如下所示：

这里定义了ScenarioConfig结构，一个ScenarioConfig中可以包含多个StageConfig。

另外，Stage和Scenario都有一个Type字段，它们的定义如下：

前面我们已经提到，ScenarioManager负责场景的注册。实际上，注册的方式就是读取配置文件：

配置文件在上文中已经全部列出。很显然，这里读取的配置文件位于/modules/planning/conf/scenario目录下。

下面这个函数用来确定当前所处的场景。前面我们已经说了，确定场景的依据是Frame数据。

这里面的逻辑就不过多说明了，读者可以自行阅读相关代码。

场景的配置文件都位于/modules/planning/conf/scenario目录下。在配置场景的时候，还会同时为场景配置相应的Task对象。关于这部分内容，在下文讲解Task的时候再一起看。

大家最熟悉的坐标系应该是横向和纵向垂直的笛卡尔坐标系。但是在自动驾驶领域，最常用的却是Frenet坐标系。基于Frenet坐标系的动作规划方法是由BMW的Moritz Werling提出的。

之所以这么做，最主要的原因是因为大部分的道路都不是笔直的，而是具有一定弯曲度的弧线。

在Frenet坐标系中，我们使用道路的中心线作为参考线，使用参考线的切线向量t和法线向量n建立一个坐标系，如上图的右图所示，它以车辆自身为原点，坐标轴相互垂直，分为s方向（即沿着参考线的方向，通常被称为纵向，Longitudinal）和d方向（即参考线当前的法向，被称为横向，Lateral），相比于笛卡尔坐标系（上图的左图），Frenet坐标系明显地简化了问题。因为在公路行驶中，我们总是能够简单的找到道路的参考线（即道路的中心线），那么基于参考线的位置的表示就可以简单的使用纵向距离（即沿着道路方向的距离）和横向距离（即偏离参考线的距离）来描述。

下面这幅图描述了同样一个路段，分别在笛卡尔坐标系和Frenet坐标系下的描述结果。很显然，Frenet坐标系要更容易理解和处理。

下面这幅图是Apollo公开课上对于Planning模块架构的描述。

从这个图上我们可以看出，参考线是整个决策规划算法的基础。从前面的内容我们也看到了，在Planning模块的每个计算循环中，会先生成ReferencePath，然后在这个基础上进行后面的处理。例如：把障碍物投影到参考线上。

在下面的内容，我们把详细代码贴出来看一下。

ReferenceLine由ReferenceLineProvider专门负责生成。这个类的结构如下：

ReferenceLine是在StdPlanning::InitFrame函数中生成的，相关代码如下：

在ReferenceLine之外，在common目录下还有一个结构：ReferenceLineInfo，这个结构才是各个模块实际用到的数据结构，它其中包含了ReferenceLine，但还有其他更详细的数据。

从ReferenceLine到ReferenceLineInfo是在Frame::CreateReferenceLineInfo中完成的。

ReferenceLineInfo不仅包含了参考线信息，还包含了车辆状态、路径信息、速度信息、决策信息以及轨迹信息等。Planning模块的算法很多都是基于ReferenceLineInfo结构完成的。例如下面这个：