How Does a Robot Return Home When Its Link Drops?

• Robot mopping
• Wi-Fi link cut
• Pump shut off
• Robot driving home
• Dock for power and water
• Link restored

What you will learn

• Name the signs that tell a robot its link is lost, and why it should confirm before it acts.
• Follow the robot's states from first suspicion to charging and reconnection.
• Explain why the estimated position drifts and how the robot still reaches the dock.

Before you start

Read the comparison of central and onboard control and the article on a PC controlling the fleet, where the heartbeat and the failure points of the chain are explained.

How does the robot notice that the link is gone?

The robot cross-checks three kinds of signs instead of trusting one signal: Wi-Fi events, the heartbeat from the computer and the state of its connection to the broker.

The ESP-IDF station scenarios guide states that when the Wi-Fi connection is disrupted, for example because the access point is powered off or the RSSI is poor, ESP32 raises a disconnect event. The beacon timeout mechanism lets a station detect whether the access point is alive, and the application can set its inactive time. A live Wi-Fi link does not prove the computer is alive, so the robot still needs the heartbeat of the control program.

The MQTT specification gives the robot and the broker one mechanism each. If Keep Alive is non-zero and the broker receives no control packet within one and a half times the Keep Alive period, the broker must disconnect as if the network had failed. If the robot receives no PINGRESP within a reasonable time after sending a PINGREQ, it should close the connection. The broker must also publish the stored Will Message when the robot's connection closes, including on a network failure the broker itself detects, unless it deleted the message on receiving DISCONNECT. If the broker and its path to the computer still work, this reports a lost connection, not the robot’s position or physical failure. With the router or broker down, the notice may not reach the computer yet.

Every sign comes with a waiting threshold, and that threshold is a design choice. A short wait makes the robot raise false alarms whenever Wi-Fi flickers. A long wait lets the robot keep mopping with nobody in control. The PX4 guide offers a pattern: its Data Link Loss failsafe triggers when the connection to the last MAVLink ground station is lost. For most failsafes the default behaviour is to enter Hold for a configurable number of seconds before acting, which gives the user time to notice what is happening and override the failsafe. The illustrative design borrows the idea: suspect, confirm, then act.

• Wi-Fi disconnect event
• Heartbeat from the computer stops
• PINGRESP does not return
• Suspect state
• Confirmation wait

What does the robot do the moment the link is lost?

The robot enters a safe state before it goes anywhere: it shuts off the pump and stops the pad, then moves. The illustrative design does this because a pump that runs while the robot stands still pours water on one spot. The states, in order:

1. Normal: the robot mops on command and watches the signs.
2. Suspect: one sign has passed its threshold. The robot cuts the pump, stops moving, accepts no new job and waits for confirmation; it does not keep mopping while it waits.
3. Safe: the suspicion is confirmed. The robot shuts off the pump, stops the pad and stores its current estimated position.
4. Returning: the robot moves only with valid localization, a local return route and enough battery. Otherwise it stays safe, records a fault and waits for help.
5. Charging: the robot enters the dock, charges and takes on water.
6. Reconnecting: from the safe state on, the robot retries the connection periodically. The ESP-IDF guide recommends that, on a disconnect event, the application calls the Wi-Fi connect function again, closes all sockets and re-creates them if necessary.

If the sign disappears while the robot is only suspicious, it returns to normal. From the safe state on, it returns to normal only after reconnecting and receiving a job from the computer.

One more layer sits below the state machine. The ESP-IDF watchdog documentation describes a watchdog timer as monitoring system operation and recovering automatically from software or hardware faults by restarting the system if it becomes unresponsive. After a restart the robot should begin in the safe state instead of continuing the old command, because that command may be stale.

• Normal
• Suspect
• Safe (pump off)
• Returning
• Charging and refilling
• Reconnecting

How does the robot find the dock without the computer?

In the illustrative model, the robot stores a return route checked against its local map. It uses odometry to follow that route and switches to the dock’s guidance signal when close enough; a dock coordinate and odometry alone do not provide obstacle-avoiding navigation. Odometry here means the position estimated from wheel encoders and the IMU.

The ROS documentation on coordinate frames for mobile platforms states that the odom frame is typically computed from an odometry source such as wheel odometry, visual odometry or an inertial measurement unit. The estimated pose in that frame can drift over time without any bounds. The frame is useful as an accurate short-term local reference, but drift makes it a poor frame for long-term reference. Wheel slip is another factor people must account for: a NASA summary describes applying slope-induced wheel slippage to the rover's location estimator in the Mars Exploration Rover mission.

