A Box Robot is a typical multi-load robot equipped with multiple storage slots (totes/baskets) to carry goods from several transport orders simultaneously. How to intelligently allocate multiple orders to the same fleet vehicle, and continuously optimize the pick-and-drop sequence during execution, is precisely the problem solved by the "Order Pooling" mechanism in M4.

This article will break down M4's order pooling capabilities layer by layer, following the entire lifecycle of an order from issuance to completion.

The Starting Point: One Order per Tote

In M4 dispatching, an order is defined as the transportation of a single container. An order can only contain one pick and one drop operation (or a pure movement without picks or drops). An order is not allowed to contain multiple picks, multiple drops, only a pick without a drop, or only a drop without a pick.

This means that if 6 totes need to be moved, 6 separate orders must be created. Order pooling does not mean stuffing 6 totes into a single order. Instead, during the assignment phase, M4 allocates these 6 orders to the same Box Robot, allowing the robot to execute their respective pick-and-drop steps within a single trip.

The advantage of this design is that the order structure remains simple and its status clear. The complexity of order pooling is entirely handled by the dispatching layer, sparing upstream systems from dealing with multi-load orchestration.

Automatic Pooling: Beyond Simple "Batch Allocation"

M4's order pooling is not a one-time binding of all orders to a vehicle at the exact moment of dispatch. It is a continuous, dynamic process that constantly adjusts throughout the robot's entire task execution.

• Dynamic Appending: Box Robot A has 3 storage slots and is currently executing 2 orders. Midway through, the upstream system issues a new order. If the new order meets the pooling criteria, the system will append it directly to Box Robot A without waiting for the first two orders to finish.

• Dynamic Sequence Adjustment: After appending a new order, the system does not simply queue it at the end. If the robot has just picked the first order and the third order (the newly appended one) is closer than the second order, the system will prioritize the third order. The execution sequence is dynamically determined primarily based on path costs.

• Order Preemption (Kicking Orders): If Box Robot A's 3 slots are already allocated, and a new order with higher priority or lower path cost arrives, the system can "kick out" an allocated but unexecuted old order. The old order is recalled to rejoin global dispatching, freeing up a slot for the new order. Preemption can only occur if the old order has not yet started its pick operation and the new order is demonstrably optimal.

• Re-dispatching: For an order already assigned to Box Robot B, if Box Robot A finishes a task and frees up a slot, and A is closer to this order than B, the system will recall the order from B and reassign it to A. Even if execution has begun (e.g., the robot is en route to the pick location), the task can be interrupted and handed over to a better robot, provided the step is flagged as withdrawOrderAllowed.

The core logic of this entire mechanism is that dispatching is not a one-time decision; rather, every single dispatching cycle re-evaluates the globally optimal allocation.

Pick-and-Drop Sequence Optimization: No Need to Pick All Before Dropping

When a multi-load robot accepts multiple orders, an intuitive execution method might be to "pick all goods first, then drop them all off together." In real-world scenarios, however, pick and drop points may be scattered across different areas. A strict "pick-all-then-drop-all" sequence can actually increase the total path length.

M4 supports interleaved pick-and-drop execution. Suppose a robot takes on 3 orders; the execution sequence could be: Pick 1 → Pick 2 → Drop 1 → Pick 3 → Drop 3 → Drop 2. The exact sequence is dynamically calculated by the system based on path costs—after completing each step, the system selects the next step with the lowest navigation cost from all pending steps for that robot.

When a robot has multiple pending orders, the system uses "Step Selection" logic to decide the next move: while the robot is idle or moving, the system traverses all executable steps (across different orders) and ranks them based on factors like in-situ execution priority, order priority, and navigation costs to select the most appropriate one. If the selected step differs from the one currently being executed and the robot is still moving, the system will interrupt the current navigation before switching to the new step.

Grouped Pooling: The taskBatch Mechanism

Automatic pooling answers the question of "which orders are most efficient to pool together." However, in certain business scenarios, a stricter constraint exists: specific orders must be completed by the exact same vehicle.

A typical scenario occurs in outbound processes: a Box Robot retrieves totes from high-density shelving and places them onto a transfer rack, which a lifter AGV then transports to the production line. If totes destined for the same transfer rack are assigned to multiple Box Robots, it can lead to buffer zone congestion as multiple vehicles converge on the same rack. Furthermore, the transfer rack must wait until the last vehicle arrives before it can be moved.

M4 addresses this requirement through the taskBatch field. When creating orders, the same taskBatch value (a string identifier) is assigned to the same batch of orders. During dispatch, the system guarantees that orders within the same group are allocated to the same Box Robot.

The core rules of taskBatch are as follows:

• Grouped Orders Must Go to the Same Vehicle: Once the first order of a group is assigned, all subsequent orders in that group can only be assigned to that specific robot.

• Different Groups Cannot Be Mixed: Even if a vehicle has 8 slots and Group A takes 4 while Group B takes 4, they cannot be pooled together. A robot cannot carry goods from different taskBatch groups simultaneously.

