當(dāng)前，汽車工業(yè)正進(jìn)入新一輪科技革命和產(chǎn)業(yè)變革中，自動(dòng)駕駛正成為新的技術(shù)制高點(diǎn)，國(guó)內(nèi)外傳統(tǒng)車企和科技公司紛紛布局。十年前，百度便開始了自動(dòng)駕駛相關(guān)研發(fā)投入。2017年，Apollo計(jì)劃正式宣布。

經(jīng)過(guò)六年建設(shè)，Apollo開源項(xiàng)目在GitHub上獲得的Star數(shù)超過(guò)2.3萬(wàn)，在社區(qū)中也備受歡迎。然而，自動(dòng)駕駛系統(tǒng)本身的復(fù)雜性和Apollo開源代碼的工程龐大，導(dǎo)致Apollo的使用門檻很高。對(duì)于基礎(chǔ)開發(fā)者來(lái)說(shuō)，從基礎(chǔ)安裝、使用到開發(fā)調(diào)試，開發(fā)者都可能會(huì)碰到各種問(wèn)題。而對(duì)于高階開發(fā)者，由于Apollo系統(tǒng)與Robotaxi場(chǎng)景的深度耦合，開發(fā)者如果期望在其他場(chǎng)景直接復(fù)用，門檻也很高。更多時(shí)候，開發(fā)者只是參考Apollo工程算法實(shí)現(xiàn)之后再移植到自身系統(tǒng)。為了更好地系統(tǒng)化解構(gòu)和量化易用性問(wèn)題，我們從以往側(cè)重技術(shù)模塊的角度轉(zhuǎn)換為側(cè)重不同類型技術(shù)開發(fā)者使用場(chǎng)景的角度來(lái)重塑產(chǎn)品，并參考內(nèi)外部?jī)?yōu)秀開源社區(qū)經(jīng)驗(yàn)，采用NPS（Net Promoter Score，凈推薦值）、開發(fā)者深度訪談、工具鏈?zhǔn)褂昧康裙ぞ邅?lái)系統(tǒng)獲取開發(fā)者反饋，并以此作為衡量易用性的參考指標(biāo)。

