【编者按】Apollo开放平台在业界的影响力与开发者易用性的问题形成反差，其本质是影响力为主的社区价值与使用体验为主的产品价值之间存在着差距。那么，该如何提升开发者在开源自动驾驶平台上的技术开发体验？通过长期基于Apollo开放平台的实践，本文作者给到他的解答。
作者 | 胡旷、王方浩 责编 | 杨阳
出品 | 《新程序员》编辑部
当前，汽车工业正进入新一轮科技革命和产业变革中，自动驾驶正成为新的技术制高点，国内外传统车企和科技公司纷纷布局。十年前，百度便开始了自动驾驶相关研发投入。2017年，Apollo计划正式宣布。
经过六年建设，Apollo开源项目在GitHub上获得的Star数超过2.3万，在社区中也备受欢迎。然而，自动驾驶系统本身的复杂性和Apollo开源代码的工程庞大，导致Apollo的使用门槛很高。对于基础开发者来说，从基础安装、使用到开发调试，开发者都可能会碰到各种问题。而对于高阶开发者，由于Apollo系统与Robotaxi场景的深度耦合，开发者如果期望在其他场景直接复用，门槛也很高。更多时候，开发者只是参考Apollo工程算法实现之后再移植到自身系统。
为了更好地系统化解构和量化易用性问题，我们从以往侧重技术模块的角度转换为侧重不同类型技术开发者使用场景的角度来重塑产品，并参考内外部优秀开源社区经验，采用NPS（Net Promoter Score，净推荐值）、开发者深度访谈、工具链使用量等工具来系统获取开发者反馈，并以此作为衡量易用性的参考指标。
开发者使用场景
根据不同类型技术开发者差别，把开发者使用场景大致分为以上机仿真开发调试为主的规划控制仿真开发调试场景和感知仿真开发调试场景，以上车调试为主的车辆适配与集成场景和实车路测与调试场景。通过场景分类，我们可以更好地理解开发者需求，并从中找到共性需求与理解差异性需求。
开发者调研
从2022年上半年开始，我们进行了社区的第一次NPS调研，并形成了半年一次的面向所有开发者的例行反馈机制。表1是2022年上半年第一次NPS调研的数据，Apollo整体NPS极高，但感知和PnC（规划与控制）的开发体验NPS极低。这也进一步印证了我们对于Apollo社区价值与产品价值差距的认知。
表1 2022年上半年NPS数据
同时，在每次发版前，我们会进行alpha内测与beta公测，针对不同使用场景的开发者形成SIG（Special Interest Group，特别兴趣小组）来定向获取反馈，如图1的感知场景开发者访谈记录。
图1 感知仿真开发调试场景SIG调研反馈
此外，我们定期与社区布道师进行深度访谈来进一步收集意见与建议。通过这些方式，我们期望深度切入开发者痛点，切实解决开发者使用中的各种问题，让小白开发者从入门到精通，帮助资深开发者快速从0到1，提升效率。
通过基于场景的分类和多方位的开发者反馈收集，我们梳理了四类核心问题。首先，是如何高效复用工程能力？Apollo工程庞杂且与Robotaxi场景耦合较深，如何能快速基于Apollo的核心能力扩展应用到其他场景？需要更灵活方便的发布机制来支撑；第二，如何快速验证新的算法模型，满足各种差异化应用场景落地对于算法模型的需求，或是满足科研领域对于新型算法的探索；第三，如何提升开发调试效率？工欲善其事必先利其器，目前Apollo工具偏向整车应用场景，而非个人开发调试场景。开发个人开发者工具，缩小与个人开发者需求之间的差距同样非常重要。最后，如何降低学习曲线？提供符合开发者学习习惯的内容与产品，缩短开发者学习过程是提升产品价值不可或缺的部分。
接下来，我们将基于以上四点，详细介绍最新发布的Apollo开放平台8.0在工程技术、算法模型、开发工具、知识学习等方面可以为开发者带来哪些价值应用。
高效复用平台能力——包管理升级
Apollo软件包管理的主要目标是将自动驾驶系统的编译产出按照“模块”粒度进行规范化组织，一方面支持直接使用产出包的方式使用组件，另一方面规范组件的依赖关系以及组件的粒度，从而降低组件的使用/复用难度，提升自动驾驶系统的的研发效率。
Apollo的源码是基于Bazel进行构建的，其优劣势都很明显，一方面得益于Bazel先进的并行编译速度，70W+行的源码可以在1小时内完成整体编译。另一方面受限于Bazel的单源码树的限制，Apollo模块之间无法使用二进制的方式进行依赖。Bazel包支持嵌套依赖，导致Apollo模块之间的依赖关系极其复杂，很难单独使用一个或者几个模块。
因此，Apollo包管理将基于Bazel进行扩展，主要规范构建产出（以及部分源码）内容，并配套相关工具，让Apollo的模块可以通过二进制的方式引入复用，因此本文介绍的概念和术语主要是针对Apollo的构建产出。
此外，Apollo的包目前对Bazel工程的支持将优先于CMake工程，但是Apollo包最终将制作成标准的DEB包，可以安装在Ubuntu操作系统上，也可以作为普通的系统包在CMake工程下使用。
包管理的整体框架介绍
Apollo的软件包管理是一系列工具的集合，覆盖整个软件包的整个生命周期，如图2所示。
图2 Apollo包管理框架
其中包含如下模块：
RepoServer是软件包的云端仓库，存储包实体（即deb包）与包的索引。具体实现是采用静态网站服务结合CDN加速技术实现高速、高可用的文件下载服务。
LocalRepo即软件包的本地仓库，是一个基础的本地文件系统，按照标准的文件系统规范存储包的内容，其中即包含从远程仓库下载安装的deb包，也包括本地工程构建产出的Local版本软件包。该本地仓库中存储的内容有两方面作用，一是在Apollo系统运行时提供动态链接库，另外也是在Apollo组件编译时提供依赖库。
Buildtool是使用软件包作为扩展组件依赖时的配套构建工具。Apollo使用Bazel作为构建系统，所以推荐扩展组件也使用Bazel进行构建，Bazel在云端编译、缓存等技术上有很大的优势。而Buildtool目前的底层也是基于Bazel的（未来可以考虑支持CMake等多种编译系统）。
Buildtool的核心作用是将Apollo的软件包作为编译依赖加到bazel构建体系中，而且尽量简化使用复杂度。众所周知，将动态库加到Bazel的依赖体系中是比较繁琐的，首先需要安装动态库，虽然Bazel中可以使用http_archive进行下载包，但是一般情况下还是会使用Apt等工具在操作系统中先安装好动态库。紧接着需要使new_local_repository创建一个repository并且提供一个BUILD文件,其中包含cc_library。
在依赖包存在相互依赖的情况下,需要自行梳理版本防止依赖冲突。Buildtool通过依赖版本分析、自动拉取依赖包、自动生成repository配置、自动处理级联依赖等功能配合包描述文件(cyberfile.xml),可以让上述繁琐过程对使用者透明，只需要在包描述中声明一个依赖即可。Buildtool的第二个作用是支持源码方式使用Apollo的软件包。C++使用二进制作为依赖一直存在ABI等问题难以解决，所以在Apollo的软件包中将源码也作为标准内容，Buildtool支持将包的源码自动引入到使用者的工作空间下参与编译，与此同时Buildtool也将多个源码包的编译顺序纳入管理。
除了在构建中使用Buildtool下载安装使用，也可以使用Apt等工具直接安装使用，例如在使用Dreamview播放Record文件的场景下我们不需要从头编译Apollo工程，只需要使用apt installapollo-neo-dreamview-dev，将dreamview以及其依赖按照到本地就可以来播放数据包回看数据了。
软件包管理的各个组成部分已经介绍完了。可以看出其全部功能都跟无人驾驶系统本身没有关系，那它对于Apollo的发展有什么作用呢？Apollo开源项目是一整套完整的无人驾驶系统，但是由于业务场景不同，具体分场景下开发者不会直接部署一整套项目，而是从中选取适合自己的功能、算法等内容放到自己的项目中使用。
而目前Monolithic Repository的组织结构，各个功能组件之间存在耦合，要抽离出来单独使用的成本很大，所以很多开发者会自己再重新实现一份代码。但这样不但浪费开发者的时间成本，也会导致开发者的扩展内容无法进行贡献。
有了软件包管理后，一方面先进技术可以按照功能模块的粒度以二进制库（或者源码）的方式被开发者直接使用，同时也为开发者提供了更轻量级并且和Apollo庞大的单体源码解耦的方式来共享自己的扩展能力，即按照Apollo软件包的规范开发/发布自己的软件包，为Apollo自动驾驶系统生态的健康发展奠定了基础。
快速验证新的模型——从感知框架重构开始
随着深度学习技术的不断发展，自动驾驶感知领域在近几年取得了显著进展。由于深度学习模型的更新速度非常快，每年都会涌现新的模型，因此如何快速发布和验证模型成为自动驾驶感知中的关键问题。同时，我们注意到大部分社区开发者更关注模型本身。而Apollo作为全栈感知框架，除了模型本身（即算法部分），还包括任务框架。目前常见的任务包括红绿灯检测、车道线检测和目标检测。为了使算法开发人员从框架中解放出来，更加专注于算法本身，我们升级了Apollo 感知框架，实现了算法和框架的解耦（见图3、图4）。
图3 升级前的Apollo感知框架
图4 升级后的Apollo感知框架
训练好的模型只需根据要求便可灵活接入，无需开发大量代码。同时，还引入了测试验证工具链，支持端到端的模型验证，从而极大地加快感知算法落地速度。针对框架部分，我们根据不同的任务流水线，通过配置便可复用提供好的模块。这样，用户只需根据配置，即可满足感知任务的开发需求。
通过以上两项升级，我们成功解耦感知模块的算法开发和任务流水线，从而加快感知模块的验证和迭代速度，显著提升开发效率。现在，最快上线一个模型只需1-2天。
模型
通过引入Paddle3D，不仅能够提供更多模型支持，还能提供一整套完备的训练工具。同时，我们通过定期和Paddle3D合作组织自动驾驶感知方向的比赛，跟进最新的模型，保证Apollo感知算法的领先性。
通过与Paddle3D的深度合作，我们建立了自动驾驶感知任务的基准，并开放了模型训练和部署代码。开发者可以在社区找到最新的模型进行对照使用，或自行进行二次开发。
框架
第二个比较大的改造在于框架的升级。之前的感知模块，各个任务和模块的区分度不高，主要是通过传感器来组织目录文件。导致用户在了解某一部分的功能时需要深入到整个模块，并且整个流水线的配置相对分散，用户修改时需要从不同的配置文件中进行修改，这对用户来说体验不好。
进行框架升级后，我们根据任务流水线创建了不同的组件，引入了组件的概念。通过不同的前处理、后处理等组件，用户只需通过一个配置文件选择不同的组件即可实现新的流水线的引入和开发，从而使模型引入更加顺畅。
提升开发调试效率——完善工具链
自动驾驶与传统互联网软件研发不同，一是实车测试成本高，二是数据量非常大。而一套能够满足自动驾驶开发流程需求，并提升研发效率的研发基础设施就非常之重要。Apollo从1.0版本开始便开创性地引入了“车+云”的自动驾驶研发迭代模式，并对外发布了Apollo数据平台。它通过云端的方式解决了数据利用效率的问题，通过与仿真结合降低了实车测试成本，能够极大提升基于Apollo的自动驾驶研发效率（见图5）。
图5 “车+云”的自动驾驶研发迭代模式
“车+云”的自动驾驶研发迭代模式为基于Apollo的上车集成调试提供了技术迭代基础设施保障，能高效支持自动驾驶技术路测，从而实现上车闭环验证。与此同时，开发者在上车验证之前的本地开发调试也是整个自动驾驶研发迭代生命周期中同样至关重要的一环，但这部分需求在之前的Apollo版本中并未被很好满足。如何提升开发者本地开发调试效率，从自动驾驶研发迭代全生命周期角度提升研发效率是Apollo开放平台在开发者易用性上的又一个重点工作。
从流程图（图6）可以看出，自动驾驶研发流程其实包含了两个迭代循环，一个是模型迭代，一个是代码迭代，都通过数据来驱动。数据驱动的模型配置迭代，其主要包括服务于自动驾驶车辆集成（如车辆标定、传感器标定、控制评测等）、模型训练的研发云服务。通过在车辆端的智能数据采集器采集数据，驱动云端工具服务生成车辆模型配置，并OTA至车端完成迭代闭环。数据驱动的代码迭代，其主要包括服务于开发调试和回归测试的Apollo仿真云服务。Apollo仿真云服务提供了可自定义并下载至开发机本地的仿真调试场景，以及云端大规模集群并发测试能力。其通过持续车端数据采集丰富仿真场景，驱动代码不断改进并验证，最终OTA至车端实现代码迭代闭环。
图6 自动驾驶研发生命周期
在开发者调试效率方面，本次8.0版本主要新增了如下新能力，PnC调试效率提升了1倍以上。
支持本地仿真调试：提供基于Dreamview的本地仿真容器，支持本地PnC仿真调试。开发者在本地通过Dreamview的仿真器可模拟车辆行驶以及再现各种场景。
便捷仿真场景管理：提供基于云端的仿真场景自定义创建、编辑与分组管理，一键从云端下载场景、动力学模型、数据包至本地Dreamview。仿真场景同步支持云端仿真评测与本地调试两种使用场景（见图7）。
图7 基于Dreamview的本地仿真调试
降低学习曲线——Apollo Studio全新学习社区
解决了技术工程、工具产品上的易用性问题，同样还需要配套的学习资源服务来降低开发者的学习曲线。基于冰山模型理论，个人能力是先由知识、技能再逐步转化成能力的。提供符合开发者学习习惯的知识内容与产品功能，缩短开发者学习过程是提升Apollo开放平台产品价值不可或缺的部分。因而，在去年8月份，我们上线了全新的Apollo开放平台技术社区官网Apollo Studio。Apollo Studio社区以全新的Apollo 开源工程和工具链为基础支撑，帮助开发者通过由浅入深的课程内容来学习自动驾驶知识，通过与课程内容配套的实验来锻炼技能，最后通过竞赛测验来提升解决问题的能力。
目前，Apollo Studio已经提供了从入门到基础，再到专项的梯度课程，包括Apollo新人之旅、Apollo自动驾驶基础课、Apollo PnC专项课等。总课时达到近200。5个月时间，课程播放量便超过了100万次。与课程配套的实验也深受开发者好评，使用量近10万。赛事测验系统有效支撑了2022 Apollo城市道路自动驾驶仿真赛，吸引了全国近200所高校的500多支队伍2000多人参赛。
Apollo Studio为开发者提供了集课程、实训、赛事三位一体的自动驾驶学习实践社区，助力开发者成长。
总结
从自动驾驶能力到开发者易用性，Apollo开放平台持续进行多维度创新。
Apollo开放平台8.0通过引入包管理为彻底解耦发布流程中模块间的依赖打好了基础，为各类不同需求开发者直接复用扩展Apollo能力提供了灵活空间。
通过重构感知框架和开放模型训练环节，极大降低了扩展新模型时在训练、部署以及验证环节的成本，让开发者将更多精力放在新模型的能力上。
通过引入基于Dreamview的本地仿真调试并与云端仿真联动，极大提升了开发者在规划控制开发调试时的效率。
通过全新上线的Apollo Studio社区，为开发者提供了符合学习习惯的课程、实验与能力测试工具，助力开发者学习成长。
在今年上半年的NPS调研中，我们也收到了开发者的正向反馈，感知开发调试、PnC开发调试、社区的NPS都大幅上涨（见表2）。
表2 2023年上半年NPS结果
在8.0版本之后，我们将持续加强Apollo开放平台的开发者使用体验：优化核心层感知模块和规划模块的包逻辑拆分，以更好地满足开发者的二次扩展开发需求，并在原有的Robotaxi场景上提供更多其他可选场景支持，以实现场景应用层的灵活选择（见图8）。
图8：Apollo开源代码架构
在工具链上，我们将进一步优化基于Dreamview的本地开发调试体验，把Dreamview打造成Apollo开发者工具入口。覆盖感知仿真开发调试、规划控制仿真开发调试、车辆适配与集成以及实车路测与调试各场景，提供各种可视化调试工具、诊断信息工具以及自定义视图能力。在社区上，我们将提供更多技术模块，覆盖Cyber RT、感知相关的专项课、配套实验与评测题。
作者介绍
胡旷， Apollo布道师。中科院软件所计算机科学专业硕士，清华大学MBA。曾在IBM负责技术研发及创新管理工作，拥有二十余项国内外专利。2014年加入百度担任技术管理岗位，目前是Apollo开放平台产品与运营负责人，负责Apollo开放平台整体架构设计与落地。
王方浩，Apollo布道师，武汉大学电子信息专业，目前主要从事L4级别自动驾驶的开发，喜欢研究技术，分析源码和解答问题。
