The Problem

As CTO, I spend a lot of my time helping my team navigate the complexities of ROS2. One of the biggest time sinks? Debugging. We're building autonomous robots, and when things go wrong (and they always do), it can be like finding a needle in a haystack. Nodes failing to communicate, message data getting corrupted, launch files refusing to cooperate – the list goes on. I needed a faster, more reliable way to diagnose problems before they became full-blown crises.

What I Tried First

Initially, we relied heavily on printf debugging – sprinkling print statements throughout the code. It was slow, messy, and made the code harder to read. Plus, with ROS2's asynchronous nature, the output was often interleaved and difficult to follow. I also tried using just ros2 topic echo to see the messages, but I needed more context and better filtering to diagnose complex behaviors.

The Solution

I've developed a core set of commands and techniques that I use virtually every day. They're my go-to toolkit for quickly understanding what's happening in our ROS2 systems. Here they are:

1. `ros2 topic echo` (with filters): This isn't just about seeing messages; it's about selectively seeing them. I use the --field option to focus on specific data within the message. For instance, if I'm only interested in the data field of a topic called /my_topic, I run:

ros2 topic echo /my_topic | grep "important_value"

To debug time-sensitive systems, the --show-timestamps option is very helpful.

ros2 node info /my_node

Example Connection output:

/rosout

Node name: /my_node

Node namespace: /

Topic name: /rosout

Topic type: rcl_interfaces/msg/Log

Endpoint type: PUBLISHER

QoS profile:

Reliability: RELIABLE

Durability: TRANSIENT_LOCAL

Lifespan: -1.0 seconds

Deadline: -1.0 seconds

Liveliness: AUTOMATIC

Liveliness lease duration: -1.0 seconds

1. `rqt_graph` (with advanced tips): RQT Graph visualizes the ROS2 computational graph, showing the connections between nodes. While seemingly simple, it's incredibly powerful when used effectively. I always use the "Filter" box to focus on specific nodes or topics. Right-clicking and selecting "Highlight Path" helps trace communication flows.
2. Launch File Debugging (conditional execution): Debugging launch files can be tricky. I use conditional execution based on arguments to enable debugging features. This allows me to launch nodes under a debugger like gdb or set specific log levels.

ros2 launch my_package my_launch.xml debug:=true

1. Structured Logging: I've moved away from basic printf statements and now embrace ROS2's structured logging system. This provides context and makes it easier to analyze logs programmatically.