這是一份詳細的Apollo自動駕駛平臺上手指南

這是一份詳細的Apollo自動駕駛平臺上手指南

喜歡 | 做者 江柳 發佈於 2017年7月28日. 估計閱讀時間: 12 分鐘 | 來 AICon 關注機器學習、計算機視覺、NLP、自動駕駛等20+AI熱點技術和最新落地成功案例。討論

• 分享到： 微博 微信 Facebook Twitter 有道雲筆記 郵件分享
• 稍後閱讀
• 個人閱讀清單

 

自百度宣佈開放Apollo自動駕駛平臺以來，不少開發者很是期待能夠深刻了解Apollo平臺的開放內容，以便更充分高效的利用這個自動駕駛平臺，研究並落地本身對於自動駕駛的諸多想法。

爲此，7月22日，由百度開發者中心主辦、極客邦科技承辦的73期百度技術沙龍設置Apollo主題，現場百度資深架構師從Apollo的開放能力、Apollo代碼開放框架以及基於深度學習的End to End自動駕駛方案三個技術維度作了深度分享，以期幫助開發者深度瞭解百度Apollo開放內容和平臺架構，設計並實現一套完整的駕駛方案。InfoQ整理了講師演講精彩內容，具體詳情可查閱講師演講PPT深刻了解。

Apollo的開放能力和開放數據

百度資深數據平臺專家楊凡作了開場演講，他表示：「Apollo開放內容實質上分爲兩大部分：能力開放和資源開放，能力開放提供開發者實現車上自動駕駛的平臺，資源開放提供開發者探索算法進化的平臺，這兩者相輔相成，缺一不可。」

Apollo的開放能力

Apollo1.0主要開放的是封閉場地循跡自動駕駛的框架，從上之下分別是服務層、軟件平臺層、參考硬件層以及參考汽車層，其中標藍部分爲具體開放模塊。這一次開放的模塊以下：

• 參考汽車層：實現電子化的控制，也就是線控汽車，這是最底層的一步；
• 參考硬件層：實現計算能力，包括計算單元、GPS/IMU、HMI Device等；
• 軟件平臺層：最核心的層，分爲3個部分。一、實時RTOS系統，要求保證明時反應；二、運行時框架；三、定位模塊和控制模塊以及HMI人機交互模塊。這三塊構成了本期開放的封閉場地循跡自動駕駛軟件體系；
• 雲服務層：在雲服務層開放了數據開放平臺和喚醒萬物的DuerOS。

以上四層構成了百度Apollo自動駕駛平臺的整個技術棧。目前開放的 Apollo1.0具備高效易拓展架構、當即可用硬件、一鍵啓動更新和完備的開發工具四大特性。

Apollo的開放資源

Apollo1.0在資源上開放了三個關鍵數據集：2D紅綠燈、3D障礙物以及Road Hackers。百度將這三部分數據開放至雲端，以便用戶高效研究運用。下圖爲Apollo數據開放平臺的架構邏輯介紹。

用戶經過雲端Docker Repository，下載基於本地的VM + Docker的開發環境，編寫訓練和預測兩部分算法，配置依賴環境。經過雲端用戶空間的可視化訓練調試平臺，將用戶在本機建立的算法容器，在雲端實現調度，展開訓練評估調試。這樣用戶能夠在整個雲中的數據開放平臺中，基於海量數據利用集羣的CPU+GPU資源訓練調試model，並在其中選取有效的model使用。

現場，楊凡親自展現了Apollo平臺的使用流程和使用方法，本文再也不此贅述，想要動手實踐的讀者能夠移步至Apollo官網 apollo.auto，在「開發者」/「數據開放平臺」頁面有詳細的使用介紹。

Apollo代碼開放框架

