Build a Phone-Controlled Robot Car Over Bluetooth or Wi-Fi

What you are building

A robot car you drive from your phone — over Bluetooth with an HC-05, or over Wi-Fi with an ESP32 serving its own control page.

It is the most approachable robot on this site: no control theory, no algorithm to get right, and the failure modes are visible rather than mathematical. It is also the one that teaches a lesson every other robot needs — what to do when you stop being in control.

The two radios

	HC-05 (Bluetooth)	ESP32 (Wi-Fi)
Extra hardware	A module, plus a divider on RX	None — radio is on the controller
On the phone	A Bluetooth serial app	Any browser
Range	Roughly 10 m	30 m+ outdoors
Phone keeps internet	Yes	No, in access-point mode
Best for	A first wireless build	Anything you want to hand to someone else

Neither is wrong. The HC-05 is the shorter path to a robot that moves; the ESP32 is the better experience once it works, because “connect to this Wi-Fi and open a browser” needs no explaining.

Build order

1 — Make it drive on a bench. Motors, driver, battery, wheels off the ground, no radio at all. Follow controlling DC motors with PWM and confirm forward, back and each turn with hardcoded commands. Debugging a radio and a motor driver simultaneously is how afternoons disappear.

2 — Add the radio and echo. Wire the HC-05 or bring up the ESP32’s access point, and get text moving in both directions before you connect it to anything that turns.

3 — Join them with a protocol. One letter plus a value, terminated by a newline. Read until the terminator rather than acting on each byte, because “some bytes have arrived” is not “the message has arrived”.

4 — Make it fail safe. This is the step people skip, and it is the one that matters.

The deadman timeout

A wireless robot keeps doing the last thing you told it. If that was “forward at full speed” and you have just walked out of range, the robot does not stop — it commits.

The fix has two halves and needs both:

• The controller repeats. The phone sends the held command every 100 ms, not once on press.
• The robot expects it. If nothing has arrived for ~400 ms, stop.

if (millis() - lastCommandAt > 400) stop();

Now a released button, a closed app, a flat phone battery and a walk out of range all produce the same outcome. You are never relying on a stop message that may never be sent.

Use millis() rather than delay() for this. A delay(200) anywhere in the loop is 200 ms during which the robot reads nothing and checks nothing.

Hardware notes

Give the radio a clean supply. Both modules draw current in sharp bursts when transmitting. Sharing a sagging rail with motors causes resets that look exactly like software crashes — the robot stops responding mid-drive and comes back a second later. Feed the motors from the battery pack through the driver, and keep the logic supply separate.

Mind the 3.3 V pins. The HC-05’s RX and every ESP32 GPIO are 3.3 V parts. A 5 V Arduino transmitting into them needs a divider. The damage is gradual and partial, which is what makes it hard to diagnose.

An L298N is fine here. Its voltage drop matters on a robot chasing a line at speed; on a manually driven car you simply compensate with the throttle, so the cheaper, more common driver is the sensible choice.

Where this goes next

The command layer you have built is independent of any behaviour layer, which is exactly what makes it a good foundation. Add an ultrasonic sensor and the robot can refuse to drive into a wall even while you hold forward — the beginning of the obstacle-avoiding robot.

That combination, a robot you can drive and that can override you, is also the easiest way to develop autonomy: you can place the robot exactly where a bug happens without walking over and picking it up.