How Sensors and Microcontrollers Work
Every automated device — from a traffic signal to a robot car — follows the same basic pattern: sense the environment, decide what to do, act. This guide explains the components involved and the mistakes that most often stop a first circuit from working.
Related area: Electronics and Embedded SystemsThe pattern behind every embedded system
Embedded systems are electronics that sense, decide and act without a general-purpose computer and screen. A microwave, a traffic signal head, an automatic door and a line-following robot all share the same three-part structure:
- Sensing: an input component measures something in the environment — a button pressed, light level, distance to an object.
- Deciding: a small processor reads the inputs and determines what should happen next, following a program.
- Acting: an output component does something visible — an LED lights, a buzzer sounds, a motor turns.
Understanding this pattern makes new projects less mysterious: when something does not work, you can ask which of the three parts is failing.
What a microcontroller actually is
A microcontroller is a complete small computer on a single chip: a processor, a little memory, and a set of connection pins that can either read electricity (inputs) or supply it (outputs). Boards such as Arduino and ESP32 packages put that chip onto a board with a USB connection and easy-to-use pins, which is why they dominate education.
The pins are the interface. A digital input pin answers a simple question: is voltage present or not? An analog input pin can measure a range of values — useful for sensors of light, temperature or distance. An output pin can be switched on and off by the program, fast enough to dim an LED or control a servo.
Your first program: button controls LED
The classic first build is one button and one LED. Wiring: connect one side of the button to 5V, the other side both to digital pin 2 and, through a 10kΩ resistor, to ground. The LED goes from digital pin 13 (the built-in LED on many boards, no extra wiring needed) through its current-limiting resistor to ground.
The program is a direct translation of the sense–decide–act pattern:
const int buttonPin = 2; // button connected to digital pin 2
const int ledPin = 13; // built-in LED on most boards
void setup() {
pinMode(buttonPin, INPUT); // read the button
pinMode(ledPin, OUTPUT); // drive the LED
}
void loop() {
int state = digitalRead(buttonPin);
if (state == HIGH) {
digitalWrite(ledPin, HIGH); // button pressed: LED on
} else {
digitalWrite(ledPin, LOW); // button released: LED off
}
}Read the button, decide based on its state, drive the LED. When this works, the same structure scales: replace the button with a light sensor and the LED with a buzzer, and you have built a darkness alarm without changing the shape of the program at all.
When it does not work: a troubleshooting checklist
Most first circuits fail for a handful of well-known reasons. Work through them in order before changing your code:
- The board does nothing at all: check the USB cable and port first. Some cables are charge-only and carry no data — try a different cable before debugging anything else.
- The LED never turns on: LED polarity matters. The longer leg (or the leg near the notch on the package) is the positive side. A reversed LED will not light and is not damaged by it.
- The button behaves erratically or reads both states randomly: a button pin that is not connected to anything is said to be floating — it picks up electrical noise. Wire the button so it connects the pin to 5V, with a pull-down resistor to ground (or use the board's internal pull-up by wiring the button to ground and using INPUT_PULLUP in code).
- The sensor readings jump around for no visible reason: check that the breadboard power rails and ground rails are actually connected across the board, and that every module shares a common ground with the microcontroller.
- None of the wiring seems to matter: confirm the code was uploaded to the board you are actually using, and select the correct board and port in the upload tool before uploading.
- A motor or buzzer behaves strangely or resets the board: motors draw much more current than a microcontroller pin can supply, and their electrical noise can reset the board. Drive motors through a separate driver module, and power them from an appropriate supply, not from the board's own 5V pin.
Care and safety at the bench
- Never connect power to a circuit while also connecting a motor's power wires backwards — double-check polarity before powering up.
- A short circuit (power touching ground directly through metal) can damage a board quickly. Check for stray wire legs under breadboards before switching on.
- Unplug USB before rearranging power wiring. Most beginner damage happens during live rewiring, not during operation.
Where this leads
These fundamentals are the foundation of robotics: a robot is, at heart, a microcontroller-based system that senses, decides and acts — with motors added. Learners who understand floating pins, common ground and polarity move into robotics projects with far fewer frustrating hours at the workbench.
In Xonovate Code Champions programs, electronics is taught through construction and experimentation: building circuits, programming microcontrollers and troubleshooting real hardware behaviour, scaled to the learners and equipment available.
More Practical Guides
Computational Thinking in Practice
Understand the four pillars of computational thinking and apply them to a worked example, step by step.
Read the guideHow to Start a School Robotics Club
Plan a robotics club that starts small, runs sustainable sessions and produces demonstrable outcomes within a term.
Read the guideLearn this with us directly
These guides reflect how we teach in schools, clubs and workshops. If you want structured, facilitated learning, let's talk.
Discuss a Program