ROS 2 Lyrical Luth · Lesson 13 of 86

Logging and debugging

Log levels, throttled logs, rqt_console, ros2 doctor and debugging nodes with gdb.

Estimated time · 45–75 min

Learning goals

What you will understand

Explain logging and debugging in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

ROS 2 logging has five levels: DEBUG, INFO, WARN, ERROR, FATAL. Use RCLCPP_INFO(get_logger(), ...) and its variants: RCLCPP_WARN_THROTTLE limits repeats, and RCLCPP_INFO_ONCE prints once. Logs go to the console, to files under ~/.ros/log and to the /rosout topic.

Change the level at run time with --ros-args --log-level debug, or per node (--log-level node:=debug). Use rqt_console to filter messages, ros2 doctor to check the installation, and run a node under gdb with --prefix 'gdb -ex run --args'.

Guided lesson

Work through these steps

1.
Source the ROS 2 Lyrical environment in a fresh terminal.
2.
Read the logging and debugging example and identify what each line does.
3.
Build only the affected package, source the workspace overlay, and run the example.
4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

RCLCPP_DEBUG(get_logger(), "raw value %d", raw);
// Detailed output, hidden unless the level is DEBUG.
RCLCPP_INFO(get_logger(), "connected to %s", port_.c_str());
// Normal progress messages.
RCLCPP_WARN_THROTTLE(get_logger(), *get_clock(), 1000, "battery low: %.0f%%", pct);
// Warn at most once every 1000 ms, however often it is called.
RCLCPP_ERROR(get_logger(), "motor %d failed", id);
// Something is wrong and needs attention.
RCLCPP_INFO_ONCE(get_logger(), "first sample received");
// Print only the first time this line runs.
// Run: ros2 run robot_nodes arm_node --ros-args --log-level debug
// Turn on debug output for one run.

What the example is doing

1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Build and run

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

// Inside a 100 Hz timer callback of a node
void on_timer() {
  // TODO: print the warning "battery low" at most once per second (1000 ms) with a throttled macro
}

Expected output

Only one WARN line per second appears

Stuck? Show the full solution (try it yourself first)

// Inside a 100 Hz timer callback of a node
void on_timer() {
  RCLCPP_WARN_THROTTLE(get_logger(), *get_clock(), 1000, "battery low");
}

Expected result

How you know it worked

ROS_DISTRO is lyrical in every terminal used for the exercise.
The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Add DEBUG, INFO, WARN and ERROR messages to a node, run it at each --log-level, view the messages in rqt_console, and add a throttled warning for a value that changes at 100 Hz.

Before you continue

ROS_DISTRO reports lyrical in every terminal you used
The example builds and runs without errors
You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.