Skip to content

Week 6

Debugging and Reliability

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

  • 70-85 minutes
  • Mission: Diagnose and fix mechanical, programming, and sensor bugs, then prove a robot is reliable with a three-run test.
Printable worksheetParent & teacher guide

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.

By the end of this week you 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

Learn

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.

Good debuggers don't just poke at the robot - they compare expected to actual, look closely at the symptom, and change one thing at a time so they can tell what fixed it.

For example: Expected: stop at the wall. Actual: crashed into the wall. -> There is a bug to find.; Expected: turn left. Actual: turned right. -> Compare the block to what you meant.

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.

The trick is to read the symptom and guess the family first. If the robot behaves the same wrong way every single time, the bug is often in the program. If it works sometimes and not others, suspect something mechanical or a shaky sensor reading.

For example: Mechanical: robot drifts to one side because a wheel is loose.; Programming: robot turns for 2 seconds instead of 1 because the number is wrong.; Sensor: robot never stops because the distance threshold is too small.

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.

Variables also hold calibration values - numbers you measure once and store so a sensor's readings mean the right thing. Storing a value means you can use it later, change it, and check it, instead of guessing.

For example: A counter that adds 1 each time an obstacle is avoided.; A stored calibration value for the light level of the white floor.; A variable that remembers how many times the robot has looped.

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.

If all three runs match what you expected, the robot is reliable for that test case. If one run is different, you've found a bug hiding in plain sight - and that failing run is exactly the clue you need.

For example: Run the stop-at-wall task 3 times from the same start and record each one.; Expected 'stops' all three runs; actual 'stops, stops, crashes' means run 3 has a bug.

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.

Stay safe

Read these before you build or run a robot this week.

  • Caution:Turn the robot off before tightening wheels, moving wires, or checking mechanical parts.
  • Caution:Keep the test and obstacle course clear of hands, feet, and clutter during runs.
  • Note:Use child-safe scissors with an adult if you rebuild a paper bumper or model part.
  • Note:Save your program and test record often so a browser refresh doesn't lose your results.

Do it

Choose your path

Do this course with a robot kit, the browser simulator, or unplugged with household materials. Pick one - you can switch anytime without losing your work.

Bug Detective missions

Robot kit

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.

Debug a misbehaving kit robot

You need: A reacting robot from Week 5, Bug Detective worksheet, Measuring tape

Steps

  1. 1Have an adult or partner secretly introduce one bug into a working robot (loosen a wheel, change a number in a block, or set a bad threshold).
  2. 2Run the robot and write the expected result and the actual result on the worksheet.
  3. 3Decide the bug family from the symptom, then investigate the likely causes in order.
  4. 4Fix the one thing you suspect, re-run, and confirm the actual result now matches the expected result.

What success looks like: The student names the correct bug family, makes one targeted fix, and the robot's actual result matches the expected result again.

Check for:
  • Expected and actual results are both written down
  • The bug family is correctly identified
  • One change was made at a time
  • The robot works after the fix

Safety: Turn the robot off before tightening wheels or moving wires. Keep fingers clear of moving parts while it runs.

If it doesn't work

Fixing 'everything' at once so the cause is unknown
- Undo all but one change; make a single change, re-run, and see if that was it.
Can't decide the bug family
- Run it three times: same wrong result every time points to programming; different results point to mechanical or a shaky sensor.

Go further: Introduce a bug for a partner and see if they can diagnose the family from the symptom alone.

Three-run reliability trial

Robot kit

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.

Reliability trial on the kit robot

You need: A reacting robot from Week 5, Three-run test record, Measuring tape

Steps

  1. 1Choose a task like 'stop before the wall' and set the wall at the same distance every run - that's your test case.
  2. 2Write the expected result: 'robot stops before touching the wall'.
  3. 3Run it three times from the exact same start, recording the actual result and Match? each time.
  4. 4If a run doesn't match, diagnose the bug family and fix it, then re-run all three.

