Unify LifecycleNode and Node

[Aposhian]

Description

Currently rclcpp_lifecycle::LifecycleNode and rclcpp::Node are two distinct classes that both implement the common node interface, but LifecycleNode exposes the lifecycle management features. It would be nice to have a common interface that exposes flexible controls for using lifecycle capabilities or not.

I think that if we were to merge the interfaces together, it would be nice to have it be completely runtime configurable. It seems like there are 3 possible configurations. To expose all 3 of these behaviors, maybe we could expose the following ros arg or special ros parameter (similar to use_sim_time) with 3 different values. Let's call this argument/parameter lifecycle.

1. lifecycle=manual: Current LifecycleNode behavior: expose publisher and services, and don’t auto transition.
2. lifecycle=none: Current Node behavior, but with “auto-transition”: don’t expose publisher and services, and call any configure and activate methods as if they are part of the constructor, and deactivate and cleanup methods as if they are part of the destructor. If the configure or activate methods fail, just fail the constructor. Maybe we would want to consider that if the node transitions itself out of active killing the node, but that might be too implementation dependent.
3. lifecycle=auto: Current LifecycleNode behavior, but with auto transition. You may want the convenience of having the configure and activate transitions on startup and deactivate and cleanup methods on shutdown, but you also want to be able to control the state transitions externally. This could be important because I have seen some LifecycleNodes be written to automatically deactivate themselves on errors, or to fail to configure or activate in the first place depending on conditions.

Motivation

Some people swear by ROS 2 lifecycle and encourage making everything use LifecycleNode. Others don't want the additional complexity and failure points introduced by LifecycleNode, and would rather manage lifecycle using different systems or abstractions. This puts library maintainers in the difficult position where they can either implement one, or implement two versions of their nodes: one lifecycle and one not. If they don't implement one, then lifecycle users may look to put that code in a wrapper or fork it to implement lifecycle, and non-lifecycle users are forced to add lifecycle management code to their project when they wouldn't otherwise (or fork and remove lifecycle). This creates additional friction between libraries and users. A unified, runtime-configurable API would give everyone what they want with no burden on library maintainers.

Design / Implementation Considerations

We may want to merge the rclcpp_lifecycle package into rclcpp. Although this change doesn't necessarily need to affect LifecyclePublisher for example, unless we take on merging all managed entities.

Additional Information

https://discourse.ros.org/t/all-nodes-as-lifecycle-nodes

[ros-discourse]

This issue has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.ros.org/t/all-nodes-as-lifecycle-nodes/43559/12

[peci1]

This proposal sounds quite reasonable to me.

[fujitatomoya]

@Aposhian thanks for creating the issue for this 👍

IMO, i am not sure unifying Node and LifecycleNode is good idea.

it would be nice to have it be completely runtime configurable.

this means, the Node user application still has to keep additional complexity, footprint as static objects. that is not great solution for embedded devices even if that functionality can be runtime configurable.

i think that LifecycleNode can inherit from Node class, idea with assuming LifecycleNode should support all functionality in regular Node (LifecycleNode still should be able to create the normal Publisher), and add the extensible methods to LifecycleNode (so that it can create LifecyclePublisher, LifecycleServiceServer and so on).
i cannot see why the unifying the classes with losing this c++ language advantage would be better solution... 🤔
besides, this approach can address main concerns, keeping Node and LifecycleNode in consistent, Node can be lightweight base class, better maintainability, documentation. user application can just pick whichever they need for their requirement, i do not see why we have to merge those classes together like suggested here.

btw, there has been a few issues already about this topic.

• [api review] Calling Syntax and Keeping Node-like Class APIs in Sync #1259
• Prevent API gaps between Node and LifecycleNode #898
• rclcpp::LifecycleNode is not on par with rclcpp::Node #1614

CC: @wjwwood @mjcarroll @alsora @MichaelOrlov

[Aposhian]

I suppose this fundamentally comes down to being able to treat lifecycle nodes as regular nodes. Because simply unifying the interface will not make the reverse true: if you have a node that hasn't implemented any state transitions, then there isn't a point to exposing lifecycle capabilities. So maybe you are right and unifying the classes themselves is not the correct approach.

Instead, maybe we could focus on the capability to auto transition or disable lifecycle interfaces on a lifecycle node at runtime? That would not add any additional overhead to those who implement rclcpp::Node, but it would be more flexible for consumers of 3rd party lifecycle nodes. I think that functionality could be done independent of making LifecycleNode inherit from Node, although that would be nice.

[fujitatomoya]

Instead, maybe we could focus on the capability to auto transition or disable lifecycle interfaces on a lifecycle node at runtime?

if they want to disable the lifecycle interfaces or auto transition, why they need lifecycle node in the 1st place? they probably should use normal node instead?

[peci1]

Instead, maybe we could focus on the capability to auto transition or disable lifecycle interfaces on a lifecycle node at runtime?

if they want to disable the lifecycle interfaces or auto transition, why they need lifecycle node in the 1st place? they probably should use normal node instead?

Probably because a package only provides lifecycle nodes, but the user decided he doesn't need the lifecycle behavior?

