Here's a judgment call after twenty years on warehouse floors: when an AMR project goes sideways, half the time it isn't the robot's fault. It's the handoff — the exact spot where the AMR meets the conveyor, the rack, or the lift. In 2023 I worked on a project in Ontario, California, an 80,000-plus-square-foot e-commerce fulfillment center. The AMRs ran beautifully in open areas. The moment they pulled into a docking station, everything fell apart. Rework dragged on for nearly three months and burned several hundred thousand dollars in extra integration cost. A systems integrator friend later told me this is routine. If the interface isn't dialed in, the fanciest robot in the world is just an expensive paperweight.
It Stopped Perfectly. It Just Didn't Line Up.
The first pitfall is the most infuriating. The AMR navigates to centimeter-level accuracy and stops exactly on its mark — and the load still won't transfer. Why? Because the conveyor on the other side has mechanical tolerances.
When conveyors get installed, leg leveling and roller height come down to tape measures and a crew's judgment. The drawing says both sides sit at the same height; in reality, a centimeter or two of difference is completely normal. The AMR lifts its pallet, and there's a two-centimeter step between the pallet deck and the roller surface. The load jams, or one end kicks up. The sneakier problem is width — the gaps on each side between the AMR-carried pallet and the conveyor rollers. The design used theoretical numbers. After installation, someone measured, and the two sides weren't even symmetric.
That's exactly what killed the Ontario project. The AMR hit its taught point every single time. The pallet went on, the left rollers took the load first, the right side floated, the pallet tilted, and the whole line alarmed out. It took two weeks to find the cause: a conveyor leg had settled, leaving a height difference of under two centimeters. Two centimeters. Invisible to the naked eye.
There's a trade-off worth settling early, too. Top-lift AMRs are the most sensitive to height mismatch; fork-style units tolerate more, but they demand specific pallet entry directions, which constrains the interface the other way. Don't spec the vehicle in isolation. The docking method and the interface tolerance are a package deal — decide them together.
So at acceptance, don't just watch whether the AMR stops on target. Bring a level and measure the height difference across the docking point. Write the height, levelness, and gap tolerances on both sides of the interface into your acceptance criteria, with the allowable deviation spelled out in black and white. And spec adjustable legs at docking stations. If the floor settles, you can re-level. Welded legs weld the risk in place.
Who Moves First?
The second pitfall lives in software. It's called the handshake. The AMR has arrived — does the conveyor know? The line pushed the load out — did the AMR actually receive it? Get the sequence wrong by one step and things break.
The classic failure scenes: the conveyor starts feeding before the AMR has fully stopped, and the pallet rams straight into the vehicle body. Or the AMR thinks it picked up the load, drives off, and the load is still sitting on the rollers — the robot proudly hauling nothing. The root cause is that the AMR fleet manager and the conveyor PLC speak different languages. Both sides have an "in position" signal, but they define it differently. To the AMR, in position means the navigation says so. To the PLC, it means a photo-eye is blocked. Half a second apart — and in that half second, the transfer goes wrong.
The fix? Draw the interface timing as a timing diagram and get both sides to sign it. How signals are exchanged (dry contacts or network messages), how long a timeout counts as a fault, who stops first on a fault — nail all of this down before joint commissioning, not on the floor mid-debug. The most robust pattern I've seen is double confirmation: the AMR signals arrival, the PLC answers with a permit, and the AMR only moves after receiving the permit. Half a second slower. Zero dropped loads. In warehouse automation, half a second slow is no shame. One dropped load is.
The Floor Gets a Vote
The third pitfall is under your feet. The docking spot is the most abused patch of concrete in the entire building.
The AMR stops, lifts, and turns at the same point dozens of times a day, with the full load concentrated on a few square feet. After a year, minor settlement or cracking at the docking point is nothing unusual. A centimeter or two of settlement and the AMR still stops dead-on — navigation doesn't care about floor height. But the lift mechanism has fixed travel. The floor sinks, and the pallet can't reach the roller surface anymore. Then there are expansion joints. If one happens to crack right under the docking point, the AMR rolls over it every cycle, the wheels jolt, positioning shudders, and your transfer success rate slides from 99% to 90% — and you have no idea why.
In that project, the floor was the last suspect. Everyone blamed the vehicle, then the conveyor, and only then got down on their knees to look at the concrete. My standing recommendation now: pour the docking area as its own high-strength slab, isolated from the surrounding floor, with expansion joints routed around the docking point. The civil work costs next to nothing. Rework is measured in months. For brownfield retrofits, put floor conditions in the upfront site survey and sweep the docking zone with a laser level. Don't trust your eyes.
Then a Human Walks In
The fourth pitfall is the most dangerous, because it touches safety. The docking zone is where people and machines mix the hardest: AMRs dock here, manual forklifts may drop loads here, and a maintenance tech might be under the conveyor adjusting something.
The logic should be simple: if a person is in the docking zone, no AMR enters; while an AMR is transferring, the conveyor doesn't move. But plenty of projects interlock only half the system. The AMR has laser scanners and stops fine — while the conveyor keeps running. Or the safety gate opens, the AMR stops, the PLC never got the signal, the rollers keep turning, loads keep coming, and the tech's hands are right next to the rollers.
Interlocking has to be bidirectional. The personnel-entry signal — safety gate, light curtain, safety mat — must go to both the AMR fleet manager and the PLC at the same time. Both stop, or it's not an interlock. Stopping one side is the same as locking nothing. At acceptance, run an intrusion test: simulate a person entering and verify that the AMR and the conveyor stop together, and that recovery happens in sequence rather than everything lurching back to life at once.
One detail that's easy to miss: the night shift. During the day, someone watches the docking area and handles small hiccups on the spot. At night you've got one or two operators. The AMR and the conveyor get into an argument at the docking point, the alarm rings for half an hour with nobody responding, and work-in-process piles up across the whole line. So build this into the interlock logic: if a docking fault exceeds a set time, suspend the task automatically and push an escalation alert. Don't let the equipment sit there arguing with itself.
Which brings me back to how the Ontario project ended. Four pitfalls, filled one by one, three months. The project manager told me that if he'd known the interface would be this much trouble, he'd have carved it out as its own work package with its own acceptance from day one. I couldn't agree more.
So here's a question to take with you: if your warehouse is about to deploy AMRs, will the docking-area floor, the conveyor, and the PLC signaling go to a single integrator as one turnkey package — or will the vehicle, the line, and the software each go to a different vendor? Your answer pretty much decides how much money you'll spend on the interface later.
