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

ROS在開發過程中，基于功能把整個自動駕駛系統分成多個模塊，每個模塊負責自己消息的接收、處理、發布。當模塊需要聯調時，通過框架可以把各個模塊快速的集成到一起。

上周阿波君為大家詳細介紹了「進階課程?Apollo ROS概述」。

此課程簡單地闡述了ROS的歷史，詳細地講解了ROS的五大特征有：點對點、支持分布式、跨語言、輕量級的ROS程序、開源的框架，以及幾個核心概念，其概念包括：松耦合、節點、節點管理器、Topic。此外，還有ROS的操作實踐。

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

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

目錄

1.ROS的不足

大數據傳輸性能瓶頸

單中心的網絡存在單點風險

數據傳輸格式缺乏后向兼容

2.Apollo ROS對ROS的改進

通信性能優化

消息通信延時

吞吐量

CPU資源占用率

---

1.ROS的不足

ROS是很多大學或者實驗室進行探索性項目實驗所采用的基本框架，但在實際的自動駕駛工程化需求面前，還有很多明顯不足。

大數據傳輸性能瓶頸

實驗性項目里面采用的Topic是Message，數據量是比較小的，可能只有幾K或者最多1~2MHZ，但在實際自動駕駛場景里面數據量非常大。例如Lidar一幀數據大概是7M，一秒鐘10幀，就會產生70M/S的流量；一個Camera按5M計算，四個Camera就是20M，如果是按10HZ計算一秒鐘會產生200M左右的數據。ROS架構對大數據傳輸存在很大的性能瓶頸，一種直接后果是時延非常高，這在自動駕駛整個系統里面是非常危險的。

單中心的網絡存在單點風險

中心化的網絡存在明顯的單點風險，整個ROS雖然是一個松耦合的架構，它包含一個節點管理器，節點管理器介入的時候，只是在節點建立通信之前有一個簡單的拓撲映射，這種關系雖說極大程度釋放了各個節點之間開發的耦合，但同時也帶來了比較大的風險。如果Roscore存在一些故障退出，而節點之間使用了需要不定時的交互方式，像Service 、Parem進行數據交互的時候就會存在一定的風險。如果是分布式系統， Roscore只存在于一臺機器上，Roscore如果出現故障，兩臺機器之間通信就處于一個不可信的狀態。

數據傳輸格式缺乏后向兼容

ROS是基于Message的分發和訂閱的消息通訊框架，使用Message需要提前設置Message包含哪些類型的數據。把這個模塊放到一個更復雜的系統里面的時候，要格外注意Message之間的數據兼容。

我們根據實際的場景需求，在定義的Obstacle信息里面加一段文字，那么相應的下游所有訂閱此Obstacle的節點都要去做對應的適配，同時基于之前的Message所錄制的一些實驗數據，想在新的框架下使用也都需要一個批量的轉化。ROS現有的數據格式缺少后向兼容，此問題在Apollo ROS里面得到解決。

---

2.Apollo ROS對ROS的改進

通信性能優化

首先，我們看看為什么要進行通信優化，主要有以下幾點原因：

• 自動駕駛大量使用傳感器引發很大的傳輸帶寬需求。

自動駕駛使用大量的傳感器，這些傳感器的數據量非常龐大。大量數據在目前ROS的通訊架構里面會帶來比較高的延遲或是丟幀。節點之間通信是一幀一幀進行的，如果上一幀消息高延遲時，下一幀消息的發送就需要等待。ROS提供了這種消息丟棄的機制，如果等待時間長會丟棄一些數據，數據丟棄在實際自動駕駛系統中會造成比較大的風險。

• 單路傳感器消息有多個消費者時負載成倍增長。

自動駕駛系統發送傳感器數據是一對一進行的。例如Lidar向自動駕駛系統發送數據時，如果只有一個訂閱節點，傳輸的數據量是7M乘以10HZ，也就是70MB/S。自動駕駛系統是一個比較復雜的拓撲結構，一個傳感器數據可能會有很多的下游訂閱節點。例如感知的障礙物檢測、通過視覺定位的模塊、用紅綠燈識別等都會訂閱Camera信息。在單點的情況下是一對一，如果是一對多，傳輸的數據會被復制多次，造成網絡負載成倍增加。

針對這一問題，Apollo ROS做了一個基于共享內存的通信機制減少數據的復制次數，從而提升這種通信模式的效率。

如上圖所示，左側是ROS原生的通訊框架，一個數據從發送方到接收方經歷四次數據復制。第一次是從節點到用戶內存的數據復制，第二次是從發送方到內核的數據復制，第三次是經過TCP連接，從內核再向接收節點用戶態空間的復制，第四次是接收節點拿到這個信息之后，通過反序列化把信息取出來組成一個結構變化的信息。

右側是Apollo?ROS優化后的框架，它基于共享內存改進，可以減少兩次數據拷貝。第一次是發送節點把消息序列化成流式數據，第二次是接收節點直接從共享內存里面取相應的消息指針，把共享內存消息取出來進行反序列化成結構化信息進行使用。減少了從用戶到內核態以及從內核態到用戶的兩次數據拷貝。

對于有多個訂閱節點的情況，例如Camera下游會有很多訂閱節點，如果是三個節點，會有三條通信鏈路，分別是四次的內存拷貝，也就是12次數據拷貝。而在基于共享內存的通信方式下，每一條鏈路內存拷貝的次數只需要兩次，三條鏈路只需要六次。

上圖是一個有優化的Apollo ROS Benchmark效果展示，用Apollo ROS替代原生ROS ?Socket的通信方式之后，從實際的路測數據表現情況來看，性能提升非常明顯。以上三張圖分別從三個指標對比兩者的性能。

---

消息通信延時

如圖右上角所示：隨著消息逐漸增大，基于共享內存通信延時比基于原聲ROS Socket的通信延時降低一半。以5M數據為例，傳送一幀5M大小的數據，基于ROS Socket大概需要四毫秒左右的時間，基于共享內存通信只需要兩毫秒左右。

---

吞吐量

如圖左下角所示：整個自動駕駛系統的網絡拓撲結構非常復雜，數據流向的拓撲結構也比較復雜。在一些極端的情況下，整機數據量會增加。在一些多車道，路面狀況比較復雜，車輛較多的情況下，感知和Planning模塊，或者和其它模塊之間的數據流就會成倍增加，所以在測試一些極端情況下，系統吞吐量也是自動駕駛需要考慮的一個重要方面。

如上圖所示，在吞吐量測試1：1情況下，整機性能可以達到5.5GB每秒的速度，如果是1：4，性能提升會更明顯。

---

CPU資源占用率

如圖右下角所示：CPU資源占用率在共享內存通信情況下降低約30%， 主要是因為減少了多次內存復制。

總結

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

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