在過去幾個月中，Apollo代碼達到了每周數(shù)十次的更新頻率，新增代碼數(shù)量共計可以達16.5萬行。

如今近8000個開發(fā)者投票支持Apollo開源軟件，超過1800個合作伙伴使用Apollo開源代碼，100多個合作伙伴申請開放數(shù)據(jù)。

了解到這些，作為百度Apollo開發(fā)者陣營中的一員，也是一個30年資深的“金領碼農(nóng)”，老黃坐不住了，本著對自動駕駛的熱忱以及對百度Apollo平臺的興趣，做了一件“驚天動地”的事兒！

對了，先介紹下我們文章的主人公老黃吧！

老黃，本名黃英君，1991年就讀國防科技大學，系統(tǒng)工程與數(shù)學系、多媒體與虛擬現(xiàn)實專業(yè)方向博士，師從吳玲達教授。

畢業(yè)留校工作，在管理科學與工程學院從事視頻分析與編解碼、機器視覺、智能硬件方面的研究工作。

2012年轉(zhuǎn)業(yè)，工作于中科院軟件所廣州分所，任商業(yè)智能實驗室主任，從事電商平臺與大數(shù)據(jù)分析方面的研究與軟件開發(fā)工作。

2017年9月，加盟長沙智能駕駛研究院，任產(chǎn)品研發(fā)部門負責人，從事智能駕駛方面解決方案與產(chǎn)品的開發(fā)工作。

老黃究竟做了一件什么事兒呢？

老黃利用Apollo提供的各種資源與能力，自研成功解決了TX2嵌入式計算平臺（NVIDIA JETSON TX2）適配Docker的嘗試，簡單來說就是使用低成本方案搭建部署了Apollo環(huán)境，值得注意的是此前官方并沒有發(fā)布相關(guān)部署的指導文件……

最最重要的一點，細心的老黃不但完成了技術(shù)嘗試，還將整體的過程做了完備的記錄，總結(jié)了一份環(huán)境搭建攻略并分享出來。說到這里，小編也不禁為老黃這位開發(fā)者無私分享的行為瘋狂打call！

是什么原因讓老黃做了這么一件有意義的事情？

談及原因，老黃很實在。

一方面是因為公司有需求，想通過一輛林肯mkz實驗自動駕駛算法方面的研發(fā)水平。

還有一個特殊根源在于，公司預定了英偉達AI超算平臺的高端產(chǎn)品PX2做一些產(chǎn)品規(guī)劃，但貨品遲遲未到，老黃想著同樣是該系列的產(chǎn)品，或許TX2會有更多的驚喜發(fā)現(xiàn)。

最重要的一點，像老黃一樣的開發(fā)者一直覺得，自動駕駛研發(fā)的目的不是取代人，而是應該走向普通人的生活，用來提升駕駛樂趣，如果開發(fā)成本很高，就很難體現(xiàn)其中的價值。

他對小編說：“如果用看似很低端的設備，用極低的成本實現(xiàn)自動駕駛的某些功能，那就是一件特漂亮的事情，所以我就大膽的做了這個！”

其實，老黃作為自動駕駛領域的開發(fā)者，在百度Apollo出現(xiàn)之前，一直關(guān)注Autoware（城市自主駕駛的開源軟件）的源碼，也就是日本名古屋大學的那款。他自己覺得，從最初的感覺來看，Autoware更像一個完整的解決方案，東西很全……Apollo生態(tài)出現(xiàn)后，覺得很有興趣，很有實操感，瞬間轉(zhuǎn)成“真愛粉”，這也是嘗試的原因所在。

選擇NVIDIA TX2，老黃前后思索了很久…

老黃可以稱之為資深程序員，漫長的職業(yè)生涯中專攻軟件整體架構(gòu)和性能優(yōu)化，尤其關(guān)注軟件的總體構(gòu)建方案、軟件與硬件的整合以及算法的優(yōu)化等方面，對很多市面上的算法平臺都研究過。

