Apollo開放平臺：從自動駕駛場景能力到開發者易用性(1)

當前，汽車工業正進入新一輪科技革命和產業變革中，自動駕駛正成為新的技術制高點，國內外傳統車企和科技公司紛紛布局。十年前，百度便開始了自動駕駛相關研發投入。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自動駕駛系統生態的健康發展奠定了基礎。

*博客內容為網友個人發布，僅代表博主個人觀點，如有侵權請聯系工作人員刪除。