百度為何選用 ROS 系統？

在百度為何選用 ROS 系統的問題上，何瑋給出解釋，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 框架的使用方法