ROS2編程基礎課程--DDS

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實現版本

Product name?產品名稱

License?許可

RMW implementation?RMW實現

Status?狀態

eProsima?Fast RTPS

Apache 2

rmw_fastrtps_cpp

Full support. Default RMW. Packaged with binary releases.

全力支持。默認RMW。打包二進制版本

RTI?Connext

commercial, research

rmw_connext_cpp

Full support. Support included in?binaries, but Connext installed separately.

全力支持。支持包含在二進制文件中，但Connext單獨安裝

RTI?Connext

(dynamic implementation)

動態實現

commercial, research

rmw_connext_dynamic_cpp

Support paused. Full support until alpha 8.*

支持暫停。完全支持直到alpha 8

ADLINK?Opensplice

Apache 2, commercial

rmw_opensplice_cpp

Partial support. Support included in binaries, but OpenSplice installed separately.

部分支持。支持包含在二進制文件中，但OpenSplice單獨安裝

OSRF?FreeRTPS

Apache 2

–

Partial support. Development paused.?部分支持。發展暫停

“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?歷史

Keep last: only store up to N samples, configurable via the queue depth option.

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

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

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

Depth?深度

Size of the queue: only honored if used together with “keep last”.

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

Reliability?可靠性

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

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

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

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

Durability?持續性

Transient local: the publisher becomes responsible for persisting samples for “late-joining” subscribers.

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

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持續性配置文件的兼容性

Publisher

Subscriber

Connection

Result

Volatile

Volatile

Yes

Volatile

Volatile

Transient local

No

Transient local

Volatile

Yes

Volatile

Transient local

Transient local

Yes

Transient local

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

Publisher

Subscriber

Connection

Result

Best effort

Best effort

Yes

Best effort

Best effort

Reliable

No

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配置文件，則不會建立連接，反之亦然。

文檔數據庫服務 DDS

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。