AMR Fleet Sizing: Travel Time, Congestion, Charging, Availability and Queueing Effects

Key takeaways #

• Raw demand is the anchor: The formula N_raw = λ × t_service (Erlang-style traffic intensity) is the only defensible starting point; all other corrections are multipliers applied to this base.
• Availability is a divisor, not an adder: A fleet with 90% availability requires roughly 11% more robots than the raw count, but this is only valid if failures are independent and the repair process is stationary.
• Charging is a time tax: Opportunity charging during idle windows can reduce the effective charging penalty, but only if the mission queue allows for sufficient dwell time at charging zones.
• Congestion is non-linear: Travel time degradation due to congestion follows a quadratic or exponential relationship with robot density; linear assumptions are only valid at very low traffic levels.
• Queueing effects dominate at high utilization: When fleet utilization exceeds 70–80%, the average mission wait time grows hyperbolically, meaning that adding a single robot can have a disproportionate effect on system performance.
• Validation is mandatory: The equations here are for pre-feasibility and conceptual design; final fleet size must be validated with discrete-event simulation (DES) and on-site commissioning trials.

Raw demand: defining λ and t_service #

The foundation of any fleet sizing exercise is the raw transport demand, which is the product of the mission arrival rate and the average service time per mission. This is not a heuristic; it is a direct application of Little’s Law, which states that the long-term average number of items in a stable queueing system equals the average arrival rate multiplied by the average time spent in the system. In the context of AMR fleets, the “items” are the robots themselves, and the “system” is the set of all active missions.

We define the raw fleet size as:

N_raw = λ × t_service

Where:

• λ (lambda) is the average arrival rate of new transport missions, expressed in missions per hour (missions/h). This is typically derived from the upstream production rate or order arrival rate.
• t_service is the average time a robot is occupied with a single mission, from the moment it accepts the mission to the moment it is free to accept the next one, expressed in hours (h).
• N_raw is the raw number of robots required to handle the demand if the system were perfectly efficient (no downtime, no charging, no congestion), expressed as a dimensionless count.

It is critical to understand that t_service is not merely the travel time from point A to point B. It includes the following components:

• Travel time: The time to traverse the path from the robot’s current position to the pickup point, and then from the pickup point to the drop-off point.
• Load transfer time: The time to physically pick up the load (e.g., via forks, conveyor interface, or lift mechanism) and the time to deposit it.
• Interface wait time: The time spent waiting at the pickup or drop-off point due to interaction with other equipment (e.g., a conveyor that is busy, a door that is closed, or a human operator who is not ready).
• Administrative time: The time for mission acceptance, navigation initialization, and any required safety checks.

In practice, t_service is a random variable, not a constant. The correct approach is to use the mean value for the raw calculation, but to track the variance for the queueing analysis. A common mistake is to use the median or the mode, which can significantly understate the required fleet size when the distribution is skewed.

Illustrative assumption: For a typical pallet-moving application in a 10,000 m² warehouse, with average travel distances of 150 m for the loaded move and 120 m for the empty repositioning, an average speed of 1.5 m/s, and load transfer times of 30 seconds per pick and 30 seconds per drop, the mean service time might be approximately 4.5 minutes (0.075 h). This is an illustrative assumption, not a sourced figure, and must be replaced with site-specific data.

Availability correction: the uptime divisor #

No robot operates 100% of the time. Robots experience unplanned downtime due to mechanical failures, software errors, safety stops, and human intervention. The availability correction factor accounts for this by dividing the raw fleet count by the fleet’s operational availability.

The corrected fleet size for availability is:

N_avail = N_raw / A

Where:

• N_avail is the fleet size required after accounting for availability, expressed as a dimensionless count.
• A is the operational availability, defined as the fraction of time the robot is in a state to perform its intended function, expressed as a dimensionless ratio between 0 and 1. It is calculated as A = MTBF / (MTBF + MTTR), where MTBF is Mean Time Between Failures (in hours) and MTTR is Mean Time To Repair (in hours).

