ROS的通信架構是ROS的靈魂所在，它包括數據處理，進程運行，消息傳遞等 。這篇文章主要介紹ROS1的通信架構的基礎通信方式和相關概念，因為ROS1和ROS2的通信方式相差很大，文章后面會介紹ROS2 的通信框架和差異。

接下來介紹一下三組概念：master<-->node<-->launch、topic<-->msg、service<-->srv<-->parameter <-->action.

一、master<-->node<-->launch

node: ROS最小的進程單元就是節點node。一個軟件包里面有多個可執行文件，可執行文件被運行就是進程（process）,這個進程就是節點node。

rosnode list 列出當前運行的node信息

rosnode info node_name 顯示出node的詳細信息

rosnode kill node_name 結束某個node

rosnode ping 測試鏈接節點

rosnode machine 列出在特定機器或列表機器上運行的節點

rosnode cleanup 清除不可到達節點的注冊信息

master: ROS網絡架構的管理中心，管理著各個node。node先在master進行注冊，node之間通信需要經過master編排才能點對點的通信。所以ROS程序啟動， 第一步先執行roscore指令啟動master,執行指令后同時啟動的還有rosout（負責日志輸出、記錄當前系統狀態）和parameter server（參數服務器，非node,負責存儲參數配置） ,再由節點管理器按照cmakelists.txt、package.xml配置執行rosrun pkgname node_name 依次啟動node 。

launch: 復雜節點啟動管理文件。執行roslaunch pkg_name file_name.launch 指令后，首先系統先檢測roscore是否啟動，如果沒有啟動會默認自動拉起。然后按照launch配置啟動規則，有序啟動多個節點，減少終端輸入。

二、topic<-->msg

ROS1的通信方式有四種：topic主題，service服務，parameter service 參數服務器 ,actionlib動作庫。

topic： ROS通信最常用的一種，對實時性、周期性消息，使用topic傳輸是最佳選擇。簡單的說，啟動topic 首先需要publisher和subscriber 節點到master進行注冊，然后publisher 會發布topic，subscriber在master指揮下會訂閱topic,從而建立sub-pub之間的通信。一個topic可以有多個publisher,一個publisher可以同時向多個subscriber發送消息，subscriber 接收消息會進行處理（回調函數 callback），publisher發送消息后就繼續執行下一個動作，消息的狀態和處理結構都不會影響publisher執行，subscriber只管消息接受和處理，publisher掛死不會對subscriber節點狀態影響,所以topic通信實現了node之間的解耦，此通信方式屬于異步通信。

rostopic list 列出當前所有topic

rostopic info topic_name 顯示某個topic的屬性信息

rostopic echo topic_name 顯示某個topic的內容

rostopic pub topic_name 向某個topic發布內容

rostopic bw topic_name 查看某個topic的帶寬

rostopic hz 查看某個topic的頻率

rostopic find topic_type 查看某個類型的topic

rostopic type topic_name 查看某個topic類型的msg

message: 直觀查看message就是一種數據格式。嚴格說按照規定的格式發送的數據就是message消息，所以消息既是內容也是標準格式。基本的msg包括bool、int8、int16、int32、int64(以及uint)、float、float64、string、time、 duration、header、可變長數組array[]、固定長度數組array[C]。

rosmsg list 列出系統消息

rosmsg show msg_name 顯示某個msg的格式

---常見消息名稱--

Vector 矢量; 向量

twist 轉動，旋轉

covariance 協方差；協變性；共離散;

Odometry 里程計

quaternion 四元組

• 話題的通信機制

此處假設 Talker 首先啟動，可分成圖中所示的七步來分析建立通信的詳細過程：

1. Talker 注冊Talker 啟動，通過 1234 端口使用 RPC 向 ROS Master 注冊發布者的信息，包含所發布消息的話題名；ROS master 會將節點的注冊信息加入注冊列表中。

2. Listener 注冊Listener 啟動，同樣通過 RPC 向 ROS Master 注冊訂閱者的信息，包含需要訂閱的話題名。

