A screen program can be perfectly logical and still produce the wrong visible result. A robot adds another layer: the code may be correct, but a sensor may vary, a wheel may slip, or a connection may fail. That makes robotics difficult. It also makes the problem-solving unusually concrete.
The goal must become testable
'Patrol the room' is not yet a program. Students must define a route, a starting state, what counts as an obstacle, which response is allowed, and when the patrol should stop. Vague intention becomes a collection of testable systems.
This decomposition is real engineering work at an accessible scale. The student learns to ask what information is missing before adding code.
Several kinds of failure can look the same
If an LED stays dark, the cause may be output code, state logic, a pin choice, component direction, connection, or power. If a simulated patrol turns forever, the cause may be a sensor condition, recovery state, or loop exit.
Students need a test order. Can the output work alone? Can the input be read? Is the current state visible? Does the complete rule connect them? The sequence prevents random replacement of parts and code.
Reality creates feedback
A robot that turns too little provides evidence. Students can measure the result, compare it with the target, change one value, and test again. The physical world makes assumptions visible because it refuses to behave like a perfect diagram.
Feedback also teaches humility. A system may work on one floor and fail on another. A threshold may work in one lighting condition and fail near a window. The correct response is not to overstate success but to describe the operating limits.
The demonstration completes the cycle
A finished robot project should be demonstrated under a known test. The student states the goal, shows the input, explains the decision, observes the output, and discusses one limitation or bug.
That explanation distinguishes building from assembling. The educational value does not depend on the machine looking advanced. A simple button-buzzer system understood deeply can teach more than an impressive kit whose behaviour remains opaque.
Failure crosses system boundaries
In a screen-only project, the visible result usually comes from code and stored state. A robot or circuit adds power, connections, components, measurement, timing, physical dimensions, and the environment. The same symptom can have several causes. A patrol that misses an obstacle may read the wrong sensor, use a poor threshold, move too quickly, or point the sensor in the wrong direction.
Students learn to divide the system before repairing it. Can the sensor value be displayed without movement? Can the motor output be tested without the sensor rule? Does the simulated decision work with known sample values? Each test isolates a relationship. This is real problem-solving because the student cannot rely on one category of answer; the evidence determines whether to inspect logic, hardware, measurement, or assumptions about the world.
A demonstration should include the boundary between layers. The student might show that the decision works with known values but the sensor varies near the threshold, or that the circuit works while the timing rule is wrong. Locating the boundary is often the most sophisticated part of the project.