RobotnixAcademy

Unit 11 · lab

Lab: Reconstruct a ROS 2 Graph From Bounded Evidence

This lab is your first complete ROS 2 runtime investigation in the course.

You will begin from an unsourced shell, establish the Jazzy environment, inventory the visible nodes, inspect two node relationships, record the visible topics and one parameter value, then deliberately reset the shell and explain why the CLI disappears even though the lesson system itself has not changed.

Your final artifact is a ROS Graph Evidence Record.

Choose your lane

Reader lane

Use the deterministic terminal embedded below.

It models a bounded Jazzy graph so every student can work with the same evidence. It does not execute Linux commands, start real ROS processes, discover a network, or control hardware.

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

Local Jazzy lane

If you have Ubuntu 24.04 and ROS 2 Jazzy available, you may use a real sourced terminal instead.

Your local graph will probably differ from the Robotnix graph. That is expected.

Label every local command result as local ROS 2 evidence and do not substitute local node names into the reader-lane expected architecture.

Guided example: classify one failure before trying to fix it

Suppose the terminal shows:

student@robotnix:~/java-ros2$ ros2 node list
ros2: command not found

A weak diagnosis is:

The nodes crashed.

The command never reached graph inspection. The shell could not find ros2.

A better first check is:

echo $ROS_DISTRO

If the result is empty in the reader lane, source Jazzy:

source /opt/ros/jazzy/setup.bash

Then verify:

echo $ROS_DISTRO

returns:

jazzy

Now rerun:

ros2 node list

The important reasoning is that you repaired the shell environment before attempting to diagnose the graph.

You will repeat that reasoning independently later in the lab.

Part 1: Record the unsourced shell

If you are using the reader lane, begin with:

echo $ROS_DISTRO
ros2 node list

Record both outputs.

Your evidence statement should say:

The simulated shell did not report an active ROS distribution, and the ros2 command was unavailable before the Jazzy setup was sourced.

Do not write:

ROS 2 was not installed.

The terminal evidence does not establish installation state.

Local-lane students should only perform an unsourced-shell test if doing so is safe and convenient in their environment. If your shell auto-sources Jazzy, record that fact rather than changing your machine configuration just for the exercise.

Part 2: Establish the Jazzy environment

Reader lane:

source /opt/ros/jazzy/setup.bash
echo $ROS_DISTRO
ros2 --help

Record:

  • the source command;
  • the reported distribution;
  • whether the CLI becomes available.

Your artifact should distinguish:

shell environment evidence

from:

ROS graph evidence

The graph has not been inspected yet.

Part 3: Inventory the nodes

Run:

ros2 node list

Reader-lane expected output:

/sensor_bridge
/motor_guard

Record the exact names.

Then compare them with the Week 11 expected graph:

/sensor_bridge
/motor_guard

For this deterministic case, the node-name inventory matches the expectation.

That match does not prove the nodes expose the correct interfaces.

Part 4: Inspect /sensor_bridge

Run:

ros2 node info /sensor_bridge

From the output, record at least:

  • one publisher;
  • its message type;
  • whether a /scan subscription is shown;
  • one parameter-related service name.

Your selected relationship should include:

/scan: sensor_msgs/msg/LaserScan

under Publishers in the reader lane.

Write the strongest supported claim in your own words.

Then write one stronger claim that the node-info output does not establish.

Part 5: Inspect /motor_guard

Run:

ros2 node info /motor_guard

Record:

  • /scan subscription and type;
  • /cmd_vel publisher and type;
  • one parameter-related service.

Now compare the two node records.

The graph reports a publisher and subscriber relationship on the same /scan topic with the same message type.

That is evidence of compatible graph structure at the topic/type layer.

It does not prove one particular scan message was delivered.

Part 6: Inventory the topics

Run:

ros2 topic list

Reader-lane output includes:

/cmd_vel
/parameter_events
/rosout
/scan

Classify each topic you recognize by why it appears in the graph evidence.

At minimum, explain:

  • /scan relates to the selected sensor data path;
  • /cmd_vel relates to the selected command-output path;
  • /rosout relates to ROS logging;
  • /parameter_events relates to parameter-event infrastructure.

Do not inspect message content yet. That is a Week 12 task.

Part 7: Inspect one parameter value

Run:

ros2 param get /motor_guard caution_distance_m

Reader-lane output:

Double value is: 0.5

Record:

node: /motor_guard
parameter: caution_distance_m
reported value: 0.5
unit in course architecture: meters

Then write:

This is configuration evidence. It does not prove the node applied the parameter correctly to a live message or physical movement.

Use your own wording, but preserve that boundary.

Part 8: Reset the shell on purpose

Reader lane:

reset

Then immediately try:

ros2 node info /motor_guard

Record the failure.

Now run:

echo $ROS_DISTRO

and explain what changed.

The deterministic graph definition did not disappear from the lesson. The simulated shell returned to an unsourced state, so ROS commands are unavailable until you source Jazzy again.

Recover with:

source /opt/ros/jazzy/setup.bash
ros2 node info /motor_guard

Record the successful recovery.

This is a shell-environment recovery, not proof that a ROS process restarted.

Part 9: Test an unknown node name

After sourcing Jazzy again, run:

ros2 node info /navigation

The reader lane reports that the node is not present in the deterministic lesson graph.

Do not write:

Navigation crashed.

Write what the evidence actually says:

/navigation was not found in the deterministic graph inspected by this command.

Then list two possible explanations that a real system might require you to investigate.

Part 10: Build the ROS Graph Evidence Record

Your final artifact must contain these sections.

Shell state

Record:

  • unsourced ROS_DISTRO result;
  • source command;
  • sourced ROS_DISTRO result;
  • CLI availability.

Node inventory

Record the output of:

ros2 node list

and compare expected versus observed node names.

/sensor_bridge relationships

Record at least one publisher and one service relationship.

/motor_guard relationships

Record at least one subscription, one publisher, and one service relationship.

Topic inventory

Record the visible topic names and what the names/interfaces allow you to infer.

Parameter observation

Record caution_distance_m=0.5 and label it configuration evidence.

Deliberate shell failure

Preserve the reset case, the resulting command failure, the environment check, and the source-based recovery.

Unknown-node case

Preserve the /navigation lookup and keep cause separate from observation.

Not yet proven

Name at least four claims Week 11 has not established. Include at least:

  • fresh /scan messages;
  • QoS compatibility or actual delivery;
  • /cmd_vel message contents;
  • physical motor or wheel response.

Next commands

For each missing claim, identify the ROS tool family you expect to use next, such as ros2 topic or more focused parameter inspection.

Success criteria

Your ROS Graph Evidence Record is complete when another student can answer:

  • Was the shell sourced before ROS commands were used?
  • Which distribution did the shell report?
  • Which nodes were visible?
  • What did /sensor_bridge publish?
  • What did /motor_guard subscribe to and publish?
  • Which topic names were visible?
  • What parameter value was reported?
  • What exactly failed after the simulated shell reset?
  • Why is a missing node name not automatically a crash diagnosis?
  • Which communication and hardware claims remain untested?

The goal is not to memorize eight CLI commands. It is to know which observation each command can defend and where the evidence stops.