Did you know that a classroom robot can be behaving perfectly according to its program and still do the wrong thing? Imagine a robot that should stop when a button is pressed. It stops even when no one touches the button. Pressing the button harder will not fix the reasoning problem. We need to find out whether the input, the logic or the physical mechanism is responsible.
A stuck-on input is a condition in which a controller keeps reporting an active state, such as ‘pressed = true’, even during times when the intended physical input is inactive. The immediate educational solution is to test the state separately from the robot’s action: observe the input with no press, with a deliberate press and after release. Then distinguish an input held in the active state from an event that should occur only when a press is detected. Diagnose before changing hardware or code.
Separate three questions before touching the robot
First, what state does the program read? Second, when should the program act? Third, what does the button or switch physically do? If these are mixed together, students may blame a motor for a button fault, a wire for a faulty condition or a sensor for a counter that increments repeatedly.
A simple controller such as the BBC micro:bit gives us a clear teaching example. The current official MakeCode documentation for Button Is Pressed describes a boolean value: true while the chosen button is being pressed and false otherwise. Its On Button Pressed documentation describes an event handler for a press action. These are different ways to use input. The example below uses the micro:bit buttons as a safe learning model; a separate physical push switch on a robot may need its own wiring and sensor guidance.
State and event are not synonyms
A state check asks: ‘Is the button pressed right now?’ If a program checks this question ten times while the button is held, the answer can be true ten times. That does not mean the button was pressed ten separate times.
An event handler asks a different question: ‘Did the specified press event happen?’ It is suitable for actions such as counting a click or starting a sequence once per recognised event. Exactly which press/release sequence the software recognises depends on the platform and API. For the MakeCode micro:bit button event, consult the official definition rather than assuming every external switch behaves identically.
This distinction is useful far beyond robots: login buttons, door sensors, game controllers and accessibility switches all need a clear separation between their physical state and the action a program should take.
A four-stage diagnostic that children can actually run
- Make the system safe: use a low-voltage teaching device, stop moving parts and obtain the instructor’s permission before testing; disconnect powered mechanisms if required by the kit instructions.
- Display the raw state: temporarily show 0 for released and 1 for pressed. Do not let the display value depend on the robot’s motor output.
- Run a deliberate sequence: observe released, press briefly, release again and repeat. Record both the intended state and what the controller reports.
- Only then isolate the cause: check program conditions, input selection, simulator versus hardware and any permitted connections. Change one thing at a time and repeat the same sequence.
For a micro:bit lesson, the state test can conceptually be written as: ‘If button A is currently pressed, show 1; otherwise, show 0.’ The official MakeCode page demonstrates this kind of condition. The important feature is an else branch. Without it, a lingering 1 on the display might merely be an old picture, not a current reading.
Worked example: twelve checks and a falsely high count
All figures here are invented for learning. A pupil checks a classroom robot’s button state 12 times at equally spaced moments. The planned physical sequence includes eight checks while the button is released and four while it is deliberately held. The expected log therefore has eight zeros and four ones. This is a state-sampling exercise, not a claim about a real robot.
The observed log shows twelve ones. The count of unexpected active states is 12 − 4 = 8. The proportion of checks showing an unexpected active state is 8/12 × 100% = 66.7% to one decimal place. That percentage describes the sampled checks, not the probability of a future sensor failure or the number of distinct button presses.
A mistaken student writes ’12 button clicks’. But the program measured a state twelve times; it did not establish that twelve press events occurred. Another student might claim ‘the switch is definitely damaged’. That is also premature. The wrong input pin, a constantly true condition, an inverted switch configuration, an old display state or a wiring fault can make the observation misleading. Each requires a different test.
Assume the program is then changed so it clearly displays 0 when released and 1 when held. On the same twelve-check sequence, it now reports eight zeros and four ones. The count matches the designed input sequence. This supports the conclusion that the state-read path behaves as expected in that test. It still does not prove that motors, event handlers or every other program state are correct.
A minimal truth table makes the fault visible
Draw two columns labelled button released and button held. For a normally inactive press-to-activate button, the expected raw state is false / true. If the program reports true / true, investigate the read path or physical switch. If it reports false / false, investigate missing press detection. If it reports true / false, inspect whether the logic is intentionally inverted or the switch type differs. Do not declare a fault until the intended electrical or API semantics are known.
This is why a flowchart with explicit AND and OR branches can help. It reveals whether two inputs must both be active, whether either one is enough, and whether an untested default path accidentally triggers the action.
What if the code is correct but the input remains wrong?
Look first at observable, reversible causes. Is the student testing the software simulator, which expects an on-screen click, or the real hardware button? Is the code reading button A while the pupil presses B? Is a physical attachment holding the button down? If the kit uses an external switch, has the teacher confirmed its approved wiring diagram and whether it is normally open or normally closed?
When using an external sensor, its ‘active’ level may be high or low depending on the device. Do not force every switch to match the micro:bit’s built-in button behaviour. A student who learns to read the manufacturer’s truth table gains a transferable engineering skill rather than another memorised workaround.
Avoid repeatedly unplugging and reconnecting a powered circuit to chase a symptom. A classroom teacher or qualified supervisor should handle damaged wiring, unexpected heat, battery damage and any equipment outside the educational kit’s safe operating instructions.
Progressive practice: from display to decision
Guided: identify state versus event
The learner holds a button for three seconds. A loop samples the state once each second and sees true on three checks. How many separate press events are proven? Not three. The observations show the button was held active for those three sampling moments. Without a separate event record, they do not establish distinct clicks.
Supported: choose a sensible condition
A robot should turn its indicator on only when both the button is pressed and the robot has been put into test mode. The condition is ‘button active AND test mode active’. Draw a four-row truth table: false/false, false/true, true/false and true/true. Only the last row should activate the indicator. A student should also test every row, not just the expected successful case.
Independent: debug a new faulty scenario
A student program has two buttons. Its screen shows 1 continuously even though neither button is pressed. Give the class a clear state table, a simulator and a supervised hardware board. Ask learners to make a hypothesis, design a reversible test, predict the output and record what actually happens. They earn credit for isolating the correct layer—display, input, program or hardware—not for guessing which component to replace.
What progress should a teacher watch for?
Early learners often jump straight to swapping wires or adding delays. Stronger learners first reproduce the failure and describe it precisely: ‘The input display remains 1 after release on all three trials.’ They then distinguish an observation from a hypothesis and verify one change at a time.
A useful assessment is to present a new fault with a different button or a different small controller. A student who can still construct a truth table, identify the measured state, write a targeted test and explain the next diagnostic step has learned a general method. Reproducing one memorised block arrangement on the same board is not the same as independent debugging.
Parents can encourage this without requiring special tools. Ask a child: ‘What should the button show when nobody touches it? What did it actually show? What single test could separate a display mistake from an input mistake?’ Keep the discussion calm and curious. The aim is understanding how systems work, not assigning blame to the pupil.
Limitations: one sample of a working state is not a full safety test
A robot that passes a button-input test may still have unsafe mechanical motion, power problems or inadequate stop controls. A classroom demonstration is not a certification for a real-world machine. Use only approved educational equipment with supervision. Never use a software button experiment as a substitute for safety systems or emergency-stop hardware.
Also, a button state checked slowly can miss brief presses, while software event handlers may have their own timing rules. For more advanced students, this motivates discussion of sampling frequency, debounce, state machines and logging. Those ideas should be introduced after the fundamental pressed/not-pressed distinction is stable.
Frequently asked questions
Does a screen showing 1 prove the switch is pressed?
No. It proves only that this particular display shows 1. The code might be showing an old value, an inverted value or a variable unrelated to the physical button. Inspect how the display value was produced.
Why does a counter rise rapidly while I hold the button?
If the counter increments every time a loop reads ‘pressed’, holding the button can produce many increments. Use an appropriate event or detect the transition from released to pressed, with attention to the particular device’s behaviour.
Is a normally closed switch broken because it reads active before pressing?
Not necessarily. A normally closed switch has different contact behaviour from a normally open switch. Confirm the approved hardware specification and interpret the input polarity accordingly; this is a distinct question from whether the code should act on a state or an event.
Is robotics only for advanced programmers?
No. A truth table, prediction and carefully recorded test are accessible starting points. See the site’s Mobile Robotics pathway explainer for broader educational context.
The real lesson is diagnostic thinking
When a system behaves strangely, pupils can learn to say: ‘I know what I expected, I know what I observed and I have a test that separates possible causes.’ That sentence is more valuable than a lucky code edit. It works in mathematics, science, computing and everyday problem solving.
Explore the eduKate Education Hub, the Core Aim of Education collection and the Clementi explanation-first practice reference for further diagnosis and structured learning.