Lifecycle node (managed node)

Lifecycle node (managed node) – definition

A lifecycle node, also called a managed node, is a ROS 2 node with a defined runtime state machine. Unlike a regular ROS 2 node, it is intended to be configured and explicitly activated before it performs its operational task. The lifecycle model does not automatically prevent arbitrary code from publishing data, accepting work, or controlling hardware; node implementations must follow lifecycle conventions and use lifecycle-aware interfaces where appropriate.

The ROS 2 lifecycle model is implemented by the rclcpp_lifecycle package in C++. Python lifecycle support is provided by the rclpy.lifecycle API in ROS 2 releases that include it. It is based on the managed-node design maintained in the ROS 2 documentation. The model is useful in mobile robotics because autonomous navigation depends on ordered startup, validated sensor availability, predictable shutdown, and fault handling.

For a UGV, lifecycle control can separate hardware initialization from motion-capable operation. For example, a LiDAR driver can open its serial or Ethernet connection during configuration, but publish scans only after activation. A navigation component can load a map and validate transforms before it is allowed to generate velocity commands.

On Leo Rover or Raph Rover, this mechanism helps prevent a partially initialized software stack from commanding the drive base. It does not make either platform autonomous by itself. A complete autonomous system still requires integrated sensing, TF transforms, localization or SLAM, obstacle perception, and a navigation controller.

ROS 2 lifecycle states and transitions

ROS 2 defines primary states, transitional states, and transition services for managed nodes. A lifecycle-aware supervisor can query the current state and request a valid transition. The state IDs below are defined in lifecycle_msgs/msg/State.

State	State ID	Meaning for a mobile robot component
`unconfigured`	1	The process exists, but hardware resources and operational interfaces are not ready.
`inactive`	2	Configuration succeeded. The node may hold resources but should not perform its active mission function.
`active`	3	The node performs its normal task, such as publishing usable sensor data or processing navigation goals.
`finalized`	4	The node has completed shutdown and cannot be returned to an operational state.

The transient states are configuring, cleaningup, activating, deactivating, shuttingdown, and errorprocessing. Their IDs range from 10 to 15 in the lifecycle message definition. A transition callback returns a result such as SUCCESS, FAILURE, or ERROR, which determines the next state.

Source: ROS 2 lifecycle_msgs State message documentation.

How lifecycle nodes work in ROS 2

A C++ lifecycle node derives from rclcpp_lifecycle::LifecycleNode. It implements callbacks that correspond to state transitions. Resource allocation belongs in configuration callbacks, while actions that enable data flow belong in activation callbacks.

on_configure() – declare or read parameters, allocate buffers, connect to a LiDAR, camera, GNSS receiver, or motor interface.
on_activate() – activate lifecycle publishers and begin operational processing.
on_deactivate() – stop operational publishing and disable motion-related outputs.
on_cleanup() – release resources and return to an unconfigured state.
on_shutdown() – close resources before final termination.
on_error() – execute recovery or safe-stop logic after an error transition.

Lifecycle nodes expose standard services under the node namespace. Important interfaces include change_state, get_state, get_available_states, get_available_transitions, and get_transition_graph. Their service definitions are provided by lifecycle_msgs.

# Inspect the state of a managed ROS 2 node
ros2 lifecycle get /lidar_driver

# Request the configure transition
ros2 lifecycle set /lidar_driver configure

# Request activation after successful configuration
ros2 lifecycle set /lidar_driver activate

Source: ROS 2 documentation, About Lifecycle Nodes.

Lifecycle management in a UGV navigation stack

Managed nodes are particularly relevant when several subsystems must start in dependency order. A localization node should not enter its active state before its required TF frames, odometry source, and sensor topics are available. Similarly, a path controller should not output velocity commands until localization and costmap components are healthy.

In Nav2, the lifecycle manager coordinates lifecycle transitions for a set of navigation servers. It can bring nodes up in a configured order and deactivate them during shutdown or failure handling. Nav2 lifecycle management is commonly used with components such as planners, controllers, behavior servers, map servers, and costmaps.

lifecycle_manager:
  ros__parameters:
    autostart: false
    node_names:
      - map_server
      - amcl
      - controller_server
      - planner_server
      - bt_navigator

This configuration does not define all runtime dependencies. The integrator must still verify topic names, frame IDs, transform availability, QoS compatibility, and hardware-driver status before enabling autonomous movement.

Source: Nav2 documentation, Lifecycle Manager.

Use on Leo Rover and Raph Rover

Leo Rover can run ROS 2 software on its built-in Raspberry Pi compute unit. Available ROS 2 distributions, platform-specific interfaces, installed packages, and supported ROS 2 images should be verified against the current Leo Rover technical documentation.

For Leo Rover, a managed sensor pipeline may use the following order: configure the LiDAR or depth-camera driver, validate the base_link to sensor transform, activate the driver, then configure and activate localization and navigation nodes. Because Leo Rover is a four-wheel differential-drive platform, the velocity-command path should be disabled whenever localization, obstacle sensing, or the base interface enters an error state.

Raph Rover can use the same ROS 2 lifecycle pattern when a configuration requires several sensors or external compute modules. Typical examples include an RTK GNSS receiver, multiple cameras, a 3D LiDAR, and a dedicated GPU computer. Lifecycle management does not guarantee timing determinism. It coordinates application state; real-time motor control, watchdog behavior, and emergency-stop design require separate hardware and software safety mechanisms.

ROS 1 and ROS 2 differences

ROS 1 did not provide the standardized managed-node lifecycle API used by ROS 2. ROS 1 nodes could implement custom startup services, diagnostics, or nodelets, but these mechanisms were not equivalent to the ROS 2 lifecycle state machine. When porting a UGV stack from ROS 1, lifecycle transitions must therefore be designed explicitly rather than assumed to exist.

The ROS 2 lifecycle model and its C++ API are available across supported ROS 2 distributions, although client-library APIs, package APIs, and Nav2 configuration details can vary between releases. ROS distribution support periods and target platforms are defined in REP 2000.

Source: REP 2000 – ROS 2 Releases and Target Platforms.

Lifecycle node (managed node)