ROS 2 Lyrical Luth · Lesson 71 of 86
Lifecycle nodes
Managed states, transition callbacks and controlled start-up of hardware.
Estimated time · 60–90 min
Learning goals
What you will understand
- Explain lifecycle nodes in your own words
- Use it in a small robotics example
- Verify the result instead of assuming it worked
Understand the idea first
The mental model
A lifecycle (managed) node has a defined state machine: unconfigured, inactive, active and finalized. You implement transition callbacks: on_configure (allocate resources), on_activate (start publishing and moving), on_deactivate, on_cleanup and on_shutdown, each returning SUCCESS, FAILURE or ERROR.
This gives the system a controlled start-up: hardware is opened in configure but only moves after activate, and it can be paused without destroying the node. Nav2 is built this way. Drive it with ros2 lifecycle set /node configure|activate and inspect with ros2 lifecycle get.
Guided lesson
Work through these steps
- 1.
Source the ROS 2 Lyrical environment in a fresh terminal.
- 2.
Read the lifecycle nodes example and identify what each line does.
- 3.
Build only the affected package, source the workspace overlay, and run the example.
- 4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.
Worked example
Read it before you run it
using CallbackReturn = rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn;
// Short name for the transition result type.
class Driver : public rclcpp_lifecycle::LifecycleNode {
// A managed node.
public:
// Public interface.
Driver() : LifecycleNode("driver") {}
// Starts in the unconfigured state.
CallbackReturn on_configure(const rclcpp_lifecycle::State&) override {
// Runs on the configure transition.
pub_ = create_publisher<std_msgs::msg::String>("status", 10);
// Create resources but do not use them yet.
return CallbackReturn::SUCCESS;
// Move to inactive.
}
// End of on_configure.
CallbackReturn on_activate(const rclcpp_lifecycle::State&) override {
// Runs on activate.
pub_->on_activate();
// Lifecycle publishers only send once activated.
return CallbackReturn::SUCCESS;
// Move to active.
}
// End of on_activate.
private:
// Hidden state.
rclcpp_lifecycle::LifecyclePublisher<std_msgs::msg::String>::SharedPtr pub_;
// A publisher that obeys the lifecycle.
};
// End of the class.What the example is doing
- 1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
- 2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
- 3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.
Watch it run · Messages between nodes
See what this code does
The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.
Demo for Lifecycle nodes. Expected result: Transitioning successful
Practice code
Now type it yourself
Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.
# TODO: configure and then activate the lifecycle node /driver from the command line
ros2 lifecycle get /driverExpected output
Transitioning successfulStuck? Show the full solution (try it yourself first)
ros2 lifecycle set /driver configure
ros2 lifecycle set /driver activate
ros2 lifecycle get /driverExpected result
How you know it worked
- ROS_DISTRO is lyrical in every terminal used for the exercise.
- The complete package from the exercise builds and the expected graph entity appears in a second terminal.
Practical exercise
Apply the lesson
Turn a talker into a lifecycle node. Use ros2 lifecycle set to configure, activate, deactivate and clean it up, and confirm with ros2 topic echo that messages flow only while it is active.
Before you continue
- ROS_DISTRO reports lyrical in every terminal you used
- The example builds and runs without errors
- You checked the result with a ros2 command, RViz2 or a test, not just by reading the code
If something goes wrong
Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.
Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.