关于服务质量(QOS)设置 [小鱼@9945]

概述

ROS 2提供了丰富多样的服务质量 (QoS) 策略,使您可以调整节点之间的通讯。通过正确设置服务质量策略,ROS 2可以像TCP一样可靠,也可以像UDP一样尽力而为,在这两者之间有很多很多可能的状态。与主要只支持TCP的ROS 1不同,ROS 2受益于底层DDS传输的灵活性,在有损无线网络的环境中“尽力而为” 策略更合适,或者在实时计算系统中,需要适当质量的服务配置文件来满足时间期限要求。 [Alyssa@9946]

一组QoS “策略” 结合在一起形成QoS “配置文件”。考虑到为给定场景选择正确的QoS策略的复杂性,ROS 2为常见用例 (例如传感器数据) 提供了一组预定义的QoS配置文件。同时,开发人员可以灵活地控制QoS配置文件的具体策略。 [Alyssa@9947]

可以为发布者、订阅、服务服务器和客户端指定QoS配置文件。QoS配置文件可以独立地应用于上述实体的每个实例,但是如果使用不同的配置文件,则它们可能不兼容,从而阻止消息的传递。 [待校准@9948]

QoS策略

基本QoS配置文件当前包括以下策略的设置: [待校准@9950]

  • 历史记录 [Alyssa@9951]

    • 保留最后的: 最多只能存储N个样本,可通过队列深度选项进行配置。 [Alyssa@9952]

    • 保留所有: 存储所有样本,但要遵守底层中间件配置的资源限制。 [Alyssa@9953]

  • 深度 [待校准@9954]

    • 队列大小: 仅在“历史记录”策略设置为“保留最后的”时才设置。 [Alyssa@9955]

  • 可靠性 [待校准@9956]

    • 尽力而为: 尝试传递样本,但如果网络不强大,可能会丢失样本。 [Alyssa@9957]

    • 可靠: 保证传递所有样品,可能会重试多次。 [Alyssa@9958]

  • 持久性 [Alyssa@9959]

    • 临时的本地: 发布者负责为“延迟加入”的订阅者保留样本。 [Alyssa@9960]

    • 易失性: 不尝试保留样本。 [Alyssa@9961]

  • 时间期限 [Alyssa@9962]

    • 持续时间: 前后两个消息发布到某个话题之间的预期最长时间 [Alyssa@9963]

  • 寿命 [待校准@9964]

    • 持续时间: 在没有被视为过时或过期的消息发布和接收之间的最长时间 (过期的消息将被静默的丢弃,实际上永远不会收到)。 [Alyssa@9965]

  • 活性 [Alyssa@9966]

    • 自动: 当节点的任何一个发布者发布消息时,系统将认为该节点的所有发布者还要存活另一个“租赁期限”。 [Alyssa@9967]

    • 按话题手动: 如果手动断言发布者仍然活着 (通过调用发布者API),则系统将认为该发布者还要存活另一个“租约期限”。 [Alyssa@9968]

  • 租赁期限 [待校准@9969]

    • 持续时间: 在系统认为它已经失去活性之前,发布者必须指明它还活着的最长周期 (失去活性可能暗示出现了故障)。 [Alyssa@9970]

对于不是持续时间的每个策略,还有“系统默认”选项,它使用底层中间件的默认选项。对于每个具有持续时间的策略,也存在一个“默认”选项,这意味着持续时间未指定,底层中间件通常将其解释为无限长的持续时间。 [Alyssa@9971]

与ROS 1的比较

ROS 2中的“历史记录”和“深度”策略相结合以提供类似于ROS 1中的队列大小的功能。 [Alyssa@9973]

ROS 2中的“可靠性”策略类似于使用UDPROS (仅在 roscpp 中) 实现“尽力而为”策略,或者使用TCPROS (ROS 1默认) 实现“可靠”策略。但是请注意,在ROS 2中即使是可靠策略也是使用UDP实现的,这允许在适当的情况下进行多播。 [Alyssa@9974]

“持久性”策略“暂时的本地”,和任何”深度“策略相结合,提供类似于“锁定”发布者的功能。ROS 2中的其余策略与ROS 1中可用的任何策略都不相似,这意味着ROS 2在这方面比ROS 1更具特色。将来,ROS 2中可能会提供更多的QoS策略。 [Alyssa@9975]