說到選擇NVIDIA TX2，老黃還有點兒感慨，“現(xiàn)在做平臺的太多了，如恩智浦的BlueBox，再就是NVIDIA的TX&PX系列，還分了很多流派，什么NVIDIA、英特爾……可是大多數(shù)都還沒有完全推出市場，成熟度也不算很高，這是比較頭疼的事情。NVIDIA這個品牌吧，產(chǎn)品布局早，成品本身技術(shù)屬性也很強大，像TX2，6核CPU，256個GPU單位，功耗15瓦，本身小巧輕便，集成度很贊，天然適合放在汽車這個環(huán)境里做研發(fā)！”

說到這一點，小編也覺得，如果封裝超算平臺的盒子占據(jù)汽車整體體積的好幾分之幾，還要專門插上一個顯卡的話……自動駕駛汽車的畫風突變了……丑出新高度……

適配過程一波三折，但幸好堅持不懈

說到實踐的具體過程，老黃打開了話匣子，言情并茂地為小編描述起來！

首先一步，適配Docker。

起初老黃對此十分疑惑不解，怎么英偉達這款平臺與Docker之間就這么不感冒呢？

原來NVIDIA在構(gòu)建TX2內(nèi)核的時候，略過了很多支持容器所必須的組件，所以解決這個問題的方法就是要重新構(gòu)建這個內(nèi)核，把缺失的部分補上。對此老黃做了兩個部分的處理，其中一個開源項目做了一個很好的內(nèi)核配置文件，另外一個項目做了很容易操作的腳本。

具體操作是這樣的：

1. rebuild the TX2 kernel to suport Docker:

原生TX2不支持Docker，所以需要重新編譯內(nèi)核，將Docker所需的模塊加載，可以參考下面兩個鏈接來定制自己的支持Docker的內(nèi)核：

https://github.com/Technica-Corporation/Tegra-Docker

https://github.com/jetsonhacks/buildJetsonTX2Kernel

最方便直接的步驟就是直接使用鏈接1發(fā)布的config文件，拷貝到鏈接2的src中，make xconfig ,然后 makeKernel.sh & copyImage.sh。

2.在Docker內(nèi)測試GPU功能?？梢詤⒖嫉谝徊降逆溄?.

在Apollo on Nvidia Tegra Tx2上開啟GPU，測試幾個典型CUDA應用的場景。其中開啟了5個常見的CUDA應用程序，GPU利用率為20%左右。

接下來，編譯Apollo！

“起初我并沒有想到這個事情還挺難！”老黃強烈表示。

“這么一算，完成這個嘗試總共花了3周時間。我覺得最開始研究測試Apollo各種功能的時候感覺很容易，然后就順理成章覺得適配工作不會太難，妥妥交給一枚實習生去操作。”老黃言語中透露著輕松。

但事實上，實習生小同志辛苦適配了三天，結(jié)果……經(jīng)常出現(xiàn)報錯的警告。怎么回事兒？迅速跑到老黃這里尋找救援。

老黃嘆了口氣說：“發(fā)現(xiàn)這個事情后，我也試了幾次，結(jié)果可想而知......怎么辦呢？就去網(wǎng)絡上查找相關(guān)資料，結(jié)果一看，網(wǎng)上救援是沒可能了，存在的資料少之又少；又查了一下當時Apollo的版本，結(jié)果發(fā)現(xiàn)從9月27日到現(xiàn)在也沒有最新的更新消息，沒有相關(guān)指導資料的前提下，又給適配增加了難度?！?/p>

小編了解到，在適配的過程中，很多被采用的第三方工具包內(nèi)部的設置并不齊備，還包括一些數(shù)據(jù)庫也存在沖突，所以在編譯的過程中，總會頻繁出現(xiàn)各種各樣的報錯，就像我們?nèi)粘０惭b一個軟件，各種安裝不上的節(jié)奏一樣，老黃這才意識到當下任務的艱巨性。

深入思考之后，老黃發(fā)現(xiàn)了報錯的本質(zhì)根源，就是不兼容造成的。