This correction is straightforward, but it carries a hidden assumption: it assumes that the demand is continuous and that a failed robot cannot be compensated for by other robots working faster. In reality, if the fleet has excess capacity, a single robot failure may not impact throughput. However, for the purposes of a conservative sizing calculation, we assume that all robots are required to meet the demand.

The availability correction is linear, which means that a fleet with 80% availability requires 25% more robots than the raw count (1 / 0.8 = 1.25). This linearity is valid only when the failure and repair processes are stationary and independent. If failures are correlated (e.g., a fleet-wide software bug or a facility-wide power issue), the availability correction is insufficient, and a more detailed reliability model is required.

Illustrative assumption: For a modern AMR fleet, an operational availability of 90–95% is a reasonable planning target, but this is an illustrative assumption. The MTBF and MTTR values must be obtained from the robot manufacturer or from historical fleet data. A fleet with an MTBF of 200 hours and an MTTR of 10 hours has an availability of 200 / (200 + 10) = 0.952, or 95.2%.

It is important to note that the availability correction does not account for scheduled maintenance. If the facility operates 24/7 and the robots require 1 hour of scheduled maintenance per day, this must be treated as a reduction in availability or as an additional time tax. The simplest approach is to include scheduled maintenance in the MTTR calculation, but this is only valid if the maintenance is performed during periods when the robot would otherwise be idle.

Charging correction: the battery time tax #

Battery charging is a fundamental constraint for battery-electric AMRs. Unlike internal combustion engines, which can be refueled in minutes, battery charging takes hours, and the charging process must be scheduled within the operational day. The charging correction accounts for the time a robot spends plugged in and unavailable for missions.

The corrected fleet size for charging is:

N_charge = N_avail / (1 – f_charge)

Where:

• N_charge is the fleet size required after accounting for charging, expressed as a dimensionless count.
• f_charge is the charging fraction, defined as the fraction of time a robot spends charging, expressed as a dimensionless ratio between 0 and 1. It is calculated as f_charge = t_charge / (t_charge + t_operate), where t_charge is the time spent charging per operational cycle (in hours) and t_operate is the time spent operating per cycle (in hours).

The charging fraction is a function of the battery capacity, the robot’s power consumption, and the charging power. A simple energy balance gives:

f_charge = (P_avg × t_operate) / (P_charge × t_charge)

Where:

• P_avg is the average power consumption of the robot during operation, expressed in kilowatts (kW).
• P_charge is the charging power, expressed in kilowatts (kW).

In practice, the charging fraction is often determined empirically. A robot that operates for 6 hours and then requires 2 hours of charging has a charging fraction of 2 / (2 + 6) = 0.25, meaning that 25% of its time is spent charging. This is an illustrative assumption, not a sourced figure.

There are two distinct charging strategies that affect the charging fraction:

• Opportunity charging: The robot charges during natural idle periods, such as between missions or during shift changes. This can reduce the effective charging fraction because the robot is charging during time that would otherwise be wasted. However, opportunity charging requires a charging station at a convenient location and a mission queue that allows for dwell time.
• Battery swapping: The robot’s battery is manually or automatically swapped for a charged one. This reduces the charging time to the time required for the swap (typically 5–10 minutes), but it requires a battery inventory and a swapping station.

The charging correction is a divisor, similar to the availability correction. A fleet with a charging fraction of 20% requires 25% more robots than the availability-corrected count (1 / (1 – 0.2) = 1.25). This is a significant penalty, and it is often the single largest correction factor in the fleet sizing calculation.

Important note: The charging correction assumes that charging is a stationary process, meaning that the robot charges at a constant rate and that the charging time is proportional to the operating time. In reality, battery charging is non-linear (the charging rate decreases as the battery fills), and the battery’s state of health degrades over time. For a conservative estimate, use the worst-case charging time (i.e., the time to charge from the minimum allowed state of charge to 100%).

