ROS2学习（六）.ROS概念 - 服务质量设置

QoS（Quality of Service）是在通信中非常常见的一个概念，用来定义通信的质量等级，以适配不同的场景。
对通信来说，最理想的情况，当然是所有的消息都无损地实时地被传输到接收端。但这带来的代价几乎是不可接受的，因此我们通过不同的服务质量等级QoS定义来使得这个代价可被接受同时保证不对业务产生影响。

例如：

1. 一段文字，如果有缺失，则会大幅影响意思
   “我不想去动物园”，传输中丢失了“不”字，则意思就完全相反了。因此这种场景下，我们需要定义相对高的QoS等级确保信息不被丢失。
2. 视频传输通常可以忍受部分的信息丢失
   一段视频，以24帧/秒的速率传输，一般来说，丢失了个别帧，不对整段视频的意义带来影响，这种场景下，我们的QoS等级就可以相对较低，容忍一定程度的信息丢失。

上面的例子中，只用了简单的高低来描述QoS，当然，实际场景要复杂得多。
因此，ROS 2提供了丰富的服务质量(QoS)策略，允许我们对节点之间的通信进行调优。在QoS的不同策略下，ROS 2可以像TCP一样可靠，或者像UDP一样提供尽力服务，当然也可以调整为两者之间任意可能的服务质量状态。
相较于ROS 1仅支持TCP，DDS为ROS 2提供了传输的灵活性：在有损的无线网络环境中，“尽力服务”策略将会更合适；在实时计算系统中，合适的服务质量配置则可以满足通信对实时时限的要求。

一组QoS策略结合形成一个QoS配置文件（profile）。ROS 2为常见场景提供了预设的QoS策略配置。当然我们也可以控制QoS配置文件。
QoS配置文件可以根据发布者、订阅者、服务的服务端和客户端加以指定。一个QoS配置文件可以被独立应用于上述实体的每个实例。当然，如果使用不同的配置文件，可能会导致不兼容，从而无法传递消息。

QoS策略¹

QoS基本配置包括了一下策略的设置：

现在包含以下策略：

• 历史History
  • 保留最后Keep last：只存储N个数据，可通过队列深度选项变更相关配置。
  • 保留所有Keep all：存储所有数据，根据底层中间件的配置进行资源限制。
• 深度Depth
  • 队列深度Queue size：仅当“历史”策略为“保持最后”时生效。
• 可靠性Reliability
  • 尽力服务Best effort：尝试发送数据，但若网络不够健壮，则可能会丢失。
  • 可靠Reliable：通过多次重试保证数据送达。
• 耐用性Durability
  • 暂存本地Transient local：发布者将负责对数据进行持久化，以便“迟加入”的订阅者可获取数据。
  • 挥发性Volatile：不尝试保存数据。
• 截止时间Deadline
  • 持续时间Duration：将连续消息发布到主题时的预期最大时间。
• 寿命Lifespan
  • 持续时间Duration：在发布和接收消息之间的最长时间，在此时间内，消息不会被认为是过期的(过期的消息会被安静地丢弃，永远不会再被接收到)。
• 活跃程度Liveliness
  • 自动Automatic：若任意节点发布了一条消息，系统将认为所有节点在接下来的租赁周期（Lease Duration）中都是活跃的。
  • 按主题手动Manual by topic：若任意节点发布了一条消息，系统仅将认为该节点在接下来的租赁周期（Lease Duration）中是活跃的（通过调用发布的API）。
• 租赁周期Lease Duration
  • 持续时间Duration：系统认为发布者失活的最大周期时间（失活将会导致失败）。

对没有指定持续时间的策略，通常使用底层中间件的默认值。
对于每一个有持续时间的策略，都存在一个默认的持续时间，底层中间件通常将其解释为无限长的持续时间。

同ROS 1比较

在ROS 2中，“历史”和“深度”策略联合使用，基本等效于ROS 1的queue size。
“可靠性”策略在ROS 1中等效于UDPROS（尽力服务）和TCPROS（可靠）。其中UDPROS仅在roscpp中存在，TCPROS是ROS 1的默认值。注意ROS 2的可靠性策略是基于UDP实现的，它仍允许组播的存在。
“耐用性”策略中的“暂存本地”，加上任意的深度，提供了类似发布者“锁存”的功能。
ROS 2中的其余策略都同ROS 1中的策略没有相似之处。

QoS配置文件

配置文件允许开发者集中精力于他们的应用本身，而无需关注到每个QoS的设置。一个QoS配置文件为一个特定的用户场景定义了一系列策略。
预定义的QoS配置文件如下:

