ROS 2扩展概念#2：服务质量（QoS）| ROS 2学习笔记

在ROS2中，服务质量（QoS，Quality of Service）允许开发者指定和调整通信中的各种参数，以满足不同场景下对数据处理速度、可靠性和实时性的需求。QoS参数影响着ROS2节点间消息传递的行为，包括消息的可靠性、持久性、传输速度等。通过合理配置这些参数，可以优化系统性能，特别是在不同的网络条件和硬件资源限制下。

ROS 2 QoS 概述

ROS 2 提供了丰富的 QoS 策略（ policy ），允许您调整节点之间的通信。 通过正确的服务质量策略集，ROS 2 可以像 TCP 一样可靠，也可以像 UDP 一样尽力而为，并且介于两者之间有很多很多可能的状态。 与主要仅支持 TCP 的 ROS 1 不同，ROS 2 受益于底层 DDS 传输的灵活性，在有损无线网络的环境中（ best effort 策略更合适），而在实时计算系统中，需要设置正确的 QoS 服务配置文件才能按时完成。

一组 QoS 策略组合起来形成 QoS 配置文件（ profile ）。考虑到为给定场景选择正确 QoS 策略的复杂性，ROS 2 为常见用例（例如传感器数据）提供了一组预定义的 QoS 配置文件。 同时，开发人员可以灵活地控制 QoS 配置文件的特定策略。

可以为发布者、订阅者、服务服务器和客户端指定 QoS 配置文件。 QoS 配置文件可以独立地应用于上述实体的每个实例，但如果使用不同的配置文件，它们可能会不兼容，从而阻止消息的传递。

QoS 策略

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

History

• Keep last：仅存储最多 N 个样本，可通过队列深度选项进行配置。
• Keep all：存储所有样本，受底层中间件配置的资源限制。

Depth

• Queue size：仅当 History 策略设置为 Keep last 时才有效。

Reliability

• Best effort：尝试交付样本，但如果网络不健全，可能会丢失样本。
• Reliable：保证样品交付，可多次重试。

Durability

• Transient local：发布者负责保存“晚加入”订阅的样本。
• Volatile：不尝试保存样本。

Deadline

• Duration：发布到主题的后续消息之间的预期最大时间量

Lifespan

• Duration：消息发布和接收之间的最长时间，消息不会被视为过时或过期（过期的消息会被静默丢弃，并且实际上永远不会被接收）。

Liveliness

• Automatic：当任何一个发布者发布消息时，系统将认为该节点的所有发布者在另一个“租赁期限”内都处于活动状态。
• Manual by topic：如果系统手动断言发布者仍处于活动状态（通过调用发布者 API），则系统将认为发布者在另一个“租赁期限”内处于活动状态。

Lease duration

• Duration：在系统认为发布者已失去活力之前，发布者必须表明其处于活动状态的最长时间（失去活力可能表示失败）。

对于每一个非持续时间的策略，还有“系统默认”选项，它使用底层中间件的默认值。 对于每个具有持续时间的策略，还存在一个“默认”选项，这意味着持续时间未指定，底层中间件通常会将其解释为无限长的持续时间。

对比 ROS 1 的改进

ROS 2 中的 History 和 Depth 策略相结合，提供类似于 ROS 1 中队列大小的功能。

ROS 2 中的 Reliability 策略类似于使用 UDPROS（仅在 roscpp 中）在 Best effort 上，或使用 TCPROS（ROS 1 默认）在 Reliable 上。 但请注意，ROS 2 中的可靠策略是使用 UDP 实现的，它允许在适当的情况下进行多播。

Durability 策略的 Transient local 与任何 Depth 策略相结合，提供了类似于“锁定”发布者的功能。 ROS 2 中的其余策略与 ROS 1 中可用的任何策略都不相似，这意味着 ROS 2 在这方面比 ROS 1 具有更多的功能。 将来，ROS 2 中可能会提供更多的 QoS 策略。

QoS 配置文件（ Profile ）

配置文件使开发人员能够专注于他们的应用程序，而不必担心每个可能的 QoS 设置。 QoS 配置文件定义了一组策略，这些策略预计可以很好地配合特定用例。

当前定义的 QoS 配置文件是：

发布者和订阅者的默认 QoS 设置

为了使从 ROS 1 到 ROS 2 的过渡更容易，需要保存类似的网络行为。 默认情况下，Keep last 将是ROS 2 中的发布者和订阅者对于保持队列大小为 10 的历史记录。对于 Reliability 则使用 reliable，对于 Durability使用 volatile，对于 Liveliness 使用 system default。 Deadline, lifespan,和lease durations 也设置为 default 。

服务

与发布者和订阅者一样，服务也是可靠的。 对于服务来说，使用 Durability 使用 volatile 尤其重要，否则重新启动的服务服务器可能会收到过时的请求。 虽然客户端受到保护，不会接收多个响应，但服务器不会受到接收过时请求的副作用的影响。

传感器数据

