Unit 07 · lesson

Program a Behavior You Can Explain

A robotics program is not finished when the robot moves. It is finished enough to test when you can explain why each important output changed.

This lesson uses pseudocode on purpose. The behavior model should survive changes in language and hardware.

Example: approach and stop

Goal: approach a wall and stop at a safe distance.

state = APPROACH

repeat:
    distance = read_range()

    if stop_input:
        state = STOPPED

    if state == APPROACH:
        if distance <= stop_distance:
            state = STOPPED
        else:
            left_motor = approach_speed
            right_motor = approach_speed

    if state == STOPPED:
        left_motor = 0
        right_motor = 0

The code is simple. The test cases are where it becomes engineering.

Test the boundary, not just the normal case

Case	Input condition	Expected result
normal	distance decreases toward threshold	robot stops at threshold
already close	starts inside threshold	no forward motion
stop input	human stop becomes active	immediate STOPPED state
bad range	sensor reports impossible value	defined safe response
noisy threshold	value crosses back and forth	no unsafe chatter

The last two cases usually reveal more than another normal run.

Decide what "bad data" means

If a distance sensor returns zero, is the wall touching the sensor? Is zero an error code? Is the sensor disconnected? The answer depends on the device.

Your software needs a defined interpretation.

"Use the sensor" is not a complete design.

Evidence package

Write pseudocode for one behavior and include:

named states;
inputs;
outputs;
normal transitions;
one failure or invalid-data path;
at least five test cases.

If you have a simulator or safe coding environment, implement the behavior there. If not, run the test cases by hand and record the state transitions.

The deliverable is not a screenshot of code. It is the argument that the behavior does what you claim under the cases you tested.

Turn behavior into a testable contract

Suppose the requirement is:

Drive until an obstacle is within 0.30 m, then stop.

That sentence contains several decisions that code must make explicit.

input: distance in meters
normal drive condition: distance > 0.30
stop condition: distance <= 0.30
invalid-data behavior: stop
output while stopped: zero drive command

Now test boundary values before deploying anything:

Sensor value	Expected command
1.20 m	drive
0.31 m	drive
0.30 m	stop
0.29 m	stop
invalid / stale	stop

This table is valuable even if the program is only pseudocode or a browser simulation.

Explain one execution trace

A defensible program is not just code that produced the right final result once. You should be able to trace one run:

distance = 0.42 → DRIVE
distance = 0.34 → DRIVE
distance = 0.30 → STOP
distance = 0.27 → STOP

If you cannot explain why the transition occurred at a specific sample, the program may still be working, but your understanding is not yet reliable.