Automating Pallet Handling with AMRs in a Running Warehouse: Where to Start

Getting a robot to drive between the racks is, today, the easy part. Anyone automating pallet movement in a warehouse that is already working runs into the other half of the problem: getting that vehicle into a building designed for people and forklifts, and doing it without switching off production on the day it goes live. Brownfield projects almost always trip there — on the surroundings, not the vehicle. The floor that isn't as flat as it looks. The aisle too narrow for two. The host system that can't tell a machine where to go. So it pays to turn the usual order around and start from the building and the flows it already has, asking which of those flows is ready to give way first to a machine.

Start with the shuttle nobody wants to run any more

The first flow to automate is the most boring one on the floor: the shuttle a forklift repeats, identical, dozens of times a shift, always between the same two points. Dock to storage. End of line to warehouse. The back-and-forth between two distant bays. These routes are fixed, predictable and medium-to-long, and that's exactly why an AMR absorbs them well. A 120-metre shuttle run forty times a shift is close to 10 kilometres a day of driving that adds nothing to the product, only an operator's hours and a truck's wear. On two shifts those numbers double, and that is where material handling stops being a detail and becomes a cost line with a name.

The rule for choosing, then, is a combination of three things more than volume itself: fixed endpoints, high frequency, and a distance worth the trip. Where even one of the three is missing, automation loses ground. Non-standard picking, the occasional load, the oversized part that changes destination every time: these stay more efficient with an operator and a forklift, and putting them at the top of the list is the fastest way to make a project look disappointing that would have paid off elsewhere. The link between a building and an external yard on asphalt is a case of its own: often repetitive and attractive, but crossing the threshold between inside and out adds ramp gradients, a different surface under the wheels and a jump in light that localisation has to handle. Treat it as a second phase, not as the fleet's baptism.

People, forklifts and AMRs in the same aisle

An AMR is built to give way. It detects a person or an obstacle and slows, stops, waits: that's what makes it safe, and it's also what caps its output when you put it in an aisle used by driven forklifts in a hurry. The standard governing the safety side is ISO 3691-4:2023 for driverless industrial trucks: it requires the system to detect people across the full width of the vehicle and in the direction of travel, with safety-rated reduced speed and protective stops, and the Performance Level demanded of each safety function, from ISO 13849-1:2023, isn't a matter of taste: it follows from the site risk assessment. This is something to require, not to negotiate.

What the standard doesn't settle, and what actually settles real throughput, is how the flows cross. There is no middle road here: either you separate the routes, with dedicated aisles, time windows, floor marking and right-of-way rules written down before anyone improvises them, or you accept that every meeting with a driven forklift slows the AMR, and that the cycles-per-hour figure on the datasheet never shows up on the floor. A busy two-way corridor is the worst place to debut a fleet; the same flow, moved onto an aisle the vehicles don't have to contest with anyone, changes the numbers entirely. Preparing the operating zones, in fact, is an explicit part of ISO 3691-4:2023, which devotes an annex to it. It is not an accessory to the project. It is the project.

What the building asks before the quote

Before comparing models it pays to know whether the building is ready, because much of the cost and delay in a brownfield project comes from the surroundings, not the vehicle. These are checks you make on a walk-through, with a tape measure and a critical eye, and they change the quote more than any datasheet:

• Floor. Flatness and the state of the joints affect vehicle localisation and the stability of the raised load; manufacturers state tolerances that have to be verified on the real floor, not the one in the render. Cracks, steps and wide joints are a problem to fix before, not during.
• Aisles. Usable width is not the vehicle's width: it's the vehicle plus the load plus lateral safety margins, and for two-way traffic it doubles, with a central clearance. An aisle that fits a forklift may not fit an AMR that has to keep its clearances.
• Charging. Stations go where they don't get in the way and where there is the electrical power to feed them; opportunity charging, in short intervals during the natural breaks in the cycle, keeps vehicles available longer than deep discharge with a battery swap, but it has to be planned into the layout from the start.
• Network and signage. Continuous communication between vehicles and fleet control needs coverage with no holes along the routes; signage and operating zones are drawn together with the safety design, not added afterwards.

None of these points is exotic, and that's exactly why they get taken for granted. It's the reason a technically correct automation sometimes returns half of what was planned: the vehicle does its job, but the building works against it.

The vehicle can move; the WMS decides where

An AMR left to itself can go from one point to another, and nothing else. The missions (which pallet, from where, to where, when) are generated by the host system, and without a hook into the WMS or ERP you get a machine that drives beautifully and that someone has to dispatch by hand: a cart dispatched by voice, not an automated flow. Real integration lives in the details you don't see in a demo: who tells the fleet a pallet is ready at the end of the line, how the vehicle confirms the completed drop back to the system, what happens when the destination is occupied. That's the layer where a project becomes genuinely automatic or stays a showy experiment.

