Mixed-Fleet Orchestration: Commissioning and Acceptance Checklist

Mixed-fleet orchestration is the coordination layer that allows different types of automatic guided vehicles, autonomous mobile robots, and human-driven handling equipment to share the same warehouse infrastructure without excessive conflict. During commissioning and acceptance, the goal is not simply to prove that individual machines can drive, stop, and lift; it is to demonstrate that the coordinated system as a whole is safe, predictable, and capable of sustaining the required throughput under realistic conditions. This article serves as a practical checklist for warehouse operators, maintenance engineers, and controls teams who must plan, witness, and document the acceptance of a mixed-fleet installation. It focuses on observable behavior, the data needed to confirm that behavior, and the common errors that can distort acceptance decisions.

Scope of Mixed-Fleet Acceptance #

Acceptance testing for mixed-fleet orchestration is broader than a standard robot commissioning procedure. The scope includes route management, traffic zone arbitration, task assignment across robot brands, battery and charging coordination, and the safety interfaces between mobile robots and fixed equipment. For a warehouse operator, the decisive criterion is whether the fleet manager can resolve conflicting uses of the same floor space without operator intervention and without creating a risk to people or loads.

The roles involved in a mixed-fleet acceptance should be clear from the outset. The site operator defines the acceptance criteria and operational limits. The controls team exercises the system and records the behavior of the orchestration layer. Maintenance staff observe whether the system is behaving in a way that can be diagnosed and maintained after handover. The integrator provides the system documentation and facilitates software and interface adjustments. A competent engineering judgment is required where safety or operational boundaries are unclear. Final judgments on safety decisions should always defer to site procedures, lockout requirements, and OEM documentation.

One of the most important concepts in acceptance is that a single robot passing a point-to-point test does not validate the orchestration layer. The orchestration layer is a higher-order system concerned with how multiple agents interact when their paths, priorities, and resource demands overlap. Acceptance must be carried out with all relevant subsystems connected and with the full expected fleet size running concurrently.

Baseline Documentation and Reference Conditions #

Before any test begins, the team must establish a documented baseline of the operating environment and the software configuration. Without a baseline, every anomaly discovered during acceptance is difficult to classify: the fault could be in the map, the fleet manager, a specific robot agent, or the facility itself. The baseline should include the site map coordinate system, the version of the fleet manager, the software versions of each robot agent type, the network segment or virtual network used by the robots, and the location of every charging station, gate, and conveyor handoff point.

The baseline must also record the intended operational parameters. These include speed limits in specific zones, priority levels assigned to different classes of traffic, the maximum number of vehicles permitted in any one zone, and the timing thresholds for handshake signals at interlocking interfaces. Any deviation from the baseline during the acceptance window should be noted and considered when interpreting the results. For example, a temporary network modification or a recently changed floor surface can alter robot behavior and lead to a false rejection or a false acceptance.

Evidence collected during acceptance should always be compared against the baseline. This is particularly important for behavior that is intermittent or that only occurs under peak traffic conditions. A short, low-load test will never reveal issues that are caused by high zone occupancy or simultaneous charging requests.

Pre-Commissioning Environmental Checks #

Floor, Racking, and Obstruction Management #

Mobile robots depend on a predictable floor and environment. Before orchestration testing starts, the floor should be checked for flatness, cracks, expansion joints, and any protrusions that could degrade navigation. Racking alignment should be verified to ensure the reflector and visual reference points are stable. The site must also be inspected for temporary obstacles such as shrink wrap, pallet overhang, loose cables, or shrink film dragged by forklift traffic. These conditions affect the robot’s interpretation of its surroundings and can create false occupancy states or unnecessary re-routing at the fleet level.

Network and Charging Infrastructure #

Mixed-fleet orchestration is heavily dependent on continuous wireless connectivity. The acceptance team should verify wireless coverage along every planned route, including elevator interiors, dock doors, and high-bay racking zones. The network is often the hidden source of orchestration failures. If a robot drops off the network briefly, the fleet manager may see the robot as inactive while the robot continues moving under its onboard planner. This can lead to two robots being granted access to the same zone. A simple wireless scan and roaming test is a necessary pre-commissioning step.

