Smart warehouse / Article
AMR Fleet Sizing: How Many Robots Your Throughput Actually Needs
Fleet size is arithmetic before it is engineering. Count the moves your floor needs in its peak hour, build a cycle time for one move from round-trip distance plus load, unload and queue time, convert that into effective moves per robot per hour with a utilisation factor, then divide. A 180-second cycle gives about 20 theoretical moves an hour, or 16 at 80 percent utilisation, so a floor needing 100 moves in its peak hour needs about seven robots plus a spare. That model gets you to the right order of magnitude in an afternoon. What it cannot see is congestion, lifts, doors and handover queues, which is why the number gets proven in simulation before anyone buys steel.
The model in four numbers
01 / The unit of the problem
An AMR fleet is sized in moves, not orders
The first mistake in fleet sizing is bringing the wrong unit to the table. Orders, lines, pallets shipped and tonnes handled are all business measures. A mobile robot does not experience any of them. It experiences a trip: go somewhere, pick up a load, go somewhere else, put it down, and become available again. So the question is not how many orders you ship. It is how many discrete transports your floor performs, and how many of those you want a machine to do.
Getting that list right is an hour of work and it is the highest-value hour in the exercise. Walk the floor and write down every repeating transport: receiving dock to inspection, inspection to putaway, storage to pick face, pick face to consolidation, consolidation to dispatch staging, line-side replenishment to production, finished goods off the line to the warehouse, empty pallet and trolley returns. Count each one in the peak hour, not across the day. Empty returns are the item most often missed, and on some floors they are close to half the total trips.
Then separate the moves that are genuinely repetitive from the ones that are not. Automation earns money where the same movement repeats, the distance is real, and the route may change. A move that happens twice a week, or that requires judgement about what to bring, is not a fleet-sizing input. It is a job for a person. Being honest here shrinks the fleet, which is the point.
Payload changes the move count
Before you count trips, decide what a trip carries, because consolidating loads is usually a bigger lever than shaving seconds. Our Latent Lift AMRs carry from 60kg to 3,000kg and move pallets, racks and trolleys, and our Forklift AMRs carry 1,500kg to 3,000kg with a lifting height of 1,000 to 4,000mm for pallets and cages. A machine that lifts a whole rack of totes where an operator previously made six trolley trips has not sped anything up. It has removed five moves from the model.
02 / The arithmetic
Four numbers, one division
Here is the whole model. It fits in four lines and it is worth doing by hand before any vendor conversation, because it tells you whether you are discussing three robots or thirty.
Travel time is where estimates go wrong, so build it rather than guess it. Take the round-trip distance including the return leg, and divide by a realistic average speed rather than the top speed on the datasheet. A machine specified at 1.5 metres per second on an open test floor will average considerably less across a real warehouse with corners, doors, pedestrian crossings and other robots. If you have no better information, halving the specified speed is a defensible planning assumption until simulation gives you a real figure.
Published benchmarks give you a sanity check on the result. One worked vendor example models a 20 metre average round trip with 40 seconds of travel and 20 seconds of load and unload, giving a 60-second cycle, and derates a nominal 360 cartons per hour to roughly 288 at 80 percent utilisation. Another puts a mid-size goods-to-person tote cycle at 90 to 120 seconds including travel, dock handoff and minor queuing, supporting roughly 30 to 40 picks per hour per robot. If your own arithmetic lands far outside those bands, check your speed assumption first.
03 / Worked examples
The same floor, four different answers
Distance and load time dominate the result, which is why two warehouses with identical volumes can need very different fleets. These four rows use the same model with a utilisation factor of 0.8 and no spare margin, so you can see the mechanism rather than a recommendation.
| Scenario | Round trip | Cycle time | Effective moves per robot per hour | Robots for 100 peak-hour moves |
|---|---|---|---|---|
| Tight cell, short hop | 40m | 80 sec: 50 travel, 30 handling | 36 | 3 |
| Typical single-building flow | 120m | 180 sec: 120 travel, 60 handling | 16 | 7 |
| Long run with a door | 240m | 320 sec: 240 travel, 60 handling, 20 door and queue | 9 | 12 |
| Long run, load consolidated 2 to 1 | 240m | 340 sec, but each trip carries two loads | 19 loads | 6 |
Scroll the table sideways on a phone / Illustrative arithmetic at 0.8 utilisation, before spare margin
Read rows three and four together, because they contain the most useful finding in the whole exercise. The distance did not change and the cycle got slightly longer, but carrying two loads per trip halved the fleet. Before you buy robots to absorb distance, check whether you can absorb it with payload, batching or a better handover point. That is a design decision worth more than any discount.
Row two is the shape of most Malaysian single-building operations we scope: a real distance, moderate handling time, and a fleet in the mid single digits rather than the dozens. Larger fleets are real but they belong to a different problem. Published deployment data notes a median new AMR deployment of 15 robots in 2024 rising to around 35 per facility by 2026 as operators expand beyond pilots, which is high-volume e-commerce territory rather than typical manufacturing intralogistics.
04 / Peak, not average
A fleet sized on the average is late every day
Almost no warehouse has a flat day. There is a receiving surge when the containers arrive, a dispatch wave before a courier cut-off, a lull over lunch, and a shift changeover where nothing moves at all. A fleet sized on the daily average will clear the day's volume and still miss the cut-off, because the volume did not arrive evenly.
Industry guidance on fleet sizing is unambiguous on this point, listing the inputs as the distances robots must cover between zones, peak throughput targets measured in required transports per hour rather than average daily volume, the number of open destination targets available at any moment, and the sequencing logic. The same source makes the counter-intuitive point clearly: a large facility with short travel distances and moderate throughput can be served by fewer units than a smaller facility dominated by high-frequency multi-zone picking. Floor area tells you almost nothing. Trips per hour and distance per trip tell you everything.
Two disciplines keep the peak rule from inflating your fleet. First, define the peak rather than adopting the worst hour ever recorded. Take the busiest hour of a normal busy week, and handle genuine annual spikes with overtime, a temporary hire or a rented unit rather than permanent capital. Second, decide what may legitimately queue. If empty trolley returns can wait twenty minutes during the dispatch wave, they are not peak-hour moves and should not be counted as such. Priority rules in the control layer are considerably cheaper than robots.
The scale-up advantage is real, and it has a boundary
A mobile fleet scales up for peak and down for quiet periods without re-engineering the layout, because the route lives in software rather than in the floor. That is a genuine structural advantage over conveyor, and it means sizing for today's defined peak and adding units as volume grows is a sound strategy. What does not scale as easily is the infrastructure around the fleet: charging positions, handover stations, door widths and lift capacity. Plan those for the fleet you expect in three years even if you only buy this year's robots.
05 / Where the arithmetic breaks
Robots interfere with each other
The model above treats each robot as independent. They are not. They share aisles, intersections, doors, lifts and handover points, and past a certain density they start queueing for each other. Adding the tenth robot to a congested floor buys less throughput than the second one did, and on a badly laid out floor it can buy almost none.
Operators manage this with an explicit ceiling. One account describes capacity logic driven by fleet density, where operators set a congestion threshold, for example a limit of eight robots per 1,000 square metres, because exceeding it increases latency. The cost of ignoring it is invisible at robot level and severe at fleet level: analytics reporting describes a single intersection generating 47 minutes of cumulative wait time across 12 robots in an hour, cutting effective throughput by 18 percent, with no individual robot mission status flagging a problem.
Four other constraints regularly override the division sum, and every one of them is a layout question rather than a robot question. Single points of passage: one fire door, one lift, one ramp that the whole fleet must cross. Destination availability, because a robot with nowhere to drop its load is a robot waiting, which is why open destination count is a sizing input in its own right. Charging strategy, since opportunity charging in gaps behaves very differently from taking a unit out of service for a full charge. And the handover itself, where a station that cannot receive at the rate robots arrive turns your fleet into a queue.
The practical consequence is the one honest sentence in every fleet-sizing exercise: layout moves the answer more than robot choice does. One vendor puts a figure on it, noting that small changes to zone layout or next-bay handoffs can change fleet count by plus or minus 30 percent. Academic work on the problem reaches the same conclusion from the other direction, finding that in robotic warehouse systems performance changes significantly not only with the number of robots but with which tasks are assigned to which robot.
06 / Simulation
The arithmetic gives a number. The model gives the answer.
This is why our sequence puts design and simulation between the floor study and the build. We design the layout and simulate throughput, so the system is proven before install. For a mobile fleet specifically, simulation is where four things surface that no spreadsheet will show you.
That last row matters more than the fleet number. A robot fleet is bought when the route is the cost, and automated storage is bought when the building is the cost. We set out the test in AMR vs AGV vs conveyor, and the reason a fleet is preferred over fixed infrastructure is change: a mobile robot carries its route in software, so re-slotting the floor or adding a delivery point is a configuration change rather than a construction project.
One prerequisite sits underneath all of it. A fleet acts on what your records say, so it will collect from the location the data names, promptly and without judgement. If your stock count cannot be trusted, a fleet will move the wrong things faster than a person would have. That is a data project, and it comes first.
07 / On your floor
Bring us your peak hour. We will bring the model.
The fastest way to get a defensible fleet number is to arrive with three things: a list of repeating moves with peak-hour counts, a floor plan with the routes marked, and the load each move carries. With those we can run the arithmetic in a meeting and tell you whether this is a three-robot conversation or a fifteen-robot one, which is usually the question that actually needs answering first.
After that the sequence is fixed, because the expensive mistakes all happen before installation. Floor study: flows, volumes, SKU profile, real distances, door and lift constraints, where the queues form today. Design and simulate: layout and throughput proven in a model against your own volumes. Deploy: install, commission, integrate with your WMS and train your team. Navigation on our Latent Lift AMRs is QR and Laser SLAM with 360-degree obstacle avoidance, and Laser SLAM on the Forklift AMRs, so no rails or floor infrastructure are installed to carry the routes.
CODETRACE integrates on site from Shah Alam in Selangor and Batu Kawan in Penang, so the team that models your fleet is the team that commissions it. For plants where the movement layer connects into production rather than only dispatch, the same simulation discipline extends upstream into factory automation.
Count the peak-hour moves. Build one honest cycle time. Then divide, and simulate.
FAQ / AMR fleet sizing
Questions, answered.
01How do I calculate how many AMRs I need?
Use four numbers. First, peak-hour moves: how many transports the floor needs in its busiest hour, not its daily average. Second, cycle time per move: round-trip travel time plus load, unload, queue and door time. Third, effective moves per robot per hour: 3,600 divided by cycle time, then multiplied by a utilisation factor of about 0.75 to 0.85 to account for charging, congestion and waiting. Fourth, divide peak-hour moves by effective moves per robot and round up, then add roughly 10 percent spare for availability. A move that takes 180 seconds gives about 20 theoretical moves an hour, or 16 at 80 percent utilisation, so 100 peak-hour moves needs about seven robots.
02Why size on peak rather than average?
Because a fleet sized on the average is late every day at the same time. Almost every warehouse has an uneven day: a receiving surge in the morning, a dispatch wave before a cut-off, a shift changeover where nothing moves. Industry guidance is explicit that peak throughput targets should be measured in required transports per hour rather than average daily volume. The corollary is that peak should be a defined peak, not the worst hour ever recorded, and that a fleet can be scaled up later for genuine growth without re-engineering the layout.
03What cycle time should I assume?
Build it rather than assume it, from round-trip distance divided by a realistic average speed, plus load, unload, queue and door time. Published benchmarks give a sense of scale: a 20 metre round trip with 20 seconds of load and unload works out at about 60 seconds per trip, while a mid-size goods-to-person tote cycle including travel, handoff and minor queuing is commonly modelled at 90 to 120 seconds. The mistake to avoid is using top speed. Real average speed over a shared floor with doors, corners and pedestrians is a fraction of the specification sheet figure.
04Does doubling the fleet double throughput?
No, and this is the most important non-linearity in the model. Robots share aisles, intersections, lifts, doors and handover points. Beyond a certain density they queue for each other, so each additional robot adds less than the last. Operators manage this with a congestion threshold, for example a limit on robots per thousand square metres, because exceeding it increases latency across the whole fleet. Waiting time at a single busy intersection can remove a material share of effective throughput without any individual robot appearing to fail.
05Can I start small and add robots later?
Yes, and that is one of the main advantages of mobile robots over fixed conveyor. The fleet scales up for peak and down for quiet periods without re-engineering the layout, because the route lives in software rather than in the floor. The practical approach is to size the fleet for today's defined peak, prove it, then add units as volume grows. What does not scale as easily is the infrastructure around the fleet: charging positions, handover stations, door and lift capacity. Plan those for the fleet you expect in three years even if you buy the robots for this year.
06What does payload have to do with fleet size?
Payload sets how much moves per trip, which changes the move count directly. A robot carrying one tote at a time and a robot carrying a full pallet are doing different jobs at different cycle times. CODETRACE Latent Lift AMRs carry 60kg to 3,000kg and move pallets, racks and trolleys, while Forklift AMRs carry 1,500kg to 3,000kg and lift from 1,000 to 4,000mm for pallets and cages. Choosing the machine that consolidates several current trips into one is often a bigger lever on fleet count than tuning cycle time.
07How does CODETRACE size a fleet?
We do not sell robots on day one. We walk your floor and map flows, volumes, SKUs and space, then design the layout and simulate throughput so the system is proven before install, then deploy: install, commission, integrate with your WMS and train your team. Simulation is the step that matters most for fleet sizing, because the arithmetic gives you a starting number and the model tells you what the floor will actually do with congestion, doors, lifts and handover queues in the way. Systems are engineered and supported from Shah Alam in Selangor and Batu Kawan in Penang.
Sources / Every figure in this article
Where the numbers come from
Sources are listed by what they are rather than by brand name. Only the last entry is peer-reviewed. The cycle-time and fleet-density figures come from companies that sell or integrate mobile robots, so read each one as a well-informed benchmark rather than a guarantee. The arithmetic itself is standard queueing logic and belongs to nobody.