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配置文件，则不会建立连接，反之亦然。