【ROS2】概念:中级-服务质量设置

目录

• 概述

• QoS 策略

  • 与 ROS 1 的比较

• QoS 配置文件

• QoS 兼容性

  • 与 ROS 1 的比较

• QoS 事件

• 匹配事件

概述

ROS 2 提供了多种丰富的服务质量 (QoS) 策略，允许您调整节点之间的通信。通过合适的服务质量策略集，ROS 2 可以像 TCP 一样可靠，也可以像 UDP 一样尽力而为，并且在两者之间有许多可能的状态。与主要仅支持 TCP 的 ROS 1 不同，ROS 2 受益于底层 DDS 传输的灵活性，在丢包的无线网络环境中，“尽力而为”策略更为合适，或者在需要满足截止日期的实时计算系统中，需要合适的服务质量配置文件。

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

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

 QoS 策略 

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

•  历史 History

  • Keep last:  保留最后：仅存储最多 N 个样本，可通过队列深度选项进行配置。

  • Keep all:  保留所有：存储所有样本，受底层中间件的配置资源限制。

•  深度 Depth

  • Queue size: 队列大小：仅在“历史”策略设置为“保留最后一个”时才有效。

•  可靠性 Reliability

  • Best effort: 尽力而为：尝试传递样本，但如果网络不稳定，可能会丢失它们。

  • Reliable: 可靠：保证样品交付，可能会多次重试。

•  耐用性 Durability

  • Transient local: 瞬态本地：发布者负责为“迟加入 late-joining ”订阅持久化样本。

  • Volatile: 易失性：没有尝试持久化样本。

•  最后期限 Deadline

  • Duration:  持续时间：预期在主题上发布后续消息之间的最大时间间隔

•  寿命 Lifespan

  • Duration: 持续时间：从消息发布到接收之间的最长时间，超过此时间消息将被视为过时或失效（过期消息会被静默丢弃，实际上永远不会被接收）。

•  活力 Liveliness

  • Automatic: 自动：当任何一个发布者发布消息时，系统将认为该节点的所有发布者在另一个“租赁期限”内仍然存活。

  • Manual by topic:  按主题手动：如果系统手动声明发布者仍然存活（通过调用发布者 API），则系统将认为发布者在另一个“租赁期限”内仍然存活。

•  租赁期限 Lease Duration

  • Duration:  持续时间：发布者必须表明其存活的最长时间段，超过此时间段系统将认为其已失去活跃性（失去活跃性可能表明发生了故障）。

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

与 ROS 1 的比较 

ROS 2 中的“历史”和“深度”策略结合起来提供了类似于 ROS 1 中队列大小的功能。

“可靠性reliability”策略在 ROS 2 中类似于使用 UDPROS（仅在 roscpp 中）用于“尽力而为”，或使用 TCPROS（ROS 1 默认）用于“可靠reliable”。但请注意，即使是 ROS 2 中的可靠策略也是使用 UDP 实现的，这允许在适当情况下进行多播。

“持久性 durability ”策略“瞬态本地 transient local ”，结合任何深度，提供类似于“锁存 latching”发布者的功能。ROS 2 中的其余策略与 ROS 1 中可用的任何策略都不相似，这意味着在这方面 ROS 2 比 ROS 1 功能更丰富。将来，ROS 2 中可能会有更多的 QoS 策略。

 QoS 配置文件 

配置文件允许开发人员专注于他们的应用程序，而不必担心每个可能的 QoS 设置。QoS 配置文件定义了一组预期在特定用例中能够很好地协同工作的策略。

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

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

  为了使从 ROS 1 到 ROS 2 的过渡更容易，最好采用类似的网络行为。默认情况下，ROS 2 中的发布者和订阅者的历史记录为“保留最后”，队列大小为 10，可靠性为“可靠”，持久性为“易失”，活动性为“系统默认”。截止日期、寿命和租赁期限也都设置为“默认”。

• 服务

  与发布者和订阅者相同，服务是可靠的。服务使用易失性持久性尤为重要，否则重新启动的服务服务器可能会收到过时的请求。虽然客户端受到保护不会收到多个响应，但服务器不会受到收到过时请求的副作用的保护。

•  传感器数据

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

•  参数

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

•  系统默认

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

点击此处 https://github.com/ros2/rmw/blob/jazzy/rmw/include/rmw/qos_profiles.h 查看上述配置文件中使用的具体政策。这些配置文件中的设置可能会根据社区的反馈进行进一步调整。

 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

出版商	订阅	兼容	结果
易变的	易变的	是	仅限新消息
易变的	瞬态局部	不	无通信
瞬态本地	易变的	是	仅限新消息
瞬态本地	瞬态局部	是	新旧消息

要实现对后期订阅者可见的“锁定”主题，发布者和订阅者都必须同意使用“瞬态本地”。

截止日期 QoS 策略的兼容性:

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

出版商	订阅	兼容
默认	默认	是
默认	x	不
x	默认	是
x	x	是
x	y（当 y > x 时）	是
x	y（其中 y < x）	不

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

出版商	订阅	兼容
默认	默认	是
默认	x	不
x	默认	是
x	x	是
x	y（当 y > x 时）	是
x	y（其中 y < x）	不

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

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

与 ROS 1 的比较 

历史上在 ROS 1 中，任何具有相同消息类型的发布者和订阅者在相同主题上都会连接。在使用 ROS 2 时，需要注意请求和提供的 QoS 配置文件不兼容的可能性。

 QoS 事件 

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

开发人员可以订阅与发布者相关的以下 QoS 事件：

•  提供的截止日期已过 Offered deadline missed

  发布者未在截止日期 QoS 策略规定的预期时间内发布消息。

•  失去了活力 Liveliness lost

  出版商未能在租赁期间表明其活跃性。

• 提供了不兼容的 QoS Offered incompatible QoS

  发布者遇到了一个相同主题的订阅，该订阅请求的 QoS 配置文件无法满足提供的 QoS 配置文件，导致发布者与该订阅之间没有连接。

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

• 请求的截止日期已过 Requested deadline missed

  订阅未在截止日期 QoS 策略规定的预期时间内收到消息。

•  活力改变  Liveliness changed

  订阅已注意到，订阅主题上的一个或多个发布者未能在租赁期限内表明其活跃性。

• 请求的不兼容服务质量 (QoS)  Requested incompatible QoS

  订阅遇到了一个在同一主题上提供不满足请求的 QoS 配置文件的发布者，导致订阅与该发布者之间没有连接。

 匹配的事件 

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

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

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

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

有一些演示展示了如何使用该事件：

•  rclcpp：演示代码

  https://github.com/ros2/demos/blob/jazzy/demo_nodes_cpp/src/events/matched_event_detect.cpp 

•  rclpy：演示代码

  https://github.com/ros2/demos/blob/jazzy/demo_nodes_py/demo_nodes_py/events/matched_event_detect.py