Network and WiFi Readiness for Autonomous Mobile Robots

Why the Network Is the Usual Suspect

When an autonomous mobile robot deployment goes badly, the network is the cause far more often than the robot. In our own implementations, wireless issues account for a clear majority of the problems that surface in the first thirty days. Navigation software is mature. Batteries are predictable. Access point placement designed for people carrying phones is not designed for a machine travelling at floor level through a service corridor.

The failure mode is rarely dramatic. A robot does not usually stop dead. It pauses in a doorway, takes a slower route, loses a task assignment, or drops a status update to the fleet dashboard. Staff read that as unreliability and confidence erodes quickly. Getting the network right before the machine arrives is the single highest-return preparation you can do.

Coverage Is Not the Same as Signal

A phone held at chest height in the middle of a corridor is a very different measurement than a robot antenna sitting roughly 40 centimetres off the floor, hugging a wall, with a metal cart parked beside it. Signal maps built from handheld surveys routinely overstate what a robot will experience.

Three areas cause most of the trouble:

• Service corridors and back-of-house routes. These are exactly where delivery and transport robots spend their time and exactly where access point budgets get cut.
• Elevator lobbies and elevator cars. A steel box is a poor radio environment, and robots often need connectivity precisely while waiting for or riding in one.
• Loading docks, soiled utility rooms, and stairwell landings. Peripheral spaces with hard surfaces and heavy equipment.

Measure at robot height, along the actual planned route, at the times of day the robot will run. A corridor that tests clean at 7am with an empty floor can behave differently at shift change.

Roaming and the Handoff Problem

A robot in motion is continuously handing off between access points. Roaming behaviour matters more for a robot than for almost any other client on your network, because the machine is moving steadily and cannot pause to reassociate the way a person unconsciously does.

The practical issues are usually these. Access points configured with overlapping coverage but mismatched power levels create sticky client behaviour, where the robot holds a weakening association rather than moving to a stronger one. Fast roaming standards such as 802.11r and 802.11k help considerably and are frequently disabled by default on enterprise networks. Captive portals and per-session authentication that expect a human to click something will break an unattended machine outright.

VLANs, Firewalls, and Where to Put the Robot

Most organisations put robots on an IoT or device VLAN, which is sensible. The complication is that a robot is a chattier and more demanding device than a badge reader, and default IoT policies are often written for something much simpler.

Work through these before the install date rather than during it:

• Outbound access to the fleet management service, including which hostnames and ports must be reachable. Get this from your vendor in writing and give it to your firewall team early.
• Local network access for any on-premises integration, such as elevator controllers, door controllers, or a nurse call system.
• Time synchronisation and certificate validation, which quietly break a lot of devices behind restrictive egress rules.
• Client isolation settings, which are commonly enabled on guest and IoT networks and which can prevent a robot from reaching a local controller it needs.

In healthcare environments, expect the security review to ask where robot telemetry goes and who can reach the machine remotely. Those are fair questions and your vendor should be able to answer them without hedging.

How Much Bandwidth a Robot Actually Uses

Less than people expect, and in a pattern that matters more than the volume. Steady-state operation for a transport or service robot is modest: telemetry, task state, position updates, and periodic health reporting. The demanding moments are firmware and map updates, which are large and infrequent, and any live video or teleoperation session, which is sustained and latency-sensitive.

Plan for the peaks rather than the average. A firmware push that would be unremarkable overnight can be disruptive if it lands during a busy service period on a saturated access point. Ask whether updates can be scheduled to a maintenance window, and whether the robot defers large downloads when it detects a constrained link.

The Pre-Deployment Site Survey

A useful survey takes a few hours and answers six questions:

1. What is the signal strength and signal-to-noise ratio along the full planned route, measured at robot antenna height?
2. Where are the handoff points between access points, and does the client roam cleanly at each one?
3. Are there dead zones, and can they be resolved by moving or adding an access point rather than by rerouting the robot?
4. Is the elevator car covered, and if not, how does the robot behave through the ride?
5. Does the assigned VLAN permit everything the robot needs, tested from a device on that VLAN rather than assumed from policy?
6. What changes on the network between the quietest and busiest hours of the day?

Document the results and keep them. When something behaves oddly six months later, a baseline taken before go-live is the fastest route to an answer. It also settles the recurring and unproductive argument about whether the problem is the robot or the building.