Factories and logistics
Warehouse AMRs and the loaded missions a fleet must complete
Choose a material-flow design, measure handoffs and delays, and estimate fleet capacity from complete loaded missions.
A warehouse mobile robot is useful when the correct load reaches the correct station at the required time. Travel speed is one input. Loading, queueing, docking, unloading and returning for the next task can occupy much of the mission.
Define the unit of work before comparing systems. An order line, a tote movement and a pallet transfer are different outputs. Combining them into a single robots-per-hour figure removes the information needed to plan the operation.
Choose the load flow before the vehicle
OTTO's 100 product page describes workcell and lineside transport with carts, bins and boxes. It also identifies separate attachment options such as a conveyor. This illustrates why the load-handling equipment belongs in a configuration comparison. A mobile base does not automatically load or unload every container. [1]
Scroll sideways for all columns.
| Workflow | What moves | Handoff to examine |
|---|---|---|
| Person-to-goods support | A container accompanies or meets a picker | Who confirms the correct item and sends the container onward |
| Goods-to-person | Inventory moves to a working station | How the station selects inventory and returns it to storage |
| Conveyor-top transfer | A tote passes between robot and fixed equipment | Alignment, load presence and the ready-to-transfer signal |
| Pallet or cart transport | A larger load moves between defined positions | Pickup geometry, load stability and destination availability |
Use the whole mission in a capacity estimate
Consider a hypothetical tote mission with 30 seconds for pickup, 120 for travel, 30 for drop-off and 60 for repositioning and waiting. Total elapsed time is four minutes. The arithmetic gives 15 missions per hour for one robot when those assumptions hold.
Assume only 80% of scheduled time remains available after charging and other planned losses. Capacity becomes 12 missions per hour. A demand of 100 missions per hour suggests at least nine robots under this simplified model, since 100/12 is about 8.33.
That is a planning estimate, not a fleet recommendation. Robots share intersections and stations, so adding a ninth vehicle can change the original mission time. Validate peak demand and congestion with the actual layout before using the estimate for procurement.
The slow missions can determine whether production waits
An average delivery time can conceal a small group of very late missions. Retain the distribution and identify which stations or time periods generate delays. A station that requires a tote every ten minutes may be affected by a few long waits even when the daily average looks acceptable.
In an illustrative set of 100 missions, 95 take four minutes and five take 20 minutes. The average is 4.8 minutes. The five delayed jobs still require an explanation. Averages do not make those 20-minute waits disappear.
Record the request time, assignment time, pickup, arrival and accepted handoff. These timestamps separate a dispatch delay from a travel delay or a blocked destination.
A shared message format is only part of integration
VDA's official page identifies VDA 5050 as an interface between mobile robots and central control, with version 3.0.0 dated March 2026. Request the implemented version and supported behavior from each supplier. A common label does not settle the details of a mixed fleet. [2]
MassRobotics' interoperability materials provide another reference for exchanging robot information. The scope of the particular version should be read before treating shared status messages as task dispatch, navigation or safety functionality. [3]
Write an integration test around an actual mission. Confirm load identity, assignment acceptance, status updates and completion. Also specify who resolves a stale status, duplicate request or failed handoff. Avoid counting a network message as proof that a physical transfer completed.
Measure useful work and remaining human work together
A pilot report should retain completed loaded missions, failed handoffs, interventions per 100 missions, recovery time and station waiting time. Empty repositioning travel should remain visible without being counted as delivered material.
For a worked cost example, assume a defined operating period costs 600 units of currency in the included categories and produces 300 accepted loaded missions. That is two units per mission. A different proposal completing only 200 missions at the same cost produces three units per mission. State which costs are included and which are excluded; these numbers are illustrative.
Record maintenance, software support and manual exception handling separately. A useful pilot ends with a repeatable workload and a traceable log, not just a tally of moving robots.
Sources and scope
Sources were consulted for this revision. Manufacturer descriptions are identified in the text. Worked examples are illustrative calculations, not measurements from a TechniaHQRobot test.
- OTTO 100 and its load-handling attachments
Manufacturer's documented workflows and attachments. Dynamic specification counters were not used as numeric evidence.
- VDA 5050 official overview
Interface purpose and the listed March 2026 version. No installation conformity is inferred.
- MassRobotics AMR interoperability repository
Primary protocol materials. Readers should check the exact version and supported scope.