原文鏈接：進階課程?丨Apollo ROS原理—2

在ROS系統中，從數據的發布到訂閱節點之間需要進行數據的拷貝。在數據量很大的情況下，很顯然這會影響數據的傳輸效率。所以Apollo項目對于ROS第一個改造就是通過共享內存來減少數據拷貝，以提升通信性能。

上周阿波君為大家詳細介紹了「進階課程?Apollo ROS原理—1」。

此課程先從三個方面闡述了ROS的不足，第一，大數據傳輸性能瓶頸；第二，單中心的網絡存在單點風險；第三，數據格式缺乏后向兼容。此外，還詳細的介紹了Apollo ROS對ROS的改進，對其通信性能進行的優化。

本周阿波君將繼續與大家分享Apollo ROS原理—2的相關課程。下面，我們一起進入進階課程第33期。

目前ROS僅適用于Apollo 3.0之前的版本，最新代碼及功能還請參照Apollo 3.5及5.0版本。

目錄

1.Apollo ROS對ROS的改進

?2.去中心化網絡拓撲

去中心化網絡拓撲的原因

使用RTPS服務發現協議實現完全的P2P網絡拓撲

3.數據兼容性擴展

數據兼容性擴展的原因

深度融合Protobuf功能，實現數據兼容性擴展

---

1.Apollo ROS對ROS的改進

---

2.去中心化網絡拓撲

去中心化網絡拓撲的原因

ROS是以Rosmaster節點管理器建立起來的一個P2P拓撲網絡，這種拓撲網絡有很明顯的優勢，如下：

節點之間相互獨立，容錯性比較強。

每個模塊用不同的語言去開發，對其它的模塊是透明的，其它模塊不用關注和它通信的數據節點以及模塊使用什么語言來開發。

模塊開發之間是比較解耦合的，你只要定義好使用Topic/Service/Param的信息，然后按照這個格式去開發自己的模塊。

但是也有兩個比較明顯的缺點。

• 第一，節點之間的通信過于依賴Rosmaster單點。兩個節點進行通信的鏈路過程，大概分為五部。第一步：發送節點去向Master注冊一個發送節點。第二步：接收節點去向Master注冊一個接收節點。第三步：Master向接收節點發送一個已有發送節點的一個信息拓撲。第四步：接收節點拿到這個拓撲信息之后去向發送節點請求建立一個tcp連接。第五步：在發送節點和接收節點建立一個P2P的單點拓撲連接之后就持續不斷的向接收節點發送信息。整個過程中對Master依賴包含三步，在建立實際通信之后，對Master的依賴可能會降低很多，但是在建立之前是比較依賴Master節點的。
• 第二，ROS沒有提供一種異常恢復機制。如果某一個節點掛掉，尤其是Master節點掛掉，其它的節點卻不知道發生了這樣的行為，還會認為整個系統運行仍然處在正確的狀態中。比如發送節點里面有一些Service或者Param相關的請求，它還是會照常去發請求或者是設置這個參數信息，這樣就會產生一些不可控的行為。

Master單點在多機的方案里，這個單機單點的不足就會更加凸顯。比如現在很多自動駕駛廠商所采用的比較主流的Nvidia Drive PX2板卡，它就包括兩個系統：一個主系統，一個是冗余備份系統即容錯系統。如果使用ROS通信在PX2上進行部署，Master只能起在一個節點上。如上圖所示：左側是它的主系統，右側是它的冗余備份系統。當主系統里面Rosmaster宕機之后，備份系統里面的節點其實并不知道Rosmaster已經處于一個宕機的狀態，那么備份系統就起不到其目的和意義了。因為此時整個系統處于一個功能不完整的狀態，所以就失去了冗余備份的意義。

使用RTPS服務發現協議實現完全的P2P網絡拓撲

Apollo ROS進行了比較大的改造：先把這個中心化的網絡拓撲給去掉，然后建立了一個點對點之間的一個復雜網絡拓撲，主要是使用RTPS服務發現協議去完成P2P網絡拓撲。如上圖所示：右側是ROS Node的一個框架圖。左下角是引入RTPS服務相關的一些功能。其它部分是ROS Node現有的一些功能。Ros Node是分層級式的結構，最上層是Handler，Handler提供節點和ROS整個通信的基本交互的句柄。下一層左側和右側定義了這個節點發送和訂閱的Channel信息。再下一層是Middleware，Middleware是這個節點和其它節點進行通信的時候去完成鏈路的建立和數據的發送。

接下來的一層左下角RTPS是新引入的一個功能。改造之后的ROS Node架構，當一個節點被啟動的時候，它會通過RTPS向所有的節點發送信息：現在有一個新的節點要加入到這個拓撲網絡。當它離開的時候，也會發送消息告訴所有的節點：現在這個節點要退出。以前這些功能都是通過Rosmaster來完成的。

下面通過幾張圖來描述：節點建立連接和通訊的一個主要流程。

