Unit 05 · lab

Lab: Reconstruct the Repetition Failure

A maintenance note says:

“The range check ran three times. ROS was up. Nothing looked wrong.”

That note is too vague to be useful. Your job is to rebuild the evidence trail and determine exactly what can be defended.

The controlled terminal below is a deterministic Robotnix simulator. It does not execute Java, connect to a ROS 2 installation, contact a network, or control hardware.

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

Incident record

You are given this Java-side reading series:

double[] readings = {0.41, 0.42, 3.70, 0.40};
double minRangeMeters = 0.10;
double maxRangeMeters = 2.00;

The intended policy is:

inspect readings in order
accept values inside the declared interval
preserve rejected values
continue after a rejection
stop when every array position has been inspected

You are also told that someone captured a ROS 2 node listing during the same investigation.

Your final artifact is a Repetition Audit: Range Check 05.

Guided example: one row before you begin

Suppose the first reading is 0.41 m at index 0.

Start with the evidence:

index = 0
reading = 0.41 m
allowed interval = 0.10–2.00 m

Apply the rule:

0.41 >= 0.10 → true
0.41 <= 2.00 → true
accepted       → yes

Record the result:

Index	Reading	Decision	Reason	Continue?
0	0.41 m	accept	inside both declared bounds	yes

What does that row prove? It proves how the controlled rule classified the value at index 0.

What does it not prove? It does not prove that a live sensor produced 0.41 m, that a ROS 2 message carried it, or that a robot moved.

You will repeat that reasoning independently for the remaining values.

Phase 1: reconstruct the Java trace

Build a trace for all four readings. Preserve 3.70 m; do not delete or replace it.

Your trace must include:

array index;
reading and unit;
accepted/rejected decision;
exact rule responsible;
whether another iteration is allowed;
the value of the controlling index after the iteration.

When the final reading has been processed, explicitly record the final false condition check that ends the loop.

Then write one sentence answering:

What exactly caused repetition to stop?

Do not use “finished normally.” Name the condition and state.

Phase 2: inspect the simulated ROS 2 record

In the terminal:

source /opt/ros/jazzy/setup.bash
ros2 node list

Record the output exactly.

Then classify the evidence:

record type:
what was observed:
smallest defensible claim:
what this record cannot establish:

If you need to review the terminology, use the official ROS 2 Jazzy node documentation.

Phase 3: test a tempting but unsupported conclusion

A teammate writes:

“The Java loop completed and both ROS nodes were present, so the range data reached the motor guard correctly.”

Mark the sentence at the exact point where it outruns the evidence.

Then rewrite it as two smaller claims that are supported by the records you have.

Finally, name one ROS 2 inspection that would move the investigation closer to answering whether range data was actually communicated. Do not claim that running the command here produced live evidence; identify the next appropriate inspection and explain why it fits the question.

Phase 4: compare repetition ownership

Use the WPILib Command Scheduler documentation and the ROS 2 node documentation to complete this comparison from Lesson 4:

System	Who owns repetition/lifecycle?	Evidence you would inspect	One thing it cannot prove alone
local Java loop
WPILib command scheduler
ROS 2 node

Your descriptions must distinguish the three mechanisms. “They all repeat code” is not enough.

Phase 5: inject a second failure

Now analyze this changed Java loop:

int index = 0;
while (index < readings.length) {
  double reading = readings[index];
  System.out.println(reading);
}

Do not run it. Trace the controlling state on paper.

Add a failure record containing:

the initial value of index;
the condition checked;
the state transition that is missing;
the expected repetition behavior;
one bounded repair;
one reason this failure could be serious in robot software even if the source compiles.

This is the branch that turns the lab into an investigation. Your audit needs to show that you can diagnose a repetition failure, not just replay the happy path.

Assemble the Repetition Audit

Your final artifact must contain these six evidence blocks:

Controlled input: the raw four-reading series and declared interval.
Iteration trace: every reading plus the final false condition check.
Stop mechanism: a precise statement of why the bounded loop ends.
ROS graph record: exact simulated ros2 node list output and its claim limit.
Three-system comparison: Java loop, WPILib scheduler, ROS 2 node.
Failure diagnosis: the broken while loop and your repair.

Finish with two short statements:

Supported conclusion: the strongest conclusion all of your evidence can defend.

Still unproven: one larger robot-system claim that would require new evidence.

Success criteria

Your audit is complete when another student can inspect it and verify all of the following without asking you what you meant:

every array position and the final false condition are visible;
3.70 m remains in the record and is classified rather than erased;
the loop’s stopping mechanism is named precisely;
the broken while loop is diagnosed from state, not just labeled “infinite”;
Java-loop evidence is separate from ROS graph evidence;
WPILib scheduling is described as a framework lifecycle, not renamed as ROS 2 behavior;
no sentence treats node visibility as proof of topic delivery or physical actuator response;
the next evidence request actually matches the stronger claim you want to test.

Keep this audit. The Week Wrap-Up asks you to cite exact labels from it.