他表示，針對Apollo，其實采用了大量的第三方開源工具包還有一些動態(tài)庫，例如像求解，預算等，其中會涉及到一些參數(shù)設計（編譯鏈接的時候有一個參數(shù)設計），大部分都是針對X86這個體系。如果現(xiàn)在要將這些放在ARM架構(gòu)下的話，必須要準確的將這些參數(shù)找到并作出修正！

“但是這就存在一個問題，需要修正哪些參數(shù)我們起初是不知道的，只有在編譯運行的過程中出現(xiàn)問題后，才能根據(jù)這個具體的問題去推測或猜測可能出現(xiàn)的編譯參數(shù)、編譯選項，然后進行修正工作，最后再來具體驗證是不是能夠通過，這個過程很復雜、耗時，大部分時間都是在反復嘗試、反復測試。”老黃補充道。

開始這樣一個糾結(jié)的過程，就需要老黃基本上從頭開始?按照Apollo架構(gòu)體系來手工搭建運行環(huán)境以及運行體系。

所以老黃在漫長的嘗試中寫下了這些：

aarch64版本的Apollo需要自己配置所需的一部分依賴包，以及編譯aarch64平臺所需的幾個第三方動態(tài)庫。有興趣的可以直接做成腳本，一鍵安裝。（具體涉及的相關(guān)步驟請見文后）

老黃開玩笑說：“當時一看這種情形，又回到我的老本行了，典型的軟件編程工作，逐個解決問題。結(jié)果一個星期過去了，不行；兩個星期過去了，還是不行……當時我也確實有那么一絲猶豫，甚至產(chǎn)生了動搖，想著干脆等到百度Apollo官方發(fā)出適配方案算了！”

在這個過程中，老黃也咨詢了Apollo開發(fā)者社區(qū)的相關(guān)技術(shù)人員，得到的回復是，對于TX2這個版本還沒有具體的適配計劃，但對于1.0版本是支持的。預計到年底，會放出支持版本。當時老黃想，要等到年底，時間有點兒久。

一咬牙，老黃又投身到了解決問題的實踐中！

過程艱辛不必多說，老黃給小編列舉了一個讓他至今印象深刻的例子，也是當時花費時間最長的一個問題。

這是一個有關(guān)數(shù)學的、線性計算數(shù)據(jù)庫的問題?！暗浆F(xiàn)在，那個庫的名字我還記得叫?qpSASES。這個庫是一個開源數(shù)學計算庫，既然是開源，就會涉及到編譯以及編譯選項的問題，進而就會和編譯的靜態(tài)庫相關(guān)聯(lián)。在X86的環(huán)境下靜態(tài)庫的運行和編譯都沒有問題，很順暢?！崩宵S強調(diào)。

“但是在ARM環(huán)境下，一開始并沒有報錯，進庫后我才發(fā)現(xiàn)進展又陷入了僵局！后來研究出最后的原因，這個庫中的某些編譯問題并不適配這個環(huán)境。如果想要解決，就必須要把這個靜態(tài)庫從Apollo整理好工具包中單獨移出，單獨手工加工下，在X86的環(huán)境下編譯成動態(tài)庫，才可以正常使用！

根據(jù)具體情況，老黃寫下了這樣的建議：

關(guān)于 qpSASES。這是個數(shù)值求解庫，Apollo的x86版是以依賴包的形式，aarch64是改為直接使用動態(tài)庫，但是需要自己在平臺下編譯，否則鏈接報錯。

a .build qpSASES to shared lib, copy it to /usr/lib

b. copy include

