4.1 生命周期节点

4.1 生命周期节点

本节摘要：普通节点一旦构造完成就开始收发数据，这份"热情"在系统级场景里反而是风险：硬件还没就位就在消费传感器流，参数还没注入就在做决策。生命周期节点把节点从构造到工作之间的事件显式化为一台状态机。本节讲清五状态语义、迁移驱动方式，以及导航栈等真实系统如何用它解决"就绪"问题——这是第 6 章 Nav2 的必经前置。

在跑，不等于就绪

上一章结尾留下的问题可以更尖锐一点：进程拉起来了、回调开始触发了，但系统真的"就绪"吗？传感器驱动可能在等硬件自检，地图服务器可能还在读盘，参数可能还有一份没注入完。普通节点对这一切毫不知情——构造函数跑完就是全部。生命周期节点的立场是：把"配置"与"激活"拆成两个由外部掌控的阶段，每一步成功了才走下一步。这个立场的受益场景远比想象的多。

一、状态机的完整语义

生命周期节点有五个状态：未配置、不活动、活动、终态，以及过程性的迁移中。真正重要的是三条主迁移线的语义差异。

configure：从未配置到不活动。 触发 on_configure 回调，此刻应当做"读取参数、打开硬件、分配资源"这类重活。配置成功进入不活动态——注意，此时订阅已经建立，但回调被设计为不处理数据，硬件可能已上电但不出流。activate：从不活动到活动。 触发 on_activate，开始真正工作：激活订阅处理、启动硬件数据流。deactivate 与 cleanup：逆向走。 deactivate 停止工作但保留配置，适合"临时暂停"；cleanup 释放资源回到未配置，适合"换一套配置重来"。任何状态都能 shutdown 直达终态。

外部通过服务调用驱动迁移。同一个节点，命令行就能操纵：

# 起一个生命周期 demo 节点
ros2 run lifecycle lifecycle_talker

# 另一终端驱动它走完一生
ros2 lifecycle set /lc_talker configure     # 配置
ros2 lifecycle set /lc_talker activate      # 激活，开始工作
ros2 lifecycle get /lc_talker               # 查询当前状态
ros2 lifecycle set /lc_talker deactivate    # 暂停
​

# Python 侧实现骨架：每个迁移对应一个回调
import rclpy
from rclpy.lifecycle import Node as LifecycleNode

class DriverNode(LifecycleNode):
    def __init__(self):
        super().__init__('lidar_driver')

    def on_configure(self, state):
        # 读参数、开硬件、建发布订阅（不激活处理）
        self.get_logger().info('配置完成：硬件自检通过')
        return True

    def on_activate(self, state):
        self.get_logger().info('激活：开始输出点云')
        return True

    def on_deactivate(self, state):
        self.get_logger().info('暂停：数据流已停')
        return True
​

⚠️ 常见坑：on_configure 返回失败不会让节点崩溃，节点停在未配置态等你重试——这是特性不是缺陷。把"硬件暂时不在"这类可恢复情况处理成 configure 失败，比抛异常退出优雅得多，运维脚本可以周期性重试 configure。

二、订阅语义的关键差异

生命周期节点最容易被误解的一点：不活动状态下订阅收到的消息怎么办。答案是回调不执行，消息按 QoS 策略处理——depth 有限的队列会被后来的消息填满顶替，等节点激活时拿到的是"最新几帧"而不是全部历史。这个语义配合 2.2 节的 durability 有个漂亮的组合：地图服务器不活动时积累 transient_local 的最后一帧地图，激活瞬间下游立刻拿到，无需特殊代码。

由此得出一条工程纪律：生命周期节点的业务回调要写成"只在激活态干活"。多数框架封装帮你做了这个判断，但当你手动创建订阅时，记得在回调入口检查当前状态，否则会出现"配置好了但还没激活，数据却已经开始被消费"的越权行为。

三、导航栈怎么用它：一个真实样本

Nav2 是生命周期语义最大的实战用户，它的每个服务器（规划、控制、地图、行为树节点）都是生命周期节点。这套设计在启动顺序上给出的答案值得细看：Launch 先把所有节点拉起到不活动态——此时每个节点已完成配置、硬件就绪、参数注入完毕，但系统还没有一条数据在流动；然后由一个编排者（通常是 bt_navigator 或专门的 lifecycle manager）按依赖顺序逐个 activate。

# 观察一条真实导航栈的状态迁移
ros2 lifecycle get /map_server        # 输出 active
ros2 lifecycle get /planner_server    # 输出 active
ros2 lifecycle get /controller_server # 输出 active
# 顺序由 lifecycle_manager 的 autostart 编排，地图先活，规划后活
​

为什么不用"全都 activate"并行拉起？因为规划器激活时需要地图服务已可用——activate 的顺序就是依赖图的拓扑序。这个样本回答了 4.1 开头的问题：生命周期不是给单节点加仪式感，而是让系统的就绪过程变成可编排、可观测、可重试的显式流程。

💡 关键直觉：把生命周期节点看作"硬件与系统之间的一道阀门"。configure 是通前检查，activate 是开阀，deactivate 是关阀。凡是要跟硬件打交道的节点，都值得这道阀门；纯计算节点用普通节点就好，别为仪式感付复杂度。

本节要点回顾

• 三条主迁移线：configure 配置资源，activate 开始工作，cleanup 释放重来；
• 不活动态订阅照常收数据，但回调不执行，历史是否保留看 QoS 的 durability；
• configure 失败可重试是特性，可恢复故障应当用它表达，而不是崩溃退出；
• Nav2 的实践范式：全部拉起到不活动，再按依赖拓扑序逐个激活；
• 判断标准：跟硬件打交道或依赖顺序敏感的节点用生命周期，其余用普通节点。

节点的状态语义齐了，下一节换个维度：这些节点该住在同一个进程里，还是各住各的。