The longer the trip home, the wider the area where the robot may actually be. So the robot aims at a staging pose in front of the dock rather than straight at the charging contacts. The Nav2 docking tutorial describes a similar sequence. If the robot is not within the pre-staging tolerance of the dock's staging pose, it navigates to that pose. The pose is chosen close enough to detect the dock but far enough away to leave room to manoeuvre, allowing for dock movement or localisation error. The robot leaves the vision-control loop once contact is detected or charging has started. The illustrative design borrows this sequence and replaces vision with the dock's guidance signal.

Reaching the staging pose without seeing the guidance signal means the robot is lost, and it follows walls to look for the dock. One cleaning-robot design has a wall-following mode: the robot meets a wall, follows it for a time and returns to another mode, and it may assume it has lost the wall and abandon the mode. A university lab describes a robot that follows the edge of a large obstacle until it can head toward the goal again. The illustrative design walks along the walls around its area and listens for the guidance signal. Search is allowed only in an area already known to be safe, with time and energy limits. Following walls does not guarantee finding the dock; at a limit, or when floor and clearance cannot be confirmed, the robot stops, waits and reports after reconnecting.

• Uncertainty growing with distance
• Staging pose in front of the dock
• Dock and guidance signal
• Walls around the area

When does the robot reconnect, and what can go wrong on the way?

The robot reconnects once the link is stable, then registers again, reports its state and waits for the computer to assign work. The steps:

1. Reconnect to Wi-Fi and the broker, and rebuild the sockets.
2. Send a registration message with battery, water level and position. Only after confirming arrival at the correct dock does the robot use that reference to correct the map-to-local-position relationship; reconnection alone never resets odometry mid-route.
3. The computer compares the assigned zone and the map of cleaned cells with the state the robot reports, then reassigns the work.
4. If battery or water is low, the robot tops up first.

Stable means a steady heartbeat over a waiting period, not one lone packet. That period is also a trade-off between reconnecting fast and reconnecting reliably.

The table is design reasoning, not a test result.

• Link lost on the way home
• Battery low on the way
• Dock busy
• Stuck under furniture

Real-world example

In a small office, a robot is mopping under a desk when the Wi-Fi router restarts mid-morning. This is a design scenario, not a test result.

The robot gets the disconnect event and loses the heartbeat, so it becomes suspicious. When the wait ends and the link has not returned, it shuts off the pump, stops the pad and stores its estimated position. It follows the stored local route with valid localization and reaches the staging pose and finds the dock charging another robot. The robot waits there, enters when the dock is free and charges.

While the router is off, the computer may not receive the Will Message yet. It also watches status-message deadlines and holds the robot’s zone to avoid overlapping assignments. When the router is back, the robot reconnects, registers and reports its state. The computer compares the cleaned cells and assigns the rest of the job.

Common misunderstandings

Losing Wi-Fi stops the robot completely. The robot stops the pump and the mopping, while local homing runs only if the robot still has the required navigation data and battery.

An accurate map removes the need for a staging pose. A position estimated by odometry can drift over time without any bounds, so the robot still needs a guidance signal near the dock.

A lost link means a broken robot. It is an expected situation, and the robot has its own route through it.

Frequently asked questions

What does a mopping robot do when it loses Wi-Fi?

In the illustrative design it shuts off the pump, stops mopping, returns only with a valid local route, localization and enough battery, then retries the connection; otherwise it stays still and records a fault. It takes new work only after registering with the computer again.

Why does the robot not go home as soon as the signal drops?

Flickering Wi-Fi can recover after a moment, while going home mid-job leaves the work unfinished. So the robot confirms first, like PX4 waiting a while before it runs a failsafe.

Can the robot find its dock if someone carries it elsewhere?

It may, but it is not guaranteed. The estimated position is only reliable while the robot drives itself, so a robot that was carried away may reach the wrong staging pose. When it sees no guidance signal it follows walls to search, then stops and reports if it still finds nothing.

Summary

• The robot confirms a lost link from several signs before it acts, and the waiting threshold is a trade-off.
• It passes through safe, returning, charging and reconnecting states, and the pump and pad stop before the robot moves.
• Odometry drifts over time, so the robot aims at a staging pose near the dock, then uses the guidance signal, and follows walls when lost.