自動駕駛系統包括障礙物檢測、紅綠燈識別、駕駛行爲決策、路徑規劃等系列複雜的功能模塊，如何將這些獨立而又相互依賴的模塊集成在一塊兒，構建成一個穩定的運行系統，是一個巨大的挑戰。百度資深架構師何瑋從百度爲什麼選用ROS系統、Apollo中ROS的改進實踐、Apollo框架使用介紹三個角度分享了ROS在百度自動駕駛的探索和實踐。

百度爲什麼選用ROS系統？

在百度爲什麼選用ROS系統的問題上，何瑋給出解釋，ROS是一個強大而靈活的機器人編程框架，同時也是學術界使用最普遍的框架，它具備三大特性：完整的開發工具包、靈活的計算調度模型以及豐富的調試工具，可以統一提供配置管理、部署運行、底層通訊等功能，讓開發者將更多精力放在算法功能的研發上，快速構建系統原型，驗證算法和功能。

Apollo中ROS的改進實踐

ROS系統的優點顯而易見，但其在Apollo平臺的應用中也並不是一路順風。百度在作研發調試到產品化的過程當中，遇到的很多情況，針對這些問題，百度從通訊功能優化、去中心化網絡拓撲以及數據兼容性擴展三個方面作了定製化的改進。

一、通訊性能優化：共享內存

問題：自動駕駛系統爲了可以感知複雜的道路場景並完成駕駛任務，須要多種傳感器協同工做，以覆蓋不一樣場景、不一樣路況的需求。而主流的多傳感器融合方案至少會包含一個激光雷達和多個相機，如此大的數據量對通訊的性能有很大的挑戰。

解決方案：百度採用的解決方案是共享內存，減小傳輸中的數據拷貝, 提高傳輸效率。

• 1對1的傳輸場景下，同一個機器上的ROS節點之間是socket進行進程間通訊，中間存在多層協議棧以及屢次用戶空間和內核空間的數據拷貝，形成了不少沒必要要的資源佔用和性能損耗。共享內存的方式來替代socket做爲進程間通訊的方式，經過減小沒必要要的內存拷貝，來下降了系統的傳輸延時和資源佔用。
• 單對多的傳輸場景下，ROS在處理一對多的消息傳輸時，底層實現實際是多個點對點的鏈接，當把一份數據要發給四個節點時，相同的數據會傳輸四次，這會形成很大的資源浪費。共享內存的傳輸過程，可以支持一次寫入，屢次讀取的功能，對於一對多的傳輸場景，相同的數據包只須要寫入一次便可，成倍地提升了傳輸的效率。

二、去中心化的網絡拓撲：使用RTPS服務發現協議

問題：ROS並不是徹底的分佈式框架，每一個ROS網絡中須要有一箇中心節點ROS Master,各個節點在初始化時會像Master註冊拓撲信息並獲取其餘節點的信息。這種方式有兩個缺點：一、Master做爲系統的單點，一旦崩潰整個網絡將不可用；二、Master缺少異常恢復機制，崩潰後沒法經過監控重啓等方式自動恢復。

解決方案：爲了解決這個問題，百度在ROS在框架加入了基於RTPS協議的服務發現功能。整個網絡拓撲再也不以master爲中心構建，而是經過域的概念進行劃分。當一個新的節點加入網絡時，會經過RTPS協議向域內的全部其餘節點發送廣播信息，各個節點也會將本身的服務信息發送給新的節點，以代替Master的信息交換功能。

經過這種方式，可以使ROS網絡的拓撲發現再也不依賴Master單點，提升了系統的魯棒性。同時該修改徹底基於ROS底層的修改，對上層應用程序徹底透明，開發者也不須要對此功能有任何的代碼適配工做。

三、數據兼容性擴展：用Protobuf替換Message

問題：ROS系統爲了保證收發雙方的消息格式一致，會對message定義作MD5校驗，任何字段的增減或順序調整都會使MD5變化，以保證系統的健壯性。然而這種嚴格的限制也引發了兼容性的問題，當接口升級後，不一樣的模塊之間再也不可以通訊，大大增長了模塊版本之間的耦合。

