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

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

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

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

老黃，本名黃英君，1991年就讀國防科技大學，系統工程與數學系、多媒體與虛擬現實專業方向博士，師從吳玲達教授。

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

2012年轉業，工作于中科院軟件所廣州分所，任商業智能實驗室主任，從事電商平臺與大數據分析方面的研究與軟件開發工作。

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

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

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

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

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

談及原因，老黃很實在。

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

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

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

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

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

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

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

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

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

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

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

首先一步，適配Docker。

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

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

具體操作是這樣的：

1. rebuild the TX2 kernel to suport Docker:

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

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

https://github.com/jetsonhacks/buildJetsonTX2Kernel

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

2.在Docker內測試GPU功能。可以參考第一步的鏈接1.

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

接下來，編譯Apollo！

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

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

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

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

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

深入思考之后，老黃發現了報錯的本質根源，就是不兼容造成的。

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

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

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

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

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

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

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

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

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

這是一個有關數學的、線性計算數據庫的問題。“到現在，那個庫的名字我還記得叫?qpSASES。這個庫是一個開源數學計算庫，既然是開源，就會涉及到編譯以及編譯選項的問題，進而就會和編譯的靜態庫相關聯。在X86的環境下靜態庫的運行和編譯都沒有問題，很順暢。”老黃強調。

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

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

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

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/.

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

關于這項實踐的成本和后續工作

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

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

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

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

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

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

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

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

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

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

采訪過程中，作為一個從業30年的程序員，老黃一直表示：“我寫了三十年程序。在我的成長過程中，互聯網給了太多太多的幫助，碰到問題就去網上查，已經是常態，網絡上肯定有人會分享他們的調錯經驗。現在我把自己的一些經驗、教訓、經驗反饋給互聯網，我覺得這是特別應該做的事情。”

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

關于Apollo平臺，像老黃一樣的開發者有話要說

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

值得特別提及的是，Apollo針對開發者的社區會有持續不斷的公開課以及社群交流，很多開發者都在分享自己在自動駕駛領域的心得。“我覺得這是一個，特別吸引我們程序員的地方，百度Apollo社群對生態的經營，十分值得贊賞。”老黃補充道。

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

Apollo 2.0有什么過人之處？

據了解，Apollo 2.0已經能夠實現簡單的城市道路自動駕駛，包括云端服務、軟件平臺、參考硬件平臺以及參考車輛平臺在內的四大模塊已全部具備。

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

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

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

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

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

老黃的寄語

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

附表：關于老黃針對這次技術適配的全面解析

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

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

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

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

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

第一部分：

1. Rebuild the TX2 kernal to suport Docker :

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

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

https://github.com/jetsonhacks/buildJetsonTX2Kernel

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

2. 在Docker內測試GPU功能。可以參考第一步的鏈接1.

第二部分：編譯Apollo

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

具體清單如下：

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

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

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指定的依賴包里面有gflags，但編譯時候還是需要手工準備頭文件和庫文件，直接拷過去。

（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 ---- 經過以上步驟，應該可以編譯通過，感知模塊也可以通過。

【相關報告問題】 報告問題之一：

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

報告問題之二：

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

報告問題之三：

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

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

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