RobotnixAcademy

Unit 04 · lesson

Bridge Checkpoint: Defend the Decision Contract

Close this route by defending one small Java decision without overstating what it proves about ROS 2 or hardware.

Your Decision Contract Note should contain:

  • the Java method signature;
  • input units;
  • exact boolean rule;
  • one normal case;
  • one boundary case;
  • one invalid-input case;
  • the observed ROS configuration value;
  • the status of the Java-to-ROS integration claim.

Use these labels:

PROVED
SUPPORTED BUT INCOMPLETE
NOT DEMONSTRATED

Example:

PROVED: shouldWarn(0.42, 0.50) returns true.
PROVED: /motor_guard reports caution_distance_m=0.5 in the supplied ROS evidence.
NOT DEMONSTRATED: the Java method receives that value from the ROS parameter.
NOT DEMONSTRATED: any physical actuator responded.

Challenge question

If another engineer changes the ROS parameter to 0.6, what exact evidence would you collect to determine whether the Java decision changed because of that configuration?

If your answer is only “run it and see,” make the evidence path more precise.

The route is complete when your claims identify their source and stop at the boundary of the evidence.