How Many AMRs Does a Factory Really Need A Practical Fleet Capacity Model

The Direct Answer: Size the Service, Not the Robot Purchase

A factory does not need “as many robots as possible,” and it rarely needs the number produced by dividing daily transports by operating hours. It needs the smallest fleet that can protect a defined material-service level during credible peak conditions, while still absorbing charging, maintenance, traffic variation and one or more agreed failure cases. That is the practical purpose of AMR fleet sizing.

The first-pass arithmetic is simple: convert peak transport demand into robot-minutes, divide that workload by the effective robot-minutes available per vehicle, round up, and then apply a clearly defined reserve policy. The engineering work is deciding what belongs in each term. A short travel-time demo, an average order count or a battery-runtime claim is not enough. The model must include the complete mission, the real mix of routes, station interaction, empty repositioning, expected unavailability and the service window production actually needs.

This guide creates an auditable pre-purchase model. It is designed to answer the buyer question how many AMRs do I need without pretending that one spreadsheet can reproduce every traffic interaction. The result is a defensible fleet range, a list of assumptions and a clear trigger for moving from arithmetic to simulation.

The Fleet Capacity Envelope: Four Ledgers Must Close

A useful sizing decision can be organized as a Fleet Capacity Envelope. Instead of treating robot count as one isolated calculation, the project closes four connected ledgers. If any ledger is incomplete, the fleet number may look precise while remaining commercially unsafe.

1. Demand ledger: how many transport missions each service class creates inside the relevant peak interval.
2. Mission-time ledger: how many robot-minutes each complete mission consumes, including empty travel, transfers, queues and release logic.
3. Effective-supply ledger: how much task-capable time one installed robot can actually provide after planned losses and operating headroom.
4. Constraint ledger: whether routes, intersections, stations, doors, elevators, chargers and control interfaces can accept the calculated flow.

This structure separates capacity from motion. A robot may be fast but wait at a conveyor. A fleet may have enough theoretical transport minutes but lose them to charger queues. A station may release work in bursts that an hourly average hides. Seven vehicles may satisfy the workload equation while a one-lane aisle prevents more than four from contributing productively. The count is valid only inside the operating envelope used to produce it.

This article focuses on the pre-purchase capacity decision. It does not duplicate the site's separate guides to fleet scaling and coordination logic, post-deployment AMR fleet KPIs, or charging strategy and fleet availability. Those topics become validation layers around the sizing model developed here.

Ledger One: Translate Production Demand into Transport Missions

Orders, pallets and production units are not automatically robot missions

The demand source may report orders, order lines, pallets, kits, totes, production cycles or finished units. None of those is necessarily equal to one robot movement. Before performing an AMR fleet size calculation, the team must define the conversion from business activity to executable missions.

One production order may create three line-side deliveries and two empty-container returns. One pallet request may require a robot to retrieve an empty carrier before collecting the load. A milk-run route may combine several station demands into one tour. A dual-load vehicle may move two containers in one trip only when destinations and release times are compatible. If the conversion rule is wrong, every later decimal place is false precision.

Create a from-to demand table for each transport family. Record the source, destination, load type, handling method, priority class, missions per interval, release pattern and required response time. The business objective should connect to actual production service. For example, the site's analysis of material response time explains why line protection can be more valuable than a simple labor-replacement count.

Use the peak interval that matches the service promise

Daily average demand is useful for energy and lifecycle planning, but it is usually weak evidence for fleet count. If 360 missions occur during an eighteen-hour day, the average is twenty missions per hour. That does not reveal whether sixty missions arrive between 08:00 and 09:00, whether requests surge for fifteen minutes after a changeover, or whether the final shipping wave creates a two-hour plateau.

The correct interval depends on the allowed response time. If line-side material must arrive within ten minutes, a one-hour average can hide an unacceptable burst. If finished goods may wait thirty minutes in a buffer, sizing against the worst individual minute may overstate the fleet. Analyze several windows—such as 15, 30 and 60 minutes—and retain the window that represents a real operational obligation. Do not multiply one abnormal five-minute spike by twelve unless the system must actually sustain that equivalent hourly rate.

