Autostarting lifecycle nodes and example launch file demo

[SteveMacenski]

This resolves #418 which implements autostarting lifecycle nodes. This is complete and ready for a review

You'll notice a couple of key changes worth explaining:

1. There is a new is_lifecycle_node attribute of the node and lifecycle nodes which is needed to remove a circular dependency on the LifecycleNode within the LifecycleTransition class which only is type checking. I replace this type check with checking if a non-None object (1) has the attribute at all and (2) has a lifecycle attribute with appropriate logging between the difference of a non-lifecycle node being attempted vs a non-node. This has been tested as well to function using the demos.

2. You will also notice that I refactored lifecycle node to have a separate util LifecycleEventManager, who handles the event emitting, handling, and topic listening for lifecycle nodes. This way, this can be used in lifecycle-components as well! No changes were made here except removing the self.__current_state variable which was completely unused. The LifecycleEventManager is only created if the node requests autostart at Launch time and otherwise has no overhead nor exposes the interfaces/event handler/emitter if its a non-lifecycle node.

3. The component nodes don't add a / before the node names with the namespaces. This messes with the node event matcher. I add in a leading / so that the action.node_name == node_name which has the / forcably applied in the node event matcher

4. I tested LifecycleNode, ComposableNodeContainer, LoadCompoableNodes for all cases: autostart=True autostart=False, and autostart field not supplied. You can also run any experiments you like using the 2 extra launch files I provide in the examples directory which shows all the features at work/

[SteveMacenski]

@mjcarroll can I get a review on this now that we're back from the holidays? :-)

[doisyg]

That would be amazing to have this part of the standard launch!
(and I can already think about a next step: choose if you want to start in Unconfigured, Inactive or Active)

[SteveMacenski]

@mjcarroll can I request a review? ❤️

[wjwwood]

A few questions, but looking pretty good. Thanks for the contribution!

[SteveMacenski]

@wjwwood I addressed all of your comments and made a fix by your review requests

[wjwwood]

I sent a few responses, resolved a few others. Sorry it took so long to reply, I'll try to be quicker on the next iteration. Thanks again!

[SteveMacenski]

I appreciate it, I know this isn't the most active project in the ROS core ecosystem, so I appreciate the attention here :-)

I think I've completed all of the tasks that need to be addressed

[wjwwood]

Sorry, one more iteration on the matchers.

[SteveMacenski]

See updated comment :-)

[wjwwood]

looks really close

I continued our conversation on the other thread, and pointed out a potential issue with how autostart is being typed and documented. Other than that, it's mostly cleanup requests after your most recent set of changes.

[wjwwood]

Sorry, after re-reviewing the new class you recently added I found some more things that should be looked into.

[SteveMacenski]

@wjwwood all of your comments have been addressed, I believe fully now.

I see I must have missed a DCO sign off on my commits, but I really don't want to mess with the git commit history bc I know that'll cause you more trouble re-reviewing not knowing what exactly I just changed.

As the CEO of my own company, I trust that I can just say I give myself permissions to do this. I can also fix DCO after you review and approve if you like. I just don't want to make your life hard.

[wjwwood]

lgtm

Had a few non-blocking questions, but I think this is good to go with passing CI.

[wjwwood]

Rpr looks like it is failing due to a few small linter issues. After you fix that I'll run full CI with Windows and everything on ci.ros2.org unless someone else beats me to it.

[SteveMacenski]

Should be good to go. I also resolved the DCO sign off

[wjwwood]

Looks like there's a test failure on the Rpr job, can you have a look and see if it's related/reproducible?

[SteveMacenski]

I don't think it relates to this - I just pushed a couple of new commits to fix your last 2 items - so we'll see :- )

[SteveMacenski]

All passing now.

Any chance for a backport to Jazzy? This would be a really nice feature that could make some folks I'm talking to move to Jazzy if it were available

[wjwwood]

CI:

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[wjwwood]

CI looks good, so I'm going to merge this now. Thanks again for the contribution!

Any chance for a backport to Jazzy? This would be a really nice feature that could make some folks I'm talking to move to Jazzy if it were available

I think it should be fine to do so. The only changes to the API seem to be backwards compatible. Generally we don't backport features due to the risk of regression, but we can make exceptions when the risk is low. I'll ask for a second opinion on that though. I can at least open the pr for the backport and let another maintainer review/merge it as my second opinion.

[wjwwood]

@Mergifyio backport jazzy

[mergify]

backport jazzy

✅ Backports have been created

• #438 Autostarting lifecycle nodes and example launch file demo (backport #430) has been created for branch jazzy