Week 6: Debugging and Reliability

Session length: 70-85 minutes

Learning purpose

Students take the reacting robots they built and make them trustworthy. They learn that debugging is the work of finding out why the actual result is different from the expected result, and that bugs come in three families: mechanical (something physical), programming (a wrong or missing instruction), and sensor (a bad reading, threshold, or calibration). They practice diagnosing purposeful debugging missions, meet variables and counters to store and track values, and run reliability trials - the same task three times - recording expected versus actual to prove the robot really works.

Expected student outcomes

By the end of this week, students can:

Explain debugging as finding why the actual result differs from the expected result
Tell mechanical, programming, and sensor bugs apart from their symptoms
Use a variable or counter to store or track a value in a program
Run a reliability trial: do the same task three times and record expected vs actual
Diagnose a misbehaving robot and describe the fix

Suggested pacing

About 70-85 minutes. Adjust to your group - these are guides, not limits.

Step	Focus	Minutes
Debugging and the three bug families	Expected vs actual results, and mechanical, programming, and sensor bugs.	15 min
Predict the bug family	Read each symptom and predict its family before investigating.	5 min
Bug Detective missions	Diagnose and fix mechanical, programming, and sensor bugs, one change at a time.	18 min
Obstacle counter	Use a variable as a counter to track obstacles avoided.	12 min
Three-run reliability trial	Run the same task three times, recording expected vs actual and Match?.	15 min
Knowledge check	Five questions on debugging, bug families, counters, and reliability.	8 min
Reflection	Write about a bug you found and what three runs told you.	7 min

Before you start

Set up

Print the three-run test record and the Bug Detective sheet, one per student or pair.
Have last week's reacting robots (or sim missions / card programs) ready to debug.
Set up a repeatable test case: mark a start line and a fixed wall or obstacle distance so runs are truly identical.

Prepare ahead

Prepare one seeded bug of each family in advance: loosen a wheel (mechanical), change a turn number (programming), and set a bad threshold (sensor).
Practice reading the live sensor value on your kit or in the sim so you can coach threshold fixes.
Decide how students will 'add 1' to a counter on your equipment, and try the obstacle-counter program once yourself.

Materials

Three-run test record (printable)(Kit, Simulator, Unplugged)
Bug Detective worksheet with the three bug families (printable)(Kit, Simulator, Unplugged)
Pencil and paper for recording results(Kit, Simulator, Unplugged)
A reacting robot built in Week 5, with at least one sensor(Kit)
Measuring tape or ruler to set up the same test case each run(Kit, Unplugged)
Computer or tablet with the browser simulator(Simulator)
Cardboard robot, program cards, and a taped floor course from earlier weeks(Unplugged)
Sticky notes or a tally sheet to act as a counterOptional(Unplugged)

Safety

cautionTurn the robot off before tightening wheels, moving wires, or checking mechanical parts.(Kit)
cautionKeep the test and obstacle course clear of hands, feet, and clutter during runs.(Kit, Unplugged)
infoUse child-safe scissors with an adult if you rebuild a paper bumper or model part.(Unplugged)
infoSave your program and test record often so a browser refresh doesn't lose your results.(Simulator)

Full safety briefing

Review these once with your group. They apply across the whole course; the notes above are what matters most this week.

Batteries and circuitsKit

Use only appropriate low-voltage educational equipment - no wall outlets and no household batteries wired by hand.
Never connect a battery's two terminals directly to each other.
Stop right away if a motor, wire, or battery becomes hot, and tell an adult.
Disconnect the power before changing wheels, motors, or other mechanical parts.

Motors and gearsKit

Keep fingers, hair, jewelry, sleeves, and loose clothing away from moving gears and wheels.
Do not force a stalled motor that has stopped turning - switch it off and find out why.
Make sure moving parts are secured before you run a test.

Moving robots

Test on the floor, not on a table where the robot could drive off an edge.
Keep robots away from stairs, roads, water, pets, and people's feet.
Use a clear, open test area.
Always include a safe-stop behavior so the robot halts when the job is done or something is in the way.

Tools and materialsKit, Unplugged

Ask an adult for help with cutting or any sharp tools.
Use safe classroom materials - no sharp, toxic, or breakable items.
Never launch or swing an attachment toward a person.

Running the session

1.Teach expected vs actual and the three bug families before any robot is touched.
2.Have students predict the bug family from the symptom first, then investigate - resist letting them randomly poke.
3.Insist on changing one thing at a time and re-running, so the cause of the fix is known.
4.Protect time for the full three-run reliability trial; a single lucky run is not proof.

Common misconceptions

'It worked once, so it's fixed' - reliability needs repeated matching runs, not one.
Assuming every bug is in the code - many are mechanical (loose wheel, dragging wire) or sensor (wrong threshold).
Changing several things at once, so no one can tell which change actually fixed it.
Thinking a variable and a counter are different things - a counter is just a variable used to count.

Questions to ask

What did you expect to happen, and what actually happened?
Does it fail the same way every run, or only sometimes? What does that tell you about the family?
What is the ONE thing you changed, and did it match your prediction?
How do you know your robot is reliable and didn't just get lucky?