Separate a peak from an exception

A peak is a planned or recurring demand condition the system is expected to serve. An exception is an unusual event that may justify a different response: delaying low-priority work, activating manual backup, adding temporary labor or accepting a controlled queue. Buying enough robots for every imaginable exception can be as poor a decision as sizing only for the average. The design basis should state which events the automated fleet must absorb and which invoke a documented fallback.

Demand variation needs a profile, not one maximum number

For each mission family, build at least three demand cases:

• Routine case: a representative stable operating period.
• Planned peak case: the busiest recurring mix the fleet is contractually or operationally expected to support.
• Degraded case: important demand combined with a defined loss, such as one unavailable charger, one blocked corridor or reduced station performance.

This is the foundation of credible AMR capacity planning. The output should be a service curve showing what demand can be protected under each condition, not a single magical integer detached from production risk.

Ledger Two: Measure the Complete Mission Occupancy

Start when the robot becomes committed, end when it can accept useful work again

The relevant AMR mission cycle time is not merely loaded travel time. It is the elapsed time for which a vehicle is committed to the mission and unavailable for another useful assignment. Depending on the control architecture, the clock may start when the dispatcher reserves the robot and end only after unloading is confirmed, the business transaction closes and the vehicle becomes eligible for reassignment.

A 2021 fleet-sizing study published in IFAC-PapersOnLine models transport through loading, loaded travel, unloading and empty travel phases. That decomposition is an important baseline, but an industrial buyer normally needs to add site-specific control and waiting states as well. See the research paper on sizing a homogeneous robot fleet.

The exact mission boundary depends on the application. A bare chassis reaching coordinates is not equivalent to a production transfer. The site's guide to the complete AMR/AGV working unit explains why the base, top module, station, sensors and controls must be evaluated as one working system. Their combined time belongs in the cycle.

Do not calculate travel time from maximum speed

Catalog speed is an upper limit under defined conditions, not a route average. Real travel includes acceleration, braking, turning, protective-field responses, door requests, pedestrian encounters and speed-zone changes. Loads can alter acceleration or allowed speed. Narrow aisles may force one-way access. A route that is 120 meters long may have a very different cycle from another route of the same distance if it crosses three shared intersections.

Use time studies from comparable vehicles in the actual or representative environment when possible. Before that evidence exists, split the route into operating segments and assign a credible speed and delay distribution to each. Record whether the estimate is measured, vendor-simulated, calculated or assumed. Official fleet calculators from KUKA and KINEXON expose variables such as orders per hour, route distance, turns, traffic, load/unload time, battery use and charging time. That breadth is a useful reminder that fleet count cannot be supported by distance alone.

Use a weighted workload when missions differ

Many plants have several routes and load types. Averaging all cycle times before considering their frequencies can distort the answer. Instead, calculate robot-minutes for each mission family and add them:

Peak robot workload (minutes/hour) = Σ [Di × Ti]

where Di is peak missions per hour for family i, and Ti is complete occupied minutes per mission for that family. This preserves the real workload mix. It also makes improvement choices visible: reducing two minutes from a high-frequency route may create more capacity than improving a long but rare mission.

Model the distribution when tails matter

An average eight-minute cycle can describe both a stable process that stays near eight minutes and an unstable process that ranges from four to twenty. Those systems require different buffer capacity. Capture at least a median and a high-percentile cycle time for critical routes. If a service promise is sensitive to the long tail, the model should test the tail rather than hiding it inside the mean.

Ledger Three: Convert Installed Time into Effective Supply

Availability and utilization are different deductions

Each installed robot contains sixty theoretical minutes per hour. The factory cannot schedule all sixty as productive mission time. Some minutes disappear because the vehicle is not task-capable; other minutes are deliberately left as operating headroom.

