【百度Apollo】探索自动驾驶：Apollo 平台发布新版本 Beta 更灵活的包管理 2.0

引入

在现代软件工程中，软件包管理是至关重要的环节之一。合理的包管理系统可以极大地提高开发效率、降低开发成本，并且有助于代码的模块化和重用。为了进一步提升开发者的体验和开发效率，我们团队在 Apollo 平台的最新 Beta 版本中引入了一系列创新性的工程功能，其中最引人注目的就是全新的包管理 2.0 系统。本文将深入解读 Apollo 平台 Beta 版本中关于工程方向的更新，着重介绍了这一新功能的特性及其带来的益处。

一、背景

在过去的软件开发过程中，包管理往往是一个比较复杂且容易出现问题的环节。传统的包管理系统虽然能够满足基本的依赖管理和版本控制需求，但在面对复杂的项目结构和多样化的开发场景时，往往显得力不从心。开发者需要花费大量的时间和精力去处理依赖关系、解决冲突问题，并且常常会受限于包管理工具本身的局限性。

针对这一问题，我们团队对 Apollo 平台的包管理系统进行了全面升级，推出了全新的包管理 2.0 系统，旨在为开发者提供更灵活、更强大的包管理功能，以及更易于二次开发的工程环境。

二、新特性介绍

2.1 Apollo进行功能扩展

统一调度接口 最快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感知包管理提供了组件开发、插件开发两种形式，开发者可以根据自身需要选择合适的方式进行感知开发。具体可以参考后续发布的开发案例。

结语

包管理 2.0 系统是 Apollo 平台 Beta 版本中一个重要的工程功能更新，旨在为开发者提供更灵活、更强大的包管理功能，以及更易于二次开发的工程环境。通过优化依赖解析、升级版本控制、支持本地包管理和自定义包源等一系列创新性功能，新系统为开发者带来了更高效、更便捷的开发体验，助力他们更好地构建出色的软件产品。

在未来，我们将继续秉承“以用户为中心，持续创新”的理念，不断优化和完善 Apollo 平台的功能和服务，为广大开发者提供更优质、更全面的工程解决方案。