Above the individual vehicles sits fleet orchestration, which assigns missions, manages traffic, sets priorities and sends vehicles to charge without stopping the service. Interoperability enters here, and it's a choice that weighs over the long run: the VDA 5050 interface, now at version 2.1.0 published by VDA and VDMA in January 2025, defines in a uniform way how a central control sends transport orders to vehicles and how vehicles report status and position, using MQTT messages with JSON payloads and describing routes as nodes and edges that each vehicle interprets with its own navigation. Adopting it lets you coordinate vehicles from different manufacturers in one fleet and grow that fleet over time without being tied to a single supplier. It is an industry recommendation, though, not a binding standard: write it into the order and the specification, or you won't get it, and you discover the lock-in on the day you need the second vendor.

How many vehicles you need, and why the number is usually wrong

Fleet sizing is a ratio that is simple to write and easy to get wrong: missions required per hour divided by the missions a vehicle runs in an hour, where the denominator is never the catalogue value because it has to be discounted for charging, traffic and slowdowns at crossings. The formula is trivial; what betrays you is the figure you feed it. A fleet tuned to the average of any given week passes acceptance and then buckles at the first serious peak: if the survey counts 300 missions a day and the seasonal peak asks for 480, the gap arrives once the vehicles are already on the floor, and the project that passed every test can't carry the day that matters. It's a classic blind window: the check happened, and it happened at the wrong time.

The cure isn't to oversize for caution, which means paying for idle vehicles eleven months a year, but to measure the flows over a period that includes the real peak and to design the fleet to grow with it. That's the second advantage of interoperability: on a scalable fleet you meet the peak by adding vehicles, not by redoing the project, and the busy season becomes a short-term rental line instead of a bottleneck. It's worth stating in the specification the way you state a requirement: the minimum fleet that carries the measured peak, and the way you add to it when the peak grows.

Who signs off a mixed-brand fleet

For ultrasonics or radiography there's a clean pair of standards: one says how the inspection is run, another says when the result is accepted. For AMRs that pair, on the performance side, doesn't exist: there's a solid safety standard, ISO 3691-4:2023, but the performance acceptance criterion (how many pallets per shift, with what reliability, under which conditions) is written by no standard. The owner writes it, and a site acceptance test verifies it. Knowing this changes the posture: the performance specification is a document you have to produce, not a box to tick.

On safety, by contrast, responsibility needs care once the fleet is mixed. Each vehicle carries its own conformity and marking, today under Machinery Directive 2006/42/EC and, from 20 January 2027, under the new Machinery Regulation (EU) 2023/1230 that replaces it. But a set of vehicles from different manufacturers, coordinated by a fleet control and integrated into the plant, can amount to new machinery or an assembly of machinery, and at that point someone has to take on the conformity of the system, not just of the individual vehicles. VDA 5050 settles how the vehicles talk to each other, and stops there: the safety conformity of the assembly stays a separate question, one to assign to someone. It's the question to put on the table before signing, who declares the conformity of the assembly and who verifies it, because finding yourself without an answer after acceptance is the most expensive way to learn it.

Written out, the part of the specification that holds all this together reads like one line:

Dock→storage flow: 480 missions/shift at peak, 2 shifts — vehicles compliant with ISO 3691-4:2023, Performance Level of safety functions per ISO 13849-1:2023 and the risk assessment — person detection across the full width and in the direction of travel — fleet orchestration via the VDA 5050 2.1.0 interface — WMS integration with mission generation and confirmation — acceptance on a measured peak week, not on an annual average — conformity of the assembly and the party declaring it defined in the contract.

Hand a supplier a line like that and you've raised the bar: you're asking for an offer on a whole flow, and that's the kind of request only a serious partner can answer.

To explore available technologies and configurations, see the PITECH industrial automation, robotics and material handling page and the page on autonomous robotic forklifts for pallet movement. For the safety and coexistence side of shared flows, the deep-dive on how AMRs reduce handling injuries is also useful — a topic whose economic weight, in lost days and indirect costs, is documented by EU-OSHA.

Starting well in a running warehouse comes down, in the end, to a sequence somebody has to write before looking at any vehicle: one repetitive, fixed flow chosen first, the aisles and time windows that separate it from driven traffic, floor and charging verified on a walk-through, the WMS hook that generates the missions, and a vehicle count figured on the real peak. That's the distance between a robot that drives and a flow that produces, and it's measured on the floor before it's measured in a quote.