How to Choose a Warehouse Transport Robot by Task

Separate Navigation Approach From Load-Handling Form

Warehouse robot discussions often mix two different questions.

The first is how the vehicle navigates and operates in traffic. This guide treats AGV and AMR as terms on that navigation and operating-approach axis. If this is the decision you are making, begin with BotOnly’s AGV vs AMR guide.

The second is how the vehicle engages and moves the load. Examples include:

• A deck or platform vehicle that carries a load on top
• A low-lift vehicle that collects a pallet near floor level
• A tugger or tow tractor that pulls one or more wheeled carts
• An under-load lifting or rotating AMR for a compatible cart, rack, or load carrier, when that form is represented in the current BotOnly source set
• A fork-style vehicle that lifts and transports pallets
• A stacker or reach-type vehicle that places pallets into storage
• A CTU or other verified tote-handling AMR that moves compatible totes between storage or transfer locations and a workstation

These are not mutually exclusive with AGV or AMR. A towing vehicle, pallet mover, or fork-style robot may use different navigation and traffic-management approaches. Treating every label as one flat list makes the shortlist less accurate.

The distinction is visible in official portfolios, although each supplier uses its own taxonomy. MiR pairs mobile robots with hook, shelf-lift, and pallet-lift applications. (MiR) ABB groups tug, mover, and stack vehicles. (ABB) Seegrid presents lift products separately from its tow tractor. (Seegrid)

Define Six Inputs Before Comparing Candidate Families

1. Task

Describe the movement in operational terms.

“Move materials” is too broad. “Collect a wrapped pallet from a marked floor position and deliver it to a production-side buffer” is useful. So is “pull four identical carts on a repeating milk run” or “move totes between a conveyor and manual inspection stations.”

OTTO’s workflow guidance similarly starts with the current movement between people, automation equipment, racks, and floor locations before evaluating an AMR solution. (OTTO Motors)

2. Load unit

Record the real load, including:

• Unit type
• Minimum and maximum weight
• Dimensions and overhang
• Center of gravity and stability
• Pallet or cart construction
• Wrapping, straps, lids, or loose contents
• Whether loads vary by SKU, shift, or season

A nominal payload figure is not enough. The same weight can behave differently on a rigid pallet, a damaged pallet, a tall cart, or a partly filled tote.

3. Pickup and drop-off

Identify the physical handoff at both ends:

• Floor position
• Pallet stand
• Wheeled cart
• Conveyor
• Rack
• Machine
• Workstation
• Manual staging area

Also record the height, alignment tolerance, approach direction, available clearance, and whether a person or control system confirms that the location is ready.

4. Horizontal and vertical action

Every candidate must satisfy the required motion:

• Horizontal travel only
• Horizontal travel plus top transfer
• Floor pickup
• Fork entry and lift
• Low-level stacking
• Rack storage or retrieval
• High reach
• Precise alignment with a conveyor or machine

A robot that can transport a pallet is not automatically able to collect that pallet from the floor or place it into a rack.

5. Operating conditions

Document route length, aisle width, intersections, manual traffic, doors, gradients, floor transitions, charging opportunities, operating hours, and current and peak flow.

OTTO’s official selection guidance asks for details such as payload dimensions, pallet type, pickup and drop-off height, throughput, manual traffic, ramps, slopes, and Wi-Fi conditions. These are useful discovery inputs, although the final validation requirements will vary by system. (OTTO Motors)

6. Validation standard

Decide what evidence will move a candidate from “possible” to “approved.” This may include load tests, docking repeatability, route observations, peak-flow simulation, exception handling, system-interface tests, safety review, and acceptance criteria.

Task-to-Robot Decision Matrix

Use the matrix to create a shortlist. A row may produce more than one candidate because facility constraints, load design, throughput, and integration can change the result.

The last row is important. A single material flow does not always require a single robot type. BALYO’s inbound-to-end-of-aisle example illustrates how horizontal pallet transport and storage handling can be treated as connected but distinct operations. (BALYO)

Compare Candidate Families by Physical Task

Pallet transport

First determine how the pallet will be collected and delivered.

For floor-to-floor movement, the candidate needs a compatible floor-pickup method. For a pallet that remains on a stand or transfer station, a deck, conveyor-top, lift-top, or fork-style approach may be possible depending on the interface.

Do not stop at payload. Verify pallet construction, entry direction, damaged-board policy, load overhang, wrapping, ground clearance, pickup height, and the space required to approach and exit.

If the destination is a rack location, the task is no longer horizontal pallet transport alone. It includes vertical placement, rack clearance, and capacity at the required height.

Cart and trolley towing

Towing is often a strong candidate when the existing process already uses wheeled carts, especially for repeated routes, line supply, replenishment, or return flows. ABB describes towing mobile robots as vehicles that pull one or more trolleys. (ABB) On its own Tow Tractor product card, Seegrid lists long-haul cart train tugging, parts-to-line, replenishment, putaway, cross-docking, and dunnage/trash removal as key applications. (Seegrid)