What success looks like: A completed three-run table; a reliable robot matches the expected result on all three runs.

Check for:
  • The same test case is used all three runs
  • Expected result written once
  • Three actual results and Match? recorded
  • Any mismatch is investigated

Safety: Keep the test area clear and stay clear of moving parts. Reset the robot to the same start line each run.

If it doesn't work

Results drift over the three runs
- Check batteries and the start position - a fading battery is a mechanical/power cause of unreliability.
It matches twice then fails
- The failing run is your clue - inspect the sensor reading and the physical setup right after that run.

Go further: Add a fourth and fifth run and see whether reliability holds as the battery drains.

Obstacle counter

Robot kit

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.

Count avoided obstacles on the kit robot

You need: A reacting robot from Week 5, A short obstacle course, Pencil and paper

Steps

  1. 1Set a variable called 'obstacles' to 0 at the start of the program.
  2. 2Keep a loop that reads the sensor; inside the 'if obstacle' branch, turn to avoid AND add 1 to 'obstacles'.
  3. 3Run the course, then display or read the final counter value.
  4. 4Compare the counter to how many obstacles you actually placed.

What success looks like: The counter's final value equals the number of obstacles the robot actually avoided.

Check for:
  • The counter starts at 0
  • It adds 1 only when an obstacle is avoided
  • The final stored value is read
  • It's compared to the real count

Safety: Keep the course clear of hands and feet while the robot drives.

If it doesn't work

The counter is too high
- 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 0
- Check that the add-1 step is inside the 'if obstacle' branch, not outside it - a programming bug.

Go further: Add a rule: after the counter reaches 3, the robot stops and signals it's done.

Program the robot

Build a program from blocks, then run it on the simulator. On the kit path, use the same steps in your robot's app; unplugged, act the blocks out on a floor grid. Your program saves on this device.

Obstacle counter program

A program that sets a counter to 0, loops to read the sensor, and adds 1 to the counter each time it avoids an obstacle.

Ready

Add a block

Events & execution

Movement

Control

Data

Output

Variables & counters

count

Your program

  • Reset counter
  • Move
Column 1, row 1Column 2, row 1 — red markerred marker at column 2, row 1Column 3, row 1Column 4, row 1 — red markerred marker at column 4, row 1Column 5, row 1Column 6, row 1 — red markerred marker at column 6, row 1Goal zone at column 6, row 1Robot at column 1, row 1
  • Robot (arrow points where it faces)
  • Goal zone (dashed outline)
  • Coloured marker (dot)

Map: A 6 by 1 grid. The robot starts at column 1, row 1, facing right. The goal zone is at column 6, row 1. There are 3 coloured markers.

Ready.

Ready to run. · 0 steps

Robot state

Column
1
Row
1
Facing
right
Distance ahead
5 cells
Touch
clear
On a line
no
Light
80
In goal zone
no
Collisions
0
Steps
0

Robot at column 1, row 1, facing right. Distance ahead: 5 cells. Touch: clear. Over a line: no. Light: 80. Not in the goal zone.

Log output

Nothing logged yet.

  • Heads up: This program has no safe stop behavior. Add a safe stop so the robot stops when it is done or blocked.

Fix the broken stopper

This program is supposed to stop the robot in the square right before the wall, but a wrong value in its distance check makes it stop in the wrong place. Predict the bug family, change the one value in the repeat-until condition, and re-run until it stops correctly.

Ready

Add a block

Events & execution

Movement

Control

Data

Output

Variables & counters

None yet.

Your program

  • Repeat until
    • Move
  • Mission complete
Column 1, row 1Column 2, row 1Column 3, row 1Column 4, row 1Column 5, row 1 — wallGoal zone at column 4, row 1Robot at column 1, row 1
  • Robot (arrow points where it faces)
  • Goal zone (dashed outline)
  • Wall (grey, X mark)

