Mixed-fleet orchestration places multiple classes of automated equipment under one coordinated control framework, but it does not remove the fundamental laws of material flow. In a warehouse where autonomous mobile robots (AMRs), automated guided vehicles (AGVs), robotic handling cells, and even manually operated trucks share the same floor space, capacity planning becomes a cross-technology balancing act. Bottlenecks rarely announce themselves as a single failed component; they emerge from the interaction between vehicle pools, infrastructure limits, scheduling logic, and recovery behavior. This article is an independent educational guide for warehouse operators, maintenance engineers, and controls teams who need to diagnose throughput loss, plan capacity realistically, and know when operational tuning is appropriate versus when deeper engineering intervention is required.
The Operating Context of a Mixed Fleet #
In a single-vendor fleet, the manufacturer typically provides consistent traffic management, charging coordination, and assignment logic. A mixed fleet, by contrast, involves vehicles with different control systems, safety field configurations, docking tolerances, speed limits, and communication protocols. An orchestration layer, usually a warehouse execution system or a fleet manager, issues tasks and arbitrates right-of-way across these heterogeneous units. This structure creates a distributed system where the performance of any single robot depends on decisions made by other robots and by the orchestration server itself.
Capacity planning in this environment is not merely a matter of counting vehicles. It is the process of matching available moving, lifting, charging, and handoff resources to the demands of the picking, putaway, packing, and shipping processes. Because the fleet is mixed, capacity exists in several forms: horizontal transport capacity, vertical transport capacity at lifts and mezzanine access points, docking capacity at pick stations, and charging capacity at both opportunistic and dedicated charging spots. The total system throughput is constrained by the smallest of these capacities, which means that a single under-provisioned element can neutralize an otherwise balanced fleet.
Capacity Planning as a Live Constraint Problem #
Classical capacity planning treats fleet size as a static calculation. The operator measures average task duration, divides it by planned shift hours, and arrives at a robot count. In mixed-fleet orchestration, this calculation is necessary but not sufficient. The system is dynamic, with traffic congestion, battery state of charge, and station availability varying from minute to minute. The effective capacity of the fleet at any moment is what actually matters, not the theoretical maximum.
Three capacity levels should be distinguished. Planned capacity is the expected throughput when all resources are available and the orchestration layer is behaving normally. Effective capacity subtracts the losses caused by traffic constraints, charging cycles, operator interventions, and system recovery events. Realized throughput is what the warehouse actually measures at the output. The gap between effective capacity and realized throughput is the zone where bottleneck analysis must operate. If an operator focuses solely on the visible output, they may miss the fact that the fleet is spending twenty percent of its time waiting for lift access or dock clearance.
Every mixed fleet also contains its own form of internal interference. Different vehicle types may use the same aisles but with different widths, turning radii, and deceleration profiles. A slower vehicle ahead of a faster vehicle creates a ripple that propagates backward through the traffic network. Reservation-based traffic systems lock path segments in advance, so a slow robot can block a fast robot even when they are not physically colliding. Capacity planning must therefore account for inter-vehicle timing, not just vehicle quantities.
Where Bottlenecks Appear in a Mixed Fleet #
Bottlenecks in a mixed-fleet system can be classified into four broad categories: infrastructure, vehicle-pool, interface, and control-software. Each category has distinct symptoms and requires different diagnostic approaches.
Infrastructure bottlenecks occur at physical locations where the material flow narrows. Common examples are shared aisles, right-angle intersections, automatic doors with limited opening cycles, lifts that serve multiple floors, and charging zones positioned near high-traffic paths. These bottlenecks are characterised by queues that grow upstream of the constrained point while resources downstream remain idle. In mixed fleets, infrastructure bottlenecks are often made worse by the fact that different vehicle types have different clearance requirements. An AMR with a wide footprint may trigger safety field expansions in narrow passageways, reducing the usable aisle width for nearby vehicles.
Vehicle-pool bottlenecks occur when one class of vehicle is undersized relative to demand. This might be as simple as too few AMRs available for transport tasks, but it can also be a mismatch in capability, such as a vehicle pool with ample carrying capacity but insufficient lift height, or a fleet with fast robots that cannot handle pallets and slow robots that can. Vehicle-pool bottlenecks show up as sustained high utilization for one class while another sits idle. The fleet as a whole looks busy, but the output is capped by the wrong bottleneck resource.
Interface bottlenecks arise at the handoff points between automation and other equipment. A robotic handling cell that loads goods onto an AMR, a conveyor spur that feeds a pick station, and a raising transfer station all impose a rhythm on the vehicles that serve them. If the interface cycle time is longer than the vehicle arrival interval, the vehicles form a queue. If it is shorter, the interface starves, and the cell waits for the next delivery. Mixed-fleet orchestration complicates this because the interfaces must accommodate varied vehicle heights, docking precision, and payload transfer mechanisms.
Control-software bottlenecks are the least visible and often the most confusing. The orchestration server, the individual fleet manager, and the warehouse execution system impose their own limits through task dispatching latency, zone reservation algorithms, and communication polling intervals. A software bottleneck may appear as intermittent delays that are not tied to any physical location. An entire area of the warehouse may momentarily stop moving because the orchestration layer is waiting for an acknowledgement from one robot. These bottlenecks require log analysis rather than floor observation to diagnose.
Component Interactions That Shape Throughput #
No component in a mixed fleet acts in isolation. The charging behavior of one robot affects the traffic density of the aisles it must cross to reach a charger. The safety field settings of one vehicle type affect how closely other vehicles can approach. The task prioritization logic of the warehouse execution system dictates which robots are dispatched first, which in turn determines which charging stations become contended.
Battery state of charge is a particularly significant interaction point. In mixed fleets, charging strategies differ. Some vehicles return to dedicated chargers only when their state of charge reaches a low threshold; others opportunistically top up during natural dwells at stations. When one fleet uses opportunistic charging, its charging spots may occupy floor space that another fleet requires for staging. When a vehicle pool returns to chargers at the same time, the charger queue becomes a bottleneck even though the vehicles are not carrying any load at that moment.
Traffic reservations create another form of interaction. Most modern AMR systems reserve path segments ahead of the vehicle, and in mixed-fleet implementations these reservations are coordinated by the orchestration layer. The duration of a reservation depends on the vehicle speed, the length of the segment, and the safety deceleration distance. A vehicle with degraded speed due to worn wheels or low battery holds its reservation for longer, making every vehicle behind it wait longer as well. This means that a single poorly maintained robot can degrade the entire fleet, not just its own task completion time.
Manual operator behavior also interacts with the automated fleet. When forklift drivers cross robot paths, the robots must slow to avoid safety field intrusions. Repeated operator entries into a robot zone at the same location and time of day will produce a repeatable, site-specific bottleneck that is invisible in static capacity models. Conditions such as shift starts, break times, and trailer loading surges create predictable waves of manual traffic that the orchestration system must ride through.
Observable Symptoms and Diagnostic Table #
Bottlenecks manifest themselves through patterns that are observable in both fleet dashboards and physical floor behavior. The table below summarises common symptoms, the likely contributor categories, the evidence required to confirm the diagnosis, and the interpretation that should be applied before making changes. It is intended as a practical starting point for site troubleshooting, not as a substitute for vendor analysis.
| Observable Symptom | Likely Contributor | Evidence to Collect | Interpretation Note |
|---|---|---|---|
| Queues build at one intersection while downstream stations wait empty | Infrastructure or control-software | Position traces, reservation wait times, intersection camera footage | A single intersection queue may indicate an under-timed reservation logic, not a capacity shortage |
| One robot class runs above ninety percent utilization while another class sits idle | Vehicle-pool mismatch | Task assignment logs, utilization per class, task completion counts | High utilization on one class often means tasks are improperly sequenced for that class |
| AMRs arrive at docks but wait before initiating transfer | Interface | Dock occupancy timestamps, handshake signals, cell cycle time logs | Compare cell cycle time to mean vehicle arrival interval to determine which side is the constraint |
| Multiple chargers occupied but robots still queue for charging | Vehicle-pool or infrastructure | Charger occupancy curves, battery state-of-charge logs, queue wait times | Charging contention may be caused by simultaneous return waves, not an absolute charger shortage |
| Recurring deadlocks at the same map location | Control-software or traffic rule conflict | Deadlock timestamps, traffic server logs, zone ownership records | Repeated deadlocks at a fixed location indicate a rule conflict between two fleet managers, not random failure |
| Fleet output drops every day at the same time despite constant order volume | Manual traffic interaction | Operator activity logs, safety field trigger events, time-stamped throughput | Correlate output drops with shift patterns and forklift activity before modifying robot paths |
Evidence Collection and Site Interpretation #
Diagnosis is only as reliable as the evidence gathered. Before changing any parameter, a site team should collect at least a full operational cycle of data, spanning all shifts and including any periods when order profiles differ, such as a weekend surge or a batching window. The minimum dataset should include mission start and end times, waiting time at each waypoint, path segment occupancy data from the traffic server, charger engagement records, and the logs of any error or recovery events.
It is important to separate dwell time into its causes. A robot waiting at a station because there is no work is not a bottleneck. A robot waiting at a station because the pick cell is still finishing the previous load is an interface bottleneck. A robot waiting on the path because the next segment is reserved by another robot is a traffic constraint. The difference matters because the corrective actions are entirely different. A warehouse execution system issue requires job-logic tuning, an interface issue requires cycle-time analysis at the cell, and a traffic issue requires map or reservation tuning.
Site observation should be mindful of outliers. Remove aborted missions, manually recovered faults, and test runs from the dataset before calculating average performance. A single robot that enters a safety stop every hour because of a sensor misalignment will skew the travel time data for the entire fleet. At the same time, do not discard regular, small delays too quickly; a fleet-wide waiting time increase of three seconds per intersection, repeated across hundreds of missions, will become a substantial daily loss.
Common Interpretation Errors #
Mixed-fleet diagnostics fail every day because of a handful of recurring interpretation mistakes. The most common is comparing utilization percentages across vehicle classes without considering their roles. A pallet-carrying AGV that runs continuously for four hours may be doing less useful work than a carton AMR that seems underutilized but delivers far more loads per hour. Utilization must be normalized by task value, not by time in motion.
Another common error is assuming that throughput scales with robot count. Adding a robot to a traffic-constrained zone can reduce total throughput because every robot spends additional time waiting for path reservations. The new robot increases the congestion for the existing robots, so the net effect is negative. In mixed fleets this is especially pronounced because the added robot may be a different class with different speed and clearance behavior.
Operators often attribute a persistent throughput drop to a single robot fault. In reality, intermittent communication drops or a slightly drifting odometry on one unit can cause repeated safety recoveries that affect the orchestration schedule for a whole area. The fault is visible as a local problem but the effect is global. Conversely, teams may focus on a highly visible physical bottleneck at a lift or door while the true constraint remains a low-priority task sequencing rule in the warehouse execution system. The physical queue at the lift is caused by bursts of traffic that arrive because the dispatcher releases all tasks of one type at once.
Charging dwell time is frequently mistaken for productive idle time. A robot sitting at a charger during a low-demand period is healthy; a robot sitting at a charger during peak demand is a symptom of poor charge scheduling. Similarly, a robot that returns to a charging station because its state of charge dropped too far indicates that the orchestration layer did not account for its future mission length. The robot is not failing; the charge planning logic lacks sufficient forecast horizon.
Maintenance Implications for an Orchestrated Fleet #
Preventive maintenance in a mixed fleet is not only about keeping individual robots reliable. It is also about preserving the predictability of the fleet as a coordinated system. A robot with worn drive wheels will decelerate more hesitantly, hold traffic reservations longer, and cause the robots behind it to spend more time at intersections. A robot with a dirty lidar window may trigger frequent safety field intrusions, forcing full stops at locations where the map expects smooth passage. These conditions degrade capacity in the same way that a physical narrowing of the aisle would, and they can be difficult to reproduce on demand.
The maintenance plan should align with capacity conservation. Robots that are pulled out of service for planned work remove capacity from the orchestration model. If the maintenance schedule is set without attention to forecast demand peaks, the fleet may enter a peak period with an unplanned reduction in effective capacity. Where possible, schedule maintenance in waves that mirror demand seasonality, and confirm that the orchestration layer is informed of the out-of-service units so that it does not persist in assigning them tasks and then waiting for them to appear.
Fleet data provides early indicators of mechanical degradation that a scheduled inspection may not catch. Rising wait time at a specific charger, increased re
