Lab: Build a Java and ROS Evidence Case File

This lab combines the first week's Java and ROS 2 concepts into one controlled investigation.

You are not trying to prove that a physical robot is healthy. You are trying to produce a record that clearly separates what the Java program established from what the ROS 2 runtime inspection established.

The browser terminal is deterministic lesson state. It does not execute commands on your computer or connect to 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

Part 1: Predict the Java program

Use this source:

public class RobotStatus {
  static boolean needsCharge(int batteryPercent) {
    return batteryPercent < 20;
  }

  public static void main(String[] args) {
    int batteryPercent = 18;

    System.out.println("battery=" + batteryPercent);
    System.out.println("needsCharge=" + needsCharge(batteryPercent));
  }
}

Before using the terminal, write the two lines you expect the program to print.

Then answer:

1. What file name should contain this source?
2. What does needsCharge(18) return?
3. What happens at exactly 20?
4. What physical claim is still unsupported even if the program runs exactly as expected?

Part 2: Inspect the Java toolchain

In the terminal, run:

java --version
javac --version

Record the simulated version output.

Then run:

javac RobotStatus.java
java RobotStatus

The terminal uses a bounded RobotStatus example and may not reproduce the exact source above line for line. Treat the terminal result as a separate controlled record.

For the case file, write:

• the command;
• the observed output;
• what the output proves;
• what it does not prove.

Do not write “Java works.” Name the specific observation.

Part 3: Start with an unsourced ROS shell

Reset the simulator:

reset

Now try:

ros2 node list

Record the failure.

Explain why this is evidence about the shell environment rather than evidence that the ROS graph itself is empty.

Now source Jazzy:

source /opt/ros/jazzy/setup.bash

Verify:

echo $ROS_DISTRO

Then rerun:

ros2 node list

This sequence matters. You deliberately created a failure, identified the missing environment setup, repaired it, and collected new evidence.

Part 4: Inspect the graph

Run:

ros2 node info /sensor_bridge
ros2 node info /motor_guard
ros2 topic list

Create this table in your case file:

Do not use “hardware works” anywhere in this table.

Part 5: Challenge one oversized claim

Repair this statement:

Java ran, /sensor_bridge and /motor_guard are online, and /cmd_vel exists, so the robot is ready to move.

Your repair must preserve every fact the evidence actually supports while removing anything that has not been demonstrated.

Then write the single next observation you would want if the investigation question became:

Is /scan actually carrying a message?

Do not collect that evidence yet. Week 2 and later ROS runtime lessons will teach how to inspect message contracts and content.

Final artifact: Java and ROS Evidence Case File

Submit or preserve a case file containing:

1. Java source note with the role of main and needsCharge(...).
2. Java execution record with compile/run observations.
3. Shell failure and repair showing why sourcing matters.
4. ROS graph record with node and topic observations.
5. Claim repair replacing the oversized robot-ready statement.
6. Next evidence naming one observation needed for a stronger claim.

Success criteria

Your case file is complete when another student can tell, without asking you:

• which observations came from Java;
• which observations came from ROS 2;
• why the unsourced-shell failure occurred;
• what needsCharge(...) actually decides;
• what graph presence does and does not establish;
• why no physical motion claim has been proven.

The best case file is not the one with the most output. It is the one where every conclusion has an identifiable source.