AMR fleet availability represents the fraction of scheduled time in which a robot is technically and operationally capable of accepting the mission class being modeled. Depending on the agreed boundary, losses may include scheduled charging, preventive maintenance, faults, manual recovery, battery temperature protection, unavailable top modules or software/network conditions that prevent task execution.

Target utilization is the share of that available time the design intends to commit under the scenario. It protects against release variability, imperfect dispatching, short queues, route imbalance and estimation error. Designing to 100 percent means any delay immediately becomes backlog. It also confuses motion with service: the site's separate KPI guide explains why maximum robot utilization can damage material-flow performance.

Effective supply per robot is therefore:

Effective robot-minutes/hour = 60 × A × U

where A is task-capable availability and U is the chosen workload limit. There is no universal correct value for either term. A low-criticality warehouse transfer, a just-in-time assembly feed and a sterile pharmaceutical workflow should not inherit the same assumptions.

Avoid double-counting the same loss

A conservative model is valuable; a confused model is not. If measured cycle time already includes normal traffic waiting, do not add all of the same waiting again through an arbitrary utilization reduction. If availability already includes planned charging, do not also subtract identical charging time from every cycle. If a probabilistic availability term already represents whole-robot failures, adding a full physical spare may be an additional resilience policy—not automatically a mathematical necessity.

Maintain an assumption register with four columns: loss, location in the model, evidence and owner. Each loss should appear once unless an explicit stress scenario intentionally compounds it.

Charging belongs in capacity even when runtime looks adequate

AMR charging downtime is not determined only by battery runtime. It depends on energy consumed per mission, usable state-of-charge window, charging rate, charger access, docking reliability, charger queues and the scheduling policy. Opportunity charging may distribute losses across a shift; scheduled charging may concentrate them in breaks; battery swapping transfers part of the constraint to people and spare batteries.

For first-pass sizing, planned non-mission charging can be represented in availability. Then perform a separate charger-capacity check using required charging minutes versus usable charger minutes in each operating interval. If charger demand peaks at the same time as transport demand, a daily energy balance can pass while production still fails. The site's charging strategy guide covers that resource calculation in depth.

Reserve must be tied to a failure policy

AMR reserve capacity is the installed capability intentionally held beyond the nominal calculation. It can be expressed as one compatible spare, an N+1 rule, a percentage, or enough uncommitted capacity to continue priority service after a defined loss.

One spare is not automatically sufficient. A heterogeneous fleet may have vehicles that cannot substitute for one another. A failed top module may remove only one mission class. A large fleet may require more than one simultaneous maintenance position. Conversely, a small noncritical process may accept reduced service and use manual contingency instead of buying an idle unit. State the protected event: “maintain all priority-A missions after loss of one compatible robot” is actionable; “include ten percent buffer” is not.

The First-Pass Equation and Its Boundaries

For one mission family, a practical screening equation is:

N = ceiling[(Dpeak × Tcycle) ÷ (60 × A × U)] + R

For multiple mission families:

N = ceiling[Σ(Di × Ti) ÷ (60 × A × U)] + R

This equation is an auditable workload screen, not a guarantee. It assumes that workload can be shared reasonably across compatible vehicles and that infrastructure does not impose a lower throughput ceiling. Those assumptions must be challenged after the arithmetic.

Worked Example: A Factory with Three Mission Families

Consider a factory sizing a homogeneous tugger-compatible fleet for its busiest recurring production hour. The team converts production releases into three mission families and uses route observations plus supplier simulation to estimate complete occupied cycle times.

The design team uses task-capable availability of 0.90 and a target utilization of 0.80 for this scenario. These are example assumptions, not industry benchmarks. Each installed robot therefore supplies:

60 × 0.90 × 0.80 = 43.2 effective robot-minutes/hour

The nominal active requirement is:

ceiling(251 ÷ 43.2) = ceiling(5.81) = 6 robots