The cart system is part of the automation. Couplers, caster behavior, cart dimensions, load retention, train length, turning radius, stop distance, and manual uncoupling all affect feasibility.

For one compatible cart, rack, or load carrier, an under-load lifting or rotating AMR may reduce coupling work when that form is present in the current BotOnly source set. It still requires mechanical standardization, verified underside clearance, and repeatable docking access.

Pallet stacking and rack handling

A stacker or autonomous forklift family becomes relevant when the robot must lift a pallet above a transfer height, place it into storage, or retrieve it from a rack.

The required height alone does not settle the choice. Capacity can change with lift height and load center, and the vehicle must work within the aisle, rack, floor, and clearance conditions. Low-level stacking, general rack handling, and high narrow-aisle storage should therefore be treated as different validation problems.

Case and tote movement

“Move totes” can describe two very different scopes.

The first is point-to-point transport: a standardized tote or case travels between workstations, conveyors, inspection points, or production cells. A top-transfer or manually loaded transport robot may be sufficient.

A verified CTU or tote-handling robot may support tote movement between compatible storage or transfer locations and a workstation. A broader goods-to-person system can also include shelves, racks, pallets, inventory logic, replenishment, sequencing, and pick stations, but this guide does not present those unverified system forms as BotOnly candidate products.

Industry suppliers use different system taxonomies. Dematic separates Bin-to-Picker, Shelf-to-Picker, Pallet-to-Picker, and AMR Transport in its own portfolio, while Geek+ presents Shelf-to-Person, Tote-to-Person, Pallet-to-Person, and Material Transport as separate solutions or modules. These examples establish the boundary between simple transport and broader fulfillment design; they are not copied into the BotOnly candidate list unless a matching BotOnly product source is verified.

This boundary prevents a simple transport requirement from being overdesigned, prevents a fulfillment requirement from being reduced to vehicle travel alone, and keeps the BotOnly shortlist limited to verified product forms.

Apply Facility and Flow Filters

A mechanically compatible robot can still be the wrong operational choice.

Filter each candidate against:

• Space: aisle width, turns, staging areas, queues, passing points, and docking clearance
• Traffic: pedestrians, forklifts, intersections, blind corners, shift changes, and shared work zones
• Floor and environment: gradients, joints, thresholds, debris, temperature, moisture, and lighting or sensing conditions
• Flow: average rate, peak rate, variability, empty return trips, waiting, and blocked destinations
• Availability: operating hours, charging windows, maintenance access, and recovery procedures
• Interfaces: doors, elevators, conveyors, machines, call buttons, traffic controls, and business systems
• Exceptions: damaged loads, missing carts, occupied stations, misplaced pallets, spills, network loss, and manual overrides

Do not convert a travel speed from a datasheet directly into throughput. Real flow also includes pickup, alignment, loading, unloading, waiting, charging, traffic interaction, exceptions, and empty movement.

Turn Candidate Families Into a Verifiable Shortlist

For every shortlisted family, ask suppliers or integrators to respond to the same task definition and evidence request.

Load evidence

• Supported load range and center-of-gravity assumptions
• Load dimensions, overhang, stability, and retention
• Pallet, cart, tote, or rack compatibility
• Required condition and dimensional tolerance of the load carrier
• Capacity at the actual lift height, where relevant

Handoff evidence

• Pickup and drop-off heights
• Required clearance and approach direction
• Docking and placement tolerance
• Station sensing and load-ready logic
• Recovery when a station is occupied, misaligned, or unavailable

Route and flow evidence

• Turning and stopping envelope with the real load
• Behavior at intersections and in mixed traffic
• Treatment of narrow points, doors, slopes, and floor transitions
• Fleet size and throughput assumptions
• Charging and peak-period strategy
• Queueing, blocked destination, and empty-return logic

Integration and operating evidence

• Interface ownership
• Command, status, fault, and recovery states
• Manual operating and override procedures
• Safety review scope
• Maintenance and support responsibilities
• Test plan and acceptance criteria

Require assumptions to be visible. A throughput estimate without route, dwell, traffic, charging, and exception assumptions is not yet a comparable result.

Common Selection Mistakes

Starting with a model list

A product list hides the physical task. Start with the movement, load, handoff, and required action.

Using payload as the only filter

Weight does not capture load center, stability, carrier condition, overhang, lift height, or transfer geometry.

Calling every pallet movement “forklift automation”

Some pallets move between fixed stations or remain on transfer stands. Others require true floor pickup or rack placement. Those tasks do not have identical mechanical requirements.

Treating tote transport as goods-to-person automation

Point-to-point tote movement and inventory presentation solve different operational problems.

Assuming one vehicle must perform every step

Separating horizontal travel from vertical storage may reduce bottlenecks in some workflows. In others, one vehicle may be simpler. Compare the complete flow.

Comparing navigation labels before defining the load task

AGV versus AMR matters, but it does not determine whether the vehicle should carry, tow, fork, stack, or transfer the load.