Debugging and Reliability

Track down why a robot misbehaves - mechanical, programming, or sensor - and prove it works again and again.

70-85 minutes

Key ideas

What debugging really is

Every time you run a program you have two results in your head: the expected result (what SHOULD happen) and the actual result (what DID happen). When they match, the robot is working. When they don't, there is a bug, and debugging is the detective work of finding out why they differ.

The three families of bugs

Bugs come in three families, and naming the family is half the fix. A mechanical bug is a physical problem with the robot's body - a loose wheel, a wire dragging on the floor, a gear that slips. A programming bug is a mistake in the instructions - a wrong number, a missing block, or blocks in the wrong order. A sensor bug is a sensing problem - a bad reading, a threshold set to the wrong value, or a sensor that needs calibrating.

Variables and counters: storing and tracking values

Sometimes a program needs to remember a number. A variable is a named box that stores a value, and the value can change while the program runs. A counter is a special variable used to count: it starts at zero and goes up by one each time something happens, like every time the robot avoids an obstacle.

Reliability: proving it with repeated trials

A robot that works once might have just gotten lucky. Reliability means doing the same job correctly again and again - and you can't claim it without proof. The proof is a reliability trial: you run the same task several times, using the same test case each run, and write down the expected result and the actual result for every run.

Words to know

Debugging:: The work of finding out why a robot's actual result is different from the expected result, then fixing it.
Variable:: A named place in a program that stores a value which can change while the program runs.
Counter:: A variable used to count: it starts at a number and goes up by one each time something happens.
Stored value:: A number or fact a program keeps in a variable so it can use or change it later.
Calibration value:: A number you measure and save so a sensor's readings mean the right thing, like the light level of a white floor.
Expected result:: What SHOULD happen when the program runs correctly - what you predict before you test.
Actual result:: What DID happen when you actually ran the robot, which you observe and write down.
Test case:: One specific situation you set up on purpose to test, like 'a wall exactly 15 cm away'.
Mechanical bug:: A physical problem with the robot's body, like a loose wheel, a dragging wire, or a jammed gear.
Programming bug:: A mistake in the instructions: a wrong, missing, or out-of-order block or number.
Sensor bug:: A problem with sensing: a bad reading, a wrong threshold, or a sensor that needs calibrating.
Reliability:: How well a robot does the same job correctly again and again, proven by repeated trials.

Your activity

Bug Detective missions

Goal: Diagnose a misbehaving robot: decide whether the bug is mechanical, programming, or sensor, then fix it.

For each mission, first write the expected result and the actual result. The gap between them is the symptom you're investigating.
Ask the three-family question: is this physical (mechanical), an instruction (programming), or a sensing problem (sensor)? Use the symptom to guess before you touch anything.
Change ONE thing at a time, run it again, and record whether the actual result now matches the expected result.

Write what happened:

Three-run reliability trial

Goal: Prove a robot is reliable by running the same task three times and comparing the expected result to the actual result each run.

Pick one clear task and one test case (the exact same setup every run). Write the expected result once - it's the same for all three runs.
Run the task three times WITHOUT changing anything between runs. Record the actual result and mark Match? (yes or no) for each run.
Three matches means reliable for this test case. Any mismatch is a bug to hunt with the Bug Detective steps.

Write what happened:

Obstacle counter

Goal: Use a variable as a counter that adds one each time the robot avoids an obstacle, then read the stored value.

Set a counter variable to 0 at the start. Each time the robot senses and avoids an obstacle, add 1 to the counter.
This is a stored value: the counter remembers how many obstacles were handled, and you can check it at the end.
Predict how many obstacles are on the course, then compare your prediction to the counter's final value.

Write what happened:

Predict

Write your guess before you test.

Before your three-run reliability trial, predict which run (if any) will fail to match the expected result, and why.

Look at the Bug Detective symptom before touching the robot: predict which family the bug is in - mechanical, programming, or sensor.

For the obstacle counter, predict the final stored value before running the course.

Test and record

Three-run reliability test

Pick one task and one test case. Write the expected result once, then run the same task three times without changing anything. Record the actual result and whether it matched each run.

Record: Whether the actual result matched the expected result on each of the three runs

Run	Expected result	Actual result	Match? (Y/N)

Bug diagnosis record

For each debugging mission, record the symptom, which bug family you suspect, the one change you tried, and whether it fixed the mismatch.

Record: Which bug family was responsible and whether one targeted change fixed it

Symptom	Suspected family	One change tried	Fixed? (Y/N)

Knowledge check

Answer each question. For choice questions, circle the best answer.

Diagnose the most likely kind of bug.
A line-following robot worked yesterday. Today it drives straight past the line every time, even though the code has not changed. The room is much brighter today.
- A.A programming bug
- B.A sensor bug that needs re-calibration
- C.A mechanical bug
- D.The robot is broken for good
What is debugging?
- A.Making the robot go faster
- B.Finding out why the actual result is different from the expected result, then fixing it
- C.Deleting the whole program and starting over
- D.Adding more sensors to the robot
A robot drove straight last week. Its program hasn't changed, but now it curves to one side every run. Which bug family is this most likely?
- A.A programming bug
- B.A sensor bug
- C.A mechanical bug
- D.There is no bug
What is a counter?
- A.A sensor that measures distance
- B.A variable that starts at a number and goes up by one each time something happens
- C.A block that makes the robot stop
- D.The robot's battery level
In a reliability trial, what is the 'expected result'?
- A.What actually happened when you ran the robot
- B.What SHOULD happen if the program works correctly
- C.The number of sensors the robot has
- D.The fastest possible time
Why do you run the same task three times in a reliability trial?
- A.To prove the robot works again and again, not just once by luck
- B.Because the first two runs are just for practice
- C.To drain the battery faster
- D.Because one run is against the rules

Reflect

What did you change because of testing rather than guessing?

How did running the task three times change what you knew about your robot, compared to running it just once?

Why does changing one thing at a time make debugging easier? What went wrong (or right) when you tried it?