Assign network and robot ownership before surveying
List the robot model, radio hardware, antenna configuration, driver and firmware, fleet-management version, required services and traffic directions. Record whether the AMR needs continuous connectivity for mission dispatch, map updates, telemetry, remote support or another function, and what remains local if communication is interrupted.
Assign owners for WLAN design, identity/certificates, firewall and DNS/DHCP/NTP services, robot configuration, application integration, cyber review, monitoring and incident response. A vendor should not silently change enterprise Wi-Fi, and IT should not tune the network without preserving the mobile-client acceptance basis.
Survey the real operating routes and RF changes
The OMRON AMR Wireless Communication Technical Guide recommends a preliminary site survey and calls out floor maps, Wi-Fi security, other clients, obstacles and building materials, interference sources and facility size. Use that as vendor-specific guidance, then apply the exact requirements for the selected AMR.
Walk every intended route, charger approach, workstation, lift or door interface, staging area, narrow aisle and exception location. Include loaded racks, metal doors, moving equipment and production states that change propagation. Record access-point identity, band/channel, RSSI or other vendor-required metrics, noise, loss, latency and sample location with timestamp and tool.
A survey must identify unsurveyed or change-prone zones. New racks, inventory, welding equipment, microwaves, temporary networks and neighboring WLANs can change the result.
Test roaming with the exact AMR client in motion
A strong signal at stationary points does not prove that the client will leave one access point and join another without disrupting the application. Drive the AMR through each cell boundary in both directions at representative speeds and loads. Correlate client logs, controller or AP logs, packet capture when approved, mission events and operator observation.
Record the old and new AP, decision time, authentication method, interruption, packet loss, application behavior and recovery. Repeat during different traffic and inventory states. Do not hide a long tail behind an average.
Validate authentication, segmentation and supporting services
Test the production-intended SSID, authentication, certificate lifecycle, VLAN/segmentation, address assignment, DNS, NTP, firewall rules and required endpoints. Confirm initial enrollment, reboot, certificate renewal or expiration handling, clock error and replacement-device process.
Document permitted flows rather than opening broad access to make the pilot work. Preserve remote-support and update boundaries, logging and approval. Cybersecurity architecture requires site review; this guide does not prescribe one universal SSID, band or authentication scheme.
Test contention, interference and operational peaks
Run representative robot counts and message loads with scanners, tablets, cameras, voice, vehicles and production devices active. Record airtime or channel use, retry/loss, latency distribution and application outcomes. A quiet after-hours walk does not validate a peak shift.
| Test | Evidence | Failure question |
|---|---|---|
| Route coverage | Location-tagged client/RF record | Where does performance fall outside vendor/site criteria? |
| Roaming | Client + AP + mission timeline | Does the application survive the transition? |
| Peak load | Traffic and latency/loss distribution | Which shared demand changes the robot outcome? |
| Interference | Spectrum/event log and production state | Is the source repeatable and controllable? |
| Services | Authentication, DHCP, DNS, NTP and firewall logs | Can the robot reconnect without manual bypass? |
Run failure and recovery tests before go-live
Test a planned AP outage, upstream-service interruption, expired or rejected credential, address/DNS failure, packet loss or delay injection where authorized, controller or link failover and a robot reboot inside a boundary zone. Run only under the approved safety plan.
For each event, define expected local robot behavior, mission state, alarms, retry, reconnection, duplicate-command protection, operator intervention, log ownership and safe return to service. A reconnect that silently loses or repeats a mission is not a clean recovery.
Build a pilot acceptance pack that survives change
Store the floor and route map, survey date and facility state, AMR client versions, WLAN configuration identifiers, test tools, raw logs, route results, roaming events, service tests, peak-load results, failures, exceptions and signed decisions. Write retest triggers for AP, channel, security, client, rack, route, robot-count and application changes.
Use the AMR integration guide to join network evidence to workflow, interface and pilot acceptance planning. Review AMR platforms only after the site requirements and ownership are clear.
FAQs
Is a warehouse Wi-Fi heatmap enough for an AMR pilot?
No. A survey is a planning input. Validate the exact AMR client while moving on representative routes, roaming between access points and recovering from faults.
What signal-strength value does every AMR need?
There is no universal value. Use the robot vendor's current requirements and test throughput, latency, loss and roaming for the actual client, applications and site.
Should AMRs use a separate SSID?
That is a site architecture decision. Document security, segmentation, capacity, operations and support consequences; do not create a new SSID without IT/OT approval.
Who decides when a mobile client roams?
Roaming depends on the AMR client radio and the access-point design together. OMRON's AMR Wireless Communication Technical Guide treats client roaming characteristics as a site-survey input and records per-location roam events as access-point (BSSID) switches in its wireless diagnostics; it states no universal rule. Confirm how the selected AMR client and WLAN design handle roaming from the vendor documentation and a test of the exact configuration.
Can the pilot run on a temporary hotspot?
Only if that is an explicit limited test. A hotspot does not validate production coverage, roaming, authentication, redundancy, monitoring or support ownership.
What should happen when Wi-Fi is lost?
The safe operational response must come from the robot and system design. Test loss detection, mission state, local behavior, reconnection, duplicate-command protection, recovery and logging.
Sources and limitations
- OMRON — AMR Wireless Communication Technical Guide (72503-100 A): site survey considerations and checklist, wireless network requirements, signal quality, bandwidth calculation, channel and access-point layout, common problems and ongoing monitoring.
No universal signal, latency, AP spacing, band, roaming time or outage behavior is claimed. Apply the exact vendor, WLAN, application, cyber and site-safety requirements.
Prepare the AMR network pilot
Share routes, facility constraints, WLAN ownership, robot count and application dependencies for a scoped integration discussion.
Discuss an AMR project