ROS2編程基礎課程--DDS

• 2019 年 10 月 5 日
• 筆記

版權聲明：本文為部落客原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。

本文鏈接：https://blog.csdn.net/ZhangRelay/article/details/100772967

ROS 2 and different DDS/RTPS vendors ROS 2和不同的DDS / RTPS供應商

ROS 2 is built on top of DDS/RTPS as its middleware, which provides discovery, serialization and transportation. This article explains the motivation behind using DDS implementations, and/or the RTPS wire protocol of DDS, in detail, but in summary DDS is an end-to-end middleware that provides features which are relevant to ROS systems, such as distributed discovery (not centralized like in ROS 1) and control over different 「Quality of Service」 options for the transportation.

ROS 2建立在DDS / RTPS之上，將其作為中間件，提供發現、序列化和傳輸等功能。 本節詳細介紹採用DDS實現和（或）DDS的RTPS有線協議的緣由，但先總述一下，DDS是一個端到端的中間件，它提供了ROS系統相關的功能，例如分散式發現（並不是ROS 1採用的集中式，如roscore）和控制傳輸不同「服務品質」的選項。

DDS is an industry standard which is then implemented by a range of vendors, such as RTI』s implementation Connext or ADLink』s implementation OpenSplice RTPS (a.k.a. DDSI-RTPS) is the wire protocol used by DDS to communicate over the network, and there are implementations of that which do not fulfill the full DDS API, but provide sufficient functionality for ROS 2, such as eProsima』s implementation Fast RTPS.

DDS是一個行業標準，然後由一系列供應商實施，如：RTI的實現版本-Connext或ADLink的實現版本-OpenSplice RTPS（又名DDSI-RTPS）是DDS用於通過網路進行通訊的有線協議，雖然有些實現並不能滿足完整的DDS API，但可以為ROS 2提供足夠的功能，例如eProsima的實現版本-快速RTPS。

ROS 2 supports multiple DDS/RTPS implementations because it is not necessarily 「one size fits all」 when it comes to choosing a vendor/implementation. There are many factors you might consider while choosing a middleware implementation: logistical considerations like the license, or technical considerations like platform availability, or computation footprint. Vendors may provide more than one DDS or RTPS implementation targeted at meeting different needs. For example, RTI has a few variations of their Connext implementation that vary in purpose, like one that specifically targets microcontrollers and another which targets applications requiring special safety certifications (we only support their standard desktop version at this time).

ROS 2支援多種DDS / RTPS實現，因此在選擇供應商/實現時，並不是「一刀切」。在選擇中間件實現時，可能會考慮許多因素：許可、技術、平台可用性或計算佔用空間等因素。供應商可能會提供多個針對滿足不同需求的DDS或RTPS實現版本。例如，RTI有一些Connext實現的變化，其目的各不相同，例如專門針對微控制器而另一個針對需要特殊安全認證的應用（目前ROS 2僅支援其標準桌面版本）。

In order to use a DDS/RTPS implementation with ROS 2, a 「ROS Middleware interface」 (a.k.a. rmw interface or just rmw) package needs to be created that implements the abstract ROS middleware interface using the DDS or RTPS implementation』s API and tools. It』s a lot of work to implement and maintain RMW packages for supporting DDS implementations, but supporting at least a few implementations is important for ensuring that the ROS 2 codebase is not tied to any one particular implementation, as users may wish to switch out implementations depending on their project』s needs.

為了使用DDS / RTPS實現與ROS 2，ROS中間介面「ROS Middleware interface, RMW」（又名rmw介面或rmw）封裝需要創建一個使用DDS實現或RTPS實現的API和工具抽象ROS中間件介面。實現和維護RMW包用於支援DDS開發需要做很多工作，但至少支援一些實現對於確保ROS 2程式碼庫不依賴於任何一個特定實現非常重要，因為用戶依據具體項目的需求，可能希望根據需要切換實現版本。具體如下：

Supported RMW implementations

支援的RMW實現版本

「Partial support」 means that one or more of the features required by the rmw interface is not implemented.

「部分支援」意味著rmw介面所需的一個或多個功能並未實現。

For practical information on working with multiple RMW implementations, see the "Working with multiple RMW implementations" tutorial.

有關使用多種RMW實現的實用資訊，請參考「使用多種RMW實現」教程。

About Quality of Service Settings

關於服務品質設置

Overview 概述

ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes. With the right set of Quality of Service policies, ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between. Unlike ROS 1, which primarily only supported TCP, ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a 「best effort」 policy would be more suitable, or in real-time computing systems where the right Quality of Service profile is needed to meet deadlines.

