When a robot does nothing, it is tempting to replace the program immediately. Instead, separate the system into layers. Power, communication, the selected program, sensor readings, and mechanical movement can each fail independently. Changing one layer at a time makes the result useful.
1. Write down the mismatch
Describe the expected behavior in one sentence and the observed behavior in another. “It is broken” provides little direction. “The display updates, but the left wheel does not turn” narrows the investigation. Note the last version that worked and what changed after it.
2. Check power and physical connections
Follow the manufacturer’s instructions for charging, power switches, and connections. Turn power off before adjusting cables where required by the maker. Inspect for loose connections or obstructions without forcing parts. Stop using damaged or unusually hot batteries and follow the supplier’s guidance rather than improvising a repair.
3. Confirm communication separately
A device can have power without being connected to the editor. Confirm the selected device, connection method, and any required permissions in the official setup guide. A cable that charges a device is not necessarily able to transfer data. Try a known suitable cable if the maker specifies a data connection.
4. Run the smallest known working program
Use a simple supported output, such as a display message, to verify that the intended program is running. If it fails, return to connection and setup. If it works, add only the next behavior you need. Keep saved copies with meaningful names so you can return to a reliable baseline.
5. Inspect the input before the decision
If obstacle detection behaves strangely, display the sensor reading while the robot is stationary. Move an object gradually and look for a sensible change. If the input is wrong, adjusting the movement code will not fix the underlying issue. Check units, sensor selection, and mounting against the device documentation.
6. Test the condition at its boundary
A rule using “less than 20” behaves differently at exactly 20 than one using “less than or equal to 20.” Use clearly separated readings first, such as 10 and 40. Then investigate the boundary. Real measurements can fluctuate, so do not assume a value stays perfectly constant.
Keep a fault notebook
Record what you tested, what changed, and what stayed the same. If you ask for help, include the robot model, editor, device type, minimal program, exact error, and observed behavior. Remove personal information before sharing screenshots publicly.
For device-specific support, use Makeblock’s help center or micro:bit support. For the underlying concept, read sense, decide, act.