TL;DR:
A microcontroller runs one program directly on the chip with predictable timing. It suits motor control and reading sensors.
A single-board computer runs a full operating system, which suits cameras, networking and heavy software but gives less predictable timing.
Many robots use both: the microcontroller for fast, exact tasks and the computer for vision and planning, linked by a serial connection.
You want a small robot that drives toward a coloured ball. It needs to read a distance sensor, spin two motors smoothly, and recognize the ball in a camera image. Should that be one board or two? The answer depends on what each job needs from the hardware.
What each one is
A microcontroller (MCU) is a small chip with a processor, memory and input and output pins in one package. Boards such as an Arduino Uno are built around one. You write a program, load it, and it starts running the moment power is applied, with no operating system in between.
A single-board computer (SBC), such as a Raspberry Pi, is a small full computer on one board. It runs an operating system such as Linux, has a large memory, connects to cameras, storage and networks, and runs many programs at once.
Real-time control versus an operating system
A motor controller often runs in a loop that repeats at a fixed rate, say 1 kHz, which means every 1 / 1000 = 1 ms. On a microcontroller the program owns the chip, so that timing is predictable down to microseconds. Hardware timers and interrupts help keep it exact.
On an SBC, the operating system shares the processor among many tasks. A control loop can be delayed by a background task, a file write or a network packet. The delay is usually small but unpredictable, called jitter. Special real-time settings reduce it, but a plain setup does not promise it.
Worked example: an Arduino reading a sensor and a Raspberry Pi running vision
Split the ball-chasing robot into two parts.
The Arduino reads the distance sensor and counts wheel encoder ticks. It runs a speed control loop at 1 kHz (every 1 ms) to keep each wheel at the commanded speed.
The Pi reads the camera at about 15 frames per second, finds the ball, and decides what speed and turn to ask for. At 15 frames per second, a new decision comes every
1000 / 15 ≈ 67 ms.The Pi sends a short message like
V 0.20 0.50(forward speed in m/s, turn rate) to the Arduino over a USB serial link.The Arduino receives it, updates its targets, and keeps its fast loop running. It sends back wheel speeds and the distance reading.
The two run at very different speeds, which is the point. The motor loop runs 67 / 1 ≈ 67 times for each camera decision, and it keeps the wheels steady in between. If the Pi is busy for 100 ms, the robot still holds its last command and does not lurch.
Check the serial link can carry the traffic. At 115200 baud, with 10 bits sent per byte (8 data bits plus start and stop bits), the link moves about 115200 / 10 = 11520 bytes per second. A 20-byte message every 20 ms is 20 × 50 = 1000 bytes per second, about 1000 / 11520 ≈ 0.087 of the capacity, so there is plenty of room.
Add a safety rule: if the Arduino does not receive a new command for, say, 200 ms, it stops the motors. That way, if the Pi crashes or the cable comes loose, the robot does not keep driving on its last command.
Power
An MCU board can run from a small supply and draws little power. An SBC draws more and is fussy: it needs a steady supply at the voltage and current in its documentation, and a dip when motors start can make it reset or corrupt its storage. It should also be shut down through the operating system, not just unplugged.
Motors cause electrical noise and big current spikes. Give them their own supply or a well-regulated stage, join the grounds so the signals share a reference, and keep power wiring away from sensor wiring.
Safety: Use only the supply and battery type the boards are designed for, fuse the motor battery, and never power a hobby robot from mains electricity directly. Do not leave LiPo packs charging unattended or use a swollen pack, and put the robot on blocks for its first motor tests.
When to use both
Use a microcontroller alone when the job is small and timing-critical: a line follower, a fan controller, a sensor logger. Use an SBC alone when you need a camera, a screen, a network or large software, and the timing needs are loose. Use both when you need heavy software and precise control, the pattern in the example above. Many larger robots follow the same split with several microcontrollers at the joints or wheels and one computer above them.
Where it goes wrong
Brownouts. Motor current dips reset the computer. Separate or buffer the supplies.
Voltage mismatch. Many SBC pins are 3.3 V and some MCU boards use 5 V. Connecting them directly can damage the 3.3 V pin.
Floating grounds. Boards on different supplies without a common ground give random serial errors.
Trusting loop timing on an SBC. Put the fast loop on the MCU.
Skipping the timeout. Without it, a lost link leaves the motors running.
How real robots use it
On bigger robots the computer often runs ROS and the microcontrollers act as drivers for motors and sensors, a split described in how ROS connects robot software. Next you will want to know how the microcontroller itself reads a signal, which is covered in reading a sensor with a microcontroller.
Try it yourself
With an Arduino-class board, blink an LED every 500 ms and also read a button. Then, on a computer, write a script that does the same by sleeping for 0.5 s. Add a heavy task to the computer, such as compressing a large file, and watch how the timing of the script wobbles while the microcontroller's does not.
Frequently asked questions
Can an SBC read sensors directly?
Yes, through its pins, and many people do. For timing-sensitive signals, a microcontroller is steadier because nothing else competes for the processor.
Do I need two boards for a first robot?
No. A microcontroller alone is enough for a driving, obstacle-avoiding robot. Add a computer when you want vision or networking.
Get started
