Planning介绍
Planning 介绍
百度Apollo自动驾驶仿真平台9.0版本Planning模块相关内容
概述
1 运行流程
如下图所示，Planning模块的上游是Localization, Prediction, Routing模块，而下游是Control模块。Routing模块先规划出一条导航线路，然后Planning模块根据这条线路做局部优化，如果Planning模块发现短期规划的线路行不通（比如前面修路，或者错过了路口），会触发Routing模块重新规划线路，因此这两个模块的数据流是双向的。
2 原理
Apollo 规划模块功能的实现是基于场景（scenario-based）实现的，针对不同的场景，规划模块通过一系列独立的 任务（task） 组合来完成轨迹的规划。开发者可以根据自己的使用需求，调整支持运行的场景列表，或者场景中支持的任务类型来满足自己的需求。
Apollo 规划架构示意图如上，其中部分重要模块如下：
- 状态机（Apollo FSM（Finite State Machine））：一个有限状态机，结合导航、环境等信息确定自动驾驶车辆的驾驶场景
- 规划分发器（Planning Dispatcher）：根据状态机与车辆相关信息，调用合适当前场景的规划器
- 规划器（Planner）：结合上游模块信息，通过一系列的任务组合，完成自动驾驶车辆的轨迹规划
- 决策器 & 优化器（Deciders & Optimizers）：一组实现决策和优化任务的 task 集合。优化器用于优化车辆的轨迹和速度。决策器则基于规则，确定自动驾驶车辆何时换车道、何时停车、何时蠕行（慢速行进）或蠕行何时完成等驾驶行为。
3 功能列表
| 功能名称 | 功能描述 | 功能相关代码包 |
|---|---|---|
| lane follow | 车辆沿指令中的路由线路行驶，从地图中查询路由中的车道信息，规划沿车道线行驶的轨迹 | LaneFollowScenarioLaneFollowPath |
| nudge | 如果道路前方有静止或低速障碍物占据车道，但当前车道内还有足够空间，车辆可以在当前车道内绕过障碍物行驶。 | LaneFollowScenarioLaneFollowPath |
| lane change | 车辆沿RoutingResponse中的路由线路行驶的过程中，从一个车道切换到相邻车道。 | LaneFollowScenarioLaneChangePath |
| lane borrow | 如果道路前方有障碍物长时间停留阻塞道路，车辆无法通过在当前车道内绕过，需要往相邻车道借道，绕过当前障碍物。当车辆经过障碍物之后，车辆会立即回到原车道行驶。 | LaneFollowScenarioLaneBorrowPath |
| pull over | 当车辆接近终点时，可以通过配置选择是否在终点处靠边停车。如果使能终点靠边停车，车辆在终点附近查找一个可以停车的位置，并将车辆停在这个位置上。如果这个位置前后有其他障碍物，车辆可以通过OpenSpace的泊车算法，将车辆停在这个位置。 | PullOverScenarioPullOverPath |
| park and go | 如果车辆停车位置不在道路上，再次启动的时候，车辆会先从当前位置使用OpenSpace规划算法（如有必要）先行驶到车道线上，然后再正常沿道路行驶。 | ParkAndGoScenario |
| crosswalk | 当车辆行驶到人行道前时，如果有行人通过，车辆会停车等待行人通过后再通行。 | Crosswalk |
| bare intersection | 车辆行驶到无交通灯和停止标志的交通路口，因为对向车辆没有明确通行指示，所以需要车辆根据路口交通情况决定是否通行。 | BareIntersectionUnprotectedScenario |
| traffic light protected/unprotected | 车辆经过有红绿灯的交通灯路口时，如果交通灯有左转/右转通行箭头，车辆在红灯亮起时停止，绿灯亮起时通行；如果交通灯不是箭头指示灯，车辆在通过路口时可能还有对向车辆经过，这时就需要在通过路口前减速慢行，没有冲突时再通过路口。 | TrafficLightTrafficLightProtectedScenarioTrafficLightUnprotectedLeftTurnScenarioTrafficLightUnprotectedRightTurnScenario |
| stop sign | 当车辆前方有停止标志时，先停车观察，没有其他行人或车辆冲突时再通行。 | StopSignStopSignUnprotectedScenario |
| yield sign | 当车辆在没有交通灯的路口，有让行标志时，优先让其他对向车辆通行后自车再通行。 | YieldSignYieldSignScenario |
| keep clear area | 车辆经过Keep Clear Area区域时，不能在这个区域内停车。 | KeepClear |
| rerouting | 如果车辆在道路上被阻塞超出一段时间后，planning发出重新路由的请求以便脱困。 | Rerouting |
| valet parking | 给定地图上某一个停车位的id，车辆从当前位置导航到停车位，并泊车入库。 | ValetParkingScenario |
| emergency pull over | 在车辆行驶过程中，可以接收外部命令紧急靠边停车。 | EmergencyPullOverScenario |
4 最新9.0更新特性
（1）接口升级
在新版本中对这些接口进行了优化和升级：
- 统一梳理和封装，调用接口时，命令统一转发到”ExternalCommandProcessor”模块，通过封装，当PNC内部模块接口升级时，可以保持外部命令接口不变。
- 改用cyber中service-client机制调用，用户可以通过client查询当前任务的执行状态。
- 对RoutingRequest的导航命令做了精简：
- 原来的导航命令需要查询地图，找到路由点和终点最近的车道，并得到在车道上对应的投影点；精简后的命令只需要给出坐标和朝向即可。
- 发送导航命令不再需要发送车辆当前的位置作为起点位置，PNC会自动获取并处理起点位置。
升级后的命令数据流程如下图：
升级前后命令功能保持不变，对照关系如下表所示：
| 功能 | 升级前命令 | 升级后命令 | 升级说明 |
|---|---|---|---|
| 点到点沿道路行驶 | routing::RoutingRequest | LaneFollowCommand | 精简了路由点信息，新的命令给出坐标和朝向，不需要查询地图找到最近的LaneWayPoint |
| 泊车 | routing::RoutingRequest(包含parking_space_id) | ValetParkingCommand | 升级前后都是给定parking_space_id进行泊车 |
| PULL_OVER,START,STOP流程控制 | planning::PadMessage | ActionCommand | 升级后合并流程操作到一个命令中 |
| 切换自动/手动模式 | control::PadMessage | ActionCommand | 升级后合并流程操作到一个命令中 |
升级后的接口有以下几个优点：
- 命令调用更清晰简便，新的导航接口精简了数据，用户只需要设置必要的坐标和朝向信息即可。
- 使用service/client的调用方式，新的接口可以通过client获取命令执行的状态，查看命令是正在执行中，已经完成或有错误发生。
- 新的接口支持用户自定义扩展自己的命令。
（2）插件化
插件是新版本中的支持用户灵活扩展新功能的一种方式，用户新扩展的插件符合父类程序接口规范，通过重写接口的实现来增加新的功能，插件以独立包的方式发布。
在planning中主要对scenario，task和traffic rules进行了插件化，用户可以根据场景需要，自定义添加自己的场景，任务或交通规则，具体插件添加的方式后续文档中有详细的介绍。
例如用户新增左转待转场景插件，增加一个包left_turn_waiting_zone，在这个包中添加左转待转场景的实现代码，以及相关的工程文件，编译调试后发布即可。
需要运行这个场景时，在planning的配置文件中，添加这个场景的pipeline：
旧版本中不使用插件的方式，用户新增一个scenario，task，traffic rules，需要修改planning component流程代码，用于创建新的类型对象，添加新增对象的流程调用，修改proto文件等。这样的问题一个是修改处较多，修改过程繁琐；另外就是当用户在planning中增加了一个新的scenario，task，traffic rules时，后续apollo升级时，用户无法直接跟着升级，需要手动merge自己修改的代码。
使用插件的方式扩展scenario，task，traffic rules，可以实现：
- 用户根据自己的场景，使用包管理的方式，选择性下载安装自己需要的scenario，task，traffic rules即可。
- 用户新增的插件独立开发，编译，发布和运行。
- 用户新增了插件后，可以直接跟随apollo一起升级。
（3）参数配置升级
planning中的配置参数量较大，入门调试时难度较高，用户想要修改的功能对应的参数不直观，并且不易快速定位需要修改的参数位置。针对这些问题，对配置参数进行了以下调整：
- 将参数分成全局变量和局部变量，全局变量是多个算法或插件中共同使用的参数；局部变量是专属于某个算法或插件的参数。如果用户需要调整某个插件的参数，直接在插件的目录中查找。
planning的全部变量在planning/planning_base/conf目录下：
planning的局部变量在插件自身的目录下，如lane_change_path这个Task插件的参数：
添加对常用功能使用到的参数的说明文档，方便用户调试时查询。对参数目录进行重新梳理和作用范围的划分，有以下优点：
- 参数的目录跟随作用范围和功能，这样对参数的定位更清晰和直观。
- 用户新增的插件所使用的参数，可以跟随插件进行发布和管理。