The plant then applies an explicit N+1 policy because priority line-side deliveries must continue after one compatible vehicle is removed from service:

Installed fleet = 6 active requirement + 1 reserve = 7 robots

This is a much stronger answer than “seven robots should be enough.” It states the demand mix, mission boundary, availability, headroom and failure policy. Finance can price it, operations can challenge it, the supplier can simulate it, and acceptance engineers can test it.

Do not hide the sensitivity behind the rounded result

Small assumption changes can cross an integer boundary and add an entire vehicle. The team should therefore show scenarios rather than defend only one number.

The table does not automatically mean the factory should buy eight units. It creates a decision. The plant can buy eight, redesign the degraded mode so low-priority returns wait, add station or charger resilience, retain a manual backup method, or accept a lower service level during that event. Fleet sizing becomes an operating-policy choice rather than a vendor guess.

Ledger Four: Prove That Infrastructure Can Use the Calculated Robots

Pickup and drop-off stations have their own capacity

A station that requires ninety seconds per transfer can theoretically complete forty transfers per hour if work arrives perfectly and it is never blocked. Production rarely behaves that cleanly. A late operator, full outbound position, handshake retry or misaligned carrier creates variability. As station loading approaches its practical limit, queues can grow nonlinearly. Adding vehicles then creates more waiting robots, not more completed material moves.

For each shared station, calculate:

Station demand (minutes/hour) = Σ [missions using station × occupied station minutes]

Compare demand with usable station minutes under normal and degraded cases. Do not assume sixty fully usable minutes. Include clearing time, changeover, blocked-position behavior and the service headroom appropriate to production risk. If a shared pickup is the bottleneck, a second transfer position or different release logic may be more valuable than another robot.

Route capacity is shaped by conflicts, not only distance

Aisles, intersections, fire doors, elevators and pedestrian crossings behave like shared resources. The fleet equation assumes robots can convert their available minutes into useful work. A route network may break that assumption through mutual blocking, single-lane reservations or long resource occupancy.

Map every constrained segment and record which mission families use it, the direction of travel, average occupancy time and release rule. Pay special attention to places where a waiting robot blocks unrelated flow. The site's AMR traffic-management guide treats congestion and deadlock design separately; in the sizing decision, the essential point is that more vehicles can reduce marginal throughput once shared-route contention dominates.

Charger capacity must survive the same peak period

Confirm that the planned robots can obtain enough energy without creating a charging queue that consumes the reserve. Calculate energy or charging-minute demand across the production schedule, not only across a full day. Then test one unavailable charger, delayed docking and an aging-battery case if those conditions belong to the service envelope.

A fleet sized with 0.90 availability does not prove the charging system can actually deliver that availability. The charging layout, electrical supply, docking reliability and scheduler must make the assumption true.

Mission generation and station data can be the hidden bottleneck

A vehicle cannot serve a request that is created late, duplicated or missing required state. PLC, WMS, MES and middleware latency can add time before dispatch and after delivery. Manual confirmation can synchronize requests into bursts. If the source system releases thirty missions at the top of every hour, a model based on a smooth arrival rate will underpredict waiting.

This is why pre-purchase delivery feasibility must include controls and process readiness, not merely vehicle specifications. Fleet quantity cannot compensate for an undefined mission transaction.

When the Spreadsheet Must Become a Simulation

An arithmetic model is valuable because it exposes assumptions and rejects obviously unrealistic proposals. It should become a discrete-event or agent-based simulation when interactions materially determine the answer. Academic work has specifically used simulation to evaluate AMR fleet size under multi-robot task allocation; see the IEEE study on simulative fleet sizing. Simulation is not a decorative animation. It is a controlled experiment for testing timing, queues, dispatch rules and failure states before hardware is purchased.

Escalate to simulation when one or more of the following applies:

