百度Apollo自動駕駛平臺介紹

1、 百度Apollo自動駕駛平臺介紹InfoQ 微信號 infoqchina功能介紹 有內容的技術社區(qū)媒體自百度宣布開放 Apollo 自動駕駛平臺以來，很多開發(fā)者非常期待可以深入了解 Apollo 平臺的開放內容，以便更充分高效的利用這個自動駕駛平臺，研究并落地自己對于自動駕駛的諸多想法。為此，7 月 22 日，由百度開發(fā)者中心主辦、極客邦科技承辦的 73 期百度技術沙龍設置 Apollo 主題，現(xiàn)場百度資深架構師從 Apollo 的開放能力、Apollo 代碼開放框架以及基于深度學習的 End to End 自動駕駛方案三個技術維度做了深度分享，以期幫助開發(fā)者深度了解百度 Apollo 開放

2、內容和平臺架構，設計并實現(xiàn)一套完整的駕駛方案。Apollo 的開放能力和開放數(shù)據(jù) 百度資深數(shù)據(jù)平臺專家楊凡做了開場演講，他表示：“Apollo 開放內容實質上分為兩大部分：能力開放和資源開放，能力開放提供開發(fā)者實現(xiàn)車上自動駕駛的平臺，資源開放提供開發(fā)者探索算法進化的平臺，這二者相輔相成，缺一不可?！盇pollo 的開放能力 Apollo1.0 主要開放的是封閉場地循跡自動駕駛的框架，從上之下分別是服務層、軟件平臺層、參考硬件層以及參考汽車層，其中標藍部分為具體開放模塊。各層級的具體功能如下參考汽車層：實現(xiàn)電子化的控制，也就是線控汽車，這是最底層的一步；參考硬件層：實現(xiàn)計算能力，包括計算單元、G

3、PS/IMU、HMI Device 等；軟件平臺層：最核心的層，分為 3 個部分。1、實時 RTOS 系統(tǒng)，要求保證實時反應；2、運行時框架；3、定位模塊和控制模塊以及 HMI 人機交互模塊。這三塊構成了本期開放的封閉場地循跡自動駕駛軟件體系；云服務層：在云服務層開放了數(shù)據(jù)開放平臺和喚醒萬物的 DuerOS。以上四層構成了百度 Apollo 自動駕駛平臺的整個技術棧。目前開放的 Apollo1.0 具有高效易拓展架構、立即可用硬件、一鍵啟動更新和完備的開發(fā)工具四大特性。Apollo 的開放資源 Apollo1.0 在資源上開放了三個關鍵數(shù)據(jù)集：2D 紅綠燈、3D 障礙物以及 Road Hack

4、ers。百度將這三部分數(shù)據(jù)開放至云端，以便用戶高效研究運用。下圖為 Apollo 數(shù)據(jù)開放平臺的架構邏輯介紹。如圖，用戶通過云端 Docker Repository，下載基于本地的 VM + Docker 的開發(fā)環(huán)境，編寫訓練和預測兩部分算法，配置依賴環(huán)境。通過云端用戶空間的可視化訓練調試平臺，將用戶在本機創(chuàng)建的算法容器，在云端實現(xiàn)調度，展開訓練評估調試。這樣用戶可以在整個云中的數(shù)據(jù)開放平臺中，基于海量數(shù)據(jù)利用集群的 CPU+GPU 資源訓練調試 model，并在其中選取有效的 model 使用?，F(xiàn)場，楊凡親自展示了 Apollo 平臺的使用流程和使用方法，本文不再此贅述，想要動手實踐的讀者可

5、以移步至 Apollo 官網(wǎng) apollo.auto，在“開發(fā)者”/“數(shù)據(jù)開放平臺”頁面有詳細的使用介紹。Apollo 代碼開放框架 自動駕駛系統(tǒng)包括障礙物檢測、紅綠燈識別、駕駛行為決策、路徑規(guī)劃等系列復雜的功能模塊，如何將這些獨立而又相互依賴的模塊集成在一起，構建成一個穩(wěn)定的運行系統(tǒng)，是一個巨大的挑戰(zhàn)。百度資深架構師何瑋從百度為何選用 ROS 系統(tǒng)、Apollo 中 ROS 的改進實踐、Apollo 框架使用介紹三個角度分享了 ROS 在百度自動駕駛的探索和實踐。百度為何選用 ROS 系統(tǒng)？ 在百度為何選用 ROS 系統(tǒng)的問題上，何瑋給出解釋，ROS 是一個強大而靈活的機器人編程框架，同時也

