When logistics teams evaluate AMR performance, they almost always lead with average speed: meters per second, picks per hour, cycle time. These numbers are easy to pull from fleet dashboards and easy to present in vendor comparisons. They're also largely irrelevant to whether your operation actually hits its throughput targets.
The real constraint, in most warehouse deployments we've seen, isn't how fast a robot moves. It's whether the robot arrives at the right pick slot within a usable window of time — and what happens to the entire pick-and-pack sequence when it doesn't.
What a Pick-Slot Timing Window Actually Is
A pick-slot timing window is the interval during which a robot's arrival at a specific slot is both safe and productive. Arrive too early and you're blocking a human picker who's already working that zone. Arrive too late and the downstream packing station has stalled, the sort induction belt has a gap, or a wave release has been mis-sequenced.
In practice, timing windows emerge from three overlapping constraints:
- Human-robot conflict zones: Pick aisles where human order selectors and AMRs share space have temporal exclusion windows. A robot arriving while a picker is mid-reach creates either a stop-and-wait (dead time) or a yield-and-reroute (path cost). Neither is free.
- Downstream station pacing: Pack stations, labeling stations, and manifesting stations operate at a cadence. A robot that arrives 40 seconds outside that cadence either queues or forces a station idle period.
- Wave release synchronization: Most WMS implementations batch releases in waves of 20–60 minutes. The slot at which a robot picks isn't just a location — it's a location at a time, and that time has to align with the wave's pick-confirm window to avoid re-queuing the task.
None of this shows up in a "picks per hour" metric. You can have a very fast AMR fleet that consistently misses timing windows and produces terrible actual throughput — because every early arrival creates a conflict event and every late arrival creates a station idle.
Why Speed Optimization Doesn't Solve a Timing Problem
Here's where most teams make the wrong investment. They see robots stopping and waiting — a clearly visible form of idle time — and conclude the fix is higher robot speed or a different path planning algorithm. But a robot that stops and waits because it arrived too early at a contested aisle zone is already moving at the right speed. The problem is scheduling, not velocity.
We're not saying speed is irrelevant. Peak speed matters for longer cross-facility transits, and acceleration/deceleration profiles matter for tight aisle geometry. But in a 200,000 sq ft ambient pick-and-pack facility running three waves per shift, we've consistently found that timing variance — not average speed — is the primary driver of throughput loss.
Consider a scenario we modeled for a mid-size 3PL operating a 180,000 sq ft facility with a fleet of 12 AMRs. Their average robot speed was 1.2 m/s, well within spec. Their average picks-per-hour was running about 15% below target. When we instrumented the fleet with arrival-relative-to-window timestamps instead of just cycle times, we found that roughly 35% of pick arrivals were outside the ±90-second timing window defined by their wave release schedule. The robots weren't slow — they were mistimed.
Measuring "Picks on Time" Instead of "Time to Pick"
The metric shift is straightforward conceptually but requires a bit of instrumentation work to implement. Instead of measuring the duration from task dispatch to pick completion, you measure how far the pick completion timestamp falls from the target window center.
A useful operational definition:
- On-time pick: Robot arrives at slot and begins pick action within ±T seconds of the wave-assigned window center (where T is typically 60–120 seconds depending on station buffer).
- Early arrival: Robot arrives before the window opens. May trigger a hold command or a short-range patrol pattern that burns time before entry.
- Late arrival: Robot arrives after window closes. Downstream consequence depends on station buffer depth — shallow buffers (conveyor-fed stations) penalize late arrivals heavily.
The ratio of on-time picks to total picks — what we call the timing adherence rate — is the number that actually predicts shift throughput. A fleet with 82% timing adherence will hit throughput targets more reliably than a faster fleet running at 68% timing adherence, in our experience across several deployments.
What Drives Timing Variance in Practice
Three main sources:
Unplanned path extensions from obstacle events. Every time a robot reroutes around an unexpected obstacle — a misplaced pallet, a stopped forklift, a fellow robot in contention — it adds 15–90 seconds to its transit. A route planned for 4 minutes that takes 5.5 minutes due to two reroute events can shift an on-time arrival to a late arrival. The fix here isn't speed — it's reducing reroute frequency and reroute latency.
Slot contention from poor fleet spacing. When two robots are dispatched to adjacent slots in the same aisle during the same time window, one will inevitably wait. The solution is staggered dispatch with spatial exclusion zones, not faster individual robots.
Conservative obstacle holds from over-cautious classification. If a robot's perception system defaults to a long stop every time it encounters a "low-confidence obstacle" classification — a category that can include everything from a piece of stretch wrap on the floor to a stationary cart — those stops accumulate. A fleet averaging three such holds per robot per shift, each lasting 25 seconds, is losing over a minute per robot per shift to false-caution holds. In a 12-robot fleet that's 12+ minutes of pure timing loss per shift.
Mobvynt's approach to that third point is to give operators a tunable hold policy per obstacle confidence tier, with separate thresholds for "pause and re-evaluate" versus "full stop and request assistance." We've found that a 3-tier hold policy (short pause / extended pause / emergency stop) with configurable confidence thresholds can cut false-caution hold time by 40–60% compared to binary stop/no-stop logic, without compromising safety-critical stops.
Integrating Timing Windows into Task Dispatch
The cleanest fix is to push timing-window awareness upstream into how tasks are dispatched, not just how they're executed. This means the fleet coordination layer — whether that's a native fleet manager or a WMS integration — needs to model expected travel time including congestion variance, not just straight-line distance divided by nominal speed.
At minimum, dispatch should account for:
- Current robot position and queue depth
- Historical travel time variance for the specific route segment (not just average)
- Known congestion patterns for the current time-of-day and shift phase
- Aisle exclusion windows based on human picker assignments
When dispatch is timing-window-aware, early-arrival holds drop significantly because robots aren't dispatched before the window is reachable. Late arrivals drop because the system knows to dispatch earlier when congestion history on that route segment shows high variance.
This doesn't require a complex centralized optimizer. A lightweight per-robot time-of-arrival estimate, refreshed every 30 seconds based on current path state, gives the dispatch layer enough signal to make better release decisions. We've implemented this as a simple topic in our ROS 2 integration: /mvnt/fleet/eta_estimates publishes per-robot ETA objects that any WMS integration can subscribe to without needing to understand the path planning internals.
The Practical Takeaway
If your AMR throughput is below target and your first instinct is to look at speed settings, take a step back. Pull the arrival-relative-to-window distribution for your fleet over the last week. If your timing adherence rate is below 75%, you have a scheduling and obstacle-handling problem, not a speed problem — and investing in faster robots won't move that number.
Throughput is a system property. The robot is one component. The dispatch sequencing, the obstacle hold policy, and the wave synchronization all feed into whether picks happen on time. That's the right frame for diagnosing AMR performance issues, and it's the frame we build toward in everything Mobvynt ships.
