In this context, I'm going to define "logging" narrowly as "getting error, warning, info, and debug messages to the user". These messages may either be printed to a tty, or written to a file, or both.
ROS 2 currently has a number of different logging pieces:
rcutils has the RCUTILS_LOG family of macros
rclcpp has the RCLCPP_LOG family of macros
rcl_logging contains backend loggers for controlling log levels and writing data out to files
rcl has infrastructure for initializing the loggers, changing the levels at startup time, and controlling what the log messages look like
launch_ros has various infrastructure for capturing messages from the processes it is supervising, and printing them to the tty or to files (or both)
In this context, I'm going to define "logging" narrowly as "getting error, warning, info, and debug messages to the user". These messages may either be printed to a tty, or written to a file, or both.
ROS 2 currently has a number of different logging pieces:
rcutilshas the RCUTILS_LOG family of macrosrclcpphas theRCLCPP_LOGfamily of macrosrcl_loggingcontains backend loggers for controlling log levels and writing data out to filesrclhas infrastructure for initializing the loggers, changing the levels at startup time, and controlling what the log messages look likelaunch_roshas various infrastructure for capturing messages from the processes it is supervising, and printing them to the tty or to files (or both)Those pieces are all useful, but we lack a coherent story around logging and how it should work for end users. Ideally the outcome of this design document is that we identify gaps in the current infrastructure, and then work on filling those gaps. We should also revamp the logging documentation (https://docs.ros.org/en/rolling/Concepts/About-Logging.html and https://docs.ros.org/en/rolling/Tutorials/Logging-and-logger-configuration.html), and likely expand it.