服务质量设置
概述
ROS 2 提供丰富的服务质量 (QoS) 策略，允许您调整节点之间的通信。 有了正确的服务质量策略集，ROS 2 可以像 TCP 一样可靠，或者像 UDP 一样尽力而为，并且两者之间有许多可能的状态。 与主要仅支持 TCP 的 ROS 1 不同，ROS 2 受益于底层 DDS 传输的灵活性，在有损无线网络的环境中，“尽力而为”策略更合适，或者在实时计算系统中，需要正确的服务质量配置文件来满足最后期限。
一组 QoS“策略”组合在一起形成一个 QoS“配置文件”。 考虑到为给定场景选择正确的 QoS 策略的复杂性，ROS 2 为常见用例（例如传感器数据）提供了一组预定义的 QoS 配置文件。 同时，开发人员可以灵活地控制 QoS 配置文件的特定策略。
可以为发布者、订阅、服务服务器和客户端指定 QoS 配置文件。 QoS 配置文件可以独立应用于上述实体的每个实例，但如果使用不同的配置文件，则它们可能会不兼容，从而阻止消息传递。
QoS 策略
基本 QoS 配置文件当前包括以下策略的设置：
历史记录
保留最后：仅存储最多 N 个样本，可通过队列深度选项进行配置。
保留全部：存储所有样本，但要遵守底层中间件的配置资源限制。
深度
队列大小：仅在“历史记录”策略设置为“保留最后”时才有效。
可靠性
尽力而为：尝试提供样本，但如果网络不稳定，可能会丢失样本。
可靠：保证样本得到提供，可能会重试多次。
耐用性
瞬态本地：发布者负责为“后期加入”订阅保留样本。
易失性：不尝试保留样本。
截止时间
持续时间：后续消息发布到主题之间的预期最大时间
寿命
持续时间：消息发布和接收之间的最大时间，不认为消息过时或过期（过期消息会被悄悄丢弃，实际上永远不会被接收）。
活跃度
自动：当节点的任何一个发布者发布了消息时，系统将认为节点的所有发布者在另一个“租约期限”内处于活跃状态。
按主题手动：如果发布者手动断言它仍然处于活跃状态（通过调用发布者 API），系统将认为发布者在另一个“租约期限”内处于活跃状态。
租约期限
持续时间：发布者必须表明自己处于活跃状态的最长时间，否则系统会认为它已经失去活跃度（失去活跃度可能表示出现故障）。
对于每个非持续时间的策略，还有“系统默认”选项，它使用底层中间件的默认值。 对于每个持续时间的策略，也存在一个“默认”选项，这意味着持续时间未指定，底层中间件通常会将其解释为无限长的持续时间。
与 ROS 1 的比较
ROS 2 中的“历史”和“深度”策略结合起来提供类似于 ROS 1 中的队列大小的功能。
ROS 2 中的“可靠性”策略类似于使用 UDPROS（仅在“roscpp”中）表示“尽力而为”，或使用 TCPROS（ROS 1 默认）表示“可靠”。 但请注意，即使是 ROS 2 中的可靠策略也是使用 UDP 实现的，如果合适，它允许进行多播。
“持久性”策略“瞬态本地”与任意深度相结合，提供与“锁定”发布者类似的功能。 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 实现可能具有不同的默认值。
Click here 针对上述配置文件所使用的具体政策。 根据社区的反馈，这些配置文件中的设置可能会进一步调整。
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 |
持久性 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 策略的兼容性：
Assume x and y are arbitrary valid duration values.
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 策略的兼容性：
Publisher |
Subscription |
Compatible |
|---|---|---|
Automatic |
Automatic |
Yes |
Automatic |
Manual by topic |
No |
Manual by topic |
Automatic |
Yes |
Manual by topic |
Manual by topic |
Yes |
租约期限 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 策略，仍然不会建立连接。 当未建立连接时，发布者和订阅者之间不会传递任何消息。 有机制可以检测这种情况，将在后面的部分中介绍。 与 ROS 1 的比较 ^^^^^^^^^^^^^^^^^^^^
从历史上看，在 ROS 1 中，任何具有相同消息类型且主题相同的发布者和订阅者都会连接。 使用 ROS 2 时，需要注意请求和提供的 QoS 配置文件不兼容的可能性。 QoS 事件 ———-
一些 QoS 策略可能具有与其相关的事件。 开发人员可以为每个发布者和订阅者提供由这些 QoS 事件触发的回调函数，并以他们认为合适的方式处理它们，类似于处理在主题上收到的消息的方式。 开发人员可以订阅与发布者相关的以下 QoS 事件：
错过提供的截止期限
发布者未在截止期限 QoS 策略规定的预期期限内发布消息。
失去活跃度
发布者未能在租约期限内表明其活跃度。
提供的 QoS 不兼容
发布者遇到同一主题上的订阅，该订阅请求提供的 QoS 配置文件无法满足的 QoS 配置文件，导致发布者与该订阅之间没有连接。
开发人员可以订阅与订阅相关的以下 QoS 事件：
错过请求的截止期限
订阅未在截止期限 QoS 策略规定的预期期限内收到消息。
活跃度发生变化
订阅注意到订阅主题上的一个或多个发布者未能在租约期限内表明其活跃度。
请求的 QoS 不兼容
订阅遇到同一主题上的发布者，该发布者提供的 QoS 配置文件不满足请求的 QoS 配置文件，导致订阅与该发布者之间没有连接。