Launch wrapper for rclcpp::Node to make it a LifecycleNode

msmcconnell · 2021-11-14T20:34:13.024Z

I have a proposal to run by the ROS2 community. Recently, I have been trying to integrate some in-house ROS2 Lifecycle nodes (rclcpp_lifecycle::LifecycleNode in Foxy) with regular non-lifecycle nodes (rclcpp::Node) that were developed externally. I want to manage all my nodes via their lifecycle interface, but obviously that is not possible with these external non-lifecycle nodes. The only currently supported way I am aware of would be to modify the node source code directly. This puts a big burden on the user of these external nodes if they want to integrate them with an existing lifecycle system, as I do.

I spent some time thinking about ways around this problem and came up with the idea to use components as a sort of wrapper. A ROS2 component node can be thought of as having 2 possible overarching states: Loaded and Unloaded This means that they can be conceptually mapped onto the Lifecycle node state machine. Specifically, nodes can be loaded on activation and unloaded on deactivation/error/shutdown. While loading/unloading a node may incur a fair bit of overhead, it has the benefit of ensuring to the user that the non-lifecycle node will not actively interfere with other nodes in the system unless in the ACTIVE state. Under such a system the only new requirement would be a node container capable of enforcing this architecture. This would effectively be an alternative to the component_managers currently available in rclcpp. Then the user could wrap their external nodes with the existing launch commands used for component loading. Here’s an example:
In XML

  <node_container pkg="rclcpp_components" name="lifecycle_wrapper" exec="lifecycle_wrapper_exec">

    <composable_node pkg="cool_pkg" 
                     plugin="cool_pkg_namespace::MyRegularNode" 
                     name="regular_node"/> <!-- This is now a minimal lifecycle node -->

  </node_container>

or Python

def generate_launch_description():
  
    lifecycle_container = ComposableNodeContainer(
        package='rclcpp_components',
        name='lifecycle_wrapper',
        executable='lifecycle_wrapper_exec',
        namespace="/",
        composable_node_descriptions=[
            ComposableNode(
                package='cool_pkg',
                name='regular_node',
                plugin='cool_pkg_namespace::MyRegularNode',
            ),
        ]
    )

    return LaunchDescription([
        lifecycle_container,
    ])

Using the above structure the “regular_node” could now be started or stopped based on tools like “ros2 lifecycle” or by other nodes managing system lifecycle. This approach does have the caveat that it will only work with component nodes, but many ros2 nodes are already being implemented as components and its easier to take an existing node and turn it into a component than to refactor it entirely to adhere to the lifecycle state machine.

At the moment, I have implemented a prototype of this using my teams internal base lifecycle node class and the concept does work, but I am writing this post to see if developing a more general implementation using the standard rclcpp_lifecycle::LifecycleNode as a base would be of interest to the wider ros community. Please let me know the following:

Would you be interested in this functionality?
Where should this new component manager implementation live? rclcpp_components?
Any implementation considerations which you think are critical?
Any suggestions on reducing code duplication with the existing component manager? Maybe implement this change as a constructor argument instead of a wholly separate class, etc.?

vmayoral · 2021-11-22T07:55:35.605Z

@msmcconnell I find this interesting and aligned with the work that I’ve been doing for the last couple of weeks. I just wrote about it at Adaptive ROS 2 Node computations and hardware acceleration contributions.

Regarding your proposal, have you disclosed the source code somwhere so that I can take a look at it?

msmcconnell · 2021-11-22T14:24:17.261Z

@vmayoral The prototype I created for my team’s project is located here

github.com/usdot-fhwa-stol/carma-utils

Feature/lifecycle component wrapper

usdot-fhwa-stol:foxy/develop ← usdot-fhwa-stol:feature/lifecycle_component_wrapper

opened 04:07PM - 15 Nov 21 UTC

msmcconnell

+1051 -22