Charging stations require their own inspection. Docking accuracy, contact alignment, and the capacity of the shared electrical supply should be checked under realistic concurrent charging conditions. A warehouse that runs a fleet of ten robots but only has the electrical capacity to charge three simultaneously will force the orchestration system to make trade-offs that were not accounted for in the original traffic model.

Safety Device Readiness #

Before any joint test is run, all safety devices—laser scanners, light curtains, door interlocks, e-stops, and pressure-sensitive edges—must be commissioned and tested individually. The orchestration layer is not a safety system; it is a coordination system that may receive signals from safety devices, but the inherent safety of each robot and each fixed machine must be confirmed independently. The acceptance team should verify that the configuration of safety zones is consistent across all robot types sharing the same area, and that any changes to one vendor’s configuration have been compared against the other vendors’ maps. No instruction for bypassing a safety device is provided here; all safety-sensitive actions must be performed according to site-specific procedures and OEM instructions with the appropriate lockout and authorization in place.

Fleet Orchestration Functional Tests #

Route Negotiation and Priority Rules #

The first functional layer to test is route negotiation. This is the logic that decides which robot receives permission to enter a shared segment when two robots request it at the same time. A controlled test should place a low-priority AMR at one end of a corridor and a high-priority forklift at the other end, with a clear instruction to cross paths. The expected result is that the orchestration layer applies the configured priority rule reliably and without any human intervention. The observable symptom of a properly working negotiation is that the lower-priority vehicle waits at a defined decision point, not mid-corridor, and the higher-priority vehicle proceeds without slowing below its target speed.

Evidence for this test should include the fleet manager event log that records the time the zone was requested, the time access was granted to each robot, and any messages that indicate the decision reason. The more detailed the log, the faster the diagnosis will be later. Simply recording that both robots eventually passed the corridor is not sufficient evidence of correct orchestration; the timing and order of access matter.

Traffic Zone Occupancy and Deadlock Resolution #

Deadlock testing is an essential part of acceptance. A deadlock is a circular wait in which two or more vehicles occupy positions such that none can move without the other moving first. In a controlled, blocked-off area, two robots should be positioned to create a face-to-face blockage in a narrow aisle. The orchestration system should either have prevented this condition through zone reservations or have a recovery protocol that instructs one robot to reverse to the nearest turnout point.

It is important to note that a robot that waits while its zone is occupied by another robot is not necessarily deadlocked; it is queuing. True deadlock is a state with no logical resolution. During the test, the team should observe whether the recovery is triggered at the orchestration level, by the fleet manager sending a reverse command, or only by an onboard safety stop. If the recovery relies only on the local safety stop, then the orchestration layer has a gap that will become frequent under high traffic density.

Charging Orchestration and Resource Sequencing #

Charging orchestration is frequently underestimated during acceptance. A robust mixed-fleet orchestration system will not simply send every robot to the closest free charger. It will analyze battery states, current task priorities, and charger availability as a set of interdependent decisions. The acceptance test should place several robots below their charge threshold simultaneously and observe whether the fleet manager staggers their approach to the charging stations without creating a bottleneck at a single charger door.

A common failure is the condition where two robots of the same brand head to the same charger, and the second robot waits directly behind the first while a charger in a different area remains idle. That behavior indicates that the orchestration layer is not considering the overall charging resource pool. The test should also include a manual override scenario: a human-equipped forklift or an out-of-service robot occupies a designated charging dwell position. The orchestration system should recognize the exception and reroute to another charger instead of queuing indefinitely in a blocked area.

Interaction Matrix Between Agents and Fixed Equipment #

The highest-risk points in a mixed-fleet installation are the boundaries between the mobile robot domain and the fixed equipment domain. These include conveyor handoff stations, robotic handling cells, shuttle interfaces, automatic doors, lifts, and palletizers. At each boundary, a combination of electrical signals, fieldbus messages, and physical positioning must agree. The orchestration logic must ensure that a robot does not enter a handoff cell before the cell has completed its cycle, and that the cell does not release a load before the robot confirms a correct docking position.