ROS 2提供豐富的服務品質（QoS）策略，支援調整節點之間的通訊。通過正確的服務品質策略集，ROS 2可以像TCP一樣可靠，也可以像UDP那樣儘力而為，其間有許多可能的狀態。與主要僅支援TCP的ROS 1不同，ROS 2更好支援具有損耗的無線網路環境中基礎DDS傳輸的靈活性，其中「儘力而為」策略將更合適，或者在具有準確品質的實時計算系統中需要服務配置文件來設置最後期限。

A set of QoS 「policies」 combine to form a QoS 「profile」. Given the complexity of choosing the correct QoS policies for a given scenario, ROS 2 provides a set of predefined QoS profiles for common usecases (e.g. sensor data). At the same time, users are given the flexibility to control specific profiles of the QoS policies.

一組QoS「策略」組合形成了QoS「配置文件」。考慮到為給定方案選擇正確的QoS策略的複雜性，ROS 2為常見案例（例如感測器數據）提供了一組預定義的QoS配置文件。同時，用戶可以靈活地控制QoS策略的特定配置文件。

QoS profiles can be specified for publishers, subscribers, service servers and clients. A QoS profile can be applied independently to each instance of the aforementioned entities, but if different profiles are used it is possible that they will not connect.

可以為發布器、訂閱器、提供服務的伺服器和客戶端指定QoS配置文件。QoS配置文件可以獨立地應用於前述實體的每個實例，但是如果使用不同的配置文件，則它們可能不會建立連接。

QoS policies QoS策略

The base QoS profile currently includes settings for the following policies:

基本QoS配置文件當前包含以下策略的設置：

• History 歷史
  1. Keep last: only store up to N samples, configurable via the queue depth option.

保留最後（最新）：僅存儲N個樣本，可通過隊列深度選項進行配置。

1. Keep all: store all samples, subject to the configured resource limits of the underlying middleware.

全部保留：根據底層中間件的配置資源限制存儲所有樣本。

• Depth 深度

1. Size of the queue: only honored if used together with 「keep last」.

隊列的大小：只有與「保留最後（最新）」一起使用，才可實現。

• Reliability 可靠性

1. Best effort: attempt to deliver samples, but may lose them if the network is not robust.

儘力而為：嘗試傳輸樣本，但如果網路不健全，可能會丟失樣本。

1. Reliable: guarantee that samples are delivered, may retry multiple times.

可靠：保證樣本已交付，可多次重試。

• Durability 持續性

1. Transient local: the publisher becomes responsible for persisting samples for 「late-joining」 subscribers.

瞬態本地：發布器負責為「遲到的」訂閱器保留樣本。

1. Volatile: no attempt is made to persist samples.

易失性：沒有試圖持續的樣本。

For each of the policies there is also the option of 「system default」, which uses the default of the underlying middleware which may be defined via DDS vendor tools (e.g. XML configuration files). DDS itself has a wider range of policies that can be configured. These policies have been exposed because of their similarity to features in ROS 1; it is possible that in the future more policies will be exposed in ROS 2.

對於每個策略，還有「system default」選項，它使用可以通過DDS供應商工具（例如XML配置文件）定義的底層中間件的默認值。DDS本身具有可以配置的更廣泛的策略。由於它們與ROS 1中的特徵相似，因此開放了這些配置; 有可能在未來更多的配置將在ROS 2中開放。

Comparison to ROS 1 與ROS 1的比較

The history and depth policies in ROS 2 combine to provide functionality akin to the queue size in ROS 1.

ROS 2中的歷史和深度策略結合起來提供類似於ROS 1中的隊列大小的功能。

The reliability policy in ROS 2 is akin to the use of either UDPROS (only in roscpp) for 「best effort」, or TCPROS (ROS 1 default) for reliable. Note however that even the reliable policy in ROS 2 is implemented using UDP, which allows for multicasting if appropriate.

ROS 2中的可靠性策略類似於使用UDPROS（僅支援roscpp）用於「儘力而為」或TCPROS（ROS 1默認值）用於可靠性。但請注意，即使ROS 2中的可靠策略使用UDP實現的，如果合適，它允許進行多點廣播。

The durability policy combined with a depth of 1 provides functionality similar to that of 「latching」 subscribers.

持續性策略與深度1相結合提供了類似於「鎖定」訂閱器的功能。

QoS profiles QoS配置文件

Profiles allow developers to focus on their applications without worrying about every QoS setting possible. A QoS profile defines a set of policies that are expected to go well together for a particular use case.

配置文件允許開發人員專註於應用程式，而無需擔心每個QoS設置。QoS配置文件定義了一組策略，這些策略可以在特定用例中很好地協同工作。

The currently-defined QoS profiles are: 當前定義的QoS配置文件是：