对于传感器数据，在大多数情况下，及时接收读数比确保所有读数都到达更重要。 也就是说，开发人员希望在捕获最新样本后立即获得最新样本，但代价可能是丢失一些样本。 因此，传感器数据配置文件使用尽力而为的可靠性和较小的队列大小。

参数

ROS 2 中的参数基于服务，因此具有类似的配置文件。 不同之处在于参数使用更大的队列深度，以便在例如参数客户端无法到达参数服务服务器时请求不会丢失。

系统默认

这对所有策略使用 RMW 实现的默认值。 不同的 RMW 实现可能有不同的默认值。

QoS 兼容性

注意：本节涉及发布者和订阅者，但内容以相同的方式适用于服务服务器和客户端。

可以为发布者和订阅者单独配置 QoS 配置文件。 仅当发布者和订阅者具有兼容的 QoS 配置文件时，才会在发布者和订阅者之间建立连接。

QoS 配置文件兼容性是根据“请求与提供”模型确定的。 订阅请求一个其愿意接受的“最低质量”的 QoS 配置文件，而发布者则提供一个其能够提供的“最高质量”的 QoS 配置文件。 仅当请求的 QoS 配置文件的每个策略不比提供的 QoS 配置文件的策略更严格时才会建立连接。 多个订阅可以同时连接到单个发布者，即使它们请求的 QoS 配置文件不同。 发布者和订阅之间的兼容性不受其他发布者和订阅的存在的影响。

下表显示了不同策略设置的兼容性和结果：

可靠性QoS策略的兼容性：

Publisher	Subscription	Compatible
Best effort	Best effort	Yes
Best effort	Reliable	No
Reliable	Best effort	Yes
Reliable	Reliable	Yes

Durability QoS策略的兼容性：

Publisher	Subscription	Compatible	Result
Volatile	Volatile	Yes	New messages only
Volatile	Transient local	No	No communication
Transient local	Volatile	Yes	New messages only
Transient local	Transient local	Yes	New and old messages

为了实现对后期订阅者可见的“锁定”主题，发布者和订阅者都必须同意使用“Transient Local”。

Deadline QoS 策略的兼容性：

假设 x 和 y 是任意有效的持续时间值。

Publisher	Subscription	Compatible
Default	Default	Yes
Default	x	No
x	Default	Yes
x	x	Yes
x	y (where y > x)	Yes
x	y (where y < x)	No

Liveliness QoS 策略的兼容性：

Publisher	Subscription	Compatible
Automatic	Automatic	Yes
Automatic	Manual by topic	No
Manual by topic	Automatic	Yes
Manual by topic	Manual by topic	Yes

Lease duration QoS策略的兼容性：

假设 x 和 y 是任意有效的持续时间值。

Publisher	Subscription	Compatible
Default	Default	Yes
Default	x	No
x	Default	Yes
x	x	Yes
x	y (where y > x)	Yes
x	y (where y < x)	No

为了建立连接，所有影响兼容性的策略都必须兼容。 例如，即使请求的和提供的 QoS 配置文件对具有兼容的可靠性 QoS 策略，但它们具有不兼容的持久性 QoS 策略，仍然不会建立连接。

当未建立连接时，发布者和订阅之间不会传递任何消息。 有一些机制可以检测这种情况，这将在后面的部分中介绍。

QoS 事件

某些 QoS 策略可能有与其相关的事件。 开发人员可以为每个发布者和订阅提供由这些 QoS 事件触发的回调函数，并以他们认为合适的方式处理它们，类似于处理在主题上收到的消息的方式。

开发人员可以订阅与 publisher 关联的以下 QoS 事件：

• 错过了 deadline：发布者尚未在截止 QoS 策略规定的预期持续时间内发布消息。
• 失去 liveliness: publish 未能在 lease duration 内表明其 liveliness 。
• 不兼容的 QoS：发布者遇到同一主题的订阅正在请求所提供的 QoS 配置文件无法满足的 QoS 配置文件，从而导致发布者与该订阅之间没有连接。

开发人员可以订阅与 subscriber 关联的以下 QoS 事件：

• 错过了请求的 deadline: 订阅在截止 QoS 策略规定的预期持续时间内未收到消息。
• Liveliness 改变了：订阅注意到订阅主题的一个或多个发布者未能在 lease duration 内表明其 liveliness。
• 请求的 QoS 不兼容：订阅遇到同一主题的发布者提供的 QoS 配置文件不满足所请求的 QoS 配置文件，导致订阅与该发布者之间没有连接。

匹配事件（Matched event）

除了 QoS 事件之外，当任何发布者和订阅者建立或断开它们之间的连接时，也会生成匹配的事件。 开发人员可以为每个发布者和订阅者提供由匹配事件触发的回调函数，并以他们认为合适的方式处理它们，类似于处理在主题上收到的消息的方式。

开发者可以通过发布者或订阅来订阅此事件。

发布者：当它找到与主题匹配且具有兼容的 QoS 的订阅或已连接的订阅已断开连接时，会发生此事件。

订阅：当找到与主题匹配且具有兼容 QoS 的发布者或连接的发布者断开连接时，会发生此事件。