Verdict first: when AMRs start acting haunted, the WiFi is guilty until proven innocent. Lost tasks, sudden e-stops, a fleet that slows down for no reason — before you call the AMR vendor to complain, grab a laptop and ping the aisle where it happened.
I have seen this exact trap three times. Every time, the site blamed the dispatch algorithm, then the LiDAR, then the firmware. Two weeks of finger-pointing later, someone finally checked the network: a coverage dead zone between two rack rows, or roaming handoffs so slow the robots kept timing out. Fix the network, and the robots' "illness" disappears overnight.
Two war stories
March 2024, a 3PL warehouse in eastern China, a little over 20,000 square meters, six AMRs two weeks into go-live. "Lost tasks" more than twenty times a day. The vendor's engineer camped on site for two days, digging through dispatch logs, and concluded it was "probably an intermittent task-assignment logic issue." I walked the problem aisle with a laptop and ran a ping: two rack rows sat in an AP coverage dead zone with packet loss above 40 percent. The AMR rolled in, its heartbeat packets never made it out, and the dispatcher assumed it had gone dark and pulled the task back for reassignment. That was the so-called "lost task."
The fix was almost embarrassing: relocate three APs, bump the roaming aggressiveness on the AMR WiFi cards one notch. Complaints dropped to zero within a week. I still remember the look on the vendor engineer's face when he left.
June 2025, a big e-commerce fulfillment center, AMRs added right after the 618 shopping festival. Before the festival they had raised the racks two levels higher. Solid metal shelving blocked the 5 GHz signal completely, and the APs were still mounted at the old height. Result: every AMR that entered the high-rack zone started "playing dumb" — slowing, pausing, the occasional e-stop — then sprang back to life the moment it left the zone. We redid the wireless heatmap survey, dropped the AP mounting height below the rack beams, replanned the channels. Fixed without the vendor ever getting involved.
Why a WiFi handoff can kill an AMR
The mechanism is simple. As an AMR moves, its WiFi client must hop between APs: pick a target AP, re-authenticate, reassociate, resume the data stream. On an untuned network, that handoff takes hundreds of milliseconds. Without 802.11r fast roaming enabled, a handoff can drop the connection for over a minute — not unusual at all.
And AMR vendors play it safe: a communication timeout triggers an e-stop. So what you see is "the robot glitching out," but the disease is in the network. Worse, a warehouse is the worst possible radio environment: metal racks, forklift charging bays, and metal roller doors are all WiFi killers, and a warehouse is full of all three.
The field checklist: five steps
This is the full network section of my go-live-eve checklist for every AMR project. Work through it and tick every box.
Step 1: Survey the site before go-live. Do not trust the drawings.
Walk the floor with survey software (even a phone-app-grade tool works) and generate a signal heatmap. Check three things: signal strength along every AMR travel path, enough overlap between APs for clean handoffs, and no dead zones behind metal racks. The AP positions on the drawing and the reality on the floor disagree eight times out of ten — racks got moved, an AP got clipped by a forklift, a partition wall went up that never made it onto the drawing.
Step 2: Plan AP placement against three hard rules.
Mounting height: APs must sit below the rack beams so the signal has line of sight to the AMR antennas. Ceiling-mounted looks tidy, but metal racks eat the signal for breakfast. Density: err on the side of more APs. One extra AP costs far less than one hour of a stalled AMR line. Channel planning: neighboring APs must not share a channel, plan 2.4 GHz and 5 GHz separately, and keep AMRs on 5 GHz where interference is lower.
Step 3: Tune the roaming. This is the core.
Enable 802.11r fast roaming on the APs to push handoff latency under 150 milliseconds. Then tune the roaming aggressiveness on the AMR WiFi cards: too "loyal" and the client clings to a dying AP; too "flirty" and it ping-pongs between two APs. My starting point is the middle setting, then measure handoff success rates and try one notch in each direction, keeping whichever is most stable. Every WiFi card behaves differently. There is no universal setting — only measured ones.
Step 4: Build redundancy for the routes that cannot afford a drop.
If AMRs run on the main artery, cross floors, or work the dock doors — anywhere a disconnect is unacceptable — consider dual WiFi cards or WiFi plus cellular failover. Yes, it costs more. It costs less than one fleet-wide e-stop event. Redundancy is for critical routes, not for every robot.
Step 5: Go-live-eve checklist plus acceptance testing.
The night before go-live, walk the floor with this list: run every AMR route end to end three times, logging each AP handoff timestamp and any packet loss. Then simulate the worst case — forklift chargers all on, roller doors down, every handset on WiFi at shift start — and run it all again. Any spot with handoff latency over 150 milliseconds gets flagged and re-tuned the next day, then re-tested. Write the acceptance bar into the contract: 72 straight hours with zero network-caused task losses before the network is signed off.
Common face-plants (all paid for in blood)
| What you see | Do not start with this | Start with this instead |
|---|---|---|
| AMRs lose tasks at the same spot | Ask the vendor to read dispatch logs | Ping that aisle and check AP coverage |
| A whole zone slows down together | Add more robots or raise task priority | Check AP load and channel interference in that zone |
| Fine in the morning, glitchy in the afternoon | Reboot AMRs or upgrade firmware | Look for time-patterned interference: charging bays, roller doors |
| Great in week one, degrading in week two | Suspect AMR hardware aging | Check for new racks, new partitions, or a knocked AP |
One contrarian take
Most projects get the order of operations backwards: two weeks of the AMR vendor tearing things apart, and only then does someone think to check the network. The correct order is always ping first, phone call second. A network check costs one laptop and half a day. A vendor site visit costs travel plus two weeks of arguing. And here is the part people miss: once the network is tuned, a lot of "AMR performance problems" fix themselves. Fleet speed goes up, task success rates go up, and you never needed those extra robots.
An AMR is an honest worker. It only does what it is told. When the instructions cannot reach it, all it can do is e-stop to stay safe. Do not blame the worker. Check your WiFi first.
By Lin Xiao, WMS Implementation Consultant