開發(fā)者使用場(chǎng)景根據(jù)不同類型技術(shù)開發(fā)者差別，把開發(fā)者使用場(chǎng)景大致分為以上機(jī)仿真開發(fā)調(diào)試為主的規(guī)劃控制仿真開發(fā)調(diào)試場(chǎng)景和感知仿真開發(fā)調(diào)試場(chǎng)景，以上車調(diào)試為主的車輛適配與集成場(chǎng)景和實(shí)車路測(cè)與調(diào)試場(chǎng)景。通過(guò)場(chǎng)景分類，我們可以更好地理解開發(fā)者需求，并從中找到共性需求與理解差異性需求。開發(fā)者調(diào)研
從2022年上半年開始，我們進(jìn)行了社區(qū)的第一次NPS調(diào)研，并形成了半年一次的面向所有開發(fā)者的例行反饋機(jī)制。表1是2022年上半年第一次NPS調(diào)研的數(shù)據(jù)，Apollo整體NPS極高，但感知和PnC（規(guī)劃與控制）的開發(fā)體驗(yàn)NPS極低。這也進(jìn)一步印證了我們對(duì)于Apollo社區(qū)價(jià)值與產(chǎn)品價(jià)值差距的認(rèn)知。表1 2022年上半年NPS數(shù)據(jù)同時(shí)，在每次發(fā)版前，我們會(huì)進(jìn)行alpha內(nèi)測(cè)與beta公測(cè)，針對(duì)不同使用場(chǎng)景的開發(fā)者形成SIG（Special Interest Group，特別興趣小組）來(lái)定向獲取反饋，如圖1的感知場(chǎng)景開發(fā)者訪談?dòng)涗洝?img class="rich_pages wxw-img" src="http://editerupload.eepw.com.cn/fetch/202308/11782be9a9a657e0199e4413f0dd3f21.png" alt="圖片" />圖1 感知仿真開發(fā)調(diào)試場(chǎng)景SIG調(diào)研反饋此外，我們定期與社區(qū)布道師進(jìn)行深度訪談來(lái)進(jìn)一步收集意見與建議。通過(guò)這些方式，我們期望深度切入開發(fā)者痛點(diǎn)，切實(shí)解決開發(fā)者使用中的各種問(wèn)題，讓小白開發(fā)者從入門到精通，幫助資深開發(fā)者快速?gòu)?到1，提升效率。通過(guò)基于場(chǎng)景的分類和多方位的開發(fā)者反饋收集，我們梳理了四類核心問(wèn)題。首先，是如何高效復(fù)用工程能力？Apollo工程龐雜且與Robotaxi場(chǎng)景耦合較深，如何能快速基于Apollo的核心能力擴(kuò)展應(yīng)用到其他場(chǎng)景？需要更靈活方便的發(fā)布機(jī)制來(lái)支撐；第二，如何快速驗(yàn)證新的算法模型，滿足各種差異化應(yīng)用場(chǎng)景落地對(duì)于算法模型的需求，或是滿足科研領(lǐng)域?qū)τ谛滦退惴ǖ奶剿?；第三，如何提升開發(fā)調(diào)試效率？工欲善其事必先利其器，目前Apollo工具偏向整車應(yīng)用場(chǎng)景，而非個(gè)人開發(fā)調(diào)試場(chǎng)景。開發(fā)個(gè)人開發(fā)者工具，縮小與個(gè)人開發(fā)者需求之間的差距同樣非常重要。最后，如何降低學(xué)習(xí)曲線？提供符合開發(fā)者學(xué)習(xí)習(xí)慣的內(nèi)容與產(chǎn)品，縮短開發(fā)者學(xué)習(xí)過(guò)程是提升產(chǎn)品價(jià)值不可或缺的部分。接下來(lái)，我們將基于以上四點(diǎn)，詳細(xì)介紹最新發(fā)布的Apollo開放平臺(tái)8.0在工程技術(shù)、算法模型、開發(fā)工具、知識(shí)學(xué)習(xí)等方面可以為開發(fā)者帶來(lái)哪些價(jià)值應(yīng)用。高效復(fù)用平臺(tái)能力——包管理升級(jí)Apollo軟件包管理的主要目標(biāo)是將自動(dòng)駕駛系統(tǒng)的編譯產(chǎn)出按照“模塊”粒度進(jìn)行規(guī)范化組織，一方面支持直接使用產(chǎn)出包的方式使用組件，另一方面規(guī)范組件的依賴關(guān)系以及組件的粒度，從而降低組件的使用/復(fù)用難度，提升自動(dòng)駕駛系統(tǒng)的的研發(fā)效率。Apollo的源碼是基于Bazel進(jìn)行構(gòu)建的，其優(yōu)劣勢(shì)都很明顯，一方面得益于Bazel先進(jìn)的并行編譯速度，70W+行的源碼可以在1小時(shí)內(nèi)完成整體編譯。另一方面受限于Bazel的單源碼樹的限制，Apollo模塊之間無(wú)法使用二進(jìn)制的方式進(jìn)行依賴。Bazel包支持嵌套依賴，導(dǎo)致Apollo模塊之間的依賴關(guān)系極其復(fù)雜，很難單獨(dú)使用一個(gè)或者幾個(gè)模塊。因此，Apollo包管理將基于Bazel進(jìn)行擴(kuò)展，主要規(guī)范構(gòu)建產(chǎn)出（以及部分源碼）內(nèi)容，并配套相關(guān)工具，讓Apollo的模塊可以通過(guò)二進(jìn)制的方式引入復(fù)用，因此本文介紹的概念和術(shù)語(yǔ)主要是針對(duì)Apollo的構(gòu)建產(chǎn)出。此外，Apollo的包目前對(duì)Bazel工程的支持將優(yōu)先于CMake工程，但是Apollo包最終將制作成標(biāo)準(zhǔn)的DEB包，可以安裝在Ubuntu操作系統(tǒng)上，也可以作為普通的系統(tǒng)包在CMake工程下使用。包管理的整體框架介紹Apollo的軟件包管理是一系列工具的集合，覆蓋整個(gè)軟件包的整個(gè)生命周期，如圖2所示。圖2 Apollo包管理框架其中包含如下模塊：RepoServer是軟件包的云端倉(cāng)庫(kù)，存儲(chǔ)包實(shí)體（即deb包）與包的索引。具體實(shí)現(xiàn)是采用靜態(tài)網(wǎng)站服務(wù)結(jié)合CDN加速技術(shù)實(shí)現(xiàn)高速、高可用的文件下載服務(wù)。LocalRepo即軟件包的本地倉(cāng)庫(kù)，是一個(gè)基礎(chǔ)的本地文件系統(tǒng)，按照標(biāo)準(zhǔn)的文件系統(tǒng)規(guī)范存儲(chǔ)包的內(nèi)容，其中即包含從遠(yuǎn)程倉(cāng)庫(kù)下載安裝的deb包，也包括本地工程構(gòu)建產(chǎn)出的Local版本軟件包。該本地倉(cāng)庫(kù)中存儲(chǔ)的內(nèi)容有兩方面作用，一是在Apollo系統(tǒng)運(yùn)行時(shí)提供動(dòng)態(tài)鏈接庫(kù)，另外也是在Apollo組件編譯時(shí)提供依賴庫(kù)。Buildtool是使用軟件包作為擴(kuò)展組件依賴時(shí)的配套構(gòu)建工具。Apollo使用Bazel作為構(gòu)建系統(tǒng)，所以推薦擴(kuò)展組件也使用Bazel進(jìn)行構(gòu)建，Bazel在云端編譯、緩存等技術(shù)上有很大的優(yōu)勢(shì)。而Buildtool目前的底層也是基于Bazel的（未來(lái)可以考慮支持CMake等多種編譯系統(tǒng)）。Buildtool的核心作用是將Apollo的軟件包作為編譯依賴加到bazel構(gòu)建體系中，而且盡量簡(jiǎn)化使用復(fù)雜度。眾所周知，將動(dòng)態(tài)庫(kù)加到Bazel的依賴體系中是比較繁瑣的，首先需要安裝動(dòng)態(tài)庫(kù)，雖然Bazel中可以使用http_archive進(jìn)行下載包，但是一般情況下還是會(huì)使用Apt等工具在操作系統(tǒng)中先安裝好動(dòng)態(tài)庫(kù)。緊接著需要使new_local_repository創(chuàng)建一個(gè)repository并且提供一個(gè)BUILD文件,其中包含cc_library。在依賴包存在相互依賴的情況下,需要自行梳理版本防止依賴沖突。Buildtool通過(guò)依賴版本分析、自動(dòng)拉取依賴包、自動(dòng)生成repository配置、自動(dòng)處理級(jí)聯(lián)依賴等功能配合包描述文件(cyberfile.xml),可以讓上述繁瑣過(guò)程對(duì)使用者透明，只需要在包描述中聲明一個(gè)依賴即可。Buildtool的第二個(gè)作用是支持源碼方式使用Apollo的軟件包。C++使用二進(jìn)制作為依賴一直存在ABI等問(wèn)題難以解決，所以在Apollo的軟件包中將源碼也作為標(biāo)準(zhǔn)內(nèi)容，Buildtool支持將包的源碼自動(dòng)引入到使用者的工作空間下參與編譯，與此同時(shí)Buildtool也將多個(gè)源碼包的編譯順序納入管理。除了在構(gòu)建中使用Buildtool下載安裝使用，也可以使用Apt等工具直接安裝使用，例如在使用Dreamview播放Record文件的場(chǎng)景下我們不需要從頭編譯Apollo工程，只需要使用apt installapollo-neo-dreamview-dev，將dreamview以及其依賴按照到本地就可以來(lái)播放數(shù)據(jù)包回看數(shù)據(jù)了。軟件包管理的各個(gè)組成部分已經(jīng)介紹完了?？梢钥闯銎淙抗δ芏几鸁o(wú)人駕駛系統(tǒng)本身沒(méi)有關(guān)系，那它對(duì)于Apollo的發(fā)展有什么作用呢？Apollo開源項(xiàng)目是一整套完整的無(wú)人駕駛系統(tǒng)，但是由于業(yè)務(wù)場(chǎng)景不同，具體分場(chǎng)景下開發(fā)者不會(huì)直接部署一整套項(xiàng)目，而是從中選取適合自己的功能、算法等內(nèi)容放到自己的項(xiàng)目中使用。而目前Monolithic Repository的組織結(jié)構(gòu)，各個(gè)功能組件之間存在耦合，要抽離出來(lái)單獨(dú)使用的成本很大，所以很多開發(fā)者會(huì)自己再重新實(shí)現(xiàn)一份代碼。但這樣不但浪費(fèi)開發(fā)者的時(shí)間成本，也會(huì)導(dǎo)致開發(fā)者的擴(kuò)展內(nèi)容無(wú)法進(jìn)行貢獻(xiàn)。有了軟件包管理后，一方面先進(jìn)技術(shù)可以按照功能模塊的粒度以二進(jìn)制庫(kù)（或者源碼）的方式被開發(fā)者直接使用，同時(shí)也為開發(fā)者提供了更輕量級(jí)并且和Apollo龐大的單體源碼解耦的方式來(lái)共享自己的擴(kuò)展能力，即按照Apollo軟件包的規(guī)范開發(fā)/發(fā)布自己的軟件包，為Apollo自動(dòng)駕駛系統(tǒng)生態(tài)的健康發(fā)展奠定了基礎(chǔ)。

*博客內(nèi)容為網(wǎng)友個(gè)人發(fā)布，僅代表博主個(gè)人觀點(diǎn)，如有侵權(quán)請(qǐng)聯(lián)系工作人員刪除。