一、说明

        本文描述了具有托管生命周期的节点的概念。它旨在记录一些支持管理 ROS 2 生命周期节点的选项。它的编写考虑了 ROS 2 C++ 客户端库的现有设计，尤其是执行程序的当前设计。

二、背景

        节点的托管生命周期允许更好地控制 ROS 系统的状态。它将允许 roslaunch 在允许任何组件开始执行其行为之前确保所有组件都已正确实例化。它还将允许重新启动或在线更换节点。

        本文档最重要的概念是受管节点呈现已知接口，根据已知生命周期状态机执行，否则可被视为黑盒。这允许节点开发人员自由选择他们如何提供托管生命周期功能，同时还确保为管理节点创建的任何工具都可以与任何兼容节点一起使用。

三、生命周期

3.1 整体流程

         有 4 个主要状态：

• Unconfigured
• Inactive
• Active
• Finalized

        要从主要状态转换出来需要外部监督进程的操作，但在 Active 状态下触发的错误除外。

        还有 6 个过渡状态，它们是请求的过渡期间的中间状态。

• Configuring
• CleaningUp
• ShuttingDown
• Activating
• Deactivating
• ErrorProcessing

        在转换状态中，将执行逻辑以确定转换是否成功。应通过生命周期管理界面将成功或失败传达给生命周期管理软件。

        有 7 个转换暴露给监督过程，它们是：

• create
• configure
• cleanup
• activate
• deactivate
• shutdown
• destroy

每个状态的行为定义如下。

3.2 状态解释

3.2.1 主要状态：未配置

        这是节点在实例化后立即处于的生命周期状态。这也是节点在发生错误后可能返回到的状态。在这种状态下，预计不会有任何存储状态。

        有效转换出

• 节点可以通过配置转换转换到非活动状态。
• 节点可以通过关闭转换转换到最终状态。

3.2.2 主要状态： 不活跃

        此状态表示当前未执行任何处理的节点。 此状态的主要目的是允许节点被（重新）配置（更改配置参数、添加和删除主题发布/订阅等）而不改变其运行时的行为。 在此状态下，节点将不会收到任何执行时间来读取主题、执行数据处理、响应功能服务请求等。 在非活动状态下，任何到达托管主题的数据都不会被读取和/或处理。数据保留将遵循为该主题配置的 QoS 策略。 对处于非活动状态的节点的任何托管服务请求都不会得到答复（对于调用者，它们将立即失败）。

        从非活动状态有效转换

• 节点可以通过关闭转换转换到最终状态。
• 节点可以通过清理转换转换到未配置状态。
• 节点可以通过激活转换转换到活动状态。

3.2.3 主要状态：活跃

        这是节点生命周期的主要状态。在此状态下，节点执行任何处理、响应服务请求、读取和处理数据、产生输出等。

        如果在此状态下发生节点/系统无法处理的错误，节点将转换为 ErrorProcessing。

        有效转换出 Active

• 节点可以通过停用转换转换到非活动状态。

• 节点可以通过关闭转换转换到最终状态。

3.2.4 主要状态：完成

        Finalized 状态是节点在被销毁之前立即结束的状态。此状态始终是终端状态，从这里开始的唯一转换将被销毁。

        此状态的存在是为了支持调试和自省。发生故障的节点将对系统自检保持可见，并且可能可以通过调试工具进行自检，而不是直接销毁。如果节点在重生循环中启动或已知循环的原因，则预计监管进程将有一个自动销毁和重新创建节点的策略。

        Finalized 之外的有效转换

• 可以通过销毁转换释放节点。

3.2.5 过渡状态：配置

        在此转换状态下，将调用节点的 onConfigure 回调以允许节点加载其配置并进行任何所需的设置。

节点的配置通常会涉及那些必须在节点的生命周期内执行一次的任务，例如获取永久内存缓冲区和设置不会更改的主题发布/订阅。

        节点使用它来设置它在其整个生命周期中必须持有的任何资源（无论它是活动的还是非活动的）。例如，此类资源可能包括主题发布和订阅、持续保存的内存以及初始化配置参数。

配置中的有效转换

• 如果 onConfigure 回调成功，节点将转换为 Inactive
• 如果 onConfigure 回调导致失败代码（TODO 特定代码），节点将转换回未配置。
• 如果 onConfigure 回调引发或导致任何其他结果代码，则节点将转换为 ErrorProcessing

3.2.6 过渡状态：清理

        在此转换状态下，将调用节点的回调 onCleanup。此方法应清除所有状态并将节点返回到与首次创建时功能等效的状态。如果无法成功完成清理，它将转换为 ErrorProcessing。

        如果 CleaningUp 则有效转换