3. ROS Master 進行信息匹配Master 根據 Listener 的訂閱信息從注冊列表中進行查找，如果沒有找到匹配的發布者，則等待發布者的加入；如果找到匹配的發布者信息，則通過 RPC 向 Listener 發布 Talker 的 RPC 地址信息。

4. Listener 發送連接請求Listener 接收到 Master 發回的 Talker 地址信息，嘗試通過 RPC 向 Talker 發送連接請求，傳輸訂閱的話題名、消息類型以及通信協議（TCP/UDP）。

5. Talker 確認連接請求Talker 接收到 listener 發送的連接請求后，繼續通過 RPC 向 Listener 確認鏈接信息，其中包含自身的 TCP 地址信息。

6. Listener 嘗試與 Talker 建立網絡連接Listener 接收到確認信息后，使用 TCP 嘗試與 Talker 建立網絡連接。

7. Talker 向 Listener 發布數據成功建立連接后，Talker 開始向 Listener 發送話題消息數據。

   從上面的分析中可以發現，前五個步驟使用的通信協議都是 RPC，最后發布數據的過程才使用到 TCP。ROS Master 在節點建立連接的過程中起到了重要作用，但是并不參與節點之間最終的數據傳輸。

三、service<-->srv<-->parameter <-->action

service: 請求--查詢雙向同步通信模型，service分層兩部分，客戶端（client）和服務端（server）。客戶端(client)發送請求(request)要等服務端(server)處理，反饋回復（reply）才會發送下一個請求到服務端（server）.

注意：遠程過程調用（RPC）可以理解為一個進程里面調用另外一個進程的函數。

rosservice list 顯示服務列表

rosservice info 打印服務信息

rosservice type 打印服務類型

rosservice uri 打印服務ROSRPC uri(統一資源標識，URI包含URL)

rosservice call 使用所提供的args調用服務

rosservice args 打印服務參數

rosservice find 查找服務

srv: service的數據類型，service通信的數據格式定義在*srv中，包含請求（request）和響應（reply）兩部分。

rossrv show 顯示服務描述

rossrv list 列出所有服務

rossrv md5 顯示服務md5

rossrv package 列出包服務

rossrv packages 列出包含服務的包

• 服務通信機制

服務是一種帶有應答的通信機制，通信原理如下圖所示，與話題的通信相比，其減少了 Listener 與 Talker 之間的 RPC 通信。

1. Talker 注冊Talker 啟動，通過 1234 端口使用 RPC 向 ROS Master 注冊發布者的信息，包含所發布消息的話題名；ROS master 會將節點的注冊信息加入注冊列表中。
2. Listener 注冊Listener 啟動，同樣通過 RPC 向 ROS Master 注冊訂閱者的信息，包含需要訂閱的服務名。
3. ROS Master 進行信息匹配Master 根據 Listener 的訂閱信息從注冊列表中進行查找，如果沒有找到匹配的服務提供者，則等待該服務提供者的加入；如果找到匹配的服務提供者信息，則通過 RPC 向 Listener 發布 Talker 的 TCP 地址信息。
4. Listener 嘗試與 Talker 建立網絡連接Listener 接收到確認信息后，使用 TCP 嘗試與 Talker 建立網絡連接，并發送服務的請求數據。
5. Talker 向 Listener 發布數據Talker 接收到服務請求和參數后，開始執行服務功能，執行完成后，向 Listener 發送應答數據。

parameter server: 參數服務器維護的一般是靜態數據字典，它使用互聯網傳輸，在節點管理器master中運行，實現整個通信。

rosparam set param_key param_value 設置參數****rosparam get param_key 顯示參數 rosparam load file_name 從文件加載參數 (yaml格式) rosparam dump file_name 保存參數到文件 (yaml格式)rosparam delete 刪除參數rosparam list 列出參數名稱

• 參數管理機制

  參數類似于 ROS 中的全局變量，由 ROS Master 進行管理，其通信機制較為簡單，不涉及 TCP/UDP 的通信。

• 