[nnarain]

When I started to get into ROS 2, I was surprised to learn lifecycle management wasn't part of nodes by default.

At my company we are in the middle of working out how to re-architect our system using newer features available in ROS 2 and it would be nice if we could assume lifecycle management was available for every node.

[MoffKalast]

Node can be lightweight base class, better maintainability, documentation. user application can just pick whichever they need for their requirement, i do not see why we have to merge those classes together like suggested here

Quite simply because of the mountain sized pile of already implemented Nodes/LifecycleNodes that will never have or not have lifecycles otherwise? Forking every package one uses three dependency levels deep is not a realistic way to do things.

[Aposhian]

At my company we are in the middle of working out how to re-architect our system using newer features available in ROS 2 and it would be nice if we could assume lifecycle management was available for every node.

But even if lifecycle interfaces are tacked onto every node, if meaningful state transitions are not implemented by the authors, then there is no purpose to having the interfaces. As it stands, if authors wish to implement lifecycle behavior, then they can do so and implement lifecycle interfaces.

@peci1 @fujitatomoya precisely. There are technical reasons one might avoid ROS 2's lifecycle implementation (ex: not wanting to depend on the RMW and executor for failure recovery). But as it achieves broader adoption in the ecosystem, if a library implements a node as lifecycle, then you must either:

• use lifecycle management anyway
• fork the library and remove lifecycle behavior

[Amronos]

From what I can currently understand, there are two use cases/problems caused due to packages (understandably) only providing either Node or LifecycleNode:

1. Using the provided Node as a LifecycleNode
2. Using the provided LifecycleNode as a Node

I agree that merging the two types is probably the best solution for these problems. Without this, problems are caused for someone just wanting a smooth launch of their nodes and then having to deal with LifecycleNodes in a package, and people wanting to use LifecycleNode instead of Node. There are also problems caused for people who want to reuse the same nodes/packages between projects, one project may require LifecycleNodes, while another may require Node.
Additionally, the current LifecycleNode lacks many wanted features, which could possibly get easier to implement if the two types are merged.

that is not great solution for embedded devices even if that functionality can be runtime configurable.

I don't think normal rclcpp is meant to be used on embedded devices, isn't using micro-ros the route for them?

[alsora]

Some thoughts on this topic.

I don't think normal rclcpp is meant to be used on embedded devices

"embedded devices" is a very large spectrum. I want to be able to use rclcpp on my Raspberry Pi, but I need to avoid what's not needed by my application.

Using the provided Node as a LifecycleNode

This is not really possible.
If my system is based on lifecycle nodes, I expect to be able to do things such as "deactivate" all my nodes to reduce CPU usage. I can't do that for the nodes, or at least I can't do that with a generic API.
Obviously a poorly implemented lifecycle node may expose those APIs but not respect the lifecycle design, but that's a different problem.

Using the provided LifecycleNode as a Node

This is doable because you can just do

auto node = std::make_shared<MyLifecycleNode>();
node->configure();
node->activate();

Lifecycle nodes constructors already have a bool to enable/disable the creation of lifecycle ROS entities: https://github.com/ros2/rclcpp/blob/rolling/rclcpp_lifecycle/include/rclcpp_lifecycle/lifecycle_node.hpp#L141
This should cover most of the runtime overhead of lifecycle nodes.
Libraries may want to expose this somehow.

i think that LifecycleNode can inherit from Node class,

I agree with @fujitatomoya , if we want to "unify" we should use inheritance.

[peci1]

What about a build flag that would enable the fake lifecycle behaviors? That would also allow you to have zero runtime overhead if you don't need it... Something like -DRCLCPP_ALL_NODES_ARE_LIFECYCLE=1 .

If state transitions can fail, then these fake behaviors could just fail if you'd e.g. want a fake LC node to deactivate. I guess lots of people are just interested into the states and state transitions and not always into actively changing the LC state.

[MoffKalast]

at least I can't do that with a generic API.

Perhaps the default deactivation behavior could pause rcl communcation internally, which would in practice pause most nodes. Bound to lead to lots of unexpected behavior in nodes with complex internal states though.

I want to be able to use rclcpp on my Raspberry Pi, but I need to avoid what's not needed by my application.

To be clear, the overhead we're talking about is the seven additional services per Node that would create a fair amount of network congestion when declared in the DDS?

[Aposhian]

To be clear, the overhead we're talking about is the seven additional services per Node that would create a fair amount of network congestion when declared in the DDS?

@MoffKalast I think a few sources of overhead have been identified:

• network overhead from more DDS entities (impact: high)
• memory overhead from more methods and members in the class (impact: medium)
• runtime overhead from checking flags whether to enable communication or not (impact: low)

This is doable because you can just do

auto node = std::make_shared<MyLifecycleNode>();
node->configure();
node->activate();

@alsora that is a good call-out, that you can create a compiled wrapper fairly easily. And then by using the flag to disable communication interfaces, you can essentially remove all the overhead (except for the memory overhead in the class). Although being able to control this at runtime would grant additional flexibility, but maybe pointing people to this option is sufficient for the no-lifecycle crowd.