解決方案：使用protobuf來替換ROS中的Message來做爲消息定義的格式。protobuf自己有良好的兼容性支持，只須要在使用中定義好required字段，後續新增optional字段並不會對消息的解析形成影響。

Apollo框架使用介紹

隨後，何瑋簡單介紹了Apollo框架的使用方法：

• 第一步：安裝docher系統。用install-dacker腳本安裝和部署docker環境，包含下載、代碼等一系列工做，安裝完以後須要註銷，而且用戶從新登錄，這其中須要注意的是由於涉及用戶權限的變動，須要當前用戶註銷以後才能徹底生效；

• 第二步：編譯Apollo。編譯代碼：bash Apollo.sh build；
• 第三步，啓動Apollo。此步驟下須要對Apollo系統進行編譯，編譯完成以後啓動Apollo。百度提供了一鍵啓動版本，能夠將後臺的應用和前端顯示完整啓動。

目前Apollo開源代碼已上傳至Github網站，具體連接爲：github.com/apolloauto，感興趣的碼農們可前往查閱相關的工具和文檔。

基於深度學習的End to End自動駕駛方案

開發者想要基於Apollo平臺設計一套完整的自動駕駛系統，前提須要瞭解百度的自動駕駛系統選擇和方案詳情，百度自動駕駛事業部資深架構師鬱浩爲你們分享了基於傳統Rule Based與End to End自動駕駛方案的異同與優劣，以及Apollo平臺在數據和模型上的實踐。

基於深度學習的方案選擇

鬱浩表示，目前，業界和學術界主流仍是Rule based系統。Rule based從車輛、到傳感器感知、World model、而後進行決策、控制、最後到車輛，造成了比較完整的閉環系統。不過，其在實際的應用上仍是有比較明顯的瓶頸：系統複雜（人工設計）、高精地圖成本高（須要廣鋪以及實時更新），計算性能（資源浪費）。而End-to-End方式可以很好的解決這些問題。下圖爲Rule based與End-to-End優劣對比。

經過對比，能夠看到End-to-End方案雖然解決了Rule based在應用上的部分缺點，但其在基本功能實現上須要進一步的探索和實踐。鬱浩認爲，這兩種方案，均有各自的優劣勢，在現階段，沒法徹底依靠某一種深度學習方案實現自動駕駛功能，Rule based和End-to-End在將來的趨勢上必將是吸取對方的優勢進行融合而絕非對立。

Apollo實踐：數據

數據產生分通常兩類，一類是真實數據，一類是模擬器數據。目前，關於中國國情的真實數據很是稀少，模擬器數據雖然能在必定的能況下起借鑑做用，但大多經過遊戲渲染出來的，其渲染的紋理與真實場景的紋理千差萬別，幾乎沒法用到真實的道路上。

百度在這方面投入甚高，每一年都會使用大量數據車實地採集幾百萬千米的數據進行分析。鬱浩表示，本次開放的數據主要摘取了前向數據，包括Image、RTK-GPS以及IMU等，每個開源的數據文件對應一次採集任務。這裏比較有意思的是，百度沒有直接開源出精準座標，而是根據座標參數繁衍出1/R數據（,拐彎半徑的倒數）和縱向指令。開發者能夠裏利用它與車廠合做，直接上路行駛。

Apollo實踐：模型

百度在去年的時候使用的是簡單的橫向模型CNN以及縱向控制模型Convolutional-LSTM，今年，百度將這兩者融合到一塊兒，採用的橫向+縱向的模式：LRCN，該模型須要關注點時序處理、橫縱向關聯關係、因果VS軌跡預測、Attention 機制、遷移等問題，即可以精準的預測出周圍的環境。

鬱浩最後總結道，自動駕駛的模型構建還在探索階段，百度但願與開發者和合做夥伴一塊兒，經過資源和能力的開放，開發出一套真正智能、完整、安全的自動駕駛解決方案。