QoS配置文件

配置文件让开发人员可以专注于他们的应用程序,而不必担心每个可能的QoS设置。QoS配置文件定义了一组策略,这些策略有望在特定用例中很好地结合在一起。 [Alyssa@9977]

当前定义的QoS配置文件如下:

  • 发布者和订阅者的默认QoS设置 [Alyssa@9979]

    为了使从ROS 1到ROS 2的过渡更容易,需要执行类似的网络行为。默认情况下,ROS 2中的发布者和订阅者对于历史记录有队列大小为10的“保留最后”策略,对于可靠性具有“可靠”策略,对于耐用性具有 “易失性”策略,和 “系统默认” 的活性。时间限制、寿命和租赁持续时间也都设置为 “默认”。 [Alyssa@9980]

  • 服务

    与发布者和订阅者一样,服务是可靠的。服务使用易失性的持久性策略尤为重要,否则重新启动的服务的服务端时可能会收到过时的请求。虽然保护客户端不接收多个响应,但不保护服务端免受接收过时请求的副作用。 [Alyssa@9982]

  • 传感器数据

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

  • 参数

    ROS 2中的参数基于服务,因此具有类似的配置文件。不同之处在于,参数使用更大的队列深度,这样,例如参数客户端无法访问参数服务的服务端时,请求就不会丢失。 [Alyssa@9986]

  • 系统默认

    这将对所有策略使用RMW实现的默认值。不同的RMW实现可能有不同的默认值。 [待校准@9988]

用于上述配置文件的具体策略请 单机这里 查看。这些配置文件中的设置会根据社区的反馈进行进一步调整。 [Alyssa@9989]

QoS兼容性

注意: 本节涉及发布者和订阅,但内容以相同的方式适用于服务的服务端和客户端。 [Alyssa@9991]

QoS配置文件可以独立为发布者和订阅者配置。仅当发布者和订阅者具有兼容的QoS配置文件时,才会在发布者和订阅者之间建立连接。 [Alyssa@9992]

QoS配置文件兼容性是基于“请求vs提供”模型确定的。订阅者* 请求 它愿意接受的“最低质量”的QoS配置文件,发布者 提供 *一个它能够提供的“最高质量”的QoS配置文件。只有在每个请求的QoS配置文件中的策略不比提供的QoS配置文件中的策略更严格才会进行连接。多个订阅者可以同时连接到一个发布者,即使它们请求的QoS配置文件不同。发布者和订阅者之间的兼容性不受其他发布者和订阅者存在的影响。 [Alyssa@9993]

下表显示了不同策略设置的兼容性以及结果: [Alyssa@9994]

可靠性QoS策略的兼容性: [Alyssa@9995]

发布者 [Alyssa@9996]

订阅者 [Alyssa@9997]

兼容性 [Alyssa@9998]

尽力而为 [Alyssa@9999]

尽力而为 [Alyssa@9999]

兼容 [Alyssa@10000]

尽力而为 [Alyssa@9999]

可靠 [待校准@10001]

不兼容 [Alyssa@10002]

可靠 [待校准@10001]

尽力而为 [Alyssa@9999]

兼容 [Alyssa@10000]

可靠 [待校准@10001]

可靠 [待校准@10001]

兼容 [Alyssa@10000]

持久性服务质量策略的兼容性: [Alyssa@10003]

发布者 [Alyssa@9996]

订阅者 [Alyssa@9997]

兼容性 [Alyssa@9998]

易失性 [待校准@10004]

易失性 [待校准@10004]

兼容 [Alyssa@10000]

易失性 [待校准@10004]

临时的本地 [Alyssa@10005]

不兼容 [Alyssa@10002]

临时的本地 [Alyssa@10005]

易失性 [待校准@10004]

兼容 [Alyssa@10000]

临时的本地 [Alyssa@10005]

临时的本地 [Alyssa@10005]

兼容 [Alyssa@10000]

时间期限QoS策略的兼容性: [Alyssa@10006]

假设 xy 是任意有效的持续时间值。 [Alyssa@10007]

发布者 [Alyssa@9996]

订阅者 [Alyssa@9997]

兼容性 [Alyssa@9998]

默认值 [Alyssa@10008]

默认值 [Alyssa@10008]

兼容 [Alyssa@10000]

默认值 [Alyssa@10008]