cp -a /apollo/third_party/qpOASES-3.2.1/include/* /usr/include/.

小編聽著老黃講述整個探索過程，感覺這項工作得以進展太不容易了！

關(guān)于這項實踐的成本和后續(xù)工作

說完糾結(jié)的過程，老黃長長地出了口氣，但是談到成本，他又興奮了起來，老黃表示整個成本真的非常低。

他說：“我們用的TX2的開發(fā)版，不到5000塊錢。如果說，用它的核心版來搭建，可能還不到2000塊錢，但是這個計算性能是非常強悍的。也就是說，用一個價格超過10萬元的PX2能夠做的事情，我們可能用到不超過4-5個這樣的TX2就能達到同等效果，這樣計算的話，全部配置完整也不過1萬塊錢左右?！?/p>

老黃強調(diào)，自己這些年做的工作，不管是哪些方面，都在不斷追求一個目標：用更低成本的平臺跑出更好的效果。

關(guān)于這次嘗試的后續(xù)工作，老黃表示自己以及團隊已經(jīng)在著手跟進了，例如視覺感知，簡單來說就是將基于深度學習的一個視覺感知部分加入放到TX2中。

通過性能測試來初步判斷最多能夠支持幾個攝像機進行虛實檢測。老黃對小編說：“我的計劃是掛4部攝像機，這樣從性能的角度，相當于TX2支持的三分之一（可以掛12部），如果可以實現(xiàn)4個我就非常滿意了?！?/p>

另外一點，就是當時Apollo 1.5版本還沒有視覺感知，所以老黃也想突擊研究下這方面，如果成功的話也可以公布出去，分享給更多的開發(fā)者以及企業(yè)。

說到分享開發(fā)攻略，老黃覺得應該向Apollo學習

不得不說，Apollo開放平臺的出現(xiàn)降低了自動駕駛的門檻，讓更多企業(yè)、機構(gòu)能夠在一個基礎平臺上去做更重要的感知、決策和控制工作，而這些具體的工作被認為是自動駕駛得以進步的核心環(huán)節(jié)。對比之前，自動駕駛領域出現(xiàn)更多的都是“國家重大科技基金”、“國家項目支持”等這些字眼兒，一些老牌的科研單位以及高等學府才有可能直接接觸這個領域。

針對技術(shù)環(huán)境與平臺，老黃認為，作為開發(fā)者可以貢獻一些力量幫助Apollo一起將基礎工具，搭建的更多樣性、更靈活、更完善。讓更多相關(guān)人員在這個平臺上，去做更值得做的事情。

此外，Apollo本身是一套開源系統(tǒng)平臺，老黃覺得開發(fā)者利用開源研究以及進行業(yè)務方面的突破，得到的成果也應該開源出去，每個人都有反饋，才能讓開源一直持續(xù)。

采訪過程中，作為一個從業(yè)30年的程序員，老黃一直表示：“我寫了三十年程序。在我的成長過程中，互聯(lián)網(wǎng)給了太多太多的幫助，碰到問題就去網(wǎng)上查，已經(jīng)是常態(tài)，網(wǎng)絡上肯定有人會分享他們的調(diào)錯經(jīng)驗?，F(xiàn)在我把自己的一些經(jīng)驗、教訓、經(jīng)驗反饋給互聯(lián)網(wǎng)，我覺得這是特別應該做的事情?！?/p>

對此，小編很敬佩像老黃一樣具有分享精神的開發(fā)者們。

關(guān)于Apollo平臺，像老黃一樣的開發(fā)者有話要說

回顧幾個月前，Apollo 1.0還是一個不成熟、不完整，甚至可以是一個不成型的系統(tǒng)。短短幾個月過去了，從百度公布的路線圖來看，這個平臺必然會傾注很多技術(shù)人員的心血去大力推廣，圍繞Apollo，可能會生長成為一個有規(guī)模、比較完善的生態(tài)圈。像老黃一樣的開發(fā)者以及更多人都會圍繞這個迅速成長的軌跡，從中獲得很多幫助以及資源共享。

值得特別提及的是，Apollo針對開發(fā)者的社區(qū)會有持續(xù)不斷的公開課以及社群交流，很多開發(fā)者都在分享自己在自動駕駛領域的心得。“我覺得這是一個，特別吸引我們程序員的地方，百度Apollo社群對生態(tài)的經(jīng)營，十分值得贊賞?！崩宵S補充道。

談及Apollo的飛速發(fā)展，就在不久前，美國的拉斯維加斯上演了一場讓世界驚艷的“自動駕駛秀”，Apollo平臺研發(fā)負責人王京傲借此在百度World大會上爆了個猛料，Apollo 2.0正式開放！

Apollo 2.0有什么過人之處？

據(jù)了解，Apollo 2.0已經(jīng)能夠?qū)崿F(xiàn)簡單的城市道路自動駕駛，包括云端服務、軟件平臺、參考硬件平臺以及參考車輛平臺在內(nèi)的四大模塊已全部具備。

此外為開發(fā)者帶來了最完整的解決方案和靈活的架構(gòu)，并首次開放安全服務，進一步強化了自定位、感知、規(guī)劃決策和云端仿真等能力。

目前，Apollo 2.0版本總共有16.5萬行代碼。

據(jù)悉，硅谷自動駕駛創(chuàng)業(yè)公司AutonomouStuff在一周內(nèi)將Apollo 1.0車輛升級為“Apollo 2.0版本”，實現(xiàn)了晝夜簡單城市道路自動駕駛，充分體現(xiàn)Apollo 2.0的靈活性和易用性。

振奮之余，截至小編發(fā)稿前，有消息稱，老黃又進一步將Apollo 2.0進行了成功的適配，真要為認真的開發(fā)者點個大大的贊！

我們有理由相信一個愿景的實現(xiàn)，“未來，通過Apollo平臺會吸引更多新鮮力量加入進來，大家一起做好自動駕駛這項事業(yè)！”

老黃的寄語

作為開發(fā)者，我十分希望百度Apollo的開發(fā)團隊能夠把更多內(nèi)容都填充到這個體系中，做出更多的好東西給大家用。也希望Apollo這個生態(tài)圈中，可以更加廣泛地吸納參與者、開發(fā)者，貢獻自己的經(jīng)驗與心得，希望大家都可以共同來維護并發(fā)展這個有意義的社區(qū)生態(tài)圈。

附表：關(guān)于老黃針對這次技術(shù)適配的全面解析

【寫在記錄前】首先，目前適配只完成了全部模塊的編譯，感知部分尤其是Caffe還是只啟用了CPU，在Docker里面還沒有安裝CUDA，隨后將開始這個工作。

其次，強烈建議大家加裝一塊外接SSD，把Apollo部署在SSD上，以便在刷的過程中，TX2經(jīng)常發(fā)生重啟后桌面出不來的問題。

第三：刷機并部署完成大概要剩余5個G（要把刷內(nèi)核的中間文件全部清除）。

第四：我把刷機和部署過程所需的一些依賴包的頭文件以及在tx2上編譯的動態(tài)庫打包，大家可以直接使用，希望那個節(jié)約一些大家的時間。

最后：本人能力有限，有的地方know why，有的地方只能誤打誤撞know how，另外對bazel剛剛接觸，很不熟練，在此拋磚引玉，請大家批評指導，謝謝！

第一部分：

1. Rebuild the TX2 kernal to suport Docker :

原生TX2不支持Docker，所以需要重新編譯內(nèi)核，將Docker所需的模塊加載，可以參考下面兩個鏈接來定制自己的支持Docker的內(nèi)核：

https://github.com/Technica-Corporation/Tegra-Docker

https://github.com/jetsonhacks/buildJetsonTX2Kernel

最方便直接的步驟就是直接使用鏈接1發(fā)布的config文件，拷貝到鏈接2的SRC中，make xconfig ,然后 makeKernal.sh & copyImage.sh。

2. 在Docker內(nèi)測試GPU功能?？梢詤⒖嫉谝徊降逆溄?.

第二部分：編譯Apollo

aarch64版本的Apollo需要自己配置所需的一部分依賴包，以及編譯aarch64平臺所需的幾個第三方動態(tài)庫。有興趣的可以直接做成腳本，一鍵安裝。

具體清單如下：

1. caffe

aarch64版本需要自己準備caffe的依賴包，為了方便直接模仿x86版本，在external目錄下手工添加@caffe and caffe dir。

另外我下載的caffe版本可能比較老，使用的是2.6版的protobuf，所以要使用protobuf3.3版重新生成一下caffe.pb.h。具體步驟如下：

a. install the bazel package to external:@caffe and caffe dir,copy from x86 apollo

cd /root/.cache/bazel/_bazel_root/540135163923dd7d5820f3ee4b306b32/external/

b.copy caffe include to:/usr/include/caffe, and regenerate caffe.pb.h,using protoc 3.3.0

cp -a /media/nvidia/ssd/install_apollo/caffe_package/caffe_external/. /usr/include/caffe/.

c.lib

cp -a /media/nvidia/ssd/install_apollo/caffe_package/lib/* /usr/lib/.

2. qpSASES

這是個數(shù)值求解庫，Apollo的x86版是以依賴包的形式，aarch64是改為直接使用動態(tài)庫，但是需要自己在平臺下編譯，否則鏈接報錯。

a .build qpSASES to shared lib, copy it to /usr/lib

b. copy include

cp -a /apollo/third_party/qpOASES-3.2.1/include/* /usr/include/.

3. Ipopt 這個需要一系列的庫，要在TX2上編譯，其他平臺編譯的也不行。

1.include

cp -a /media/nvidia/ssd/install_apollo/IPopt/include/coin/* /usr/include/.

cp -a /media/nvidia/ssd/install_apollo/IPopt/include/LinAlg/* /usr/include/.

cp -a /media/nvidia/ssd/install_apollo/IPopt/include/Interfaces/* /usr/include/.

2.lib-----Ipopt的幾個目錄的庫都要拷貝過去，

cp -a /media/nvidia/ssd/install_apollo/IPopt/lib/* /usr/lib/.

cp ...

cp ...

4. ros

需要自己準備aarch64版本的ros。

（1）準備include

cp -a /media/nvidia/ssd/install_apollo/ros/include/* /usr/include/.

（2）將ros目錄拷貝至 /home/tmp/ros

5. gflags

WORKSPASE指定的依賴包里面有g(shù)flags，但編譯時候還是需要手工準備頭文件和庫文件，直接拷過去。

（1）include

cp -a /media/nvidia/ssd/install_apollo/gflags/include/* /usr/include/.

（2）lib

cp -a /media/nvidia/ssd/install_apollo/gflags/lib/* /usr/lib/.

6. glog

同上，直接安裝。

apt-get install libgoogle-glog-dev

7. Build ---- 經(jīng)過以上步驟，應該可以編譯通過，感知模塊也可以通過。

【相關(guān)報告問題】 報告問題之一：

Apolloauto的Github提供了aarch64的ros版本是1.51，可以直接下載release使用，我嘗試了一下自己編譯，發(fā)現(xiàn)少了個rosbag指令。使用release版的話，rosbag的play指令報錯，導致現(xiàn)在無法在TX2上回放數(shù)據(jù)。

報告問題之二：

在Build時，全部通過OK，但是在bazel-bin下并沒有生成target，最后是使用Bazel Build 對modules下的模塊進行手工編譯。

報告問題之三：

gflag, glog，gtest是出問題最多的地方，有的地方使用bazel構(gòu)建包生成的庫，有的第三方依賴使用自帶的庫，兼容性的問題一直存在。所有使用gmock的地方我始終沒有解決，所以 臨時屏蔽了幾個單元測試。

按照開發(fā)者提供的運行文檔，Apollo團隊也用相同套件編譯安裝實踐了一遍，并整理了若干兼容細節(jié)，形成了官方支持TX2，CPU為ARM平臺的支持文檔。

目前發(fā)現(xiàn)Apollo部分模塊對于ARM架構(gòu)的計算單元兼容性支持還不夠好，如感知紅綠燈識別模塊、定位模塊，在編譯安裝的過程，先跳過該模塊編譯部分，已與研發(fā)團隊溝通，后續(xù)會輸出完整的文檔分享。