# PR Details ## Description I have been trying to integrate some our carma l…ifecycle nodes with regular non-lifecycle nodes from Autoware.Auto. I want to manage all the nodes via their lifecycle interface we discussed earlier, but obviously that is not possible with these external non-lifecycle nodes. The only currently supported way I am aware of would be to modify the node source code directly. This puts a big burden on us to modify these autoware nodes if we want to integrate them with an existing lifecycle system. I spent some time thinking about ways around this problem and came up with the idea to use components as a sort of wrapper. A ROS2 component node can be thought of as having 2 possible overarching states: Loaded and Unloaded This means that they can be conceptually mapped onto the Lifecycle node state machine. Specifically, nodes can be loaded on activation and unloaded on deactivation/error/shutdown. While loading/unloading a node may incur a fair bit of overhead, it has the benefit of ensuring to the user that the non-lifecycle node will not actively interfere with other nodes in the system unless in the ACTIVE state. Under such a system the only new requirement would be a node container capable of enforcing this architecture. This would effectively be an alternative to the [component_managers ](https://github.com/ros2/rclcpp/blob/master/rclcpp_components/include/rclcpp_components/component_manager.hpp) currently available in rclcpp. Then the user could wrap their external nodes with the existing launch commands used for component loading. Here’s an example of what using the wrapper would look like: ``` def generate_launch_description(): lifecycle_container = ComposableNodeContainer( # Standard setup for using ROS2 components package='rclcpp_components', name='lifecycle_component_wrapper', executable='lifecycle_component_wrapper_mt', # Select a multithreaded or single threaded wrapper lifecycle executable namespace="/", composable_node_descriptions=[ ComposableNode( # This non-lifecycle node is now a exposed as a lifecycle node thanks to the wrapper package='cool_pkg', name='regular_node', plugin='cool_pkg_namespace::MyRegularNode', ), ] ) return LaunchDescription([ lifecycle_container, ]) ``` Using the above structure the “regular_node” could now be started or stopped based on tools like “ros2 lifecycle” or by other nodes managing system lifecycle. This approach does have the caveat that it will only work with component nodes, but many ros2 nodes are already being implemented as components and its easier to take an existing node and turn it into a component than to refactor it entirely to adhere to the lifecycle state machine. To make this review easier I have marked all the code changes which actually modify the existing component_manager with ///// CARMA START ///// and CARMA END. This will hopefully help the reviewer target their review to the new functionality as I do not intend to modify the ROS2 implementation unless absolutely necessary. The changes work in the following way: - When the load node call occurs but the lifecycle node is not in the ACTIVE state then the load request is cached. - When the activate trigger is sent the cached nodes are loaded - When the deactivate/shutdown/cleanup/error calls occur the currently loaded nodes are all unloaded. PS: I am going to try to upstream this change into the ROS mainline code, but it likely wouldn't be in the current version so we will still need this copy here. Plus having this version allows us to reuse the carma-lifecycle node's error handling behavior. ## Related Issue This supports the ROS2 milestone https://github.com/usdot-fhwa-stol/carma-platform/issues?q=is%3Aopen+is%3Aissue+milestone%3AROS2 ## Motivation and Context See description ## How Has This Been Tested? Command line testing and unit tests in progress ## Types of changes - [ ] Defect fix (non-breaking change that fixes an issue) - [x] New feature (non-breaking change that adds functionality) - [ ] Breaking change (fix or feature that cause existing functionality to change) ## Checklist: - [ ] I have added any new packages to the sonar-scanner.properties file - [ ] My change requires a change to the documentation. - [ ] I have updated the documentation accordingly. - [x] I have read the **CONTRIBUTING** document. [CARMA Contributing Guide](https://github.com/usdot-fhwa-stol/carma-platform/blob/develop/Contributing.md) - [ ] I have added tests to cover my changes. - [ ] All new and existing tests passed.

(lifecycle_component_wrapper.hpp, and lifecycle_component_wrapper.cpp specifically)

But as mentioned in the post, this implementation is specific to my team’s project and still being tested. I will put up a more general implementation PR to the ROS repositories when I have a bit more free time around the new year.