Computing · Year 2

Active learning ideas

Robot Debugging Challenges

Active debugging lets young programmers see commands become visible action, turning abstract errors into concrete fixes. When students plan, test, and revise in real time, they connect logical thinking to physical results, building lasting debugging habits.

• National Curriculum Attainment Targets
• KS1: Computing - Programming
• KS1: Computing - Debugging

• 25–40 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Plan-Do-Review
• 30 min · Pairs

Pair Route Retry

Pairs draw a simple maze route on grid paper, program their shared robot, and run it. They note where it deviates, discuss the error, revise two commands, and test again. Repeat until the goal is reached, then swap mazes with another pair.

Analyze the discrepancy between the planned route and the robot's actual movement.

Facilitation Tip

During Pair Route Retry, have partners alternate roles every two attempts so both students watch the robot and reflect on the commands.

What to look for

After a robot fails to reach its goal, ask students to point to the specific command in the sequence they believe caused the error and explain why. 'Which command do you think went wrong, and what should it have been instead?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 02

• Plan-Do-Review
• 35 min · Small Groups

Small Group Error Hunt

Provide small groups with pre-programmed robots that fail common tasks. Groups predict paths from code cards, test robots, identify one input mistake per member, and vote on a group fix before retesting.

Construct a revised set of commands to correct a robot's error.

Facilitation Tip

In Small Group Error Hunt, give each group one colored marker and a single mat so they must agree where the robot deviates before marking it.

What to look for

Provide students with a simple mat and a pre-programmed robot path that contains one error. Ask them to draw the robot's actual path and write one sentence explaining the mistake. Then, have them write the corrected command sequence.

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 03

• Plan-Do-Review
• 40 min · Whole Class

Whole Class Debug Relay

Divide class into teams. Each team sends one student to debug a robot at the front based on class observations, inputs a fix, and returns. Teams discuss discrepancies aloud before the next runner.

Differentiate between a planning mistake and a command input mistake.

Facilitation Tip

Use Whole Class Debug Relay to highlight that every fix is a small step, reminding students that debugging often involves multiple, manageable trials.

What to look for

In pairs, have students program a robot to reach a goal. One student runs the program while the other observes and notes any unexpected movements. The observer then explains to the programmer where the robot went off track and suggests a fix. 'I noticed the robot turned too early. Try changing the third command to move forward instead of turn left.'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

Activity 04

• Plan-Do-Review
• 25 min · Individual

Individual Debug Journal

Students work solo on personal robot mats, logging planned route, actual path sketch, error type, and fix. They test twice, reflecting on what changed success.

Analyze the discrepancy between the planned route and the robot's actual movement.

Facilitation Tip

Guide Individual Debug Journals by modeling how to circle the exact command that caused the problem and write the corrected version below.

What to look for

After a robot fails to reach its goal, ask students to point to the specific command in the sequence they believe caused the error and explain why. 'Which command do you think went wrong, and what should it have been instead?'

• Remember
• Apply
• Analyze
• Self-Management
• Decision-Making
• Self-Awareness

A few notes on teaching this unit

Start with a whole-class run-through of one command sequence, then freeze the robot after each move to ask students what to expect next. Avoid giving answers; instead, prompt students to compare the plan to the robot’s action after each trial. Research shows that young learners build debugging confidence when they see errors as data rather than failures, so celebrate partial successes and small fixes explicitly.

By the end of the sequence, students accurately predict how command sequences affect robot paths and systematically correct one error at a time. They articulate whether the issue came from planning, typing, or testing, and they persist until the goal is reached.

---

Watch Out for These Misconceptions

• During Pair Route Retry, watch for students who assume the robot is broken when it misses the goal. Redirect them to check their written plan against the actual path on the mat.

  Ask partners to trace the robot’s path with their finger on the mat while comparing it to the plan. They should circle the first point where the real path splits from the intended one and adjust that command.

• During Small Group Error Hunt, watch for students who blame button-pressing without checking the original plan. Redirect them to look at their code cards before retesting.

  Have each group lay out their code cards in order and read them aloud together. Then, they mark discrepancies on the mat before changing any inputs.

• During Whole Class Debug Relay, watch for students who expect the first fix to solve everything. Redirect them to focus on one small error at a time.

  After each relay round, ask the class to identify only the one command that changed and explain how that single change affected the final position.

---

Methods used in this brief

• Plan-Do-Review