• Default QoS settings for publishers and subscribers 發布器和訂閱器默認的QoS設置

In order to make the transition from ROS 1 to ROS 2, exercising a similar network behavior is desirable. By default, publishers and subscribers are reliable in ROS 2, have volatile durability, and 「keep last」 history.

為了實現從ROS 1到ROS 2的轉換，期望執行類似的網路行為。默認情況下，發布器和訂閱器在ROS 2中 是可靠的，具有不穩定的持續性，並且「保持最後（最新）」的歷史記錄。

• Services 服務

In the same vein as publishers and subscribers, services are reliable. It is especially important for services to use volatile durability, as otherwise service servers that re-start may receive outdated requests. While the client is protected from receiving multiple responses, the server is not protected from side-effects of receiving the outdated requests.

與發布器和訂閱器一樣，服務也是可靠的。對於使用volatile（易失）持續性的服務尤其重要，否則重新啟動 的伺服器可能會收到過時的請求。雖然保護客戶端不接收多個響應，但是伺服器不受保護,避免受接收過期請求 的副作用。

• Sensor data 感測器數據

For sensor data, in most cases it』s more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some. For that reason the sensor data profile uses best effort reliability and a smaller queue depth.

對於感測器數據，在大多數情況下，及時接收讀數更重要，而不是確保所有讀數都到達。也就是說，開發人員 一旦捕獲就會想要最新的樣本，但可能會損失一些樣本。因此，感測器數據配置文件使用儘力而為的可靠性和 較小的隊列深度。

• Parameters 參數

Parameters in ROS 2 are based on services, and as such have a similar profile. The difference is that parameters use a much larger queue depth so that requests do not get lost when, for example, the parameter client is unable to reach the parameter service server.

ROS 2參數是基於服務的，因此具有類似的配置文件。不同之處在於參數使用更大的隊列深度，以便在參 數客戶端無法訪問參數服務伺服器時請求不會丟失。

• System default 系統默認

This uses the system default for all of the policies.

這將使用所有策略的系統默認值。

Click here for the specific policies in use for the above profiles. The settings in these profiles are subject to further tweaks, based on the feedback from the community.

單擊此處查看上述配置文件使用的特定策略。根據社區的回饋，這些配置文件中的設置可能會進一步調整。

While ROS 2 provides some QoS profiles for common use cases, the use of policies that are defined in DDS allows ROS users to take advantage of the vast knowledge base of existing DDS documentation for configuring QoS profiles for their specific use case.

雖然ROS 2為常見用例提供了一些QoS配置文件，但使用DDS中定義的策略允許ROS用戶利用現有DDS文檔的龐大知識庫來為其特定用例配置QoS配置文件。（支援自定義）

QoS compatibilities QoS兼容性

Note: This section refers to publisher and subscribers but the content applies to service servers and clients in the same manner.

注意：此部分涉及發布器和訂閱器（主題），但內容同樣適用於提供服務的伺服器和客戶端。

QoS profiles may be configured for publishers and subscribers independently. A connection between a publisher and a subscriber is only made if the pair has compatible QoS profiles. QoS profile compatibility is determined based on a 「Request vs Offerer」 model, wherein connections are only made if the requested policy of the subscriber is not more stringent than the that of the publisher. The less strict of the two policies will be the one used for the connection.

QoS配置文檔可以獨立地為發布器和訂閱器進行配置。僅當對具有兼容的QoS配置文件時，才會建立發布器與訂閱器之間的連接。QoS配置文件兼容性是基於「請求與提供者」模型確定的，其中僅在所請求的訂閱器策略不比發布器的策略更嚴格時才進行連接。兩種策略中較不嚴格的方式是用於連接的策略。

The QoS policies exposed in ROS 2 that affect compatibility are the durability and reliability policies. The following tables show the compatibility of the different policy settings and the result:

ROS 2中開放的影響兼容性的QoS策略是持續性和可靠性策略。下表顯示了不同策略設置和結果的兼容性：

Compatibility of QoS durability profiles: QoS持續性配置文件的兼容性

Transient local Volatile Yes Volatile Transient local Transient local Yes Transient local

Compatibility of QoS reliability profiles: QoS可靠性配置文件的兼容性

Reliable Best effort Yes Best effort Reliable Reliable Yes Reliable

In order for a connection to be made, all of the policies that affect compatibility must be compatible. That is, even if a publisher-subscriber pair has compatible reliability QoS profiles, if they have incompatible durability QoS profiles a connection will not be made, and vice-versa.

為了建立連接，所有影響兼容性的策略必須兼容。也就是說，發布器-訂閱器需要具有兼容可靠的QoS配置文件，如果它們具有不兼容持續性QoS配置文件，則不會建立連接，反之亦然。