质量 of 服务设置
概述
ROS 2提供了丰富多样的质量 of 服务（QoS）策略，允许您调整节点之间的通信。通过正确的一组质量 of 服务策略，ROS 2可以像TCP一样可靠，也可以像UDP一样尽力而为，中间还有许多可能的状态。与主要仅支持TCP的ROS 1不同，ROS 2受益于底层DDS传输的灵活性，在存在丢包无线网络的环境中，"尽力而为"策略更适合，或者在实时计算系统中，需要正确的质量 of 服务配置文件以满足截止日期。
一组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中，即使在ROS 2中，可靠性策略也是使用UDP实现的，如果适用，可以进行多播。
ROS 2中的"持久性"策略"瞬态本地"，与任何深度结合使用，提供了类似于"latching"发布者的功能。ROS 2中的其余策略与ROS 1中可用的任何内容都不相似，这意味着在这方面，ROS 2比ROS 1更具功能性。未来可能会在ROS 2中提供更多的QoS策略。
QoS配置文件
配置文件允许开发人员专注于应用程序，而不必担心可能的每个QoS设置。QoS配置文件定义了一组预期在特定用例中很好配合的策略。
当前定义的QoS配置文件如下：
发布者和订阅者的默认QoS设置
为了使从ROS 1到ROS 2的过渡更加容易，希望实现类似的网络行为。默认情况下，ROS 2中的发布者和订阅者的"历史"采用"保留最后"，队列大小为10，"可靠性"采用"可靠"，"持久性"采用"volatile"，"活跃性"采用"系统默认"。截止日期、寿命和租约持续时间也都设置为"默认"。
服务
与发布者和订阅者类似，服务也具有可靠性。对于服务来说，使用“volatile”持久性尤为重要，否则重新启动的服务服务器可能会收到过时的请求。虽然客户端受到多个响应的保护，但服务器却没有受到接收过时请求的副作用的保护。
传感器数据
对于传感器数据来说，大多数情况下，及时接收读数比确保所有数据到达更为重要。也就是说，开发者希望尽快获取最新的采样数据，即使可能会丢失一些数据。因此，传感器数据配置文件使用尽力而为的可靠性和较小的队列大小。
参数
ROS 2 中的参数基于服务，因此具有类似的配置文件。不同之处在于参数使用更大的队列深度，这样当参数客户端无法连接参数服务服务器时，请求不会丢失。
系统默认值
这使用RMW实现的默认值来设置所有策略。不同的RMW实现可能具有不同的默认值。
点击此处 获取上述配置中使用的具体策略。这些配置文件中的设置可能会根据社区的反馈进行进一步调整。
QoS 兼容性
**注意：**本部分内容适用于发布者和订阅者，同样适用于服务端和客户端。
可以独立为发布者和订阅者配置 QoS 配置文件。仅当发布者和订阅者具有兼容的 QoS 配置文件时，才会建立发布者和订阅者之间的连接。
QoS配置文件的兼容性是基于"请求与提供"模型确定的。订阅者*请求*一个QoS配置文件，表示它愿意接受的"最低质量"，而发布者*提供*一个QoS配置文件，表示它能够提供的"最高质量"。只有在所请求的QoS配置文件的每个策略都不比提供的QoS配置文件更严格的情况下，才会建立连接。即使所请求的QoS配置文件不同，多个订阅者也可以同时连接到单个发布者。发布者和订阅者之间的兼容性不受其他发布者和订阅者的影响。
以下表格显示了不同策略设置的兼容性及其结果：
可靠性QoS策略的兼容性:
发布者 |
订阅者 |
兼容 |
|---|---|---|
尽力而为 |
尽力而为 |
是 |
尽力而为 |
可靠 |
否 |
可靠 |
尽力而为 |
是 |
可靠 |
可靠 |
是 |
持久性 QoS 策略的兼容性：
发布者 |
订阅者 |
兼容 |
结果 |
|---|---|---|---|
易失性 |
易失性 |
是 |
仅新消息 |
易失性 |
瞬态本地 |
否 |
无通信 |
瞬态本地 |
易失性 |
是 |
仅新消息 |
瞬态本地 |
瞬态本地 |
是 |
新旧消息均包括 |
要实现"latched"主题，以便向后续订阅者可见，发布者和订阅者必须都同意使用"瞬态本地"。
截止期限 QoS 策略的兼容性：
假设 x 和 y 是任意有效的持续时间值。
发布者 |
订阅者 |
兼容 |
|---|---|---|
默认 |
默认 |
是 |
默认 |
x |
否 |
x |
默认 |
是 |
x |
x |
是 |
x |
y*（其中 *y > x） |
是 |
x |
y*（其中 *y < x） |
否 |
活跃性 QoS 策略的兼容性:
发布者 |
订阅者 |
兼容 |
|---|---|---|
自动 |
自动 |
是 |
自动 |
按主题手动 |
否 |
按主题手动 |
自动 |
是 |
按主题手动 |
按主题手动 |
是 |
租约持续时间QoS策略的兼容性:
假设 x 和 y 是任意有效的持续时间值。
发布者 |
订阅者 |
兼容 |
|---|---|---|
默认 |
默认 |
是 |
默认 |
x |
否 |
x |
默认 |
是 |
x |
x |
是 |
x |
y*（其中 *y > x） |
是 |
x |
y*（其中 *y < x） |
否 |
为了建立连接，必须使所有影响兼容性的策略相互兼容。例如，即使请求和提供的QoS配置文件对可靠性QoS策略是兼容的，但如果它们的持久性QoS策略不兼容，仍然无法建立连接。
当无法建立连接时，发布者和订阅者之间将不会传递任何消息。有机制可以检测到这种情况，将在后面的章节中介绍。
QoS 事件
一些QoS策略与可能的事件相关联。开发人员可以为每个发布者和订阅者提供与这些QoS事件相关的回调函数，并以他们认为合适的方式处理这些事件，类似于处理在主题上接收到的消息的方式。
开发人员可以订阅与发布者相关联的以下QoS事件：
提供的截止期限未达成
发布者在截止期限QoS策略规定的预期持续时间内未发布消息。
活跃性丧失
发布者未在租约期限内指示其活跃性。
提供的QoS不兼容
发布者遇到了在相同主题上订阅的请求一个无法满足提供的QoS配置文件的QoS配置文件，导致发布者与该订阅之间没有连接。
开发者可以订阅与订阅相关的以下QoS事件：
请求的截止时间已过
该订阅在预期的持续时间内未收到消息，该持续时间由截止时间的QoS策略设置。
可用性发生变化
订阅发现，某个或多个发布者在订阅的主题上在租约期内未能表明其存活状态。
请求的QoS不兼容。
订阅遇到了同一主题上提供不符合请求的QoS配置文件的发布者，导致订阅与该发布者之间没有连接。