Inspect a ROS 2 Graph Without Guessing

You have seen the words node, topic, and graph. Now you are going to inspect them with the ROS 2 command-line interface.

The terminal on this page is a deterministic simulator. It behaves like a small, controlled lesson environment. It does not run a real ROS installation or contact a robot.

xterm.js terminal simulation

Inspect a Java application beside a ROS 2 Jazzy graph

Source a simulated Jazzy shell, verify the active distribution, inspect nodes and their graph relationships, and keep runtime observations separate from Java and hardware claims.

This is a controlled command simulator. It does not execute Java, ROS 2, shell commands, or network requests on your device.

Commands worth trying

• echo $ROS_DISTRO
• source /opt/ros/jazzy/setup.bash
• echo $ROS_DISTRO
• ros2 --help
• ros2 node list
• ros2 node info /sensor_bridge
• ros2 node info /motor_guard
• ros2 topic list
• ros2 param get /motor_guard caution_distance_m

First: source the environment

Start by checking the active ROS distribution:

echo $ROS_DISTRO

In a fresh unsourced shell, the simulator returns an empty line.

Now load the Jazzy environment:

source /opt/ros/jazzy/setup.bash

Then run:

echo $ROS_DISTRO

Now the result is:

jazzy

This teaches an important shell concept. ROS environment setup is associated with the current shell session. Opening a new terminal does not automatically preserve the sourced state.

If a ROS command works in one terminal and fails in another, check the environment before assuming the package or graph is broken.

ros2 is the CLI entry point

After sourcing, run:

ros2 --help

The output lists subcommands such as:

node
topic
service
action
param
pkg
launch

You will learn these over the course. For now, focus on node and topic.

List the nodes

Run:

ros2 node list

The controlled graph returns:

/sensor_bridge
/motor_guard

This is a graph observation.

It supports this statement:

The deterministic lesson graph contains node names /sensor_bridge and /motor_guard.

It does not support this statement:

The sensor and motor hardware are working correctly.

The second claim requires evidence outside a node-name list.

Inspect one node

Now run:

ros2 node info /sensor_bridge

The output includes a publisher:

/scan: sensor_msgs/msg/LaserScan

That gives you more detail than node list did.

You now have evidence that, in this controlled graph description, /sensor_bridge has a publisher endpoint associated with /scan using the sensor_msgs/msg/LaserScan type.

Notice how the claim becomes more specific as the command becomes more specific.

Next run:

ros2 node info /motor_guard

The result shows that /motor_guard subscribes to /scan and publishes /cmd_vel.

A reasonable summary is:

That is enough to describe a communication relationship in the graph.

It is not enough to prove that useful messages are flowing.

Node names and topic names are different things

Run:

ros2 topic list

You will see names including:

/scan
/cmd_vel
/rosout

A node is a runtime participant.

A topic is a named communication channel used for message streams.

Do not write:

/scan is a node.

and do not write:

/motor_guard is a topic.

The leading slash does not tell you which kind of graph entity you are looking at. The command you used and the context of the result matter.

Try an invalid node name

Run:

ros2 node info /camera

The simulator tells you that the node is not present in this controlled graph.

That failure is useful. It shows why guessing names is weaker than listing what exists first.

A practical investigation often begins with:

ros2 node list

before using node info on a specific name.

Build a graph evidence record

Create a short record with these columns:

Then add one record of your own.

The next question should follow from the missing evidence

Suppose your investigation ends with this observation:

/sensor_bridge publishes /scan
/motor_guard subscribes to /scan

What should you inspect next if the question is whether data is actually appearing on /scan?

Another ros2 node list would not add much.

A topic inspection command would be more useful.

That reasoning pattern will drive the rest of the course: choose the next tool based on what the current evidence cannot answer.

In the next lesson, you will combine Java evidence and ROS graph evidence into one claim without mixing the two together.