Congestion correction: travel time degradation #

Congestion is the most complex and often the most underestimated correction factor in AMR fleet sizing. As the number of robots in a facility increases, the average travel speed decreases due to traffic conflicts, intersection blocking, and path re-planning. This is a non-linear effect: doubling the number of robots can more than double the travel time.

The congestion correction is applied to the travel time component of t_service, not to the entire service time. The corrected travel time is:

t_{travel, corrected} = t_{travel, free} × (1 + α × (N / N_max)^β)

Where:

• t_{travel, free} is the travel time under free-flow conditions (no other robots present), expressed in hours (h).
• N is the number of robots in the fleet, expressed as a dimensionless count.
• N_max is the maximum number of robots that the facility can physically accommodate before gridlock, expressed as a dimensionless count. This is a site-specific value that depends on aisle width, intersection spacing, and robot dimensions.
• α (alpha) is a dimensionless scaling factor that represents the sensitivity of travel time to congestion. A typical value is 0.5–1.0, but this is an illustrative assumption.
• β (beta) is a dimensionless exponent that represents the non-linearity of the congestion effect. A value of 2 represents a quadratic effect, which is a common approximation. This is an illustrative assumption.

This equation is a simplified version of the Bureau of Public Roads (BPR) congestion function, which is widely used in transportation engineering. The BPR function is:

t = t₀ × (1 + α × (V / C)^β)

Where V is the traffic volume and C is the road capacity. In the AMR context, V is analogous to the number of robots N, and C is analogous to N_max.

The congestion correction is not a simple divisor; it is an iterative calculation. The corrected service time depends on the fleet size, which in turn depends on the corrected service time. The solution is to iterate until convergence:

1. Start with an initial guess for the fleet size, N₀.
2. Calculate the corrected travel time using the congestion function.
3. Calculate the corrected service time: t_{service, corrected} = t_{travel, corrected} + t_load + t_unload.
4. Calculate the new fleet size: N₁ = λ × t_{service, corrected}.
5. Repeat steps 2–4 until the change in fleet size is less than 1%.

This iterative process is essential because the congestion effect is a feedback loop: more robots cause more congestion, which increases travel time, which requires more robots.

Illustrative assumption: For a warehouse with a grid layout, 3-meter aisles, and 1.2-meter-wide robots, the maximum robot density N_max might be approximately 50 robots per 10,000 m². This is an illustrative assumption and must be validated with a traffic simulation.

Queueing effects: waiting time and utilization #

The raw demand calculation N_raw = λ × t_service assumes that missions arrive at a constant rate and that robots are always available to serve them. In reality, mission arrivals are stochastic, and robots are often busy when a new mission arrives. This creates a queue of waiting missions, and the average waiting time depends on the fleet utilization.

Fleet utilization, ρ (rho), is defined as:

ρ = λ × t_service / N

Where:

• ρ is the utilization, expressed as a dimensionless ratio between 0 and 1.
• N is the number of robots in the fleet, expressed as a dimensionless count.

For a stable system, ρ must be less than 1. If ρ ≥ 1, the queue of waiting missions grows without bound, and the system is unstable.

The average waiting time for a mission can be estimated using the M/M/c queueing model, which assumes Poisson arrivals, exponential service times, and c identical servers (robots). The average waiting time in the queue, W_q, is:

W_q = (C(c, ρ) × t_service) / (c × (1 – ρ))

Where:

• W_q is the average waiting time in the queue, expressed in hours (h).
• C(c, ρ) is Erlang’s C formula, which gives the probability that all c robots are busy. It is a complex function that depends on c and ρ.

The Erlang C formula is:

C(c, ρ) = ( (cρ)^c / c! ) / ( (1 – ρ) × Σ_k=0^c-1 (cρ)^k / k! + (cρ)^c / c! )

