Make LifecycleNode logs publish to rosout

[tonynajjar]

---

Feature request

Feature description

The logs inside the LifecycleNode are not published to rosout making hard to debug issues when relying on rosout-reading tools (e.g foxglove). I guess the reason is because the rcutil logging macros are used
instead of the rclcpp logging macros?

What would be the easiest way to enable publishing those logs to rosout? Thanks

Implementation considerations

[clalancette]

So the logging subsystem uses a dependency-injection type of model. In particular, what happens is that the rcutils_logging APIs allow the registration of an arbitrary number of callbacks, and when a log message comes in, it calls each of those callbacks in turn. By default, rcutils only registers a callback to print to the screen. But the rclcpp layer than registers additional callbacks to send the logs to disk and to /rosout. Thus, no matter whether you are calling the RCUTILS log macros or the RCLCPP ones, they should in theory go out to all registered places.

But I can indeed confirm that this is not happening with the RCUTILS macros, either with the LifecycleNode or with a regular Node, for that matter. Something about the logging subsystem isn't working how I expect.

[clalancette]

So the logging subsystem uses a dependency-injection type of model. In particular, what happens is that the rcutils_logging APIs allow the registration of an arbitrary number of callbacks, and when a log message comes in, it calls each of those callbacks in turn.

Actually, after looking at this further, this is wrong. rcutils only has room for a single callback. The multiple callback solution is implemented in the rcl layer, so it will indeed only work if you are using the RCLCPP macros. That seems like something of a design problem, and it would be nice to move that into the rcutils layer. But for now, the easier solution is to change the Lifecycle code to just use the RCLCPP macros. See #2233 for the fix.

[tonynajjar]

Thanks a lot for the quick fix! When I find some time, probably early next week, I'll try to backport the fix to Humble locally and test it out