[Lifecycle] Input on extent of use

[SteveMacenski]

So in my war against unnecessary dynamic memory allocation, I ran into a bunch of objects that are essentially only pointers so that they can be initialized in on_configure where they grab parameters and create/subscribe to things.

I wonder how "low" we should go with lifecycle, is our intention to make everything lifecycle, just the high level components, where does that stop? Should we be going into all our dependencies and lifecycle-izing them?

In this audit, I also still found a great deal of member objects that create / subscribe to things or ask for parameters in the constructor. I'm looking for a hard rule that we're going to enforce on this topic: can we create topics or subscribers / servers in constructors of utility objects? Parameters are clear that on_configure is where they should be initialized, while sometimes not respected.

With an understanding of the how deep we want to go and how careful we want to be for "complete correctness" vs ease of use and readability with lifecycle, I can clean it up however we decide. Another motivating question to get us started would be why did we make the high level components lifecycle, what was the specific goal we were trying to accomplish? and does making low level utilities of lifecycle break that intent? and from following that logic we should be able to come to a conclusion.

[mjeronimo]

Excellent questions. How "low" we should go with the lifecycle interface is a question I've been pondering for a while. I raised this issue a while back here:

• Lifecycle helper interface proposal ros2/rclcpp#654

The initial impetus for going with lifecycle nodes was to take a baby step towards determinism - at least separate the memory allocation and other initialization from the active, running state of the nodes. This also helps, IMO, with code clarity as there are specific patterns that result w/ lifecycle nodes, such as (only) declaring parameters in constructors and immedately returning to spin, allocating resources in on_configure, doing any necessary activation of those resources in on_activate, etc. Also, a larger goal of ours is to help make ROS2 ready for production robots. I think that the lifecycle capability is helpful in that regard and using it with the navigation stack helped us to find and fix deficiencies in ROS2 related to lifecycle nodes, including:

• Lifecycle nodes don't use simulation time when use_sim_time set ros2/rclcpp#641
• Lifecycle node class is missing parameter-related templates ros2/rclcpp#642
• LifecycleNode needs an accessor method for the NodeLogging interface ros2/rclcpp#649
• Lifecycle node support for tf2_ros::MessageFilter ros2/geometry2#95
• LifecycleNode support for tf2_ros::TransformListener ros2/geometry2#94

Regarding the helper classes, the current helper classes and plug-in interfaces are a mixture of various approaches. My inclination is to push the lifecycle interface all the way down. This would require more work to refactor many of these support classes, but the result would be much cleaner. The current state of affairs, where the interface is not used consistently all the way down, including plug-ins, results in some unwanted side-effects. For example, we currently see MessageFilters active immedately once they are created in on_configure. The internel queue for the MessageFilter gets filled up and it starts dropping messages. Once everything is running, the system eventually catches up.

I think that helper classes can be designed to support both lifecycle and non-lifecycle nodes. @bpwilcox and I have been discussing this and I believe we can define guidelines for creating such helper classes.

[SteveMacenski]

I think that response clears up things in my mind, closing.