Mobile robots and AGVs

A mobile robot is a Wi-Fi client that never stops moving. Every roam it makes is a gap, and the worst of those gaps has to fit inside the shortest timer the vehicle carries.

The site already covers mobile robots in depth. This page is the map.

Two kinds of vehicle share the subject. An automated guided vehicle (AGV) follows a fixed path, such as ODVA’s example of an AGV following an embedded path in the floor, and in one published car plant ran under a central system’s control over Wi-Fi. An autonomous mobile robot (AMR) plans its own route, which ODVA files under irregular movement, where several base stations are likely to be needed. OMRON’s AMRs avoid obstacles with on-board sensors, and one working alone can navigate on a stored map with no wireless link, while a fleet needs its fleet manager. The difference matters to the radio. An AGV passes the same access points in the same order on every trip. An AMR can turn up anywhere in coverage and roam in any order.

Safety standards govern the vehicles, not the network. ISO 3691-4 is a type C safety standard for driverless industrial trucks. In the US, the ANSI/A3 R15.08 series covers industrial mobile robots, with parts for the robot, for its integration, and for users. The wireless design fits inside what the machine builder derives from them.

What it carries

Fleet manager commands and status. A fleet manager assigns work, plans routes and tracks each vehicle. VDA 5050, the open interface between fleet control and mobile robots, has each robot publish its state when relevant events occur or at least every 30 seconds¹, and it expects connection failures and lost messages over wireless by design.

Traffic management between vehicles. OMRON’s intra-fleet ports dispatch jobs and share position and trajectory updates throughout the fleet. AGILOX runs without a fleet manager at all: its vehicles communicate with each other over Wi-Fi.

Safety and I/O on some vehicles. PI lists wireless safety-related transmission for driverless transport systems and AGVs among PROFIsafe applications, and ODVA describes CIP Safety over wireless links on moving equipment. Their clocks are short. A CIP Safety input connection at documented defaults times out after 40 ms², and its data goes to the safe state. The VDA 5050 state message above may be 30 seconds apart. If one vehicle carries both, the 40 ms clock sets its budget. Safety over wireless covers what those connections are and what they are not.

Everything else. MiR budgets robot-to-fleet traffic at 180 kbit/s average per robot³, and robot-to-PC traffic at 520 kbit/s average with 3 Mbit/s peaks. OMRON’s 50 kbps average per AMR becomes 500 kbps while MobilePlanner monitors it⁴. Control traffic is small. What rides beside it is not. See bulk transfers competing with control.

What it needs from the network

A roam that fits the budget. No robot maker in the requirements database publishes a maximum roam time; what robot makers publish counts that gap and the others. What some makers do publish are timers. Spot sits after 3 seconds without controller communication and turns off its motors after 8⁵. The roam budget is the shortest timer on the vehicle, minus what the wired path spends. The timing budget shows the arithmetic. Loss of comms covers what happens when one runs out.

Coverage everywhere a vehicle can be. The makers agree on the principle and differ on the numbers. MiR asks for full coverage along every robot’s travel path, at -70 dBm or better from the best access point and -75 dBm from the second. That second figure shapes the design: it asks for a roam target in view everywhere, not just a signal. OMRON asks for -60 dBm at minimum, -40 dBm ideally, and calls constant access an operational requirement for a fleet. AGILOX wants reception without fluctuation in all areas of the operating area. For an AGV, everywhere means its route. For an AMR, it means the whole floor it may plan a path across.

Latency each maker can live with. OMRON recommends 10 ms round trip and allows 50 ms at most. MiR allows 200 ms. Design to the tightest figure among the vehicles you run.

Airtime per vehicle. MiR asks the network to give each robot at least 3 Mbps at a transfer rate of at least 20 Mbps, with no more than 2% packet loss, and warns that above 60% channel use its system suffers latency and packet loss. The fleet capacity tool fits per-vehicle traffic under that ceiling, and airtime is finite explains why it exists.

How wireless fails it

The roam, more than the coverage. In a study of AGVs in a car plant, 85.84% of disconnections of 3 seconds or more began with a roam attempt, and 57.53% followed a roam that succeeded⁶. Each mechanism has its own page:

Holding a fading access point too long: sticky client.
Leaving the channel to scan: roam scan gaps.
A full 802.1X exchange on every handoff: slow roam, full reauthentication.
Fast roaming one side does not support: fast roam mismatch.
A defect that follows one vehicle model everywhere: client driver and firmware defects.

Infrastructure features that fight the robot. MiR requires load balancing disabled so the robots can roam freely. It also warns against hidden SSIDs, because the robot must disconnect and scan, which can take several seconds of complete loss of communication. See band steering and load balancing.

Old radios on a shared channel. OMRON’s AMR guide lists 802.11a, b and g. None of the nine robot entries in the requirements database lists 6 GHz. A slow client holds the channel longer for every byte, and the rest of the fleet waits behind it. See low data rates and management overhead and fleet density.

The vehicle’s own body and the building. OMRON tells you not to obstruct the robot’s antennas with metal. Racks, loads and other vehicles do it anyway. When a large object blocks the direct path, NIST notes that the link may be lost, and hand-off to another access point can be too slow. See vehicle antenna placement and moving metal.

Recovery that costs more than the gap. OMRON warns that frequent disconnections may leave an AMR unable to reconnect, requiring user intervention. A one-second gap that strands a vehicle costs the whole recovery.

Design implications

Get the timers in writing first. For every vehicle model, ask for its loss-of-comms behavior and every timer behind it, per software version. The questions are in loss of comms. What to demand from your wireless vendor covers the infrastructure side.

Design for the vehicle’s radio, not the best client on the floor. Most robot makers publish little about fast roaming. MiR asks only for fast reauthentication, by WPA2-PSK or by key caching. The OMRON LD series entry records no mention of 802.11r, k or v. Plan for the slowest roam the vehicle can make, then measure what it does. Shortening or hiding the roam covers the options. If the vehicle uses a separate client bridge, that bridge is the client that roams; see workgroup and client bridges.

Give the radio fewer choices. OMRON states that roam times are faster with fewer channels in the robot’s channel set. MiR plans 20 MHz channels on 2.4 GHz and 40 MHz on 5 GHz only where enough channels exist, and says 80 MHz is often not required for its robots. A fleet gains more from channels it does not share than from width.

Separate control from bulk. Keep fleet and control traffic off the airtime that map pushes, log uploads and updates use, and schedule those outside production. Where the vehicle supports it, a second radio for control traffic only, Wi-Fi on its own channels or private 5G, keeps a download from queuing in front of a command. Redundant radio paths covers the arrangements.

How to validate

Measure the gap from the vehicle. Drive the real routes at production speed with the vehicle’s own radio, and time every roam. The method is in how to measure a roam gap. An access point log that shows a clean roam proves little: in the car plant study, more than half the long disconnections came after a successful roam.

Load the channel with the whole fleet. Measure utilization with every vehicle and every scheduled transfer running, then compare it with the maker’s ceiling, such as MiR’s 60%.

Turn the budget into a pass line. The requirements translator and the timing budget calculator turn a timeout into a roam budget. The acceptance test plan turns that budget into a count of roams that must all pass. The worked example runs one published robot, the MiR1350, through all three.

Count recoveries, not only outages. Log every disconnect per vehicle per shift, with its duration and what recovery took.

The robot never sees your coverage map. It sees the longest gap on its route, and so does whatever timer it carries.

What it carries

What it needs from the network

How wireless fails it

Design implications

How to validate

Causes that hit it

Where it runs

Requirements

Terms on this page

About this page