6、是學術界使用最廣泛的框架，它具有三大特性：完整的開發(fā)工具包、靈活的計算調度模型以及豐富的調試工具，能夠統(tǒng)一提供配置管理、部署運行、底層通信等功能，讓開發(fā)者將更多精力放在算法功能的研發(fā)上，快速構建系統(tǒng)原型，驗證算法和功能。Apollo 中 ROS 的改進實踐 ROS 系統(tǒng)的優(yōu)勢顯而易見，但其在 Apollo 平臺的應用中也并非一帆風順。百度在做研發(fā)調試到產(chǎn)品化的過程中，遇到的不少狀況，針對這些問題，百度從通信功能優(yōu)化、去中心化網(wǎng)絡拓撲以及數(shù)據(jù)兼容性擴展三個方面做了定制化的改進。1、通信性能優(yōu)化：共享內存 問題：自動駕駛系統(tǒng)為了能夠感知復雜的道路場景并完成駕駛任務，需要多種傳感器協(xié)同工作，以覆蓋不

7、同場景、不同路況的需求。而主流的多傳感器融合方案至少會包含一個激光雷達和多個相機，如此大的數(shù)據(jù)量對通信的性能有很大的挑戰(zhàn)。解決方案：百度采用的解決方案是共享內存，減少傳輸中的數(shù)據(jù)拷貝, 提升傳輸效率。1 對 1 的傳輸場景下，同一個機器上的 ROS 節(jié)點之間是 socket 進行進程間通信，中間存在多層協(xié)議棧以及多次用戶空間和內核空間的數(shù)據(jù)拷貝，造成了很多不必要的資源占用和性能損耗。共享內存的方式來替代 socket 作為進程間通信的方式，通過減少不必要的內存拷貝，來降低了系統(tǒng)的傳輸延時和資源占用。單對多的傳輸場景下，ROS 在處理一對多的消息傳輸時，底層實現(xiàn)實際是多個點對點的連接，當把一份數(shù)

8、據(jù)要發(fā)給四個節(jié)點時，相同的數(shù)據(jù)會傳輸四次，這會造成很大的資源浪費。共享內存的傳輸過程，能夠支持一次寫入，多次讀取的功能，對于一對多的傳輸場景，相同的數(shù)據(jù)包只需要寫入一次即可，成倍地提高了傳輸?shù)男省?、去中心化的網(wǎng)絡拓撲：使用 RTPS 服務發(fā)現(xiàn)協(xié)議 問題：ROS 并非完全的分布式框架，每個 ROS 網(wǎng)絡中需要有一個中心節(jié)點 ROS Master, 各個節(jié)點在初始化時會像 Master 注冊拓撲信息并獲取其他節(jié)點的信息。這種方式有兩個缺點：1、Master 作為系統(tǒng)的單點，一旦崩潰整個網(wǎng)絡將不可用；2、Master 缺乏異?；謴蜋C制，崩潰后無法通過監(jiān)控重啟等方式自動恢復。解決方案：為了解決這個

9、問題，百度在 ROS 在框架加入了基于 RTPS 協(xié)議的服務發(fā)現(xiàn)功能。整個網(wǎng)絡拓撲不再以 master 為中心構建，而是通過域的概念進行劃分。當一個新的節(jié)點加入網(wǎng)絡時，會通過 RTPS 協(xié)議向域內的所有其他節(jié)點發(fā)送廣播信息，各個節(jié)點也會將自己的服務信息發(fā)送給新的節(jié)點，以代替 Master 的信息交換功能。通過這種方式，能夠使 ROS 網(wǎng)絡的拓撲發(fā)現(xiàn)不再依賴 Master 單點，提高了系統(tǒng)的魯棒性。同時該修改完全基于 ROS 底層的修改，對上層應用程序完全透明，開發(fā)者也不需要對此功能有任何的代碼適配工作。3、數(shù)據(jù)兼容性擴展：用 Protobuf 替換 Message 問題：ROS 系統(tǒng)為了保證收

