ROS QoS - 截止时间、活动性和生命周期¶
本文提出在 ROS 中添加截止时间（Deadline）、活动性（Liveliness）和生命周期（Lifespan）QoS 设置的理由，概述了相关需求并探讨了如何将这些设置与现有代码库集成。
作者: Nick Burek
翻译：Akana-kunama
撰写日期: 2019-09
最后修改: 2019-09**
术语¶
DDS - 数据分发服务（Data Distribution Service）
RTPS - 实时发布订阅（Real-Time Publish Subscribe）
QoS - 服务质量（Quality of Service）
服务客户端 - 通常简称为客户端，指连接到 ROS 服务发送请求和接收响应的应用程序。
服务服务器 - 通常简称为服务器，指运行 ROS 服务、接收请求并发送响应的应用程序。
现有的 ROS QoS 设置¶
DDS 提供了许多设置，允许对实体的服务质量进行精细控制，而 ROS 原生只支持其中少数设置。ROS 用户可以通过 QoS 配置结构体，在创建发布者、订阅者等实体时指定历史、深度、可靠性和持久性。
这导致许多 QoS 设置只能通过 DDS 供应商加载额外的默认配置文件来设置。如果用户希望利用这些额外的 QoS 设置，则需要获取 rmw 实现的引用并针对供应商特定的 API 进行编程。这样做会削弱代码的可移植性，因为它绕过了 ROS 提供的抽象层。
新的 QoS 设置¶
随着用户开始构建更复杂的应用程序，他们将需要更多的控制来管理数据的传递时间，以及获取系统失败的相关信息。为了解决这些需求，建议添加以下新的 DDS QoS 设置支持：
截止时间（Deadline）¶
截止时间策略为消息之间的时间间隔设立了一个契约。对于订阅者，它规定了接收消息之间的最大允许时间。对于发布者，它规定了发送消息之间的最大允许时间。截止时间的跟踪将支持到 rmw 层，这意味着如果 rmw 层未在指定时间内接收到消息，则认为截止时间未满足。
订阅者请求的截止时间必须大于或等于发布者设定的截止时间。设置为 0 的截止时间将禁用截止时间跟踪。默认的截止时间为 0。
活动性（Liveliness）¶
活动性策略规定了实体报告其仍然“存活”的方式。订阅者规定其从所订阅的发布者中要求的报告级别；发布者规定其向订阅者提供的活动性报告。
支持的活动性级别包括：
LIVELINESS_SYSTEM_DEFAULT - 使用 ROS 指定的活动性默认值（LIVELINESS_AUTOMATIC）。
LIVELINESS_AUTOMATIC - 活动性信号来自 ROS
rmw层。LIVELINESS_MANUAL_BY_TOPIC - 活动性信号在主题级别上。只有在主题上发布消息或应用程序显式发送信号时，才能标记该主题为“活跃”。
订阅者要求的活动性跟踪级别必须等于或不比发布者提供的级别更详细，且订阅者设定的失活时间必须大于发布者设定的失活时间。
生命周期（Lifespan）¶
生命周期策略规定了消息保持有效的时间。对于订阅者，它规定了消息被视为有效的时长，超过该时长后消息将不再被接收。对于发布者，它规定了消息被视为有效的时长，超过该时长后消息将从主题历史记录中移除并不再发送给订阅者。生命周期时间为 0 将禁用生命周期跟踪，默认生命周期时间为 0。
DDS QoS 关系¶
这些新策略基于 DDS QoS 策略，但它们不需要 DDS 就能被 rmw 实现支持。
ROS 变更¶
为原生支持截止时间和活动性，需要对 ROS 进行以下变更：
资源状态事件处理器¶
截止时间和活动性策略会在 rmw 层生成事件，应用程序需要接收通知。可以为用户提供新的回调函数，当某个主题发生事件时调用这些回调函数。
QoS 结构体¶
现有的 QoS 结构体将新增字段来指定截止时间、活动性和生命周期的设置。新字段将是枚举和时间值的组合。
声明活动性函数¶
新功能允许应用程序显式声明活动性，既可以在节点级别，也可以在主题级别进行声明。
rcl_wait 和 rmw_wait¶
为了支持新的主题状态事件，现有的 WaitSet 将添加新的类型，用于捕捉这些事件。
rcl_take_status 和 rmw_take_status¶
新函数 rcl_take_status 和 rmw_take_status 将直接查询主题的状态，用于获取新的状态事件。
RMW 供应商支持¶
所有这些新的 QoS 策略都需要在 rmw 实现中得到支持。如果某个 rmw 供应商不支持指定的策略，应用程序应该能够通过 API 查询当前供应商的支持情况。
常见问题解答¶
如何考虑 ROS 的额外开销（如反序列化）？ 截止时间不考虑 ROS 的额外开销，仅考虑
rmw层接收消息的时间。为何不对每个状态事件调用回调？ 这样做需要额外的缓冲区来存储多个事件，DDS API 更适合仅通知最新的状态变化。
这些 QoS 策略如何影响 Actions 和 Services？ 初始实现不支持 Actions 和 Services，因为它们的实现更加复杂，需要进一步研究。
未来工作¶
未来计划包括在 Actions 和 Services 中实现这些 QoS 策略。