ROS2 Logging

My understanding is that even when you install Nodes from binaries that ROS dynamically links them from your sourced workspace when they run. That should allow a developer to use some environment variables or some other mechanism to swap out the logger for any predefined ones at runtime or replace the shared library logger by providing their own with the same interface to be linked in instead. I don’t know off hand how difficult or easy that is to do, but it is all possible.

As noted in a console_bridge issue, ros1 logging doesn’t support unicode strings, so it would be nice to support that in ros2.

We’ve created the first set of pull requests for the new logging features (links below). Our next steps are to work on adding rosout topic capability. As part of that we are planning on porting the Log message from ROS 1.

For the new ROS 2 message I would like to remove the list of topics the node is publishing on that is in each log message as I don’t think it makes sense to include that with every logged line. I’ll also be adjusting the verbosity level constants to match the values defined in the rcutils package. The final change I was looking at for this message was to move it into the rcl_interfaces package instead of keeping it in a rosgraph_msgs package.

Links to pull requests below.

rclcpp: #582
rcl: ros2/rcl#327
rcutils: ros2/rcutils#127

Edit (Nov 14th, 2018 9:45am PST) - Changed the package we’re planning on moving Log message into from common_interfaces/diagnostic_msgs to rcl_interfaces to avoid adding another dependency in rcl.

1 Like

Another pull request for the Log message definition.

The initial implementation of the rosout features is code complete as well and available in the branches listed below. I’m going to wait to start the pull request for the rosout changes until the existing pull request is complete.


Please go ahead any missing PRs asap (and add a note in it what it is blocked on). We are very close to the API freeze and can’t consider what is not visible anywhere.

I’ve gone ahead and created pull requests for those features, though I could not find a way to decouple them from the earlier commits being reviewed in the existing pull requests. Once those PRs are done I can rebase these so only the new commits show in the rosout PRs.


There was some interesting development in rosconsole from @mgrrx to use pluginlib to support different logging sinks, particuilarly to support journald (https://github.com/ros/rosconsole/issues/16). I wonder if you could consider a similar approach for logging in ROS2, which would provide a familiar mechanism for swapping logging sinks without recompilation.

@Paul_Bovbel is your desire to be able to actually develop custom logging sinks (a reason for using pluginlib), or are you simply suggesting that ROS2 should be able to log to a number of backends which should be configurable at runtime (not necessarily requiring pluginlib)?

I have a pretty limited number of sinks in mind (stdout, /rosout, journald), but given the fluentd suggestion above (and that ROS2 is cross platform), being able to develop a sink plugin outside of the rcl source tree via pluginlib seems valuable.

Of course, you can always just write /rosout to journald via an intermediate node, but this can be expensive when intra-process transport is not available.

it would be very nice if we can choose the backend logging system, cz some vendors have their own specific logging system once it comes to the embedded system.

@nburek are there any tutorials, examples, or demos for making use of the new logging features?

1 Like

@nuclearsandwich This doesn’t exist right now but i have opened https://github.com/ros2/rcl_logging/issues/6 for our team to track.

is there any process / package to store /rosout into the file system?
e.g) ROS rosout node.

and there are directories under ~/.ros/log/, once we run the ros node there will be directory based on PID. so far it is empty, what this is for? expecting we are able to enable/disable logging to file system under ~/.ros/log/ for each node setting.

@tomoyafujita There are a couple of options right now for logging to a file. There were hooks added in crystal to allow a third-party logger to be hooked up that can handle logging to a file. An implementation using log4cxx was created, but was ultimately not enabled in the release due to some memory safety issues in the library that can cause it to segfault during shutdown (https://github.com/ros2/build_cop/issues/189). If you don’t mind that issue you can use the log4cxx logger by compiling rcl_logging_log4cxx and rcl with the set environment variable RCL_LOGGING_IMPLEMENTATION=rcl_logging_log4cxx.

The second option is to configure a log file handler in your launch file. I have not personally looked into it much, so maybe someone else here can provide more detail, but you should now be able to configure your launch files to forward the stdout/stderr from the processes it starts to a log handler class that can be configured to send it to a log file. See the example configuration here: https://github.com/ros2/launch/blob/master/launch/examples/launch_counters.py#L43-L44

@nburek

appreciate for your quick response!

a third-party logger to be hooked up that can handle logging to a file.

actually i already tried to use RCL_LOGGING_IMPLEMENTATION=rcl_logging_sony,
that works just fine, we can use our own implementation.

i was thinking that there is common way(not vendor specific) to log to file? and configurable for each node to do that? of course, we can do that with RCL_LOGGING_IMPLEMENTATION, but i think this is common use-case during debug.

okay i will look into launch_counter

thanks,
Tomoya

okay launch_counters example is logger setting example for launch.
for launch logger can be configurable launch.logging.launch_config.
actually launch.log is configured in default and store launch log into file system.

what i am looking for is node logger for file system…

The intent had been for rcl_logger_log4cxx to be included by default to solve the common use case. However, the memory safety issue in multithreaded programs was discovered in the last few weeks before the release and there wasn’t time to replace it with something else. There is already done discussions on a new logger implementation that could be used as a default.

@nburek

thanks for the information to share, really appreciate that.

i mean that dumping info into file system is really common usage as default during development, so i was thinking that it should be generic and enabled as default(but can be configurable), not as in user extension or anything like that.

do you have any information above that?

thanks,
Tomoya

1 Like

I’ve posted a few PRs that implement a new per-process ROS 2 logger; the main one is at https://github.com/ros2/rcl_logging/pull/17 . Any feedback on the proposed implementation and choice of the backend logger is appreciated.