第一步：Sub節點啟動，通過組播向網絡注冊。

訂閱節點在啟動的時候，它會向當前這個域里面所有的節點發送信息：現在有一個新的節點要啟動。

第二步：通過節點發現，兩兩建立unicast。

所有的節點在接收到新加入這個節點發生拓撲信息變更之后，會和新加入這個節點分別建立兩兩連接關系。

第三步：向新加入的節點發送它們已經有拓撲信息。

所有已經存在的節點會向新加入的節點發送它們已經有拓撲信息，也就是在新節點加入之前每個節點其實是維護了它和其它所有節點的一個連接關系，這個連接關系發送給接收節點，供接收節點去更新自己的網絡拓撲結構。

第四步：收發雙方建立連接，開始通信。

當新加入節點接到所有節點發送出來的歷史拓撲信息之后，它會根據它自己注冊的實際消息內容去決定和哪些節點建立實際的通信連接。如上圖所示：新加入節點只和右下角的一個節點之間有拓撲關系，它除了維護所有的節點給它發送出的整個網絡拓撲信息之外，同時會和發送節點建立點對點的通信連接。

通過RTPS拓撲發現方式，Apollo ROS去除了對Rosmaster這一個單點的依賴，從而提升整個系統的魯棒性。這個修改完全是對ROS底層的修改，用戶基于原生ROS代碼寫的節點程序，到Apollo ROS是完全兼容的一個遷移即開發者不需要去改動任何的接口，就可以直接使用RTPS網絡拓撲這種新的關系建立。

---

3.數據兼容性擴展

數據兼容性擴展的原因

原生ROS基于Message的訂閱發布消息模型。發送者和接收者在進行實際通訊之前需要進行消息格式定義，其包含字段：基礎的數據類型或者復雜的數據類型。在它們進行消息通信的時候，才可以有選擇性的去建立通信連接和數據實際發送。如果有一個節點訂閱的消息類型不是Channel預先指定的消息類型，這種通信連接是建立不起來的?；蚴菑娭浦付ㄒ粋€節點去訂閱某一種類型的Channel信息，但是它的實際回調函數里卻寫的是另外一種消息類型，這種編譯可能在實際運行的時候就會報相關的一些錯誤。

Message是兩個節點進行消息通信的抽象描述文件。這個描述文件提前定義好兩個節點之間進行消息通信的基本數據類型。ROS采用這種方式是因為能比較大概率地對兩個節點之間進行解耦合，同時兩個節點之間也是跨語言的，即不需要關注兩個節點是用什么語言寫的，都可以通過這種描述文件去進行實際的消息通信。通過Message通信的時候接、收節點在接受到信息之后，會進行MD5的校驗、驗證這個消息是否符合它的預先訂閱，或者是在使用消息之后才會去進行消息的回調處理。

但是ROS基于Message這種通訊方式有很多的缺點。它最大限度解放兩個點之點的一個耦合關系也帶來了一些問題。比如Message接口升級，不同版本之間的兼容是需要做大量的適配工作。再如某個模塊進行升級，之前所錄制的一些實驗數據，在進行回放的時候就會產生不匹配的現象。

歷史數據在接口升級之后也面臨著無法轉化和兼容使用的問題。

---

深度融合Protobuf功能，實現數據兼容性擴展

Apollo ROS實踐里面引入了一種新的消息描述的格式去實現很好的向后兼容即Protobuf。只需要在使用的過程中，定義好必須的字段或者是一些新增的字段，新增的字段我們可以使用Optional屬性去描述。在進行模塊升級或者是模塊之間的消息接口升級的時候，下游模塊其實不需要關注新增字段對它來說會造成什么樣的影響。如果它要去使用這個字段的話才需要去進行一定程度的適配。如果它的程序不使用這個新增的字段，就不需要做任何的修改。

上圖是原生ROS和Apollo ROS對數據兼容支持的對比。

為了做好數據兼容，在原生ROS里面，開發者使用了一個trick：將Proto文件序列化成一個字符串信息放到Message信息里面，完成消息的向后兼容。比起Apollo ROS這個方式有兩個明顯的缺點：

它增加了一次數據序列化和反序列化。并把Proto序列化信息壓到Message里面，增加了兩次額外的數據Copy。

如果想實時調試信息，通過Rostopic echo打印出來Message里面那個序列化的字母串，若是采用Wrapper的方式，則這個字符串信息在屏幕上就會是一堆亂碼。

Apollo ROS 為了滿足數據兼容，深度整合了Protobuf的功能。用戶可以直接定義Proto的字段信息，同時信息傳遞的過程不需要再進行額外的Message的數據轉化。另外，在使用調試工具的時候，通過Rostopic echo可以看出原始消息傳遞的實際展示。

總結

以上是生活随笔為你收集整理的Apollo进阶课程㉝丨Apollo ROS原理—2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。