You're reading the documentation for a version of ROS 2 that has reached its EOL (end-of-life), and is no longer officially supported. If you want up-to-date information, please have a look at Iron.
About logging and logger configuration
Table of Contents
The logging functionality currently supported is:
Client libraries (
rclpy) using a common logging library to provide:
Log calls with a variety of filters.
Hierarchy of loggers.
Loggers associated with nodes that automatically use the node’s name and namespace.
File output and functionality akin to rosout for remote consumption of messages is forthcoming.
Programmatic configuration of logger levels.
Launch-time configuration of the default logger level is supported; config files and external configuration at run-time is forthcoming.
Log messages have a severity level associated with them:
FATAL, in ascending order.
A logger will only process log messages with severity at or higher than a specified level chosen for the logger.
Each node (in
rclpy) has a logger associated with it that automatically includes the node’s name and namespace.
If the node’s name is externally remapped to something other than what is defined in the source code, it will be reflected in the logger name.
Non-node loggers can also be created that use a specific name.
Logger names represent a hierarchy. If the level of a logger named “abc.def” is unset, it will defer to the level of its parent named “abc”, and if that level is also unset, the default logger level will be used. When the level of logger “abc” is changed, all of its descendants (e.g. “abc.def”, “abc.ghi.jkl”) will have their level impacted unless their level has been explicitly set.
See the logging demo for example usage.
See the rclcpp documentation for an extensive list of functionality.
See the rclpy examples for example usage of a node’s logger.
See the rclpy tests for example usage of keyword arguments (e.g.