In warehousing and factory logistics, Autonomous Mobile Robots (AMRs) are replacing manual handling on a massive scale. However, different handling requirements demand entirely different robot models. Currently, M4 supports three major categories of AMRs: Latent Robots, Forklifts, and Box Robots. Among them, the Box Robot is the most complex from both a hardware architecture and software control perspective.

This article will break down the fundamental concepts of the Box Robot across four dimensions: vehicle positioning, hardware structure, business workflows, and dispatching logic.

Three Major Models, Each to Their Own Duties

To understand the uniqueness of the Box Robot, we must first look at its position within the robot family.

Latent Robots represent the "bulk handling type." A latent robot drives underneath a rack and lifts the entire rack using an internal lifting mechanism, moving the rack and goods together. This is ideal for rack-level batch transfers, such as moving an entire rack of materials from a warehouse to a production line.

Forklifts are the "highly adaptable type." They use forks to rise and lower across various height levels to pick and place pallets or racks, making them perfect for multi-tier racking storage and retrieval. High-reach forklifts can operate on the second tier and above, covering capabilities from ground-level horizontal transport to high-position storage.

Box Robots are the "precision picking type." Instead of moving an entire rack, a Box Robot retrieves an individual tote or carton from the rack and delivers it to a designated workstation or storage slot. Equipped with multi-tier storage slots (baskets) onboard, it can carry multiple totes in a single trip and perform picking or placing operations in any sequence. This ability to operate finely at the single-box level makes it inherently more complex in both hardware and software than the other two models.

Baskets: The Core Hardware Structure of Box Robots

The most prominent hardware feature of a Box Robot is its multi-tier baskets. You can think of these baskets as storage compartments arranged vertically on the robot body—with the first tier numbered 0, the second tier numbered 1, and so on. Different Box Robot models come with varying numbers of baskets, with 3-tier, 6-tier, or even 9-tier configurations being common.

In addition to the baskets, Box Robots feature another critical mechanism: the fork arm. During a picking operation, the fork is responsible for grabbing the tote from the rack slot, retracting, and pushing it into a basket. For placing operations, it reverses the process, retrieving the tote from the basket and extending it into the target slot. In certain scenarios, the fork arm itself is required to temporarily hold a tote. This is known as the "N+1 Mode"—where N baskets plus the fork arm itself provide a total of N+1 carrying positions.

The presence of these baskets naturally enables the Box Robot to transport multiple totes in a single trip. However, this also means that M4 must track the status of each basket in real time: which tier is occupied, which is empty, and which specific tote is currently loaded. By default, the system will select the lowest available empty basket for loading, or the highest occupied basket for unloading.

Pick and Place Workflows: A Chain of Precision Steps

The complexity of a Box Robot is reflected not only in its hardware structure but even more so in the business workflow of every single pick and place operation.

By comparison, the core action for a Latent Robot to pick up goods is simply "drive under the rack → lift," while for a Forklift, it is "raise forks to the target height → insert and pick." Their action sequences are relatively short with fewer intermediate steps.

A single pick operation for a Box Robot, however, requires executing eight distinct steps: navigate to the target point → rotate and elevate the fork to the scanning position → scan the location barcode with the camera (to confirm arrival at the correct rack location) → scan the tote barcode with the camera (to confirm the correct tote is about to be grabbed) → grab the tote with the fork → retract the fork → push the tote into the basket → reset the fork.

The placing workflow is equally precise: navigate to the target point → move the fork to the corresponding basket → retrieve the tote from the basket → rotate and elevate the fork to the scanning position → scan the location barcode with the camera (to confirm placement at the correct location) → deliver the tote into the storage slot → retract and reset the fork.

Several notable characteristics are shared across both workflows:

1. Vision recognition is embedded throughout the process. The camera scans barcodes twice during picking (location code and tote code) and once during placing (location code). These scanning steps are not optional auxiliary features; they are rigid nodes in the workflow—if the barcode is incorrect, the robot will not move.

2. Goods must be transferred between the fork and the baskets. Latent Robots and Forklifts hold goods directly on their main body, moving as soon as the load is secured. Box Robots require an extra transfer step: "fork → basket" (picking) or "basket → fork" (placing). This transition involves mechanical actions like fork rotation, extension, and gripping, making it the step most prone to mechanical faults.

3. Fault recovery protocols are stricter. If a mechanical failure occurs during picking, even if the tote has already been gripped by the fork, the tote must be returned to its original slot before releasing the emergency stop to allow the robot to re-execute the picking action. No steps can be skipped.