• missions arrive in bursts or depend on stochastic production events;
• several robot types have different payload, speed or task eligibility;
• routes contain narrow bidirectional aisles, elevators or high-contention intersections;
• multiple stations share limited buffers or synchronized machine windows;
• charging is interleaved with missions and charger queues can affect dispatch;
• priority rules may starve lower classes or cause frequent reassignment;
• the required response-time percentile matters more than average throughput;
• the fleet result changes with a small variation in cycle time or availability;
• a whole-unit, charger, route or station failure must be survived automatically.

What a credible simulation should preserve

The model should reproduce the actual route graph, mission-release pattern, speed zones, vehicle kinematics at a useful level, docking and transfer distributions, resource reservations, dispatch logic, battery/charging behavior and defined failures. The supplier should disclose which data are measured and which are assumptions. Results should include completed missions, queue time, response-time percentiles, station utilization, traffic delay, charging delay, mission backlog and the time required to recover after a disturbance.

Run several random seeds for stochastic models. One visually successful animation is not statistical evidence. Compare fleet counts around the arithmetic result—for example five, six, seven and eight active units—so the team can see where additional robots stop creating useful throughput. A 1993 analytical AGV design model already framed vehicle count against a material-transport waiting-time constraint; the continuing lesson is that service performance, not vehicle motion alone, should govern the number. See the INFORMS multivehicle AGV design study.

Turn the Calculation into an RFQ Data Package

A buyer should not ask vendors only, “How many robots do you recommend?” Give each qualified supplier the same operating data and require an auditable answer. This turns an AGV fleet calculation or AMR proposal into a comparable engineering submission.

Require suppliers to show the bridge from inputs to count

A proposal should state the mission boundary, time source, traffic assumptions, planned charging method, availability definition, utilization policy, reserve logic and infrastructure dependencies. If simulation was used, request the scenario matrix and key output distributions—not only the recommended count.

Also request the incremental capacity curve. The useful question is not only whether seven robots pass, but what six can support, which bottleneck appears first, and whether eight creates material improvement. This information helps the buyer phase investment, define expansion triggers and avoid paying for nominal capacity the site cannot use.

Make the sizing assumptions testable at acceptance

Every material assumption should become a test condition or tracked commissioning metric. If the proposal assumes a 7.5-minute delivery cycle, test it across representative routes, loads and traffic. If it assumes 0.90 availability, define the measurement boundary and observation period. If it promises N+1 service, remove one vehicle during a controlled peak test and verify that priority missions remain within the agreed response limit.

The site's AMR acceptance testing guide provides the broader FAT, SAT and operational-acceptance structure. For this article, the key rule is simple: a sizing assumption that cannot be observed, measured or challenged is not yet a procurement requirement.

Common Sizing Errors and Their Commercial Consequences

Using average daily demand

Consequence: the fleet looks adequate over a shift but builds a mission backlog during the period production cares about most. Correction: model demand over the response window and test planned peaks separately.

Using loaded travel only

Consequence: the calculation omits empty approach, transfer, queue and release time, so theoretical trips per hour cannot be achieved. Correction: measure commitment-to-release cycle time for every significant mission family.

Treating availability, utilization and reserve as one vague buffer

Consequence: stakeholders cannot tell which losses are protected or whether the proposal double-counts them. Correction: define each deduction independently and link it to evidence.

Assuming every robot is interchangeable

Consequence: the stated spare cannot serve the mission disabled by a top-module, payload or station-interface mismatch. Correction: calculate capacity by compatibility class before combining the fleet.

Buying robots to fix a station bottleneck

Consequence: queues and traffic increase while completed transfers remain capped by the workstation. Correction: close the station and shared-resource ledgers before approving the vehicle count.

Accepting one deterministic simulation run

Consequence: a favorable event sequence disguises queue tails and failure sensitivity. Correction: test distributions, multiple seeds, adjacent fleet counts and degraded scenarios.

Focused FAQ

How do you calculate the number of AMRs required?