This formula is computationally intensive but can be implemented in a spreadsheet or a simple script. The key insight is that the waiting time grows hyperbolically as ρ approaches 1. At ρ = 0.5, the waiting time is relatively small. At ρ = 0.8, the waiting time is significant. At ρ = 0.9, the waiting time is enormous.

The queueing analysis provides a critical design constraint: the fleet must be sized such that the utilization is below a target threshold, typically 70–80%, to keep waiting times acceptable. This means that the fleet size must be larger than the raw demand N_raw even before considering availability, charging, and congestion.

Illustrative assumption: For a target average waiting time of 2 minutes (0.033 h) and a service time of 4.5 minutes (0.075 h), the target utilization is approximately 70%. This is an illustrative assumption and must be set based on the facility’s service level requirements.

Combined correction model: the full equation #

The complete fleet sizing model combines all the correction factors into a single iterative calculation. The final fleet size, N_final, is:

N_final = (λ × t_{service, corrected}) / (A × (1 – f_charge)) × (1 / (1 – ρ_target))

Where:

• t_{service, corrected} is the service time after applying the congestion correction, expressed in hours (h).
• A is the operational availability, expressed as a dimensionless ratio.
• f_charge is the charging fraction, expressed as a dimensionless ratio.
• ρ_target is the target utilization, expressed as a dimensionless ratio (e.g., 0.7 for 70% utilization).

This equation is a simplification because it treats the corrections as independent multipliers, which is not strictly accurate. The congestion correction affects t_service, which in turn affects the utilization ρ. The correct approach is to solve the system iteratively:

1. Assume an initial fleet size N₀.
2. Calculate the corrected service time t_{service, corrected} using the congestion function.
3. Calculate the utilization ρ = λ × t_{service, corrected} / N₀.
4. Calculate the required fleet size N₁ = (λ × t_{service, corrected}) / (A × (1 – f_charge)) × (1 / (1 – ρ)).
5. If N₁ differs from N₀ by more than 1%, set N₀ = N₁ and repeat steps 2–4.

This iterative process is essential for accuracy. In practice, the iteration typically converges in 5–10 steps.

The table below summarizes the correction factors and their typical ranges. These ranges are illustrative assumptions based on industry experience, not sourced figures.

Worked example #

This section provides a fully worked example of the fleet sizing methodology. All input values are explicitly labelled as illustrative assumptions and must be replaced with site-specific data.

Inputs #

Step 1: Raw fleet size #

The raw service time is the sum of travel time and load transfer time:

t_{service, raw} = t_{travel, free} + t_load = 0.050 + 0.017 = 0.067 h

The raw fleet size is:

N_raw = λ × t_{service, raw} = 40 × 0.067 = 2.68 robots

This is the theoretical minimum number of robots if the system were perfectly efficient.

Step 2: Availability correction #

N_avail = N_raw / A = 2.68 / 0.92 = 2.91 robots

Step 3: Charging correction #

N_charge = N_avail / (1 – f_charge) = 2.91 / (1 – 0.20) = 2.91 / 0.80 = 3.64 robots

Step 4: Iterative congestion and utilization correction #

We now iterate to account for congestion and utilization. We start with an initial guess of N₀ = 5 robots.

Iteration 1:

Congestion factor: 1 + α × (N₀ / N_max)^β = 1 + 0.5 × (5/50)² = 1 + 0.5 × 0.01 = 1.005

Corrected travel time: t_{travel, corrected} = 0.050 × 1.005 = 0.05025 h

Corrected service time: t_{service, corrected} = 0.05025 + 0.017 = 0.06725 h

Utilization: ρ = λ × t_{service, corrected} / N₀ = 40 × 0.06725 / 5 = 0.538

Required fleet size: N₁ = (λ × t_{service, corrected}) / (A × (1 – f_charge)) × (1 / (1 – ρ)) = (40 × 0.06725) / (0.92 × 0.80) × (1 / (1 – 0.538)) = 2.69 / 0.736 × 2.16 = 7.89 robots

