One-sentence summary
Remote control means a robot catches a command sent by a controller and turns it into movement; the robot hears the command, decides what to do, and drives its motors.
Why it matters
If you steer a car with a garage remote, fly a drone from the ground, or drive a toy robot from your phone, you are using a remote control system. The robot is not tied to you with a cable; the command travels across the gap as an invisible signal.
In earlier lessons we learned the robot's sense–decide–act loop. Now we add a new kind of "sense": the robot listens not only to its own sensors but also to the command you send. A "go forward" command triggers a decision, just like a distance-sensor reading. By the end of this lesson you will understand how a system that sends a robot forward at the press of a button thinks.
The three parts of remote control
Every remote control system has three parts. Their names may sound intimidating, but the idea is simple.
- Transmitter: The side that sends the command. It can be a handheld remote, a micro:bit, or a phone.
- Receiver: The side that catches the command. It is the module on the robot.
- Processor (controller): The brain that decides based on the command and drives the motors. In our examples this is an Arduino or a micro:bit.
Everyday example: talking on walkie-talkies
Picture two people using walkie-talkies. One speaks (transmitter), the other listens (receiver). They must be on the same channel; on different channels they cannot hear each other. Remote control is the same: transmitter and receiver must share the same "language" and setting.
Everyday example: a TV remote
When you press a button on a TV remote, you cannot even see a light, yet the TV receives the command. The remote sends a small code using invisible infrared light, and the receiver reads it. "Volume up" is one number, "change channel" is another. In a robot, too, each command is really just a small number or letter.
Ways to send a command
There are several ways to carry a command through the air. Let us compare three of them conceptually.
Infrared (IR) remote
This is the method TV remotes use. It is cheap and easy, but it has two conditions: the remote and the receiver must see each other (no wall in between) and the range is short (a few metres). If you want the robot to turn a corner, the signal gets blocked by the obstacle.
Radio (micro:bit and similar)
Radio waves can pass behind walls and reach farther, with no line of sight needed. A micro:bit has a built-in radio; you can make one micro:bit the controller and another the robot's brain, and send messages between them. The two devices must use the same group number, the same idea as the same channel on a walkie-talkie.
Bluetooth
This connects a phone or tablet to the robot. Its range is similar to radio, but the two devices must first recognise each other, that is, they must pair. When you press a button in a phone app, a command goes to the robot. Setup takes longer, but the interface can be rich.
In short: infrared is simple but needs a line of sight; radio and Bluetooth work behind walls and reach farther.
Turning a command into movement
What does the robot do once it receives a command? This is the heart of the lesson. A command is an input; the robot looks at that input and decides on a movement. Let us write the logic first as pseudocode:
Start
Repeat forever:
Read the incoming command
If the command is "forward"
drive both motors forward
Else if the command is "stop"
stop both motors
Else
do nothing (keep the last command)Notice this is the same condition structure from the algorithms lesson. The robot compares each command with an "if." If an unknown command arrives, the safest behaviour is usually to stop or to keep the last known command.
From micro:bit to Arduino: shrinking a command to one letter
The easiest way to send between two micro:bits over radio is to send the command as a single letter. When the controller's A button is pressed, it sends "F" (forward); when B is pressed, it sends "S" (stop). The robot's micro:bit receives the letter and passes it to the Arduino, which works with this logic:
char command = receivedLetter(); // letter from radio/serial port
if (command == 'F') { // forward
digitalWrite(leftMotor, HIGH);
digitalWrite(rightMotor, HIGH);
}
else if (command == 'S') { // stop
digitalWrite(leftMotor, LOW);
digitalWrite(rightMotor, LOW);
}The line command == 'F' asks "is the incoming letter F?"; if so, it runs both motors. The motors are not powered straight from the Arduino pin but through a motor driver, because motors draw more current than a pin can supply. The driver takes the low-power signal and turns the motor using a separate battery pack.
Why a separate battery and common ground?
The rule we learned in the robot-arm lesson applies here too. Motors use a separate battery pack; the negative terminals (GND) of the Arduino and the battery pack are connected to each other. This is called common ground. Without common ground, the signal and the power do not share the same reference, and the system will not work properly.
Latency and range
In remote control there are two facts to keep in mind: how fast does the signal arrive, and how far does it reach?
- Latency: There is a small delay between pressing the button and the robot reacting. It is usually very short, but it grows when the signal is weak. A robot that receives "stop" a second late can hit a wall in that time. That is why a safe speed matters on fast robots.
- Range: As the distance between transmitter and receiver grows, the signal weakens. Beyond the range limit, the robot receives no command at all. Some systems stop the robot if no command arrives for a set time; this is called a safe stop.
Walls, interference from other devices, and battery level also affect range. A good design plans in advance for what the robot should do when the command is lost.
Hands-on mini task
You can do this even without a real robot; the goal is to build the command-to-movement logic.
- On a sheet of paper write four commands:
F(forward),B(back),L(turn left),S(stop). - Make a friend the "robot." You are the transmitter, they are the receiver.
- Give commands by saying only the letter; your friend takes one step or turns for each letter.
- Now add a "latency": after you say the letter, your friend waits two seconds before moving. Walking toward an obstacle, you will see how dangerous this is.
- Add a "range" rule: once you move to the far side of the room, whisper the command. For commands they cannot hear, your friend should stop (safe stop).
Tip: When your friend hears a letter they do not recognise, they should stop, not move. In a real robot, this is also the safest reaction to an unknown command.
Common mistakes
Leaving the transmitter and receiver on different settings
If the group number on micro:bits or the pairing on Bluetooth is different, the command never arrives. Make sure both sides use the same channel/group.
Expecting infrared to work behind a wall
Infrared needs a line of sight. If the remote and receiver cannot see each other, the command does not go through. Use radio or Bluetooth for behind a wall.
Skipping the "what if there is no command?" question
If the robot keeps running the last command forever when the signal drops, it can drive into a wall. Add a rule to stop if no command arrives for a set time.
Trying to drive motors straight from the Arduino
Motors draw more current than an Arduino pin can supply. Put a motor driver in between, power the motors from a separate battery pack, and connect the common ground.
Ignoring latency
On a fast robot even a small delay can cause a crash. Test at low speed first and observe the reaction time.
Safety note
A remotely controlled robot moves metres away from you; that is a reason to raise your attention, not lower it. The robot can move suddenly on an unexpected command.
- Before running the robot, clear the test area; move away breakable objects and feet.
- Keep your fingers, hair, and cables away from the wheels and gears.
- Run at low speed on the first try and watch the reaction time.
- Use a separate, low-voltage battery pack and a motor driver; connect the common ground. Never use mains electricity (the wall socket).
- Make sure the robot stops when the command is lost; if you lose control, cut the power (disconnect the battery).
- Get help from an adult when working with motors, batteries, and tools.
Lesson summary
- Remote control has three parts: the transmitter that sends the command, the receiver that catches it, and the processor that decides.
- The ways to carry a command differ: infrared is simple but needs a line of sight; radio and Bluetooth work behind walls and reach farther.
- An incoming command is an input to the robot; the robot compares it with a condition and turns it into movement.
- Every system has latency and range; when the command is lost, the robot should stop safely.
- Motors are driven with a motor driver and a separate battery pack, sharing a common ground with the Arduino.
Check questions
- What are the three basic parts of a remote control system?
- What are two disadvantages of an infrared remote compared with radio?
- Which setting must be the same for two micro:bits to communicate over radio?
- What is usually the safest behaviour when a robot receives an unknown command?
- What do "range" and "latency" mean, and what should the robot do when the command is lost?
Answers
- The transmitter that sends the command, the receiver that catches it, and the processor (controller) that drives the motors based on the command.
- Infrared requires the remote and receiver to see each other (it does not pass behind walls) and has a short range (a few metres).
- Both micro:bits must use the same group number, which is the same idea as the same channel on a walkie-talkie.
- Usually to stop or to keep the last known safe command; the robot should not move randomly on a command it does not recognise.
- Range is the farthest distance at which the transmitter and receiver can communicate; latency is the short delay between pressing the button and the robot reacting. When the command is lost, the robot should stop safely (safe stop).
Source and verification note
For “Remote Control”, verification focuses on whether the relationship between The three parts of remote control and Everyday example: a TV remote remains consistent across examples. Robot behaviour cannot be explained by code alone; mechanical structure, power system, sensor placement and surface conditions must be evaluated together. Test results should be recorded over several runs on the same course.
Next lesson
Autonomous and Semi-Autonomous Systems: How a robot makes some decisions on its own, using its own sensors, without asking you.