Convert peak missions into robot-minutes by multiplying the demand of each mission family by its complete cycle time. Divide total robot-minutes by 60 × task-capable availability × target utilization, round up, and apply a separately justified reserve policy. Then check stations, routes and chargers before treating the result as a purchase quantity.

Should fleet count be based on average or peak demand?

Use average demand for lifecycle, energy and broad economic analysis, but use the relevant recurring peak interval for service capacity. The interval should match the allowed response time. A fifteen-minute burst may matter for a ten-minute line-feed promise even when the hourly average looks comfortable.

What utilization factor should be used?

There is no universal percentage. Choose a target based on demand variability, route contention, dispatch quality, station behavior, service criticality and confidence in the input data. Document which uncertainty the headroom covers, and avoid deducting losses already embedded in measured cycle time or availability.

How should charging be included in fleet sizing?

Represent planned periods when robots cannot accept missions within the availability term, then validate the assumption with a separate charger-minute or energy-capacity model. Test charging during the same peak schedule as transport, including queueing and at least the charger-failure condition required by the operating policy.

Is one spare AMR always enough?

No. Reserve policy depends on fleet size, failure probability, maintenance practice, service criticality and interchangeability. A spare without the correct top module or station interface cannot protect the affected mission class. Define the loss to be survived and the service that must continue.

Can adding more robots reduce throughput?

Yes. Once intersections, narrow aisles, stations or chargers become highly contended, additional vehicles may add waiting and blocking faster than useful capacity. This is why mobile robot fleet capacity must be checked at system level rather than inferred from the sum of individual robot ratings.

When is simulation necessary?

Simulation is appropriate when bursty arrivals, mixed vehicles, shared resources, route conflicts, charging queues, priority rules or failure scenarios materially influence response time. Use the spreadsheet to establish an order of magnitude and expose assumptions; use simulation to test interactions and distributions.

How should multiple mission types be handled?

Calculate workload separately for each family using its own peak demand and complete cycle time, then sum the robot-minutes for compatible vehicles. Do not use an unweighted average cycle. If vehicles are heterogeneous, solve each compatibility group and shared-resource interaction explicitly.

What is the difference between uptime and task-capable availability?

A robot may be powered on and connected yet unable to perform a particular mission because its top module, battery state, load interface, localization confidence or required station is unavailable. Task-capable availability uses the operational capability needed by the modeled service, making it more useful than generic uptime for sizing.

What evidence should an AMR vendor provide?

Request the demand conversion, cycle-time breakdown, route and station assumptions, availability boundary, utilization rationale, charging model, reserve policy, simulation scenario matrix, adjacent fleet-count comparison and acceptance method. A number without this evidence is an estimate, not an engineered commitment.

The Decision Should Be Auditable, Not Optimistic

A defensible fleet decision begins with material service. It identifies the demand that must be protected, converts each mission into complete occupied time, reduces theoretical supply through transparent availability and workload assumptions, and then tests whether infrastructure can use the result. That is the difference between buying a quantity of robots and engineering production capacity.

The calculation may recommend seven vehicles, but the real deliverable is larger: a demand profile, cycle-time ledger, assumption register, bottleneck map, degraded-mode policy and acceptance plan. Those artifacts allow the model to be updated when product mix, layout, station time or charging behavior changes. They also make vendor proposals comparable.

The strongest answer is therefore not “you need seven AMRs.” It is: “seven installed vehicles protect these mission classes during this defined peak, under these measured cycle times, with this availability boundary, this utilization headroom, this reserve event and these validated infrastructure constraints.” That statement can be priced, simulated, tested and improved. It turns fleet quantity from sales intuition into an operating decision.

#AMRFleetSizing #AMRFleetSizeCalculation #AGVFleetCalculation #AMRCapacityPlanning #MobileRobotFleetCapacity #AMRMissionCycleTime #AMRFleetAvailability #AMRChargingDowntime #AMRReserveCapacity #IntralogisticsEngineering #FactoryAutomation #MobileRobotics