Since N₁ (7.89) differs significantly from N₀ (5), we iterate again.

Iteration 2:

Congestion factor: 1 + 0.5 × (7.89/50)² = 1 + 0.5 × 0.0249 = 1.0125

Corrected travel time: 0.050 × 1.0125 = 0.05063 h

Corrected service time: 0.05063 + 0.017 = 0.06763 h

Utilization: ρ = 40 × 0.06763 / 7.89 = 0.343

Required fleet size: N₂ = (40 × 0.06763) / (0.736) × (1 / (1 – 0.343)) = 2.705 / 0.736 × 1.522 = 5.59 robots

Iteration 3:

Congestion factor: 1 + 0.5 × (5.59/50)² = 1 + 0.5 × 0.0125 = 1.0063

Corrected travel time: 0.050 × 1.0063 = 0.05031 h

Corrected service time: 0.05031 + 0.017 = 0.06731 h

Utilization: ρ = 40 × 0.06731 / 5.59 = 0.482

Required fleet size: N₃ = (40 × 0.06731) / (0.736) × (1 / (1 – 0.482)) = 2.692 / 0.736 × 1.931 = 7.06 robots

Iteration 4:

Congestion factor: 1 + 0.5 × (7.06/50)² = 1 + 0.5 × 0.0199 = 1.0100

Corrected travel time: 0.050 × 1.0100 = 0.05050 h

Corrected service time: 0.05050 + 0.017 = 0.06750 h

Utilization: ρ = 40 × 0.06750 / 7.06 = 0.382

Required fleet size: N₄ = (40 × 0.06750) / (0.736) × (1 / (1 – 0.382)) = 2.70 / 0.736 × 1.618 = 5.93 robots

Iteration 5:

Congestion factor: 1 + 0.5 × (5.93/50)² = 1 + 0.5 × 0.0141 = 1.0070

Corrected travel time: 0.050 × 1.0070 = 0.05035 h

Corrected service time: 0.05035 + 0.017 = 0.06735 h

Utilization: ρ = 40 × 0.06735 / 5.93 = 0.454

Required fleet size: N₅ = (40 × 0.06735) / (0.736) × (1 / (1 – 0.454)) = 2.694 / 0.736 × 1.832 = 6.70 robots

Iteration 6:

Congestion factor: 1 + 0.5 × (6.70/50)² = 1 + 0.5 × 0.0180 = 1.0090

Corrected travel time: 0.050 × 1.0090 = 0.05045 h

Corrected service time: 0.05045 + 0.017 = 0.06745 h

Utilization: ρ = 40 × 0.06745 / 6.70 = 0.403

Required fleet size: N₆ = (40 × 0.06745) / (0.736) × (1 / (1 – 0.403)) = 2.698 / 0.736 × 1.675 = 6.14 robots

The iteration is converging to approximately 6.3 robots. We round up to the nearest integer.

Result #

The recommended fleet size is 7 robots. This is 2.6 times the raw fleet size of 2.68, illustrating the significant impact of the correction factors.

Sensitivity analysis #

The table below shows how the final fleet size changes with variations in the key input parameters. Each row varies one parameter while holding all others constant at the base case values.

The sensitivity analysis shows that the mission arrival rate and the charging fraction have the largest impact on fleet size. A 25% increase in arrival rate (from 40 to 50 missions/h) increases the fleet size by approximately 14% (from 7 to 8 robots). A 50% increase in charging fraction (from 0.20 to 0.30) also increases the fleet size by approximately 14%.

Limitations #

This worked example has several limitations that must be acknowledged:

