参考文献：ROS2 EXTENDED CONCEPTS

在前2篇博文中总结了ROS2的基本概念，这些内容大致与ROS1类似或改进，属于ROS2/ROS1的核心概念。本节侧重ROS2扩展的新内容。

既然是极简，自然不会面面俱到，以2个例子为主吧。

• 管理节点
• 服务质量

1 管理节点

主要由5个部分组成：

1. 状态机
2. 状态
3. 标准接口
4. 命令行接口（CLI）
5. 启动文件

• ROS1 中的常见问题反馈是无法控制节点的生命周期。
  • 例如：传感器的读取往往在传感器驱动程序之前启动！
• ROS 2 解决方案是具有详细生命周期管理的节点
  • CPP implemented，Python pending
• 节点使用 rclcpp_lifecycle::LifecycleNode 而不是常用的 rclcpp::Node
• 符合已知接口和已知生命周期状态机。
• 也称为生命周期 (Lifecycle, LC) 节点

管理节点状态机

状态机具有：

• 主要状态 - 稳态。 一个节点大部分时间都是此类状态。
• 次要状态 - 瞬态。 处理过渡。
• 转换 - 触发状态更改。 用户可以通过启动文件、管理器节点和 CLI 服务调用等方式实现。

详细模型如下图所示：

状态

主要状态

• 未配置 - 节点开始时的第一个状态，并在出现错误后结束。没有执行，其主要目的是错误恢复。
• 非活跃 - 节点持有资源（发布者、监听者等）和配置（参数、内部变量），但什么也不做。 没有执行，没有传输，传入的数据可以保存在缓冲区中，但不能读取。 主要目的是允许重新配置。
• 活跃 - 一切正常。 正常执行。
• 已完成 - 节点已被销毁。 仅用于调试。

注意下图所示的蓝色箭头所指：

次要状态

执行标准化的回调函数。用户代码在此处实现。

• 配置 - 执行 onConfigure() - 加载配置、冗长的设置步骤、获取节点生命周期内使用的资源，如常量发布者/侦听器、内存缓冲区分配等...
• 清理- 执行 onCleanup() - 放弃资源，擦除内存。 新的开始，清理状态。
• 激活 - 执行 onActivate() - 获取传感器等短期资源，激活所有资源。 设置时间短。 启动主节点任务。
• 停用 - 执行 onDeactivate() - 反向Activatingsteps（反激活）。 暂停执行，释放短期资源。
• 关闭 - 执行 onShutdown() - 最后步骤。 删除剩下的资源等。 没有信息从此处回来。
• 错误处理- 执行 onError() - 错误处理状态。 如果错误可以处理，则恢复到 Unconfigured，否则，转到 Finalized 销毁节点。

有目的地实现回调函数可以避免畸形节点。

典型状态流程

标准接口

创建生命周期节点需要一些标准接口 服务：

• <ns>/change_state - 调用触发合法转换
• <ns>/get_available_transitions - 显示合法的转换
• <ns>/get_state - 显示当前状态
• <ns>/get_available_states - 列出所有状态
• <ns>/get_transition_graph - 显示完整状态机

主题：

• <ns>/<node_name>__transition_event - 发布正在进行的转换

生命周期命令行接口

生命周期节点除了可以通过服务进行控制，也可以通过 ros2 lifecycle 进行控制。

• ros2 lifecycle nodes - 列出所有 LC 节点
• ros2 lifecycle get <node> - 列出指定节点或所有 LC 节点的当前状态。
• ros2 lifecycle list <node> - 列出指定节点可能的下一个状态和相应的转换调用（名称和 ID）。
• ros2 lifecycle set <node> <transition> - 在 LC 节点上触发转换（按名称或 ID）。

启动文件中的 LC 管理

ROS2 Python Launch 文件提供了一些 LC API：

• launch_ros.actions.LifecycleNode(..) 定义一个 LC 节点
• launch_ros.event_handlers.OnStateTransition(..) 当 LC 节点从一种状态转换到另一种状态时，执行此动作
• launch.actions.EmitEvent(..) 选择想要触发的事件
• launch_ros.events.lifecycle.ChangeState(..) 通过为 LC 节点选择转换创建更改状态事件
• Lifecycle_msgs.msg 保存状态和转换名称的枚举

2 服务质量（QoS）

介绍如下3个部分：

• 策略
• 概况
• QoS兼容性

ROS 1 通讯协议：

• 默认为 TCP。 无损传输、高延迟、可靠。
• UDP 可选。 有损传输、低延迟、不可靠、不像 TCP 那样丰富地实现。

ROS 2 通讯协议：

• 仅默认 UDP。 （但依赖于 DDS）。 轻量级，允许实时通信。
• 应用 QoS 策略在 TCP 和 UDP 之间灵活变化。
• QoS：称为配置文件的策略组合，应用于发布者、订阅者、服务器端和客户端，定义了这些实体之间的通信质量。

支持 C++ 和 Python 实现。

• C++：qos.h 包含在 <rclcpp.h> 中。
• Python：import rclpy.qos
• 创建 QoS 对象、设置不同的策略或分配现有配置文件。
• 创建资源时将 QoS 对象作为参数传递。

策略

概况

策略组合。 方便选择个人配置，而不必担心个别策略。 一些默认配置文件已经可用（例如 C++：qos_profiles.h）：

• 默认：如果未指定，则默认应用。 类似 ROS1。keep_last(10),reliable(),volatile()...
• 服务：通常服务应该是可靠的。 易失性避免过时的请求 keep_last(10),reliable(),volatile()...
• 参数：ROS2 参数通过服务访问。 类似的配置文件，但深度更长在缓冲区中保留更多参数。 keep_last(1000),reliable(),volatile()...
• 传感器：传感器数据需要具有最小延迟才能保持相关性，但会丢失一些样本。 keep_last(5),best_effort(),volatile()...

也可以创建自定义配置文件。 例如，要制作一个闩锁的发布者：

• rclcpp::QoS qos_profile(10); qos_profile.reliable().transient_local();

兼容性

QOS 资源只有兼容才能配对

QoS 配置文件单独分配给每个资源。

资源兼容性基于“Request vs Offerer”模型

• 仅当订阅者/客户端与发布者/服务器一样/不那么严格时才配对。
• 然后对连接采用两者中较不严格的策略。

为此只考虑持久性和可靠性。 两者都必须满足。

• 持久性严格性：transient_local > volatile
• 可靠性严格性：reliable > best best_effort

案例：