Autostarting lifecycle nodes and example launch file demo (backport #430)

[mergify]

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/

   ---

   This is an automatic backport of pull request Autostarting lifecycle nodes and example launch file demo #430 done by Mergify.

[wjwwood]

@methylDragon if you have some time, could you review this backport with an eye towards likelihood of regressions in jazzy?

@SteveMacenski fyi

[wjwwood]

CI:

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

[audrow]

Friendly ping @methylDragon

[SteveMacenski]

Thanks! I look forward to this!

[christophebedard]

#449 should be backported after this, too.

[christophebedard]

@Mergifyio rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[christophebedard]

I've taken a look. Regression-wise, there aren't many actual tests for this, but it looks fine. The autostart feature is fairly separate.

I rebased and I'll trigger a fresh round of CI.

[christophebedard]

Pulls: #438
Gist: https://gist.githubusercontent.com/christophebedard/268da2541a058cc2da3ffbae02102bb5/raw/5454692502baa3ff2fa71754dd131842e7f1471d/ros2.repos
BUILD args: --packages-above-and-dependencies launch_ros test_launch_ros
TEST args: --packages-above launch_ros test_launch_ros
ROS Distro: jazzy
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/15456

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

[SteveMacenski]

@christophebedard I'd make sure to also merge in the fix from #449 as that's an important fix

[christophebedard]

I was going to process them separately to keep the (backporting) history clean, but yeah. I've created #453 to backport #449 and rebased it on this commit. I triggered CI for the combination of both backports in #453 (comment). Once that looks good, we can merge them both: #438 then #453.