Classroom & group adaptations

Make it easier

Give students one seeded bug at a time with the family already named, so they practice the fix and the three-run test without also diagnosing the family.

Make it harder

Seed two bugs from different families at once, or require a counter that triggers an action (like stopping after 3 obstacles) that students must also test for reliability.

Groups & whole class

In pairs or small groups, give each student a role that rotates - driver (builds or types), navigator (reads the plan), and recorder (fills the worksheet) - so everyone participates. For a whole-class demo, run one shared robot or simulator on the board, have students predict together, then let groups repeat it on their own path. Groups can also mix paths: one builds on the kit while another checks the same idea in the simulator or unplugged, then they compare results.

Hardware and no-hardware notes

Every activity this week runs three ways - all three teach the same core idea, so pick whichever fits your room. No specific product is required.

Kit

Three-run test record (printable)
Bug Detective worksheet with the three bug families (printable)
Pencil and paper for recording results
A reacting robot built in Week 5, with at least one sensor
Measuring tape or ruler to set up the same test case each run

Simulator

Three-run test record (printable)
Bug Detective worksheet with the three bug families (printable)
Pencil and paper for recording results
Computer or tablet with the browser simulator

Unplugged

Three-run test record (printable)
Bug Detective worksheet with the three bug families (printable)
Pencil and paper for recording results
Measuring tape or ruler to set up the same test case each run
Cardboard robot, program cards, and a taped floor course from earlier weeks
Sticky notes or a tally sheet to act as a counter

Troubleshooting

Common problems from this week's activities and what to try.

Fixing 'everything' at once so the cause is unknownKitTry: Undo all but one change; make a single change, re-run, and see if that was it.
Can't decide the bug familyKitTry: Run it three times: same wrong result every time points to programming; different results point to mechanical or a shaky sensor.
The loop never endsSimulatorTry: That's a programming symptom - check that the repeat-until condition can actually become true.
The robot ignores the wallSimulatorTry: Read the sensor value in the sim and check the threshold is on the correct side of it - a sensor bug.
The 'robot' is run differently each timeUnpluggedTry: Make each card an exact instruction so the actual result is repeatable - that's how you spot the real bug.
Not sure if it's a card or the bumperUnpluggedTry: Read the cards aloud exactly as written; if they're correct, the bug is mechanical.
Results drift over the three runsKitTry: Check batteries and the start position - a fading battery is a mechanical/power cause of unreliability.
It matches twice then failsKitTry: The failing run is your clue - inspect the sensor reading and the physical setup right after that run.
Runs differ even though nothing changedSimulatorTry: Check that the start tile is really identical and the loop ends on a definite condition, not by luck.
Every run matches perfectly and it feels too easySimulatorTry: Try a harder test case (closer wall, tighter turn) to see where reliability breaks.
Different people get different endingsUnpluggedTry: Rewrite the cards as exact, unambiguous steps so the actual result is repeatable.
The same person gets different endingsUnpluggedTry: Mark the start spot and step lengths so the test case is truly identical each run.
The counter is too highKitTry: The robot is adding 1 more than once per obstacle - make sure the count happens once per detection, not every loop.
The counter stays at 0KitTry: Check that the add-1 step is inside the 'if obstacle' branch, not outside it - a programming bug.
Counter over-countsSimulatorTry: The add-1 fires every loop while touching one obstacle; only count once per new detection.
Counter never changesSimulatorTry: Confirm the add-1 block is inside the sensor condition, not in the plain loop.
Too many talliesUnpluggedTry: Only tally when the 'turn to avoid' card actually fires, not every step.
Forgot to reset the counterUnpluggedTry: Always start a new run by setting the counter back to 0 - the stored value must begin fresh.

Knowledge-check answer key

Answers are shown here for the adult only - the student worksheet keeps them hidden.

1. Diagnose the most likely kind of bug.
Correct answer: A sensor bug that needs re-calibration
Why: Same code plus changed lighting plus bad readings points to a sensor/calibration bug, not a program or mechanical one.
2. What is debugging?
Correct answer: Finding out why the actual result is different from the expected result, then fixing it
Why: Debugging is the detective work of finding why the actual result differs from the expected result, then fixing that cause.
3. 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?
Correct answer: A mechanical bug
Why: When the code is unchanged and the robot veers the same way, suspect a mechanical bug like a loose wheel or dragging wire.
4. What is a counter?
Correct answer: A variable that starts at a number and goes up by one each time something happens
Why: A counter is a variable that stores a running count, starting at a number and increasing by one each time an event happens.
5. In a reliability trial, what is the 'expected result'?
Correct answer: What SHOULD happen if the program works correctly
Why: The expected result is what should happen; you compare it to the actual result each run to see if the robot is reliable.
6. Why do you run the same task three times in a reliability trial?
Correct answer: To prove the robot works again and again, not just once by luck
Why: Repeated matching runs prove reliability; if one run's actual result doesn't match the expected result, you've found a bug to fix.