Make a Bluetooth remote-controlled robot

TL;DR:

• A Bluetooth serial module acts like a wireless USB cable: your phone sends characters and your program reads them like any serial input.

• Use a tiny command format, such as one letter per direction, sent repeatedly while a button is held.

• The most important line is the timeout: if no command arrives for a short time, the motors stop.

A remote-controlled robot is satisfying quickly: you press a button and something moves. It is also the first project where a bug can drive away from you. A command that was meant to be a one-off ("go forward") should never mean "go forward forever" if your phone moves out of range. This build is about the commands, and about stopping safely.

What you will build

You will drive a two-wheel robot from a phone app that sends characters over Bluetooth. The robot understands five commands, and it stops if it stops hearing from the phone.

Parts and tools

• A two-wheel robot base, a microcontroller board and a motor driver

• A Bluetooth serial module, or a board that has Bluetooth built in

• A phone with a serial-terminal or controller app that can send characters

• Battery pack with a switch, jumper wires

• A cleared floor space

Wiring and assembly

The module has power, ground, a transmit pin (TX) and a receive pin (RX). The wiring rule for serial is crossing: the module's TX goes to the board's RX, and the module's RX goes to the board's TX. Make the grounds common. Check your module's sheet for its logic voltage, because some modules expect 3.3 V on their receive pin and a 5 V board can damage them.

Watch out: Switch the battery off before you rewire. Share one ground between the board, the motor driver and the Bluetooth module, or the commands will be garbled.

A command format a beginner can debug

Keep commands to a single character so every message is one byte and you can type them by hand in a terminal to test.

Serial over Bluetooth just delivers bytes in order. It does not promise how fast they arrive, so the program should treat each byte as "the latest wish of the driver" and not as a queue of orders to carry out one by one.

Worked example: a stop when the signal drops

Suppose the app sends the current command every 100 ms while a button is held. The program remembers the time of the last byte received and stops if more than 300 ms pass, the length of three missed messages.

#include <SoftwareSerial.h>
SoftwareSerial bt(10, 11);   // RX, TX pins on the board
unsigned long lastMsg = 0;
const unsigned long TIMEOUT_MS = 300;

void drive(char c) { /* set motor pins for F, B, L, R, S */ }

void setup() {
  bt.begin(9600);          // use your module's baud rate
  drive('S');
}

void loop() {
  if (bt.available()) {
    char c = bt.read();
    drive(c);
    lastMsg = millis();
  }
  if (millis() - lastMsg > TIMEOUT_MS) drive('S');
}

How far does the robot coast if the phone dies? Say it moves at 0.3 m/s. In the worst case the last message was just received, so it keeps going for 300 ms: 0.3 m/s × 0.3 s = 0.09 m, which is 9 cm. A longer timeout feels smoother when the connection stutters but costs distance, so pick the shortest one that does not make the robot judder in normal use.

The code, step by step

1. Open the serial link: Start the module at the speed its manual gives. A mismatch gives garbage characters.

2. Read one byte at a time: Check available() and read a single character. Ignore anything that is not in your command table.

3. Act and stamp the time: Set the motors, and record millis() as the last time you heard from the driver.

4. Check the clock every loop: If the time since the last message is over the limit, command stop. This runs even when no bytes arrive, which is the whole point.

Two more habits make the code easier to trust. First, print every received byte to the serial monitor while you are testing, so you can see exactly what the phone sends. Some apps add a newline or carriage return after each press; if your program treats those as unknown commands and ignores them, nothing breaks, but if it treats them as a stop, the robot will stutter. Second, make the stop path simple: one function that sets every motor pin low, called from the timeout, from the S command, and from setup. When every road leads to the same short function, there is less to get wrong.

Test, measure and fix

1. With the wheels off the ground, send each command and watch the right wheel turn the right way.

2. Hold a forward button, then switch off the phone's Bluetooth. The wheels should stop within about a third of a second.

3. Time the stop with a phone video, frame by frame, if you want a measured number.

4. Walk away slowly until the link drops, and note the range. Walls and bodies shorten it.

If the robot turns the wrong way for left and right, swap the two motor wires on one side or swap the two pins in your code. If it twitches, check the shared ground.

Make it better

• Add a speed command, such as digits 0 to 9 that set a power level.

• Add a pairing step or change the module's default name and code, so a stranger's phone cannot connect to your robot.

• Send sensor readings back to the phone, such as battery voltage.

Stay safe

Treat a remote robot as a moving object that can hit someone. Test it in a clear space, keep people and pets away, keep a physical power switch within reach, and never rely on the app's stop button alone: the timeout and the switch are your real safety.

Frequently asked questions

Why use a timeout instead of a stop button?

A stop button only works if the message arrives. A timeout works exactly when messages stop arriving, which is the case you are worried about.

Can I control it from a computer?

Yes. Any program that can open a Bluetooth serial port can send the same letters.