Designing Wireless for Robotics and AMRs in Warehouse Environments
https://www.linkedin.com/pulse/designing-wireless-robotics-amrs-warehouse-jarryd-de-oliveira-c1koe
Warehouses have changed.
They’re no longer just forklifts, pallet racks, and handheld scanners.
Autonomous Mobile Robots (AMRs) and robotic picking systems are now part of the core operation, and that changes everything for Wi-Fi.
Designing for a handheld scanner is forgiving.
The device moves slowly. The user can pause. A brief roam isn’t noticeable.
AMRs don’t give you that margin.
They move continuously. They carry real payloads. They interact with people. And they rely on the network not just for data, but for real-time decision making and safety.
A 300 ms roam might mean a failed scan.
For an AMR, that same delay can mean a stopped workflow, a mission failure, or worse.
At that point, Wi-Fi stops being connectivity.
It becomes part of the control system.
Understanding the Traffic
Before you even open a floor plan, you need to understand what the robots are doing on the network.
AMR traffic is not enterprise traffic.
Most platforms operate with two key flows:
• A control channel to the Fleet Management System (FMS)
• Sensor and telemetry data (LiDAR, cameras, IMU, etc.)
The control channel is low bandwidth, but extremely sensitive to latency and jitter.
Sensor data can be heavy, depending on the platform.
The key point:
You’re not designing for throughput.
You’re designing for consistency.
Latency Over Throughput
This is where most designs fall over.
Typical Wi-Fi design focuses on capacity.
AMR environments live and die by latency and stability.
A solid baseline to design around:
• Latency: < 20 ms • Jitter: < 5 ms • Packet loss: < 0.1% • Roam time: < 50 ms (ideally < 20 ms)
If your network can’t hold that under load, the robots will feel it immediately.
And unlike users, they don’t adapt.
They fail.
QoS Is Not Optional
QoS needs to be part of the design, not an afterthought.
• WMM enabled and mapped correctly
• Control traffic prioritised (AC_VO / AC_VI depending on vendor)
• DSCP preserved end-to-end
I’ve seen solid RF designs fall apart because QoS markings were dropped somewhere upstream.
Coverage, Capacity… and Continuity
We all know the CWDP pillars:
Coverage Capacity Continuity
In AMR environments, continuity is the one that matters most.
Because it’s not about whether the robot has signal.
It’s about whether that signal stays stable while moving.
Cell Overlap and Roaming
Standard enterprise guidance sits around 15–20% overlap.
For AMRs, that’s not enough.
You’re typically looking at:
• 20–30% overlap
Robots don’t stop and wait for a clean roam.
They move through coverage boundaries, and they need time to make decisions while still on a strong signal.
If they’re roaming at the edge, you’ve already lost.
RF Targets That Actually Work
A solid baseline:
• RSSI: -55 dBm or better
• SNR: 25 dB or better
• Overlap: 20–30%
• MCS: MCS7+ preferred
And this is important.
Don’t design to minimums.
Warehouses are dynamic. Racking, stock, and environment all change.
What looks clean on paper rarely stays that way.
5 GHz, 6 GHz… and Avoiding 2.4 GHz
5 GHz is still the workhorse:
• 20 MHz channels for control and reuse
• 40 MHz is situational
• 80 MHz rarely makes sense in dense robotics
6 GHz (Wi-Fi 6E) is where things get interesting.
More spectrum. Less legacy overhead. Lower latency potential.
If the robots support it, it’s worth serious consideration.
2.4 GHz?
Avoid it where possible.
Limited channels, high contention, and legacy overhead all work against you.
Antennas and Placement
Warehouse RF is driven by structure.
High-bay environments behave very differently to open spaces.
• High racking (8m+): mid-rack, end-of-aisle mounting often works best
• Lower ceilings: ceiling-mounted APs can work, but watch multipath
The key principle:
Design around robot movement paths.
Not just coverage maps.
Focus on:
• Travel routes
• High-speed zones
• Charging areas
• Pick locations
Those are your critical RF zones.
Roaming Design
This is where deployments either work… or don’t.
Fast roaming is non-negotiable:
• 802.11r • 802.11k • 802.11v
But don’t just enable them.
Validate that the robot platform actually supports them properly.
The Sticky Client Problem
Robots can hold onto poor connections longer than they should.
Minimum RSSI thresholds can help:
• Typically around -70 to -75 dBm
But this needs careful tuning.
Too aggressive = disconnect loops Too relaxed = no roaming
Roaming Velocity
A robot moving at 2 m/s in a 30m cell will roam roughly every 15 seconds.
That’s fine… if roaming is fast.
It’s a problem if one roam spikes to 300 ms.
Because that single failure can cascade.
This is why telemetry matters.
Track roaming performance continuously, not just at deployment.
Channel Planning and Interference
Warehouses can help and hurt RF at the same time.
Racking can:
• Improve reuse by isolating RF
Key approach:
• Stick to 20 MHz channels
• Use DFS carefully (understand the impact)
• Avoid auto channel changes in production
• Plan and lock channels based on survey data
Transmit Power
More power is not better.
It increases overlap, interference, and roaming ambiguity.
The goal:
Just enough signal for coverage, with a clear dominant AP per area.
Ekahau and Validation
Shortcuts here will cost you later.
Model properly:
• Accurate floorplan scale
• Racking attenuation (typically 3–6 dB, but validate)
• Correct survey height (match the robot, not a human)
Active Survey Matters
Passive surveys show coverage.
They don’t show behaviour.
For AMRs, you need:
• Active surveys
• Realistic movement speeds
• Ideally real client hardware
Measure:
• RSSI and SNR along paths
• Roaming behaviour
• Latency to FMS
• Performance under movement
Validate Under Load
This is where most projects fall short.
You need to test:
• Real robot movement
• Real traffic load
• Real operating conditions
Then correlate:
• RF metrics
• Infrastructure telemetry
• Robot fault logs
That’s where the truth is.
Network Architecture
Keep it simple where possible.
Dedicated SSID
Always isolate AMR traffic:
• Dedicated SSID
• Enterprise authentication (cert-based where possible)
• QoS applied correctly
• Minimum data rates enforced
VLAN and Mobility
In a single warehouse:
• One VLAN across the entire site is often the simplest and most reliable approach
The key requirement:
The robot must never lose its IP during a roam.
Wired Still Matters
Perfect RF won’t save a poor wired network.
Check:
• Link speeds
• PoE budgets
• Packet loss
• Stable switching topology
Common Mistakes
A few that come up again and again:
• Designing coverage without modelling load
• Leaving roaming at vendor defaults
• Not involving the robot vendor early
• Surveying empty environments
• Forgetting charging zones
Charging areas are often where the most data exchange happens.
They need solid coverage.
Final Thoughts
Designing Wi-Fi for AMRs is not just another wireless deployment.
It sits somewhere between RF engineering and real-time systems design.
The margin for error is lower.
The impact of getting it wrong is immediate.
But the fundamentals are clear:
Design for continuity Prioritise latency over throughput Validate under real conditions Work closely with the robot vendor Avoid relying on defaults
Get it right, and the network disappears into the background.
And in these environments, that’s exactly where it should be.
----
----
Written by Jarryd De Oliveira, CWNE #594