• 如果 onCleanup 回调成功，节点将转换为未配置。
• 如果 onCleanup 回调引发或导致任何其他返回代码，则节点将转换为 ErrorProcessing。

3.2.7 过渡状态：激活

        在此转换状态下，将执行回调 onActivate。此方法应为开始执行做任何最后准备。这可能包括获取仅在节点实际处于活动状态时持有的资源，例如对硬件的访问。理想情况下，不应在此回调中执行需要大量时间的准备工作（例如冗长的硬件初始化）。

        如果激活则有效转换

• 如果 onActivate 回调成功，节点将转换为活动状态。

• 如果 onActivate 回调引发或导致任何其他返回代码，则节点将转换为 ErrorProcessing。

3.2.8 过渡状态：停用

        在此转换状态下，将执行回调 onDeactivate。此方法预计会进行任何清理以开始执行，并且应该反转 onActivate 更改。

        停用的有效转换

• If the onDeactivate callback succeeds the node will transition to Inactive.
• If the onDeactivate callback raises or results in any other return code the node will transition to ErrorProcessing.

3.2.9 过渡状态：关闭

        在此转换状态下，回调 onShutdown 将被执行。预计此方法将在销毁之前进行任何必要的清理。它可以从除 Finalized 之外的任何主要状态输入，原始状态将传递给该方法。

        退出 ShuttingDown 的有效转换

• If the onShutdown callback succeeds the node will transition to Finalized.
• If the onShutdown callback raises or results in any other return code the node will transition to ErrorProcessing.

3.2.10 过渡状态：错误处理

        此过渡状态是可以清除任何错误的地方。可以从将执行用户代码的任何状态进入此状态。如果错误处理成功完成，节点可以返回到未配置状态，如果不可能进行完全清理，则它必须失败，并且节点将过渡到已完成状态以准备销毁。

        到 ErrorProcessing 的转换可能是由回调中的错误返回代码以及回调中的方法或未捕获的异常引起的。

        ErrorProcessing 的有效转换

• 如果 onError 回调成功，节点将转换为未配置。预计 onError 将清除任何先前状态的所有状态。因此，如果从 Active 进入，它必须提供 onDeactivate 和 onCleanup 的清理以返回成功。

• 如果 onShutdown 回调引发或导致任何其他结果代码，则节点将转换为已完成。

3.2.11 破坏过渡

        此转换将简单地导致节点的重新分配。在面向对象的环境中，它可能只涉及调用析构函数。否则它将调用标准的释放方法。这种转变应该总是成功的。

3.2.12 创建过渡

        此转换将实例化节点，但不会运行构造函数之外的任何代码。

四、管理的接口

        管理节点将通过以下接口暴露给 ROS 生态系统，如执行管理的工具所见。该接口不应受到生命周期状态强加的通信限制。

        预计一个常见的模式是拥有一个容器类，该类从库中加载托管节点实现，并通过插件体系结构通过方法自动公开所需的管理接口，并且容器不受生命周期管理的约束。但是，将提供此接口并遵循生命周期策略的任何实现视为受管节点是完全有效的。相反，任何提供这些服务但不按照生命周期状态机中定义的方式运行的对象都是畸形的。

        除了公开 ROS 消息和主题/服务（用于远程管理）之外，还可以通过属性和方法调用（用于本地管理）提供这些服务。在提供 ROS 中间件接口的情况下，必须使用特定的主题，并将它们放在合适的命名空间中。

        每个可能的监督转换都将作为一个服务以转换的名称提供，create 除外。 create 将需要一个额外的参数来查找要实例化的节点。该服务将报告转换是否已成功完成。

4.1 生命周期事件

        应提供一个主题，以在其更改时广播新的生命周期状态。这个话题一定要顶。该主题必须命名为 lifecycle_state 它将包含结束状态和转换，以及结果代码。每次触发转换时都会发布，无论成功与否。

4.2 节点管理

        受管节点可以通过几种不同的方式在状态之间转换。大多数状态转换预计将由外部管理工具协调，该工具将为节点提供其配置并启动它。还期望外部管理工具对其进行监视并在发生故障时执行恢复行为。本地管理工具也是一种可能性，利用方法级接口。并且节点可以配置为自我管理，但是不鼓励这样做，因为这会干扰试图通过接口管理节点的外部逻辑。

        有一种转换预计会在本地发起，即 ERROR 转换。

        受管节点可能还希望公开参数以在非受管系统中运行时自动配置和激活。

4.3 扩展

        此生命周期将需要在整个工具链中得到支持，因此此设计不打算使用其他状态进行扩展。预计会有更复杂的特定于应用程序的状态机。它们可能存在于任何生命周期状态内部，或者在宏观层面上，这些生命周期状态被期望作为监督系统的一部分是有用的原语。

Managed nodes