• A Single Group Occupies Only One Vehicle at a Time: If a group contains 10 orders but the robot only has 8 slots, the system will fill up one vehicle's slots first rather than splitting the group across two vehicles. This avoids the worst-case scenario where multiple vehicles head to the same group simultaneously, each carrying only one item, leaving other groups completely starved of robots.

• Orders Without a taskBatch Participate in Normal Auto-Pooling: Orders without a batch identifier are unaffected by these constraints and will not be pooled together with taskBatch orders. The execution sequence within a group is still dynamically determined by the dispatcher based on path costs; taskBatch only controls "who gets the order," not "which one is executed first."

Conveyor Scenarios: Coordination of Three Mechanisms

In conveyor line (roller lines, conveyor belts) scenarios, order pooling faces a unique challenge: after a Box Robot picks a tote from the conveyor, another new tote may arrive on the line very shortly, but the system has not yet had time to issue a new order. If the robot immediately departs to drop off its load or pick up orders elsewhere, it will have already left by the time the new tote arrives. Backtracking would severely degrade efficiency.

M4 resolves this by combining three mechanisms, each operating at a different layer:

• Restrict Order Intake Range (In-situ Waiting): This handles the execution layer. After completing a pick, the robot does not immediately proceed to the drop step; instead, it waits in place for a specified duration. During this waiting period, it only accepts new pick orders at its current location (or within a designated range). It only proceeds to subsequent steps after a timeout or when fully loaded. This feature requires a two-step configuration: first, set the wait time and intake range at the scenario level, and then enable the "Restrict Order Intake Range" parameter within the order step.

• Pause Auto-Pooling: This handles the dispatching layer, preventing the robot from being dispatched to other stations while waiting. By default, multi-slot robots automatically pool new orders. If another conveyor line has a pick task, the robot might be pooled into that task and leave its current line. When the "Pause Auto-Pooling" state is enabled, the robot only accepts orders explicitly assigned to it and rejects automatic pooling inputs.

• Station Lease: This addresses more complex scenarios involving multiple conveyors and multiple robots. When a robot arrives at a conveyor and picks a tote, the system creates a lease for that station. During the lease period, all new goods on this conveyor are exclusively allocated to the lease-holding robot, and other robots cannot cut in line. Leases support renewals (resetting the timer after each pick) and various termination conditions (fully loaded, timeout, or fault). Think of it like renting a parking space—upon arrival, the robot "rents" an exclusive spot, gaining sole service rights to that line for the duration of the lease.

The division of labor among the three can be understood as follows: taskBatch or order sequences ensure that new orders are assigned to the same vehicle (dispatch-layer constraint); pausing auto-pooling prevents the robot from being sent elsewhere (dispatch-layer constraint); and restricting the order intake range pauses the robot after a pick so it does not immediately leave for a drop-off (execution-layer constraint). In practice, combinations are chosen based on scenario complexity: in simple scenarios, restricting the order intake range alone is sufficient, whereas complex multi-station scenarios may require all three to work in tandem.

No-Pooling Mode

Not all scenarios require order pooling. If the business logic dictates a strict one-order-per-vehicle rule, the maximum load capacity can be set to 1 in the robot group configuration. The system will completely disable pooling, ensuring each robot executes only one order at a time.

Current Limitations and Evolution Roadmap

M4's order pooling capabilities are continuously expanding. Currently supported core features include dynamic pooling, dynamic execution sequencing, order preemption, re-dispatching, taskBatch grouped pooling, pick-and-drop sequence optimization, and restricted order intake ranges.

Several capabilities are currently being planned or developed:

• Pooling by Specified Keys: Passing conditions like production line numbers or material categories via taskBatch, allowing only orders with matching conditions to pool together.

• Same-Priority Rule: Restricting pooling exclusively to orders of identical priority.

• Script Extensions: Supporting custom scripts to tailor order sorting, robot filtering, and avoidance logic.

• Order Sequences: A more comprehensive workflow management tool than taskBatch, supporting explicit creation, sealing, and lifecycle controls.

• Smart Staging During Task Execution: Enabling robots to temporarily wait in a staging/buffer area after picking goods if the lift or elevator is unavailable.

Additionally, a special scenario worth noting is order pooling for double-deep racking. When an inner tote needs to be retrieved, the outer tote must be moved out of the way first. Currently, this is handled in two ways: reserving an empty slot on the robot to temporarily hold the outer tote, or finding an empty slot on the rack for a stock relocation. These scenarios place higher demands on slot management and path planning for order pooling.

Summary: A Process of Continuous Decision-Making

Order pooling for Box Robots is not an isolated feature; it is the result of multiple subsystems within M4—such as dispatching, step selection, execution control, and exception recovery—working in unison. From the dynamic appending and preemption of automatic pooling, to the group constraints of taskBatch, and the fine-grained coordination of the three mechanisms in conveyor scenarios, the richness of these pooling capabilities reflects the complex demands multi-load robots place on M4, and represents the ongoing direction of M4's evolution.