深度剖析Apollo自動駕駛平台

自百度宣布開放 Apollo 自動駕駛平台以來，很多開發者非常期待可以深入了解 Apollo 平台的開放內容，以便更充分高效的利用這個自動駕駛平台，研究並落地自己對於自動駕駛的諸多想法。

為此，7 月 22 日，由百度開發者中心主辦、極客邦科技承辦的 73 期百度技術沙龍設置 Apollo 主題，現場百度資深架構師從 Apollo 的開放能力、Apollo 代碼開放框架以及基於深度學習的 End to End 自動駕駛方案三個技術維度做了深度分享，以期幫助開發者深度了解百度 Apollo 開放內容和平台架構，設計並實現一套完整的駕駛方案。

Apollo 的開放能力和開放數據

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

Apollo 的開放能力

Apollo1.0 主要開放的是封閉場地循跡自動駕駛的框架，從上之下分別是服務層、軟體平台層、參考硬體層以及參考汽車層，其中標藍部分為具體開放模塊。各層級的具體功能如下

• 參考汽車層：實現電子化的控制，也就是線控汽車，這是最底層的一步；
• 參考硬體層：實現計算能力，包括計算單元、GPS/IMU、HMI Device 等；
• 軟體平台層：最核心的層，分為 3 個部分。1、實時 RTOS 系統，要求保證實時反應；2、運行時框架；3、定位模塊和控制模塊以及 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 對 1 的傳輸場景下，同一個機器上的 ROS 節點之間是 socket 進行進程間通信，中間存在多層協議棧以及多次用戶空間和內核空間的數據拷貝，造成了很多不必要的資源佔用和性能損耗。共享內存的方式來替代 socket 作為進程間通信的方式，通過減少不必要的內存拷貝，來降低了系統的傳輸延時和資源佔用。
• 單對多的傳輸場景下，ROS 在處理一對多的消息傳輸時，底層實現實際是多個點對點的連接，當把一份數據要發給四個節點時，相同的數據會傳輸四次，這會造成很大的資源浪費。共享內存的傳輸過程，能夠支持一次寫入，多次讀取的功能，對於一對多的傳輸場景，相同的數據包只需要寫入一次即可，成倍地提高了傳輸的效率。

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

問題：ROS 並非完全的分散式框架，每個 ROS 網路中需要有一個中心節點 ROS Master, 各個節點在初始化時會像 Master 註冊拓撲信息並獲取其他節點的信息。這種方式有兩個缺點：1、Master 作為系統的單點，一旦崩潰整個網路將不可用；2、Master 缺乏異常恢復機制，崩潰後無法通過監控重啟等方式自動恢復。

解決方案：為了解決這個問題，百度在 ROS 在框架加入了基於 RTPS 協議的服務發現功能。

整個網路拓撲不再以 master 為中心構建，而是通過域的概念進行劃分。當一個新的節點加入網路時，會通過 RTPS 協議向域內的所有其他節點發送廣播信息，各個節點也會將自己的服務信息發送給新的節點，以代替 Master 的信息交換功能。

通過這種方式，能夠使 ROS 網路的拓撲發現不再依賴 Master 單點，提高了系統的魯棒性。同時該修改完全基於 ROS 底層的修改，對上層應用程序完全透明，開發者也不需要對此功能有任何的代碼適配工作。

3、數據兼容性擴展：用 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。百度提供了一鍵啟動版本，可以將後台的應用和前端顯示完整啟動。第一步：安裝 docher 系統。用 install-dacker 腳本安裝和部署 docker 環境，包含下載、代碼等一系列工作，安裝完之後需要註銷，並且用戶重新登陸，這其中需要注意的是因為涉及用戶許可權的變更，需要當前用戶註銷之後才能完全生效；

目前 Apollo 開源代碼已上傳至 Github 網站，具體鏈接為：http://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 機制、遷移等問題，即能夠精準的預測出周圍的環境。

自動駕駛的模型構建還在探索階段。百度希望與開發者和合作夥伴一起，通過資源和能力的開放，開發出一套真正智能、完整、安全的自動駕駛解決方案。