ROS1的通信架構(gòu)的基礎(chǔ)通信方式及相關(guān)概念

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

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

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

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

rosnode list 列出當(dāng)前運行的node信息

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

rosnode kill node_name 結(jié)束某個node

rosnode ping 測試鏈接節(jié)點

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

rosnode cleanup 清除不可到達節(jié)點的注冊信息

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

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

二、topic<-->msg

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

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

rostopic list 列出當(dāng)前所有topic

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

rostopic echo topic_name 顯示某個topic的內(nèi)容

rostopic pub topic_name 向某個topic發(fā)布內(nèi)容

rostopic bw topic_name 查看某個topic的帶寬

rostopic hz 查看某個topic的頻率

rostopic find topic_type 查看某個類型的topic

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

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

rosmsg list 列出系統(tǒng)消息

rosmsg show msg_name 顯示某個msg的格式

---常見消息名稱--

Vector 矢量; 向量

twist 轉(zhuǎn)動，旋轉(zhuǎn)

covariance 協(xié)方差；協(xié)變性；共離散;

Odometry 里程計

quaternion 四元組

• 話題的通信機制

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

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

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

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

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

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

6. Listener 嘗試與 Talker 建立網(wǎng)絡(luò)連接Listener 接收到確認信息后，使用 TCP 嘗試與 Talker 建立網(wǎng)絡(luò)連接。

7. Talker 向 Listener 發(fā)布數(shù)據(jù)成功建立連接后，Talker 開始向 Listener 發(fā)送話題消息數(shù)據(jù)。

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

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

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

注意：遠程過程調(diào)用（RPC）可以理解為一個進程里面調(diào)用另外一個進程的函數(shù)。

rosservice list 顯示服務(wù)列表

rosservice info 打印服務(wù)信息

rosservice type 打印服務(wù)類型

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

rosservice call 使用所提供的args調(diào)用服務(wù)

rosservice args 打印服務(wù)參數(shù)

rosservice find 查找服務(wù)

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

rossrv show 顯示服務(wù)描述

rossrv list 列出所有服務(wù)

rossrv md5 顯示服務(wù)md5

rossrv package 列出包服務(wù)

rossrv packages 列出包含服務(wù)的包

• 服務(wù)通信機制

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

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

parameter server: 參數(shù)服務(wù)器維護的一般是靜態(tài)數(shù)據(jù)字典，它使用互聯(lián)網(wǎng)傳輸，在節(jié)點管理器master中運行，實現(xiàn)整個通信。

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

• 參數(shù)管理機制

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

• 

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

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

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

action protocal: action協(xié)議包含三部分,目標（設(shè)定終點），反饋（實時狀態(tài)信息），結(jié)果（時長、最終姿態(tài)）。

ROS1和ROS2通信架構(gòu)比對

這里主要給大家介紹ROS2和ROS1的通信架構(gòu)區(qū)別，ROS1和ROS2的架構(gòu)如下，可以分成3層：OS層、中間層和應(yīng)用層

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

ROS 2 的通信模型

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

基于DDS數(shù)據(jù)分發(fā)服務(wù)的ROS2模型包含以下幾個關(guān)鍵概念。

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

發(fā)布者（Publisher） :數(shù)據(jù)發(fā)布的執(zhí)行者，支持多種數(shù)據(jù)類型的發(fā)布，可以與多個數(shù)據(jù)寫入器（DataWriter）相聯(lián)，發(fā)布一種或多種主題（Topic）的消息。

訂閱者（Subscriber） :數(shù)據(jù)訂閱的執(zhí)行者，支持多種數(shù)據(jù)類型的訂閱，可以與多個數(shù)據(jù)讀取器（DataReader）相聯(lián)，訂閱一種或多種主題（Topic）的消息。

數(shù)據(jù)寫入器（DataWriter） :上層應(yīng)用向發(fā)布者更新數(shù)據(jù)的對象，每個數(shù)據(jù)寫入器對應(yīng)一個特定的Topic，類似于ROS 1中的一個消息發(fā)布者。

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

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

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

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