x [Alyssa@10009]

不兼容 [Alyssa@10002]

x [Alyssa@10009]

默认值 [Alyssa@10008]

兼容 [Alyssa@10000]

x [Alyssa@10009]

x [Alyssa@10009]

兼容 [Alyssa@10000]

x [Alyssa@10009]

y (其中 y > x) [Alyssa@10010]

兼容 [Alyssa@10000]

x [Alyssa@10009]

y (其中 y < x) [Alyssa@10011]

不兼容 [Alyssa@10002]

活性QoS策略的兼容性: [Alyssa@10012]

发布者 [Alyssa@9996]

订阅者 [Alyssa@9997]

兼容性 [Alyssa@9998]

自动 [待校准@10013]

自动 [待校准@10013]

兼容 [Alyssa@10000]

自动 [待校准@10013]

按话题手动 [Alyssa@10014]

不兼容 [Alyssa@10002]

按话题手动 [Alyssa@10014]

自动 [待校准@10013]

兼容 [Alyssa@10000]

按话题手动 [Alyssa@10014]

按话题手动 [Alyssa@10014]

兼容 [Alyssa@10000]

租赁期限QoS策略的兼容性: [Alyssa@10015]

假设 xy 是任意有效的持续时间值。 [Alyssa@10007]

发布者 [Alyssa@9996]

订阅者 [Alyssa@9997]

兼容性 [Alyssa@9998]

默认值 [Alyssa@10008]

默认值 [Alyssa@10008]

兼容 [Alyssa@10000]

默认值 [Alyssa@10008]

x [Alyssa@10009]

不兼容 [Alyssa@10002]

x [Alyssa@10009]

默认值 [Alyssa@10008]

兼容 [Alyssa@10000]

x [Alyssa@10009]

x [Alyssa@10009]

兼容 [Alyssa@10000]

x [Alyssa@10009]

y (其中 y > x) [Alyssa@10010]

兼容 [Alyssa@10000]

x [Alyssa@10009]

y (其中 y < x) [Alyssa@10011]

不兼容 [Alyssa@10002]

为了建立连接,所有影响兼容性的策略都必须兼容。例如,即使请求和提供的QoS配置文件对具有兼容的可靠性QoS策略,但它们具有不兼容的持久性QoS策略,也不会建立连接。 [待校准@10016]

未建立连接时,发布者和订阅之间不会传递任何消息。有对这种情况进行检测的机制,将在后面的章节中介绍。 [Alyssa@10017]

与ROS 1的比较

过去在ROS 1中,任何在相同话题上具有相同消息类型的发布者和订阅者都将被连接。在使用ROS 2时,需要注意的新事项是请求和提供的QoS配置文件不兼容的可能性。 [Alyssa@10018]

QoS事件

一些QoS策略有可能与之相关的事件。开发人员可以为每个发布者和订阅提供由这些QoS事件触发的回调函数,并以他们认为合适的方式处理它们,类似于处理话题上接收的消息。 [Alyssa@10020]

开发人员可以订阅与发布者相关的以下QoS事件: [Alyssa@10021]

  • 错过时间期限 [Alyssa@10022]

    发布者未在时间期限QoS策略规定的预期持续时间内发布消息。 [Alyssa@10023]

  • 失去活性 [Alyssa@10024]

    发布者未能在租赁期限内声明其活性。 [Alyssa@10025]

  • 提供不兼容的QoS [待校准@10026]

    发布者在同一话题上遇到了一个订阅者,发布者所提供的QoS配置文件无法满足该订阅者正在请求的的QoS配置文件,导致发布者与该订阅者之间无法连接。 [Alyssa@10027]

开发人员可以订阅与订阅者相关的以下QoS事件: [Alyssa@10028]

  • 错过请求的时间期限 [Alyssa@10029]

    订阅者未在时间期限QoS策略规定的预期持续时间内收到消息。 [Alyssa@10030]

  • 活性改变了 [Alyssa@10031]

    订阅者注意到在订阅的话题上存在一个或多个发布者未能表明他们在租赁期限内的活性。 [Alyssa@10032]

  • 请求的不兼容QoS [待校准@10033]

    订阅者在同一话题上遇到了一个发布者,其提供的QoS配置文件不满足所请求的QoS配置文件,导致订阅者与该发布者之间无法连接。 [Alyssa@10034]