Beta 解读｜【工程方向】更灵活的包管理2.0，更易于二次开发

Apollo Beta在8.0的基础上将工程进行了全面升级，Apollo 8.0我们首次引入软件包管理的概念，将Apollo各个模块进行了整理并以软件包的形式进行发布，优化了下载安装流程并提升了开发效率。

现在，Apollo 新版本Beta推出包管理2.0，将模块按照功能粒度拆分成更小的软件包，开发者可以根据需要自由选择组合。不仅如此，包管理2.0还在功能扩展方面做了优化和提升，大大提高了Apollo的二次开发能力。

一、Beta工程升级整体思路

Apollo 8.0将Apollo各个模块进行重新梳理，去掉了不合理的依赖关系，整合了通用的模块，使Apollo整体结构更清晰简洁。在Apollo 8.0的基础上，新版本Beta沿着更灵活组装自动驾驶应用和更便利地二次开发两个方向进行升级。

1.帮助开发者更灵活地组装自动驾驶应用

Apollo新版本Beta将模块按照功能的粒度拆分成更小的软件包，开发者可以更加方便地根据自己的需求选择使用。

2.更加容易地基于Apollo进行功能扩展

为了让开发者可以更容易地针对自己的场景来构建自动驾驶应用 ，Apollo Beta除了提供各种丰富的功能组件/插件之外，还在功能扩展方面做了提升和优化。具体来说，Apollo Beta优化后在以下三方面进行了升级。

2.1 统一调度接口 最快1天内即可完成场景Demo搭建

对于需要实现自定义调度逻辑的自动驾驶应用的扩展场景，Apollo Beta增加了统一的接口模块，并对已有的规划功能进行封装。一方面统一了接口功能使用方式，开发者基于接口进行开发，避免了逻辑的耦合，而且无需关注Apollo内部模块复杂的数据流拓扑实现；另一方面对这些接口进行了分类和简化，使得结构更加清晰，使用起来更加方便。

现在，开发者只需基于接口开发自己的调度模块即可实现自己应用场景的自动驾驶，最快在1天内就可以搭建好场景Demo。

2.2 简化调参方式 调参效率提升1倍

随着Apollo功能的不断丰富，相应地参数配置量也在不断地增加。为了降低开发者修改参数的难度，对于Apollo已经涵盖了功能，但需要针对具体应用调整参数配置的扩展场景，Apollo新版本Beta对参数配置管理和说明做了优化和补充：

• 增加了针对应用级别的增量参数配置管理。开发者可以按照不同的使用场景（不同的车或者不同的区域场景）来管理配置，并且在开发调试过程中可以快速切换；
• 将参数按全局和局部划分（全局参数是多个算法或插件中共同使用的参数，局部变量是专属于某个算法或插件的参数），让参数配置跟随作用的范围和功能，开发者可以更方便地找到功能的相关参数配置；
• 补充了更多关于参数的说明文档，以便于更好地理解其功能和用法。

基于以上优化和补充，在Apollo Beta中，开发者可以更加快速和容易地找到需要调整的参数配置，调参效率提升1倍以上。

2.3 新增插件机制 代码学习成本可降低90% 代码量降低50%

对于开发者需要添加自定义功能的扩展场景，Apollo Beta 设计了新的插件机制，并对感知、规划、控制等模块中常用的功能逻辑进行了插件化改造，提供可继承扩展的插件基类，开发者只需要学习重写基类接口就可以轻松实现功能的扩展，而无需了解模块完整的逻辑，代码学习成本降低可90%，代码量降低50%。

*Apollo 插件机制是一个比组件更加轻量化的动态加载机制，其目的是让开发者可以更加聚焦到功能逻辑上，更加方便地进行功能扩展。

二、PnC包管理2.0，方便可扩展

Planning模块框架比较复杂，代码量多，为了方便开发者学习和上手，并能快速根据自己的需求开发扩展功能，Planning在框架上进行了一些调整。

1.统一对外接口

Apollo新版本Beta中，PnC的接口统一封装在 external_command 模块处理，隔离了上层业务调用和PnC模块内部升级导致的接口变化，同时便于用户自定义扩展接口和底盘命令。

新版本Beta中对接口进行了优化和升级：