Map: A 5 by 1 grid. The robot starts at column 1, row 1, facing right. The goal zone is at column 4, row 1. There is 1 wall.

Ready.

Ready to run. · 0 steps

Robot state

Column
1
Row
1
Facing
right
Distance ahead
3 cells
Touch
clear
On a line
no
Light
80
In goal zone
no
Collisions
0
Steps
0

Robot at column 1, row 1, facing right. Distance ahead: 3 cells. Touch: clear. Over a line: no. Light: 80. Not in the goal zone.

Log output

Nothing logged yet.

Predict

Commit to a guess before you test - then see how close you were. Your predictions save automatically.

How to check: Run all three, record actual vs expected and Match?, and compare your prediction to what really happened.

How to check: Investigate the likely causes and see whether the family you predicted was the one that fixed it.

How to check: Run the course, read the counter, and compare it to your predicted number and the real obstacle count.

Test & improve

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.

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

RunExpected resultActual resultMatch? (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.

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

SymptomSuspected familyOne change triedFixed? (Y/N)

Debugging missions

Each robot below misbehaves on purpose. Work out whether the bug is mechanical, in the program, or with a sensor - then check the fix.

The robot that spins in place

A robot that should roll straight forward instead spins on the spot, turning around and around as if one wheel drives forward while the other drives backward.

Symptom: Both motors run, but the robot rotates instead of moving forward - it spins the same way every run.

Hint: Watch the wheels: both are turning, but in opposite directions, and nothing is loose. Think about how one motor is wired or set, not about the driving commands.

Show the fix

Fix: Swap the reversed motor's connection (or flip that one motor's direction setting) so both wheels drive forward together. Re-run and confirm the robot now goes straight instead of spinning.

Likely causes

  1. 1One motor is plugged in backwards, so its wheel spins the wrong way.
  2. 2One motor's direction setting is reversed compared to the other.
  3. 3The two motors are mounted mirror-image but driven as if they face the same way.

The wall it won't stop for

A robot should drive forward and stop when its distance sensor says the wall is close, but it rolls right into the wall and keeps pushing without ever stopping.

Symptom: Every run, the robot never stops - the actual result is a crash - even though a stop instruction is in the program.

Hint: The sensor reads fine and the stop block is there. Read the comparison in the loop out loud: as the wall gets closer, does the condition that should stop the robot ever actually become true?

Show the fix

Fix: Reverse the comparison operator (or swap its two sides) so the stop condition becomes true when the distance gets small. Re-run and confirm the robot stops before the wall.

Likely causes

  1. 1The comparison is reversed - it stops when distance is 'greater than' instead of 'less than', so it is never true as the robot approaches.
  2. 2The two sides of the comparison are swapped.
  3. 3The wrong operator (> where < was meant) keeps the stop condition from ever triggering.

The counter that counts too much

A robot drives past three markers and should report a count of 3, but it reports a huge number like 47.

Symptom: The counter's final value is far larger than the number of real objects - it grows every loop instead of once per object.

Hint: Watch the counter tick up as it drives. Is it adding 1 once per object, or once on every trip through the loop even when there is no new object in front of it?

Show the fix

Fix: Reset the counter to 0 at the start, and move the 'add 1' inside the condition that detects a NEW object. Re-run and confirm the final count matches the real number of objects.

Likely causes

  1. 1The 'add 1' is outside the 'do I see an object?' check, so it counts every loop.
  2. 2The counter is never reset to 0 at the start of the run.
  3. 3The robot sits next to the same object for several loops and counts it each time.

The line follower that fails in the light

A line-following robot worked perfectly yesterday. Today, in a much brighter room, it drives straight off the line every time - and the program has not changed.

Symptom: The robot ignores the line and does not steer, even though the same code steered correctly under yesterday's lighting.

Hint: The code is identical to yesterday's; what changed is the room. Read the live light value on the line and off the line today, and compare both to the threshold in the program.

Show the fix