Because a single pick or place involves so many intricate steps, the problems M4 needs to solve multiply exponentially when a Box Robot is tasked with handling multiple totes in a single trip.

Single-Load vs. Multi-Load: The Watershed of Dispatching Perspective

From M4’s perspective, AMRs can be divided into two categories: single-load robots and multi-load robots.

Latent Robots and Forklifts generally belong to the single-load category—the vehicle body has only one cargo position and carries goods for only one transport order at a time. M4 assigns it a task, it picks, delivers, completes the task, and then takes the next order. The logic is crystal clear, and the workflow is simple.

Box Robots are classic multi-load robots. Multiple baskets mean they can carry goods for multiple transport orders simultaneously. This introduces challenges that single-load robots never face: Should multiple orders be assigned to the same robot? If so, which one should be picked first and which one later? After picking, should the robot deliver them all together, or deliver a portion of them first?

The answers to these questions form the core subject addressed by the Order Batching (Order Pooling) mechanism in M4.

Order Batching: The Efficiency Engine for Multi-Load Robots

"Order batching" can be compared to a food delivery courier taking optimized, multi-stop routes. If a courier rides out and back for every single order, efficiency is incredibly low. By batching multiple orders with similar routes together, the courier can pick up multiple meals in one go and deliver them along the way, vastly increasing the delivery volume per unit of time.

The batching logic for Box Robots follows a similar principle. M4 comprehensively considers factors such as path costs, order priorities, and order waiting times to assign multiple transport orders to a single Box Robot, allowing it to pick and place as much as possible in one trip.

In M4, order batching is not a simple "bundling of tasks." Each transport order in M4 corresponds to the handling of a single tote (one pick and one place). Batching occurs at the dispatching layer—the system intelligently assigns multiple independent orders to the same multi-basket robot and dynamically determines the execution sequence.

The word "dynamic" is key here. During execution, the Box Robot’s pick-and-place sequence is not a rigid "pick everything first, then place everything." Instead, it is adjusted dynamically based on real-time path costs. The sequence could be pick, pick, place, pick, place, place, or any other combination—largely depending on which destination yields the shortest path for the multi-load robot at that moment. Furthermore, if a new order is released upstream during execution and meets the batching criteria, the Box Robot can dynamically append or swap in this order without waiting to complete its current tasks.

In certain business scenarios, order batching must also satisfy additional constraints. For example, in outbound scenarios, multiple totes might need to be placed onto the same transfer rack, which is then moved away as a whole by a Latent Robot. In this case, this batch of totes must be picked and delivered by the exact same Box Robot. Otherwise, if multiple Box Robots attempt to drop off goods at the same rack simultaneously, it will cause congestion in the handover zone, and the rack would have to wait for multiple robots to arrive one by one before it could be moved. M4 achieves this type of batch-bound order pooling through its taskBatch mechanism.

Non-Isolated Work: Collaboration Scenarios for Box Robots

In real-world projects, Box Robots rarely complete an entire logistics link in isolation. A more common pattern is for them to work in tandem with Latent Robots to form a relay-style material handling process.

A typical collaborative workflow looks like this: the upstream system issues an outbound instruction to the dispatching system; the Box Robot retrieves totes one by one from high-density racking and places them onto a designated transfer rack; once the rack is full, a Latent Robot drives underneath the rack and transports it as a whole to the target production line. In this process, the Box Robot handles "picking" while the Latent Robot handles "bulk transfer," with the capabilities of the two models complementing each other.

This collaborative model has been validated across multiple real-world projects. For instance, in a project for an electrical equipment manufacturer, after a Latent Robot transports a rack equipped with electronic tags to the handover area, a Box Robot retrieves individual totes from the rack based on the tag information and sends them to the corresponding workstations. Because the tag-facing side of the rack cannot be identified by the Box Robot, the Latent Robot must utilize a follow-and-turn function when placing the rack to ensure it faces the correct direction. This level of detail in coordination exemplifies the true complexity of multi-model collaborative dispatching.

The Most Complex Vehicle Model, The Richest Dispatching Logic

The Box Robot stands out as the model with the most complex structure, the most precise workflows, and the richest dispatching logic among AMRs. While multi-tier baskets empower it with multi-tote handling capabilities in a single trip, they also place higher demands on M4: tracking the real-time status of each basket, planning the pick-and-place sequence of multiple orders, and dynamically responding to new tasks mid-execution. Behind these capabilities lies M4’s continuous evolution in batching algorithms, task orchestration, and multi-robot collaboration.