本系列用來記錄ROS2的學習過程，有錯誤或者不合理的地方請大家指正。由於博主具有ROS1的學習經歷，會新增一些與ROS1的一些對比，當然這對於ROS2本身的學習內容沒有絲毫影響，歡迎大家積極與我在評論區交流。如果給您帶來幫助，希望能給點個關注，以後還會陸續更新有關機器人的內容，點個關注不迷路~歡迎大家一起交流學習。
1.為什麼選擇ROS2?
由於ROS1基於TCP/IP通訊機制，這就導致了ROS1不可避免的出現以下缺陷：
- 實時性差
- 嵌入式裝置不友好
- 需要大頻寬的穩定網路連線
- 多用於學術應用
2. ROS2 的架構
針對以上ROS1中存在的問題，ROS2對其進行改進以解決上述問題。
如圖所示，ROS1需要一個Master來處理髮布-訂閱通訊中間層，而ROS2採用基於RTSP（Real-Time Publish-Subscribe）協議的DDS作為中間層，DDS（Data-Distribution Service)資料分散式服務是一種用於實時和嵌入式系統釋出-訂閱式通訊的工業標準，DDS不需要像ROS1藉助master來完成兩個節點的通訊，這使得系統更加容錯和靈活。DDS廣泛應用在各種軍用場景下，證明了DDS的可靠性。同時，ROS2可以部署在多種作業系統中。
多個⼚商提供多種DDS實現，⼀般來說DDS的底層通訊機制基於UDP協議或者共享記憶體機制（當然也有⼚商提供基於TCP的DDS實現），⽽ROS2⽀持多種DDS實現，⽤⼾可以根據實際情況選擇DDS中間層， ⽬前來說ROS2 Foxy完整⽀持以下DDS中間層：
- eProsima的Fast RTPS（當前ROS2版本預設的DDS實現）
- RTI的Connext DDS
- Eclipse Cyclone DDS
3.ROS2的內部架構
ROS2主要包括兩個主要的內部介面：
- RMW API（ROS middleware interface)
- RCL API（ROS client library interface)
rmw API是ROS2軟體棧和底層中介軟體的實現介面。用於ROS2的底層中介軟體是DDS或RTPS實現，負責發現、釋出和訂閱機制、服務的請求-應答機制和訊息型別的序列化。
rcl API是一個稍高階的API，用於實現客戶端庫，不直接接觸中介軟體實現，而是通過ROS中介軟體介面(rmw API)抽象來實現。
4.ROS2中的QoS
ROS2中引⼊了Quality of Service, QoS(服務質量)的策略⽤於配置節點間通訊，進⽽提升了ROS2適應於不同應⽤場景的靈活性。ROS1只⽀持基於TCP的通訊，通過配置QoS，ROS2可以表現出TCP的可靠性，也可以表現出UDP那樣的⾼實時性。⽤⼾可以通過選擇不同的QoS配置⽂件以實現不同的通訊表現，QoS配置⽂件為策略的集合，ROS2提供了預設的QoS配置⽂件，如下所⽰：
- 釋出-訂閱機制的QoS設定
- 服務 (Service) 的QoS設定
- 感測器資料的QoS設定
- 引數的QoS設定
- DDS中間層預設的QoS設定
瞭解更多DDS相關背景，可以參考這篇⽂章：
About internal ROS 2 interfaces — ROS 2 Documentation: Foxy documentation
所以，由於ROS1與ROS2在架構方式上的不同，ROS1在啟動時需要啟動roscore，而ROS2則不需要（yyds）。
參考文章：ROS2探索總結（二）——走近ROS2.0時代 - 古月居 (guyuehome.com)
擁抱ROS2系列：ROS2概述和實踐入門(一) - 知乎 (zhihu.com)
都看到這了，點個推薦再走吧~
未經允許，禁止轉載。