Lab: Range Series Audit

This lab turns a suspicious four-value series into a complete audit record.

The browser terminal is deterministic lesson state. It does not connect to a live ROS graph or physical sensor.

xterm.js terminal simulation

Inspect a range-reading series

Confirm a topic type, inspect one message, and analyze a bounded sequence of simulated readings.

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

Commands worth trying

• source /opt/ros/jazzy/setup.bash
• ros2 topic info /range
• ros2 topic echo /range --once
• javac RangeSeries.java
• java RangeSeries

Part 1: Preserve the raw Java series

Start with:

double[] readings = {0.41, 0.42, 3.70, 0.40};

Write the array exactly as supplied in your audit.

Record:

length = 4
valid indexes = 0, 1, 2, 3

Then create the index/value table before classifying anything.

Part 2: State the acceptance rule

Use:

minimum = 0.10 m
maximum = 2.00 m

and the inclusive rule:

0.10 <= reading <= 2.00

Classify all four values manually.

Your audit should identify 3.70 m at index 2 as rejected while preserving it in the raw series.

Part 3: Calculate the accepted-value mean

Write the accepted subset explicitly:

0.41, 0.42, 0.40

Show the calculation:

(0.41 + 0.42 + 0.40) / 3 = 0.41 m

Then write a sentence that includes:

• accepted count;
• total count;
• accepted-value mean;
• rejected value and index.

If your sentence says only “average = 0.41 m,” rewrite it.

Part 4: Inspect /range

Source the controlled ROS environment:

source /opt/ros/jazzy/setup.bash

Run:

ros2 topic info /range

Record:

• topic name;
• message type;
• publisher count;
• subscription count.

Then run:

ros2 topic echo /range --once

Preserve the message fields separately from the Java array.

Answer:

Does this one message prove that the Java array came from /range?

The answer is no unless an actual data-transfer path is demonstrated.

Part 5: Run the deterministic Java analysis

Run:

javac RangeSeries.java
java RangeSeries

Compare the program output with your manual audit.

Record whether the program agrees with:

• accepted count;
• rejected value;
• accepted-value mean.

A matching result is useful evidence that the deterministic Java analysis followed the expected logic for this supplied series. It is not proof about a physical sensor.

Part 6: Introduce a second failure by reasoning

Analyze this new series without modifying the simulator:

double[] secondSeries = {0.41, -0.20, 0.42, 0.40};

Use the same interval.

Create the rejection record for -0.20 and answer:

1. Which index contains the rejected value?
2. Which boundary did it violate?
3. What is one plausible hypothesis for the value?
4. What evidence would you need before calling that hypothesis the root cause?

Part 7: Audit the claim

Repair this statement:

The average is normal, so the sensor data is good.

Your replacement must mention the rejected evidence and keep the physical sensor claim unresolved.

Then repair:

/range exists and one message was observed, so the Java program is connected to ROS.

Your replacement must distinguish similar data from demonstrated integration.

Final artifact

Your Range Series Audit must contain:

1. raw array;
2. index/value table;
3. declared interval;
4. classification table;
5. accepted subset;
6. accepted-value mean;
7. rejected evidence record;
8. /range topic/type/message evidence;
9. Java analysis output;
10. one unresolved hypothesis;
11. one next-evidence action.

Success criteria

Another student should be able to reproduce your classification and average, identify the outlier without searching through prose, and explain why the ROS message and Java array remain separate evidence sources.

The lab is not complete if the rejected value disappeared from the final artifact.