Add support for enable_lifecycle_services parameter in LifecycleNode

[SteveMacenski]

Expose the enable_communication_interface parameter from rclcpp_lifecycle::LifecycleNode through nav2's LifecycleNode wrapper. This allows users to disable lifecycle communication interfaces when manually managing node lifecycle transitions.

The parameter can be set via NodeOptions parameter overrides:

rclcpp::NodeOptions options;
options.parameter_overrides({{"enable_lifecycle_services", false}});

Fixes #5305

Generated by Claude Sonnet 4

[codecov]

Codecov Report

Attention: Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
..._common/include/nav2_ros_common/lifecycle_node.hpp	80.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
..._common/include/nav2_ros_common/lifecycle_node.hpp	92.39% <80.00%> (-0.80%)	⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[roncapat]

@SteveMacenski thanks! Will check this morning.
Meanwhile, why this PR and not the second Claude output (this commit)?

It may need some fixes due to double call to declare_parameter_if_not_declared, but at least one usage was not one of your requests in the last prompt?

Anyway, will do some test and apply any required modification, then report to you.

[roncapat]

Tested both ways. Works like a charm!

• I prefer the solution from this PR, without the extra temp node
• Downsides:
  • does not take from YAML the param (but if someone writes its own bringup logic, this is not an issue at all)
  • subnodes (global_costmap, local_costmap) need that override to be forwarded via NodeOptions (but Pass node options to costmap node #5202 should have fixed it)

[SteveMacenski]

Meanwhile, why this PR and not the second Claude output (this commit)?

I do not accept the idea of a fake internal node being registered. I've worked hard to make that not occur in the stack! There was once a time we had many internal nodes and now we only have 2 in the 2 exact situations where they make sense (costmap + internal BT node for the BT Nodes to do with as they wish). It would break my soul a little bit to add in a temp node like that 🥲

does not take from YAML the param (but if someone writes its own bringup logic, this is not an issue at all)

It should - did you try that? The parameter overrides should have that content from the yaml file.

Edit: I see now that it wouldn't. Does this still work for your needs? Posting a short workflow for how you use it in this PR before we merge would be nice breadcrumb documentation for someone that might want to follow in these steps.

[roncapat]

As I said, works pretty well for me. As I have custom C++ code to load the node, I already make use in various other situation of parameter overrides and I'm fine with it.

I too had a situation in the past where I had to deal with temporary nodes, but they are indeed bad by design. However, I may propose in the future a node-less approach for taking in ordinary ROS parameter (I use something similar in other contexts).

For the time being, this is performing great :)

[roncapat]

I will try to provide some example code tomorrow :)

[SteveMacenski]

Please! OK I'll wait for that but will plan to merge at that point

[roncapat]

I'll try to summarize down here below the "full picture", since it will be Markdown maybe it could also be added to some repo README if you like. Feel free also to directly edit my comment if you like to apply some touch ups.

---

Nav2 comprises many ROS 2 nodes, all of them being specifically LifecycleNodes. LifecycleNodes share a common interface that allow their current status to be managed externally.

LifecycleNodes feature the following management I/Fs:

• C++ API
  • configure() method
  • activate() method
  • deactivate() method
  • cleanup() method
  • shutdown() method
• ROS 2 services
  • change_state
  • get_state
  • get_available_states
  • get_available_transitions
  • get_transition_graph

This means that for every LifecycleNode in the ROS 2 graph, 5 services servers are created.

The CLI tool ros2 lifecycle allows to manually interact with such services with a slightly better user experience than directly calling them via ros2 service call.

Moreover, in a typical nav2 setup, nav2_lifecycle_manager node is spawned (for example, by a launch file), to handle for you such transition - basically guaranteeing that nodes get correctly configured and activated. This node acts through the ROS 2 lifecycle services API.

However, robotic system integrators may require custom setups, with lower involvement of service calls, stricter control on the number of ROS 2 entities on the ROS graph (less nodes, less service endpoints) and maybe also custom lifecycle management strategy.

In this case, the lifecycle C++ API could be used instead. Developers can directly calls the appropriate methods to control the lifecycle of the robot.

Here's a snippet for creating a LifecycleNode and spinning it in a dedicated executor (this is the so called isolated node strategy) and appropriately transition it to the active state. This code can be put in a dedicated thread to let your application fit many nodes in the same process space, opening up to intra-process communication scenarios.

auto node = std::make_shared<NodeT>(options);
node->configure();
node->activate();
auto node_base = node->get_node_base_interface();
executor = std::make_shared<rclcpp::executors::SingleThreadedExecutor>();
executor->add_node(node_base);
executor->spin();
executor->remove_node(node_base); // Automatic shutdown transition on ctrl-c

In this scenario, lifecycle services could be not only superfluous, but an entry point for an user to interfere with the hardcoded lifecycle management logic.

However, rclcpp allows to optionally disable the lifecycle services.
Nav2 exposes this option via enable_lifecycle_services parameter, which can be only disabled via C++ API.
This makes sense because the user is already and presumably trying to control the node via C++ API, so it is not necessary to expose this toggle as a normally configurable parameter (CLI/YAML/...).
Notice that the user may expose a parameter of his own from his custom application to toggle the feature without a rebuild.

auto node = std::make_shared<NodeT>(options.parameter_overrides({{"enable_lifecycle_services", false}}));
node->configure();
node->activate();
auto node_base = node->get_node_base_interface();
executor = std::make_shared<rclcpp::executors::SingleThreadedExecutor>();
executor->add_node(node_base);
executor->spin();
executor->remove_node(node_base); // Automatic shutdown transition on ctrl-c

Remember: in this way, you will only be able to control the lifecycle node via C++ API calls. Even ros2 lifecycle will not detect your node as a lifecycle one. The only residual on the ROS graph telling somebody that the node is lifecycle-managed is the topic node_name/transition_event.

There's one additional thing to know about nav2 nodes specifically. They use the bond mechanism by default.
This typically enables the nav2_lifecycle_manager, even if residing in a different process (standalone node, not composed) to know whether the other nodes are alive or not.
As user, in the above example, will not need nav2_lifecycle_manager anymore, they may either reimplement the monitoring logic based on bond or disable it.

To disable such mechanism, every nav2 node needs the following parameters to be set (eg. via YAML file with wildcards):

/**:
  ros__parameters:
    bond_heartbeat_period: 0.0
    bond_timeout: 0.0