Robot keeps driving after the remote connection drops: add a failsafe stop

Stop the motors if no command has arrived for a short time.

What the message means

If the last command stays active when the link drops, the robot runs away. Wireless links drop often.

Fix it in this order

  1. Save the time of each received command with millis().
  2. In the main loop, compare the time since the last command with a limit such as half a second.
  3. Set speed to zero when the limit passes.
  4. Send commands repeatedly, not only on change.
  5. Add a physical power switch you can reach.
  6. Test by switching off the remote while the robot drives.

Why it happens

If a remote or a Bluetooth link drops, the last command stays in force and the robot keeps driving. A failsafe stops the motors when no valid command has arrived for a short time.

Record the time of every command and stop the motors when too much time has passed. A timeout of a few hundred milliseconds is a common starting point.

unsigned long lastCmd = 0;
void onCommand() { lastCmd = millis(); }

void loop() {
  if (millis() - lastCmd > 500) stopMotors();   // your function
}

Example sketch: change pins and values for your own wiring. It has not been bench-tested on your hardware.

If you see this, do this

You seeDo this
Robot runs on after disconnectNo timeout.
Stops during normal useLimit too short or commands too rare.

millis timing, WebSocket drops.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.