质量 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配置文件的发布者,导致订阅与该发布者之间没有连接。