质量 of 服务设置 [17510]
目录 []
概述 [17016]
ROS 2提供了丰富多样的质量 of 服务（QoS）策略，允许您调整节点之间的通信。通过正确的一组质量 of 服务策略，ROS 2可以像TCP一样可靠，也可以像UDP一样尽力而为，中间还有许多可能的状态。与主要仅支持TCP的ROS 1不同，ROS 2受益于底层DDS传输的灵活性，在存在丢包无线网络的环境中，"尽力而为"策略更适合，或者在实时计算系统中，需要正确的质量 of 服务配置文件以满足截止日期。 [17511]
一组QoS "策略" 组合在一起形成QoS "配置文件"。考虑到选择给定场景的正确QoS策略的复杂性，ROS 2为常见用例（例如传感器数据）提供了一组预定义的QoS配置文件。同时，开发人员可以灵活控制QoS配置文件的具体策略。 [17512]
可以为发布者、订阅者、服务服务器和客户端指定QoS配置文件。一个QoS配置文件可以独立应用于上述实体的每个实例，但如果使用不同的配置文件，可能会导致不兼容，从而阻止消息的传递。 [17513]
QoS策略 [17514]
基本QoS配置文件当前包括以下策略的设置： [17515]
历史记录 [17516]
深度 [17519]
队列大小：仅在"历史"策略设置为"保留最后"时受到尊重。 [17520]
可靠性 [17521]
耐久性 [17524]
截止日期 [17527]
持续时间：期望的发布到主题的连续消息之间的最大时间间隔。 [17528]
寿命 [17529]
持续时间：在发布消息和接收消息之间的最大时间间隔，超过此时间则将认为消息已过期或失效（已过期的消息将被静默丢弃，实际上永远不会被接收）。 [17530]
活跃性 [17531]
租约期 [17534]
持续时间：在系统认为发布者失去活跃性之前，发布者有的最长时间来表明自己仍然存活（失去活跃性可能表明出现故障）。 [17535]
对于不是持续时间的每个策略，还有"系统默认"选项，它使用底层中间件的默认值。对于持续时间的每个策略，还存在一个"默认"选项，表示持续时间未指定，底层中间件通常会将其解释为无限长的持续时间。 [17536]
与ROS 1的比较 [17057]
ROS 2中的"历史"和"深度"策略组合在一起，提供类似于ROS 1中队列大小的功能。 [17537]
ROS 2中的"可靠性"策略类似于使用UDPROS（仅在``roscpp``中）进行"尽力而为"或使用TCPROS（ROS 1默认）进行"可靠"的情况。但请注意，即使在ROS 2中，即使在ROS 2中，可靠性策略也是使用UDP实现的，如果适用，可以进行多播。 [17538]
ROS 2中的"持久性"策略"瞬态本地"，与任何深度结合使用，提供了类似于"latching"发布者的功能。ROS 2中的其余策略与ROS 1中可用的任何内容都不相似，这意味着在这方面，ROS 2比ROS 1更具功能性。未来可能会在ROS 2中提供更多的QoS策略。 [17539]
QoS配置文件 [17540]
配置文件允许开发人员专注于应用程序，而不必担心可能的每个QoS设置。QoS配置文件定义了一组预期在特定用例中很好配合的策略。 [17541]
当前定义的QoS配置文件如下： [17542]
发布者和订阅者的默认QoS设置 [17543]
为了使从ROS 1到ROS 2的过渡更加容易，希望实现类似的网络行为。默认情况下，ROS 2中的发布者和订阅者的"历史"采用"保留最后"，队列大小为10，"可靠性"采用"可靠"，"持久性"采用"volatile"，"活跃性"采用"系统默认"。截止日期、寿命和租约持续时间也都设置为"默认"。 [17544]
服务 [17192]
与发布者和订阅者类似，服务也具有可靠性。对于服务来说，使用“volatile”持久性尤为重要，否则重新启动的服务服务器可能会收到过时的请求。虽然客户端受到多个响应的保护，但服务器却没有受到接收过时请求的副作用的保护。 [17545]
传感器数据 [17546]
对于传感器数据来说，大多数情况下，及时接收读数比确保所有数据到达更为重要。也就是说，开发者希望尽快获取最新的采样数据，即使可能会丢失一些数据。因此，传感器数据配置文件使用尽力而为的可靠性和较小的队列大小。 [17547]
参数 [17022]
ROS 2 中的参数基于服务，因此具有类似的配置文件。不同之处在于参数使用更大的队列深度，这样当参数客户端无法连接参数服务服务器时，请求不会丢失。 [17548]
系统默认值 [17549]
这使用RMW实现的默认值来设置所有策略。不同的RMW实现可能具有不同的默认值。 [17550]
QoS 兼容性 [17552]
**注意：**本部分内容适用于发布者和订阅者，同样适用于服务端和客户端。 [17553]
可以独立为发布者和订阅者配置 QoS 配置文件。仅当发布者和订阅者具有兼容的 QoS 配置文件时，才会建立发布者和订阅者之间的连接。 [17554]
QoS配置文件的兼容性是基于"请求与提供"模型确定的。订阅者*请求*一个QoS配置文件，表示它愿意接受的"最低质量"，而发布者*提供*一个QoS配置文件，表示它能够提供的"最高质量"。只有在所请求的QoS配置文件的每个策略都不比提供的QoS配置文件更严格的情况下，才会建立连接。即使所请求的QoS配置文件不同，多个订阅者也可以同时连接到单个发布者。发布者和订阅者之间的兼容性不受其他发布者和订阅者的影响。 [17555]
以下表格显示了不同策略设置的兼容性及其结果： [17556]
可靠性QoS策略的兼容性: [17557]
发布者 [17558] |
订阅者 [17559] |
兼容 [17560] |
|---|---|---|
尽力而为 [17561] |
尽力而为 [17561] |
是 [17562] |
尽力而为 [17561] |
可靠 [17563] |
否 [17564] |
可靠 [17563] |
尽力而为 [17561] |
是 [17562] |
可靠 [17563] |
可靠 [17563] |
是 [17562] |
持久性 QoS 策略的兼容性： [17565]
发布者 [17558] |
订阅者 [17559] |
兼容 [17560] |
结果 [17566] |
|---|---|---|---|
易失性 [17567] |
易失性 [17567] |
是 [17562] |
仅新消息 [17568] |
易失性 [17567] |
瞬态本地 [17569] |
否 [17564] |
无通信 [17570] |
瞬态本地 [17569] |
易失性 [17567] |
是 [17562] |
仅新消息 [17568] |
瞬态本地 [17569] |
瞬态本地 [17569] |
是 [17562] |
新旧消息均包括 [17571] |
要实现"latched"主题，以便向后续订阅者可见，发布者和订阅者必须都同意使用"瞬态本地"。 [17572]
截止期限 QoS 策略的兼容性： [17573]
假设 x 和 y 是任意有效的持续时间值。 [17574]
发布者 [17558] |
订阅者 [17559] |
兼容 [17560] |
|---|---|---|
默认 [17575] |
默认 [17575] |
是 [17562] |
默认 [17575] |
x [17576] |
否 [17564] |
x [17576] |
默认 [17575] |
是 [17562] |
x [17576] |
x [17576] |
是 [17562] |
x [17576] |
y*（其中 *y > x） [17577] |
是 [17562] |
x [17576] |
y*（其中 *y < x） [17578] |
否 [17564] |
活跃性 QoS 策略的兼容性: [17579]
发布者 [17558] |
订阅者 [17559] |
兼容 [17560] |
|---|---|---|
自动 [17580] |
自动 [17580] |
是 [17562] |
自动 [17580] |
按主题手动 [17581] |
否 [17564] |
按主题手动 [17581] |
自动 [17580] |
是 [17562] |
按主题手动 [17581] |
按主题手动 [17581] |
是 [17562] |
租约持续时间QoS策略的兼容性: [17582]
假设 x 和 y 是任意有效的持续时间值。 [17574]
发布者 [17558] |
订阅者 [17559] |
兼容 [17560] |
|---|---|---|
默认 [17575] |
默认 [17575] |
是 [17562] |
默认 [17575] |
x [17576] |
否 [17564] |
x [17576] |
默认 [17575] |
是 [17562] |
x [17576] |
x [17576] |
是 [17562] |
x [17576] |
y*（其中 *y > x） [17577] |
是 [17562] |
x [17576] |
y*（其中 *y < x） [17578] |
否 [17564] |
为了建立连接，必须使所有影响兼容性的策略相互兼容。例如，即使请求和提供的QoS配置文件对可靠性QoS策略是兼容的，但如果它们的持久性QoS策略不兼容，仍然无法建立连接。 [17583]
当无法建立连接时，发布者和订阅者之间将不会传递任何消息。有机制可以检测到这种情况，将在后面的章节中介绍。 [17584]
QoS 事件 [17586]
一些QoS策略与可能的事件相关联。开发人员可以为每个发布者和订阅者提供与这些QoS事件相关的回调函数，并以他们认为合适的方式处理这些事件，类似于处理在主题上接收到的消息的方式。 [17587]
开发人员可以订阅与发布者相关联的以下QoS事件： [17588]
提供的截止期限未达成 [17589]
发布者在截止期限QoS策略规定的预期持续时间内未发布消息。 [17590]
活跃性丧失 [17591]
发布者未在租约期限内指示其活跃性。 [17592]
提供的QoS不兼容 [17593]
发布者遇到了在相同主题上订阅的请求一个无法满足提供的QoS配置文件的QoS配置文件，导致发布者与该订阅之间没有连接。 [17594]
开发者可以订阅与订阅相关的以下QoS事件： [17595]