Warehouse Robot Fleet Throughput

How this warehouse robot throughput calculator works

This calculator estimates how many autonomous mobile robots (AMRs) you need to achieve a target order line throughput in a warehouse or fulfillment center. It focuses on a simple but powerful idea: every order line consumes a slice of robot time. If you know how much time one line takes on average, you can estimate how many lines per hour one robot can process, and therefore how many robots you need to hit your target volume.

The model combines three main contributors to time per line:

• Travel time to and from the pick location.
• Handling time to actually perform the pick or drop.
• Battery swap or recharge overhead spread across all lines the robot completes in a battery cycle.

By adjusting the inputs, you can run quick what-if scenarios to see how changes in layout, robot speed, or battery strategy affect fleet size and per-robot productivity.

Core formulas behind the calculator

The calculator treats one order line as a repeatable cycle consisting of travel, handling, and an averaged share of battery downtime. The key variables are:

• d = average travel distance per pick (meters)
• v = robot travel speed (meters per second)
• t_handle = handling time per pick (seconds)
• t_swap = battery swap time (minutes)
• N_cycle = lines per battery cycle (before a swap is needed)
• T_target = target order lines per hour

Travel time per line is distance divided by speed:

Battery swap time is provided in minutes, but the rest of the model uses seconds. First, convert swap time to seconds and spread it across the full battery cycle:

Total time per line (in seconds) is then:

Once you know the time per line, you can estimate throughput per robot in lines per hour by dividing the number of seconds in an hour by the time per line:

To meet the required target lines per hour, the approximate number of robots needed is:

In practice, you would round this up to the next whole robot and often add a buffer to cover peak demand, maintenance, or congestion effects that this simple model does not explicitly capture.

Interpreting the inputs

Average travel distance per pick

Distance per pick is driven mainly by layout and strategy:

• Goods-to-person systems (robots bring shelves or totes to pick stations) often achieve average distances in the tens of meters.
• Picker-to-goods or hybrid designs can see much longer distances per line, especially in large, sparse facilities.

Shortening average distance (through better slotting, zoning, or more pick stations) often has a larger impact on robot fleet size than modest changes in speed.

Robot travel speed

The calculator assumes a constant average speed over the route, already reflecting acceleration, deceleration, and turns. Raising the top speed does not always translate into proportional throughput gains if safety rules, congestion, or stop-and-go patterns dominate.

Handling time per pick

Handling time covers all non-travel time directly tied to a line: confirming the pick, grabbing the item, scanning, and placing it in a tote or shipping container. In goods-to-person environments, improvements in workstation design, pick-to-light technology, and training can all reduce handling time and therefore boost lines per hour per robot.

Battery swap time and lines per battery cycle

Battery management directly affects effective robot availability. The model uses two values:

• Battery swap time (in minutes): time a robot is out of service for a swap or full recharge.
• Lines per battery cycle: average number of order lines a robot can process between swaps.

A larger number of lines per cycle or a faster swap reduces the downtime penalty allocated to each line. Strategies such as opportunity charging or automated battery exchange systems aim to push this penalty as low as practical.

Worked example

Consider a warehouse with the following assumptions (which match the default values in the calculator):

• Average travel distance per pick: 60 m
• Robot travel speed: 1.5 m/s
• Handling time per pick: 10 s
• Battery swap time: 2 min
• Lines per battery cycle: 100
• Target order lines per hour: 1,000

Step 1: travel time per line:

60 m ÷ 1.5 m/s = 40 s

Step 2: swap time per line:

2 min × 60 = 120 s per swap. Spread over 100 lines gives 120 ÷ 100 = 1.2 s per line.

Step 3: total time per line:

40 s (travel) + 10 s (handling) + 1.2 s (battery penalty) = 51.2 s per line.

Step 4: throughput per robot:

3,600 s per hour ÷ 51.2 s ≈ 70.3 lines per hour per robot.

Step 5: number of robots required:

1,000 target lines per hour ÷ 70.3 ≈ 14.2 robots. In practice, you would plan for at least 15 robots, and potentially add a safety margin depending on uptime and peak demand.

Example scenarios and comparison

The table below compares how different operating regimes might affect throughput and fleet size, using indicative numbers only. Your actual results will come from the calculator based on your own inputs.

Use this table as a qualitative guide when reviewing your outputs. If your results suggest lines per robot far outside typical ranges, verify that your inputs (especially distance, speed, and handling time) reflect realistic conditions.

Using the results for planning

Once you have an estimated lines-per-robot figure and required fleet size, you can use them to:

• Support capital budgeting: combine robots required with unit cost, charging infrastructure, and software licenses to estimate total investment.
• Run sensitivity analyses: test how much fleet size changes if you halve average distance, improve handling time by 20%, or shorten swap time with better processes.
• Identify bottlenecks: if distance dominates time per line, layout optimization may pay off more than faster robots; if handling dominates, focus on picking ergonomics and tools.
• Plan peak vs. average operations: compare fleet needs for average demand and for peak weeks, and decide whether to flex capacity with overtime, temporary labor, or additional robots.

Assumptions and limitations

This calculator is intentionally simple and designed for early-stage planning and comparison rather than detailed engineering. It relies on several important assumptions:

• Average values: distance, speed, handling time, and lines per battery cycle are treated as stable averages. Real operations have variability that can reduce effective throughput.
• No congestion or queuing: the model assumes robots can travel freely with no traffic jams, blocking, or queuing at pick/pack stations.
• Continuous availability: aside from battery swaps, robots are assumed to be available continuously, with no maintenance downtime, software updates, or operator interventions.
• Unlimited pick/pack capacity: it assumes human or automated workstations can keep up with the robot fleet and do not become the bottleneck.
• Fixed process design: it does not explicitly model batching, multi-line orders, zoning strategies, or dynamic task allocation logic that many WMS/robot systems use.

Because of these simplifications, you should treat the outputs as directional estimates. For critical decisions, use them as a starting point and refine with detailed simulations, vendor data, or pilot operations. When in doubt, apply a safety factor or range rather than relying on a single point estimate for robot count.