1. Talker 設置變量Talker 使用 RPC 向 ROS Master 發送參數設置數據，包含參數名和參數值；ROS Master 會將參數名和參數值保存到參數列表中。
2. Listener 查詢參數值Listener 通過 RPC 向 ROS Master 發送參數查找請求，包含索要查找的參數名。
3. ROS Master 向 Listener 發送參數值Master 根據 Listener 的查找請求從參數列表中進行查找，查找到參數后，使用RPC 將參數數值發送給 Listener。

這里需要注意的是，如果 Talker 向 Master 更新參數值，Listener 在不重新查詢參數值的情況下是無法知曉參數值已經被更新的。所以在很多場景中，需要一種動態參數更新機制。

action: 動作類似service,屬于請求--查詢雙向同步通信模型，但是通信過程連續反饋狀態信息和隨時終止請求。通信雙方在action protocol 下通過消息進行數據交流，client和server為用戶提供API來請求目標或者通過函數調用和回調來執行目標。

action protocal: action協議包含三部分,目標（設定終點），反饋（實時狀態信息），結果（時長、最終姿態）。

ROS1和ROS2通信架構比對

這里主要給大家介紹ROS2和ROS1的通信架構區別，ROS1和ROS2的架構如下，可以分成3層：OS層、中間層和應用層

• OS層：ROS1主要構建在Linux上，但ROS2支持多個操作系統。
• 中間層：ROS1通信基于TCPROS/UDPROS，而ROS2通信基于DDS（data distribution service）數據分發服務。它是專門為RTOS設計的數據分發/訂閱標準，其技術關鍵是以數據為核心的發布/訂閱 模型 DCPS（data-centric publish-subscribe）,DCPS模型類似現在流行的容器命名空間技術，創建了一個全局數據空間，空間內的進程都可以直接訪問。另外ROS2的intra-process 和ROS1的nodelet 數據傳輸方式類似，只是更名了而已，哈哈哈。
• 應用層：ROS1強依賴于master單點，只要單點就會降低系統的可靠性，所以ROS1只適用于實驗室研究，無法商用。ROS2取消了master節點管理器，節點間使用discover發現機制幫助彼此建立鏈接。

ROS 2 的通信模型

ROS 1的通信模型主要包含話題、服務等通信機制，ROS 2的通信模型會稍顯復雜，加入了很多DDS的通信機制。如下圖所示：

基于DDS數據分發服務的ROS2模型包含以下幾個關鍵概念。

參與者（Participant） :在 DDS 中，每一個發布者或者訂閱者都成為參與者，對應于一個使用 DDS 的用戶，可以使用某種定義好的數據類型來 讀/寫 全局數據空間。

發布者（Publisher） :數據發布的執行者，支持多種數據類型的發布，可以與多個數據寫入器（DataWriter）相聯，發布一種或多種主題（Topic）的消息。

訂閱者（Subscriber） :數據訂閱的執行者，支持多種數據類型的訂閱，可以與多個數據讀取器（DataReader）相聯，訂閱一種或多種主題（Topic）的消息。

數據寫入器（DataWriter） :上層應用向發布者更新數據的對象，每個數據寫入器對應一個特定的Topic，類似于ROS 1中的一個消息發布者。

數據讀取器（DataReader） :上層應用從訂閱者讀取數據的對象，每個數據讀取器對應一個特定的Topic，類似于ROS 1中的一個消息訂閱者。

話題（Topic） ：和 ROS 1 中的概念類似，話題需要定義一個名稱和一種數據結構，但 ROS 2 中的每個話題都是一個實例，可以存儲該話題中的歷史消息數據。

質量服務原則（Quality of Service） :簡稱 QoS Policy，這是 ROS 2 中新增的、也是非常重要的一個概念，控制各方面與底層的通信機制，主要從時間限制、可靠性、持續性、歷史記錄這幾個方面，滿足用戶針對不同場景的數據需求。

• 實時性增強：數據必須在 deadline 之前完成更新；
• 持續性增強：DDS 可以為 ROS 2 提供數據歷史服務，新加入的節點也可以獲取發布者發布的所有歷史數據；
• 可靠性增強：配置可靠性原則，用戶可以根據需求選擇性能模式（BEST_EFFORT）或者穩定模式（RELIABLE）。