• Stationary assumptions: The model assumes that the arrival rate, service time, and failure rates are constant over time. In reality, these parameters vary by shift, by day of the week, and by season.
• Homogeneous fleet: The model assumes that all robots are identical. In reality, a fleet may have robots with different speeds, battery capacities, or load handling capabilities.
• Simplified congestion model: The BPR-style congestion function is a macroscopic approximation. It does not capture the dynamics of specific intersections, narrow aisles, or elevator interfaces.
• No spatial distribution: The model assumes that missions are uniformly distributed across the facility. In reality, there may be hot spots that create localized congestion.
• No human interaction: The model does not account for pedestrian traffic, which can significantly affect robot travel time in mixed-use facilities.

Traffic management architecture: zoning, routing, and recirculation #

The congestion correction factor is a mathematical abstraction of a complex physical reality. To achieve the predicted fleet performance, the warehouse control system must implement a robust traffic management architecture. This is an editorial recommendation from Pearl Gateway, not a requirement imposed by any cited standard.

Three architectural choices have a direct impact on the congestion correction factor:

• Zoning: Dividing the facility into zones with restricted robot access can reduce congestion but may increase travel distance. For example, a zone might be restricted to robots carrying specific load types, or a zone might be closed during peak pedestrian traffic. The zoning strategy must be defined before the congestion parameters α and β can be calibrated.
• Routing: The routing algorithm determines which path a robot takes from point A to point B. A dynamic routing algorithm that reacts to real-time traffic conditions can reduce congestion but requires a reliable data infrastructure. The Routing Decision Services: Commissioning and Acceptance Checklist provides guidance on validating the data signals that feed routing decisions.
• Recirculation control: Recirculation occurs when a robot cannot reach its destination and is routed in a loop. Excessive recirculation is a sign of congestion or a routing failure. The Recirculation Control: Data Signals and Condition Monitoring article describes the data signals needed to detect and control recirculation.

The choice of traffic management architecture affects the maximum robot density N_max and the congestion parameters α and β. A facility with a well-designed zoning strategy and a dynamic routing algorithm will have a higher N_max and lower α and β than a facility with a naive traffic management approach.

It is important to note that the traffic management architecture is not a static configuration. It must be monitored and tuned over time as the facility layout changes, the product mix changes, and the fleet composition changes. The Control-System Time Synchronization: Data Signals and Condition Monitoring article highlights the importance of accurate time synchronization for coordinating traffic management decisions across multiple robots and control nodes.

Mission queue design: prioritization and batching #

The queueing model presented earlier assumes a single queue of missions served by a pool of robots. In practice, the mission queue is a complex software artifact that can be designed to improve fleet efficiency. The design of the mission queue directly affects the effective arrival rate λ and the service time t_service.

Key design decisions include:

• Prioritization: Not all missions are equal. A mission to deliver a critical spare part to a production line should have higher priority than a mission to move finished goods to a remote storage location. Priority can be implemented as a weighted queue or as a multi-level queue.
• Batching: A robot can sometimes handle multiple missions in a single trip. For example, a robot with a multi-deep rack can pick up several items from the same aisle. Batching reduces the effective service time per mission but increases the complexity of the mission queue.
• Mission decomposition: A single transport mission can be decomposed into multiple sub-missions (e.g., travel to pickup, pick up load, travel to drop-off, drop off load). The queue must manage these sub-missions as a single logical unit to avoid deadlocks.

The Mission and Task Queues: Selection Criteria and Application Boundaries article provides a detailed discussion of the trade-offs between different queue architectures. For fleet sizing purposes, the key takeaway is that the mission queue design can reduce the effective λ (by batching) or reduce the effective t_service (by reducing empty travel), but it cannot eliminate the fundamental stochastic variability that drives the queueing effects.

It is also important to consider the interaction between the mission queue and the charging strategy. If the mission queue is empty, a robot can be sent to a charging station. If the mission queue is full, the robot must defer charging. The charging correction factor f_charge must be consistent with the mission queue’s ability to generate idle time for charging.

Load handling interface: impact on service time #

The load handling device (LHD) is the physical interface between the robot and the load. The time to