10、發(fā)雙方的消息格式一致，會對 message 定義做 MD5 校驗，任何字段的增減或順序調整都會使 MD5 變化，以保證系統(tǒng)的健壯性。然而這種嚴格的限制也引起了兼容性的問題，當接口升級后，不同的模塊之間不再能夠通信，大大增加了模塊版本之間的耦合。解決方案：使用 protobuf 來替換 ROS 中的 Message 來作為消息定義的格式。protobuf 本身有良好的兼容性支持，只需要在使用中定義好 required 字段，后續(xù)新增 optional 字段并不會對消息的解析造成影響。Apollo 框架使用介紹 隨后，何瑋簡單介紹了 Apollo 框架的使用方法：第一步：安裝 docher 系統(tǒng)。

11、用 install-dacker 腳本安裝和部署 docker 環(huán)境，包含下載、代碼等一系列工作，安裝完之后需要注銷，并且用戶重新登陸，這其中需要注意的是因為涉及用戶權限的變更，需要當前用戶注銷之后才能完全生效；第二步：編譯 Apollo。編譯代碼：bash Apollo.sh build；第三步，啟動 Apollo。此步驟下需要對 Apollo 系統(tǒng)進行編譯，編譯完成之后啟動 Apollo。百度提供了一鍵啟動版本，可以將后臺的應用和前端顯示完整啟動。第一步：安裝 docher 系統(tǒng)。用 install-dacker 腳本安裝和部署 docker 環(huán)境，包含下載、代碼等一系列工作，安裝完之后需

12、要注銷，并且用戶重新登陸，這其中需要注意的是因為涉及用戶權限的變更，需要當前用戶注銷之后才能完全生效；目前 Apollo 開源代碼已上傳至 Github 網(wǎng)站，具體鏈接為：/apolloauto，感興趣的碼農(nóng)們可前往查閱相關的工具和文檔?；谏疃葘W習的 End to End 自動駕駛方案 開發(fā)者想要基于 Apollo 平臺設計一套完整的自動駕駛系統(tǒng)，前提需要了解百度的自動駕駛系統(tǒng)選擇和方案詳情，百度自動駕駛事業(yè)部資深架構師郁浩為大家分享了基于傳統(tǒng) Rule Based 與 End to End 自動駕駛方案的異同與優(yōu)劣，以及 Apollo 平臺在數(shù)據(jù)和模型上的實踐?；谏疃葘W習的方案選擇 郁浩

13、表示，目前，業(yè)界和學術界主流還是 Rule based 系統(tǒng)。Rule based 從車輛、到傳感器感知、World model、然后進行決策、控制、最后到車輛，形成了比較完整的閉環(huán)系統(tǒng)。不過，其在實際的應用上還是有比較明顯的瓶頸：系統(tǒng)復雜（人工設計）、高精地圖成本高（需要廣鋪以及實時更新），計算性能（資源浪費）。而 End-to-End 方式能夠很好的解決這些問題。下圖為 Rule based 與 End-to-End 優(yōu)劣對比。通過對比，可以看到 End-to-End 方案雖然解決了 Rule based 在應用上的部分缺點，但其在基本功能實現(xiàn)上需要進一步的探索和實踐。郁浩認為，這兩種方案

14、，均有各自的優(yōu)劣勢，在現(xiàn)階段，無法完全依靠某一種深度學習方案實現(xiàn)自動駕駛功能，Rule based 和 End-to-End 在未來的趨勢上必將是吸收對方的優(yōu)點進行融合而絕非對立。Apollo 實踐：數(shù)據(jù) 數(shù)據(jù)產(chǎn)生分一般兩類，一類是真實數(shù)據(jù)，一類是模擬器數(shù)據(jù)。目前，關于中國國情的真實數(shù)據(jù)非常稀少，模擬器數(shù)據(jù)雖然能在一定的能況下起借鑒作用，但大多通過游戲渲染出來的，其渲染的紋理與真實場景的紋理千差萬別，幾乎無法用到真實的道路上。百度在這方面投入甚高，每年都會使用大量數(shù)據(jù)車實地采集幾百萬公里的數(shù)據(jù)進行分析。郁浩表示，本次開放的數(shù)據(jù)主要摘取了前向數(shù)據(jù)，包括 Image、RTK-GPS 以及 IMU 等，每一個開源的數(shù)據(jù)文件對應一次采集任務。這里比較有意思的是，百度沒有直接開源出精準坐標，而是根據(jù)坐標參數(shù)繁衍出1/R（拐彎半徑的倒數(shù)）和縱向指令。開發(fā)者可以里利用它與車廠合作，直接上路行駛。Apollo 實踐：模型 百度