nebula streams start before ros finishes its setup

[knzo25]

Mainly in setups with a higher number of sensors, we have observed that sometimes autoware's containers (the ones that include nebula) die during startup, usually in the constructor.
Due to how ROS loads containers as libraries sequentially, I believe we should wait until ROS has finished its setup before starting the driver's streams.

This may be related to #181

@drwnz @mojomex

[mojomex]

I totally agree. To do this properly, we should be refactoring to use lifecycle nodes. I know that using a one-off ROS2 timer has been proposed as a quick solution, which would work (init code only runs once ROS2 executor starts spinning). While we can do this as a temporary measure, I would like to kick off a discussion in the Autoware forums on startup sequences, lifecycles, etc.

[mojomex]

Would be fixed by #263 (which is currently only targeting Velodyne, see this comment) (lifecycle nodes are still on the long-term roadmap).

[mojomex]

(FYI @drwnz @knzo25)

It took me a while to find this, but ros_launch comes with support for filecycle nodes:

    emit_event_to_request_that_talker_does_configure_transition = launch.actions.EmitEvent(
        event=launch_ros.events.lifecycle.ChangeState(
            lifecycle_node_matcher=launch.events.matches_action(talker_node),
            transition_id=lifecycle_msgs.msg.Transition.TRANSITION_CONFIGURE,
        )
    )

    ld = launch.LaunchDescription()
    ld.add_action(talker_node)
    ld.add_action(emit_event_to_request_that_talker_does_configure_transition)

This would allow us to support both

• Nebula launching as it does now, but with deferred configuration and activation of hardware connections (solving this issue)
• another system, like Autoware, triggering the lifecycle transitions as part of the system's startup procedure

Supporting both of these would be as simple as adding a launch flag defer_init or similar.

[mojomex]

Update:

The above comment does not apply to composable nodes, see: ros2/launch_ros#41

For low-performance use cases (latency for pointclouds over DDS is acceptable), this is a non-issue.

For high-performance use cases, pointcloud preprocessing will be able to move away from component containers in the near future thanks to zero-copy middleware Agnocast which we plan on supporting soon in Nebula.

IMO, moving to composable nodes and sacrificing container launch compatibility is a good tradeoff given the above considerations.