The autonomous mobile robot pilot ran in a cleared corner of the distribution center. Five robots, one temperature zone, a dedicated SSID, and a direct line to the vendor’s cloud. It worked. The production rollout covered the full building, three temperature zones, and a fleet ten times the size. The robots were the same. Nothing else was.

Operations evaluates a robot by looking at the chassis. IT has to look at the fleet manager. The physical robot is just the actuator. The actual system is the web of APIs connecting that robot to the warehouse management system, the network infrastructure, and the vendor’s cloud.

The network is the only layer every robot vendor shares. It is also the layer no robot vendor owns. That is why it is where things break first.

A network site survey conducted with a laptop at chest height in an empty warehouse tells you nothing about the robot’s radio. The robot’s antenna sits at 0.3 meters. The laptop was at 1.5 meters. When the warehouse fills with dense pallets of liquid and metal, the racks act as Faraday cages that change shape every time a forklift moves. The RF map you designed in January is not the network you have in November.

Then there is the roaming problem. A robot moving at three meters per second must constantly hand off between access points. If the client supplicant on the robot’s network card is configured to hold onto a degrading access point too long, packet loss spikes. The heartbeat to the fleet manager drops. The robot executes an automated safety stop. A dropped packet in a carpeted office means a delayed email. A dropped packet in a distribution center means physical gridlock.

The fleet manager is presented in the sales deck as a robot accessory. It is actually an enterprise application. It holds task history, robot configuration, map data, and telemetry. It requires high availability, backups, patching, and lifecycle management. It is a system of record you do not own.

The seam between the WMS and the fleet manager is where accountability goes to die. The WMS generates a movement order. The integration layer translates it. The fleet manager calculates a route and dispatches it. When a robot picks up a tote, but the WMS cancels the order before delivery, the fleet manager still has an active mission. The robot stops in an aisle, waiting for instructions that neither system is programmed to provide. A robot’s position and an order’s status are two different kinds of truth.

Nobody budgets for the integration layer. Everybody pays for it. Each additional vendor adds network configuration, security review, API integration, support contracts, and a telemetry pipeline.

Procurement inevitably wants competitive pricing, so they bring in a second robot vendor. The second vendor is an architecture test disguised as a procurement decision. One vendor can be integrated point-to-point. Two vendors force you to build a middleware layer and introduce physical traffic problems.

Vendor A and Vendor B robots approach the same aisle crossing. Neither proprietary fleet manager sees the other. Local sensors prevent a collision, but both robots execute a safety stop. They remain deadlocked until a human operator drags one out of the way.

Vendors will point to VDA 5050 or the MassRobotics interoperability standards. These standards define a JSON-over-MQTT interface between a master control and a robot. They are necessary, but not sufficient. Compliance does not solve traffic management, charging strategies, or WMS integration. Products implement the standards partially. That gap is your problem. An interface that accepts a task is not proof that two fleets can share an aisle.

A stopped robot is not a robot problem. It is an observability and ownership problem wearing a robotics costume.

When a robot stops in a busy aisle with an amber light flashing, the fleet manager knows. The WMS doesn’t. The picker sees it. IT gets the ticket. Four systems, four versions of the truth. Who gets paged? Operations, usually. Who gets called when operations cannot fix it? IT. Who does IT call? The vendor. Which vendor? It depends on the error.

The runbook for this scenario is usually three pages. It should be thirty. It needs to cover Wi-Fi drops, WMS downtime, fleet manager outages, and certificate expirations. You will not notice a certificate until it expires fleet-wide on a Tuesday morning because a security certificate installed by the vendor two years ago on an on-premises fleet manager was never patched.

Cold chain turns a network problem into a physics problem. In a sub-zero freezer, battery capacity drops. Condensation corrodes access point connectors. Frost obscures LiDAR sensors. The robot loses localization. The vendor’s operating range spec said it was fine down to -10C. The freezer is -20C. Read the spec before signing the purchase order.

The robot is a client. Treat it like one. It needs DHCP, DNS, NTP for time sync, certificates, proxy configuration, and firewall rules. It runs Linux. It has APIs. It has CVEs. Firmware updates are not routine maintenance; they are change management events that can alter fleet behavior.

If the only interface to the robot’s telemetry is the vendor’s cloud dashboard, your IT team is blind. Negotiate the telemetry API and event stream in the contract. Stream the robot state to your own monitoring tools. Correlate robot events with network events and WMS events.

The pilot proves the robot. Production proves the integration. The integration work outlasts the robot deployment. Plan for months, not weeks. Put the integration layer on the architecture diagram. Give it an owner, a roadmap, and a runbook. The robots will eventually be replaced, but the middleware you build to connect them to the warehouse will be there for the next decade.

Take it with you

Takeaways

  • Robot pilots prove the hardware; production proves the integration.
  • The network is the shared layer no robot vendor owns, and it breaks first.
  • Multi-vendor fleets require middleware, traffic management, and runbooks that standards do not provide.

Asked and answered

Questions

Why do autonomous mobile robots stop in production when the pilot worked?

The pilot ran in a cleared corner with five robots, one temperature zone, and a dedicated SSID. Production covers the full building, three temperature zones, and a fleet ten times the size. The robots are the same; the network, integration, and operational conditions are not.

What breaks first in an AMR deployment?

The network. It is the only layer every robot vendor shares and no robot vendor owns. RF maps change as inventory moves, and roaming between access points can drop the heartbeat to the fleet manager, triggering safety stops.

Do interoperability standards like VDA 5050 solve multi-vendor fleets?

They define a JSON-over-MQTT interface between a master control and a robot, but they do not solve traffic management, charging strategies, or WMS integration. Products implement the standards partially, and that gap remains the operator's problem.