• 默认：适用于发布订阅
  为了可以更简单地从ROS1迁移至ROS2，需要采用同ROS1相似的网络配置。默认情况下，ROS2中的发布订阅使用“保留最后”的策略，且队深为10；可靠性设置为“可靠”；耐用性设置为“挥发性”；活跃程度设置为“系统默认”。截止时间、寿命、租赁周期也均设为“默认”。
• 服务
  服务也设置为与发布订阅相同的可靠性。对服务来说，使用挥发性的耐用性设置尤为重要，否则服务端将可能会收到过期的请求。此时，客户端可以避免收到多个响应，而服务端则会收到过期请求。
• 传感数据
  大部分情况下，我们希望能够实时地接收到传感器的数据，而不会过多地关注于所有的数据都被送达。对开发者来说，我们需要的是最新的采样数据，可以接受部分数据被丢弃。因此，传感器的配置文件将使用尽力的可靠性和一个较小的队列深度。
• 参数
  ROS2的参数是基于服务的，因此使用同服务相同的配置文件。不同点仅在于参数会使用更大的队列深度，以便在参数的请求方无法获取服务时尽可能地保留相关请求不被丢弃。
• 系统默认
  对所有的策略使用RMW实现的默认设置。不同的RMW实现可能有不同的默认值。

可以在此链接中找到上述的配置文件。此配置文件中的设定将根据社区的反馈进行调整。

QoS兼容性

注意本节涉及的发布者和订阅者的内容，也覆盖了服务中的服务端和客户端。

我们可以为发布者和订阅者独立地设置QoS配置文件，只有在具有相兼容的的配置文件时，二者才能正确连接。

QoS配置文件基于“请求/提供”模型来确定器兼容性。订阅者请求一个它可接受的最低质量的QoS配置文件，发布者提供一个它可提供的最高质量的QoS配置文件。只有当请求的QoS配置文件的每个策略都松于提供的QoS配置文件的对应策略时，连接才会被建立。发布者和订阅者之间的兼容性不受其它发布者和订阅者的存在影响，这意味着，即使多个订阅者请求的配置文件不同，它们也可以同时连接到同一个发布者。

不同策略的配置兼容性如下表所示：

reliability QoS策略兼容性

发布者	订阅者	兼容与否？
Best effort	Best effort	Yes
Best effort	Reliable	No
Reliable	Best effort	Yes
Reliable	Reliable	Yes

durability QoS策略兼容性

发布者	订阅者	兼容与否？
Volatile	Volatile	Yes
Volatile	Transient local	No
Transient local	Volatile	Yes
Transient local	Transient local	Yes

deadline QoS策略兼容性
假设x与y为可用的任意持续时间值

发布者	订阅者	兼容与否？
Default	Default	Yes
Default	x	No
x	Default	Yes
x	x	Yes
x	y (y>x)	Yes
x	y (y<x)	No

liveliness QoS策略兼容性

发布者	订阅者	兼容与否？
Automatic	Automatic	Yes
Automatic	Manual by topic	No
Manual by topic	Automatic	Yes
Manual by topic	Manual by topic	Yes

lease duration QoS策略兼容性

假设x与y为可用的任意持续时间值

发布者	订阅者	兼容与否？
Default	Default	Yes
Default	x	No
x	Default	Yes
x	x	Yes
x	y (y>x)	Yes
x	y (y<x)	No

只有所有影响兼容性策略的策略都为兼容时，方可建立连接。反之，即使请求的和提供的某一QoS配置文件不具有兼容性时，则他们仍不会建立连接。
当无法建立连接时，发布者和订阅者之间不会传递任何消息。有一些机制可以检测这种情况，可以在后续的小节中进行讨论。

ROS1的QoS体系

在ROS1中的QoS体系更为宽松，任何在相同主题上具有相同消息类型的发布者和订阅者之间都能通信，并不考虑相互间的服务质量。

QoS事件

在某些QoS策略下，系统将提供相关的事件，我们可以对发布者和订阅者提供回调函数。回调函数由前述的QoS事件触发，我们可以在回调函数中书写相应的处理，典型的例如如何处理接收到的主题消息。

发布者相关事件

• 发布者过期Offered deadline missed
  发布者未能在deadline QoS策略期望的时间内发布相应的消息。

• 失活Liveliness lost
  发布者未能在周期内声明其活跃性。

• QoS设置不兼容Offered incompatible QoS
  发布者的QoS配置不能满足订阅者请求的相关配置要求，导致二者无法连接。

订阅者相关事件

• 订阅者过期Requested deadline missed
  订阅者未能在deadline QoS策略期望的时间内收到相应的消息。

• 活跃性变化Liveliness changed
  订阅者发现任意发布者未能在周期内声明其活跃性。

• QoS设置不兼容Requested incompatible QoS
  发布者的QoS配置不能满足订阅者请求的相关配置要求，导致二者无法连接。

参考

---

1. About Quality of Service settings ↩︎