Fix: Read today's light values on and off the line, pick a new threshold halfway between them, store that calibration value, and re-run. The robot should follow the line again.

Likely causes

  1. 1The light threshold was calibrated for yesterday's darker room and is now wrong.
  2. 2Brighter light raised all the readings above the threshold, so 'on the line' never registers.
  3. 3The sensor was not re-calibrated for today's lighting conditions.

The robot that never finishes

A robot should drive forward, avoid a few obstacles, and then stop at the goal - but it keeps driving and avoiding forever and never finishes, even after it reaches the goal.

Symptom: The robot never ends its program - it repeats its avoid-and-drive behavior endlessly with no stop.

Hint: The avoiding itself works. The problem is that the robot never leaves the loop. Look for a way out: is there any condition that ends the loop once the goal is reached?

Show the fix

Fix: Add an exit - a repeat-until that ends at the goal, or an 'if at goal then stop' - so the loop can finish. Re-run and confirm the robot stops once it reaches the goal.

Likely causes

  1. 1The behavior is inside a forever loop with no exit.
  2. 2A repeat-until has a condition that can never become true.
  3. 3There is no 'safe stop' or 'mission complete' when the goal is reached.

The good code that still drifts

A robot's program is correct and unchanged - it drove straight last week - but now it curves to one side every time it moves forward, even on a short, obstacle-free path.

Symptom: Instead of driving straight, the robot drifts to one side the same way every run, though the code has not changed.

Hint: It fails the same way every run, but the program is proven correct from last week. Look at the robot's body and wheels, or the simulated surface and setup, before you touch the code.

Show the fix

Fix: Leave the code alone. Re-seat and tighten both wheels, clear any dragging wire or debris (or reset the simulated surface/alignment). Re-run and confirm it drives straight again.

Likely causes

  1. 1A wheel or axle is loose or not fully seated.
  2. 2A wire or part drags on the floor on one side, or a wheel rubs the frame.
  3. 3In the simulator, a surface or alignment setting makes one side slip.

The stop that comes too late

A robot uses its distance sensor to stop before a wall. At a slow speed it stops perfectly, but when it is sped up it overshoots and bumps the wall - with the exact same threshold.

Symptom: At high speed the robot stops too late and hits the wall; at low speed the very same program stops in time.

Hint: The threshold that works when slow is not enough when fast - the robot travels further between sensor checks. Think about how the speed and the stopping threshold work together, and change only one of them at a time.

Show the fix

Fix: Change one thing at a time: either lower the driving speed or raise the distance threshold so it stops sooner. Re-run at the target speed and confirm it stops in time.

Likely causes

  1. 1At high speed the robot covers more distance between readings, so a close threshold triggers too late.
  2. 2The threshold was tuned for a slower speed than the robot is now using.
  3. 3The sensor is read too rarely to catch the wall in time at speed.

Knowledge check

Answer these to check that you can debug bugs by family and prove a robot is reliable.

  1. 1. 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.

  2. 2. What is debugging?

  3. 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?

  4. 4. What is a counter?

  5. 5. In a reliability trial, what is the 'expected result'?

  6. 6. Why do you run the same task three times in a reliability trial?

0 of 6 answered

Reflect

Your reflections save automatically.

Coming up next week

Next week we put reliability to work: planning a full autonomous mission the robot runs safely on its own.

  • Keep your three-run test record and Bug Detective sheet - reliable behavior is the foundation for next week's mission.
  • Think about a job your robot could do start-to-finish without anyone steering it.
  • Charge your kit, bookmark the simulator, or gather your cardboard robot and course.

Finish Week 6

Complete these to mark the week done and unlock the next one:

  • Diagnose and fix at least one bug from each family, recording the symptom and fix (not done yet)
  • Complete a three-run reliability trial with expected vs actual recorded (not done yet)
  • Use a counter variable to track obstacles avoided (not done yet)
  • Score at least 4 of 5 on the knowledge check (not done yet)
  • Write your reflection (not done yet)