• 统一梳理和封装。调用接口时，命令统一转发到"ExternalCommandProcessor"模块。通过封装，当PnC内部模块接口升级时，可以保持外部命令接口不变。
• 改用cyber中service-client机制调用。用户可以通过client查询当前任务的执行状态。
• 对RoutingRequest的导航命令做了精简：1.原来的导航命令需要查询地图，找到路由点和终点最近的车道，并得到在车道上对应的投影点，精简后的命令只需要给出坐标和朝向即可。2.发送导航命令不再需要发送车辆当前的位置作为起点位置，PnC会自动获取并处理起点位置。

升级后的命令数据流程如下图：

升级前后命令功能保持不变，对照关系如下表所示：

升级后的接口有以下几个优点：

• 命令调用更清晰简便。新的导航接口精简了数据，开发者只需要设置必要的坐标和朝向信息即可。
• 使用service/client的调用方式。新的接口可以通过client获取命令执行的状态，包括正在执行中，已经完成和有错误发生。
• 新的接口支持开发者自定义扩展自己的命令。

2.全新插件扩展机制

插件是Beta中支持开发者灵活扩展新功能的一种方式，只要开发者新扩展的插件符合父类程序接口规范，就可以通过重写接口的方式来增加新的功能，插件以独立包的方式发布。

Beta在Planning中主要对scenario，task和traffic rules进行了插件化，开发者可以根据场景需要，自定义添加自己的场景、任务或交通规则。例如用户新增左转待转场景插件，增加一个包left_turn_waiting_zone，在这个包中添加左转待转场景的实现代码，以及相关的工程文件，编译调试后发布即可。

8.0中不使用插件的方式，开发者新增一个scenario、task或者traffic rules，需要修改Planning component流程代码，用于创建新的类型对象，添加新增对象的流程调用，还需要修改proto文件等，修改处较多，过程繁琐。并且后续apollo升级时，上述开发者新增的内容无法直接跟着升级，需要手动merge自己修改的代码。

Beta使用插件的方式扩展scenario，task，traffic rules，开发者：

• 只需根据自己的场景，使用包管理的方式，选择性下载安装自己需要的scenario，task，traffic rules即可。
• 新增的插件独立开发，编译，发布和运行。
• 新增了插件后，可以直接跟随apollo一起升级。

3.分级参数配置机制

Planning中的配置参数量较大，入门调试时难度较高，在8.0版本中开发者想要修改的功能对应的参数不直观，并且不易快速定位需要修改的参数位置。针对这些问题，对配置参数进行了以下调整：

• 将参数分成全局变量和局部变量，如果用户需要调整某个插件的参数，直接在插件的目录中查找。Planning的全部变量在planning/planning_base/conf目录下，局部变量在插件自身的目录下。具体修改后的主要参数分数可以参考相应技术文档。（全局变量是多个算法或插件中共同使用的参数；局部变量是专属于某个算法或插件的参数）
• 添加对常用功能使用到的参数的说明文档，方便用户调试时查询。

Beta将参数目录进行重新梳理和作用范围的划分后，一方面参数的目录跟随作用范围和功能，对参数的定位更清晰和直观；另一方面，开发者新增的插件所使用的参数，可以跟随插件进行发布和管理。

三、感知包管理2.0，灵活又统一

Apollo 8.0中，我们为开发者提供了一整套端到端的自动驾驶感知开发流程，Beta对感知流程做了更进一步优化，将感知框架从功能层面进行拆分，现在您可以根据自己的需求来制定专属的感知开发流程，同时优化了配置管理方式和流程。

1.功能组件拆分

针对感知，Apollo新版本Beta从功能层面将激光雷达、相机目标检测和红绿灯检测拆分为小的功能组件，每个组件功能更加内聚，开发者可以灵活的组合和定制不同的算法流程，来满足当前场景的需求，方便进行学习和二次开发。

如上图所示，Beta感知对lidar、camera目标检测、traffic_light检测做了框架重构，组件内部的结构和功能更简洁，入门和开发成本更低。此外，组件之间呈线性结构，依赖关系清晰，易于理解。

2.感知配置项优化

Apollo新版本Beta感知针对每个组件的配置和各个模块的公共配置做了统一管理，优化了传感器参数的设置。组件通过 PluginParam 配置功能或算法，在执行初始化时，经由参数将配置文件的路径和名称传递给初始化函数。Beta还提供了详细的参数说明与修改文档，方便开发者随时查阅修改。

3.提供两种感知开发模式

Apollo Beta感知包管理提供了组件开发、插件开发两种形式，开发者可以根据自身需要选择合适的方式进行感知开发。具体可以参考后续发布的开发案例。