Lab: Bounded Decision Record

This lab brings together comparisons, booleans, branching, methods, and ROS parameter evidence.

The terminal is deterministic lesson state. It does not run your Java source or control 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: Record the baseline inputs

Use this Java state:

double rangeMeters = 0.42;
double minRangeMeters = 0.10;
double maxRangeMeters = 2.00;
long messageAgeMilliseconds = 90;
long maxAgeMilliseconds = 200;
double cautionDistanceMeters = 0.50;

Copy the values and units into your Bounded Decision Record.

Then calculate:

boolean insideDeclaredRange =
    rangeMeters >= minRangeMeters
    && rangeMeters <= maxRangeMeters;

boolean readingFresh =
    messageAgeMilliseconds <= maxAgeMilliseconds;

boolean outsideCautionZone =
    rangeMeters >= cautionDistanceMeters;

Predict all three values before continuing.

Part 2: Predict the branch

Use:

if (!insideDeclaredRange) {
  System.out.println("REJECT RANGE");
} else if (!readingFresh) {
  System.out.println("REJECT STALE");
} else if (rangeMeters < cautionDistanceMeters) {
  System.out.println("CAUTION");
} else {
  System.out.println("RANGE CONDITION CLEAR");
}

Write the branch you expect and explain why Java skips the others.

Do not write only the output word. Include the condition that selected it.

Part 3: Write the reusable method

Add this method to your record:

static boolean movementConditionsMet(
    double rangeMeters,
    double cautionDistanceMeters,
    boolean insideDeclaredRange,
    boolean readingFresh
) {
  return insideDeclaredRange
      && readingFresh
      && rangeMeters >= cautionDistanceMeters;
}

Calculate the result for the baseline state.

Then write one sentence explaining why the method name says movementConditionsMet instead of robotSafe.

Part 4: Inspect the ROS parameter

Source Jazzy:

source /opt/ros/jazzy/setup.bash

Run:

ros2 param get /motor_guard caution_distance_m

Record the supplied value and compare it with:

cautionDistanceMeters = 0.50;

Write two statements:

1. a supported statement about the matching values;
2. an unsupported statement about Java-to-ROS integration that you must not make.

A correct record does not claim the Java variable was populated from the ROS parameter.

Part 5: Change one input

Keep every value the same except:

rangeMeters = 0.80

Recalculate:

• insideDeclaredRange;
• readingFresh;
• outsideCautionZone;
• movementConditionsMet;
• selected if/else branch.

Record exactly which results changed and which stayed the same.

This is a useful debugging method: change one variable at a time so you can attribute the changed output to a known cause.

Part 6: Introduce a rejected reading

Now use:

rangeMeters = 3.70

The first branch should reject the range before the caution threshold is treated as a normal decision.

Record:

insideDeclaredRange=false
branch=REJECT RANGE

Then answer:

Why would reporting “3.70 is outside the caution zone” be misleading even though 3.70 >= 0.50 is mathematically true?

Your answer should explain that the reading failed validation first.

Part 7: Introduce stale data

Return the range to:

0.80 m

and change:

messageAgeMilliseconds = 500

Recalculate the branch.

Now the numeric range is valid and outside the caution zone, but the freshness rule fails.

Your record should show why a system can reject data that looks numerically reasonable.

Part 8: Build the final decision table

Include at least these four cases:

Fill in the last two columns from your reasoning.

Final artifact

Your Bounded Decision Record must contain:

1. baseline inputs and units;
2. three intermediate booleans;
3. method signature and result;
4. selected branch with explanation;
5. ROS parameter snapshot;
6. statement that matching values do not prove integration;
7. four-case decision table;
8. one rejected-input explanation;
9. one stale-input explanation;
10. one physical-system claim that remains unsupported;
11. the next evidence you would collect if the question became whether a real controller acted on the decision.

Success criteria

Another student should be able to change any one input and predict the result without asking what your booleans mean.

If your artifact contains one final true/false result but hides the intermediate rules, it is not complete.