Mobile Robots: AMRs & AGVs — The Ultimate Guide

A mobile robot is the only machine in your facility that decides, on its own, where to put a couple of hundred kilograms of moving mass. Get the chassis, the sensing, and the safety stack right and it threads through a working aisle full of people for years. Get them wrong and you have a 0.3 m/s battering ram with a SLAM map, or — more common — a very expensive robot that sits in a corner because nobody could get it commissioned.

This guide is about the machines that move loads around a floor without a human steering them: automated guided vehicles (AGVs) and autonomous mobile robots (AMRs). We will pull apart the real distinction between the two (it is not marketing), walk the drive and chassis configurations and their kinematics, go deep on the navigation sensing and the SLAM that turns LiDAR returns into a pose, cover path planning and fleet traffic, and then get serious about safety standards, charging strategy, the software stack, payload modules, and what deployment actually costs once the demo is over. Real hardware throughout: MiR, OTTO Motors, Locus, Fetch/Zebra, Amazon (Kiva), Geek+, AgileX, Clearpath.

The take: AMRs won the mid-market because they removed infrastructure, not because they navigate better — a guidewire AGV is more deterministic than any free-roaming AMR will ever be. The engineering question is never "AMR or AGV?" in the abstract; it is "how deterministic does this path need to be, how often will the layout change, and who shares the floor?" Answer those three and the chassis, the nav method, and the safety class fall out almost mechanically.

Companion reading: LiDAR & depth cameras, robot sensors, motion planning & kinematics, and ROS 2.

Table of contents

1. Key takeaways
2. AGV vs AMR — the real distinction
3. Drive & chassis configurations
4. Locomotion hardware
5. Navigation sensing
6. SLAM & localization
7. Path planning & traffic
8. Safety
9. Power & charging
10. Compute & software stack
11. Payload handling & top modules
12. Deployment realities
13. Selecting an AMR/AGV
14. Frequently asked questions

AGV vs AMR — the real distinction

The terms get thrown around as if AMR simply means "newer AGV." It doesn't. The distinction is about how the vehicle knows where to go and what it does when something is in the way.

An AGV follows guidance infrastructure. Classically that was a wire buried in the floor carrying a signal the vehicle tracked; later, magnetic tape stuck to the floor, optical lines, retroreflective targets on walls, or a grid of QR/DataMatrix codes. The path is fixed. When an obstacle appears on that path, a pure AGV stops and waits. It does not go around — it has no concept of "around," because it has no map of free space, only a line to follow.

An AMR carries a map of the environment and continuously estimates its own pose within that map (localization). It is given a goal — a coordinate or a named station — and it computes its own route, then replans in real time around obstacles a planner didn't know about. Take a box off the floor and drop it in the aisle: the AGV stops; the AMR steers around it and carries on.

The clean test: if removing the floor infrastructure breaks navigation, it's an AGV. If you can pick the robot up, set it down in a mapped building, and it just drives, it's an AMR.

Why AMRs ate AGVs' lunch

The historical AGV cost wasn't the vehicle — it was the infrastructure tax. Cutting a wire channel into a finished concrete floor, or laying and maintaining magnetic tape that forklifts shred, costs real money and freezes your layout. Change the racking and you re-lay the guidance. For a facility that reconfigures seasonally, that's a recurring cost and a recurring downtime.

AMRs (MiR launched 2015, Fetch and Locus around the same window) removed that. You drive the robot around once to build a map, and you're running. Re-arrange the warehouse and you re-map in an afternoon — no floor work. That flexibility, plus the safety-scanner-driven ability to share aisles with people instead of needing caged lanes, is why AMRs took the mid-market: e-commerce fulfilment, hospitals, electronics assembly, anywhere the layout and the people are fluid.

Where AGVs still win

AGVs are not legacy. Where the route never changes and throughput is high, a guided vehicle is more deterministic and often cheaper per move. A wire-guided tugger train running the same loop 24/7 in an automotive plant doesn't benefit from replanning — replanning is a liability you'd rather not have on a fixed high-speed route. Heavy-payload vehicles (counterbalance AGV forklifts moving 1,500 kg pallets) lean toward guided paths because the safety case for a free-roaming 2-tonne vehicle is far harder. And Amazon's fulfilment "drives" use a QR-grid floor precisely because a deterministic grid lets thousands of robots run dense, coordinated traffic at speed — that's an infrastructure-guided system by design, not a fleet of free-roaming AMRs.

Dimension	AGV (infrastructure-guided)	AMR (map-based autonomous)
Path definition	Fixed: wire, mag-tape, optical, reflector, QR grid	Dynamic: computed on a map, replanned live
Obstacle response	Stop and wait	Reroute around it
Infrastructure	Floor/wall modification required	None (drive-to-map)
Layout change cost	High (re-lay guidance, downtime)	Low (re-map)
Determinism / repeatability	Very high (sub-cm on guidance)	Lower (±1–5 cm typical free-nav, tighter with fiducial docking)
Sharing space with people	Caged lanes or slow zones, historically	Designed for it (safety scanners, dynamic zones)
Throughput on fixed routes	Excellent	Good
Per-pick economics on fixed loop	Often lower	Higher (compute, sensing)
Typical payload sweet spot	100–3,000+ kg	50–1,500 kg
Examples	Wire-guided tuggers, counterbalance AGV-forklifts, Amazon QR drives	MiR, OTTO, Locus, Fetch/Zebra, Geek+

In practice the line blurs. "Hybrid" vehicles run free-nav in open areas and snap to magnetic tape or fiducials for precise docking. OTTO and MiR vehicles will use floor or wall markers to dock to a conveyor within ±1 cm while navigating naturally everywhere else. The taxonomy is a spectrum of how much determinism you buy with infrastructure, not a binary.

Drive & chassis configurations

The drive configuration sets the robot's kinematics — what motions it can and cannot make — and that ripples into the planner, the docking strategy, and the cost. Pick this first; everything downstream inherits it. The math here is the planar mobile-robot kinematics covered in the motion planning guide; here we care about the practical tradeoffs.

Differential drive

Two independently driven wheels on a common axis, plus one or more passive casters for balance. It is the default for indoor AMRs (MiR, Fetch, Kiva-class shelf-lifts) because it is mechanically dead simple, cheap, and can spin in place — a zero turning radius.

The forward kinematics are clean. With wheel radius r, wheel separation (track width) L, and left/right wheel angular velocities ω_L, ω_R:

v_L = r · ω_L          # left wheel linear speed
v_R = r · ω_R          # right wheel linear speed

v     = (v_R + v_L) / 2          # body linear velocity (m/s)
ω     = (v_R − v_L) / L          # body angular velocity (rad/s)

# Integrate to get pose (x, y, θ), e.g. each control tick dt:
θ_new = θ + ω · dt
x_new = x + v · cos(θ + ω·dt/2) · dt
y_new = y + v · sin(θ + ω·dt/2) · dt

# Pure spin in place: v_R = −v_L  →  v = 0, ω ≠ 0

The cost of all that simplicity: it is nonholonomic. It cannot move sideways. To shift 10 cm laterally to dock against a conveyor it must do a little turn-drive-turn dance, which eats time and floor space. For most warehouse work that's fine — you design dock approaches as straight-in.

Omnidirectional (omni/mecanum)

Mecanum wheels have angled rollers (typically 45°) around the rim; omni wheels have rollers perpendicular to the rolling direction. Drive four of them with the right velocity mix and the chassis becomes holonomic — it can translate in any direction and rotate independently, all at once. It can strafe straight into a dock with no maneuvering.

For a four-mecanum chassis with half-track a and half-wheelbase b, the inverse kinematics (body velocity → wheel speeds) are:

# Body command: vx (forward), vy (left), ωz (yaw), wheels at corners
ω_FL = (1/r)·(vx − vy − (a+b)·ωz)
ω_FR = (1/r)·(vx + vy + (a+b)·ωz)
ω_RL = (1/r)·(vx + vy − (a+b)·ωz)
ω_RR = (1/r)·(vx − vy + (a+b)·ωz)

The price is steep and physical: the angled rollers slip by design, so you lose roughly 15–30% of available traction and your odometry is noticeably worse than differential. Mecanum wheels also hate floor debris, seams, and ramps — a small bolt jams a roller — and they wear faster. Use omni/mecanum where lateral precision in a tight footprint genuinely pays: machine tending, narrow-aisle docking, mobile manipulation cells. Don't use it for long-haul transport; you're burning energy and tire life for a capability you rarely exercise.

Steered / swerve drive

Each wheel module both drives and steers (the "swerve" you know from FRC robotics). Two-to-four steered drive modules give holonomic-like motion without the roller slip — full traction, good odometry, can translate any direction. The catch is mechanical and control complexity: each module is a drive motor plus a steer motor plus its own controller, and coordinating module heading during transitions is nontrivial. You see this on higher-end heavy AMRs and some outdoor platforms where you want omnidirectionality and traction both.

Tricycle

One steered+driven front wheel and two passive rear wheels (or the mirror). This is classic AGV-forklift geometry. It's robust and carries heavy loads well, but it has a turning radius (no spin-in-place) and the kinematics put a hard constraint on tight-space maneuvering. Counterbalance AGV-forklifts and many tow-tractors use it.

Ackermann (car-like)

Front wheels steer like a car, rear wheels drive. Used almost exclusively on outdoor mobile robots and larger yard vehicles (AgileX Hunter/Bunker-class, Clearpath outdoor platforms) where speed and ride quality matter and tight indoor maneuvering doesn't. It has a minimum turning radius set by the wheelbase and max steer angle, so it cannot turn in place — a planner constraint you carry everywhere.

Drive type	Holonomic?	Spin in place?	Odometry quality	Traction efficiency	Complexity	Typical use
Differential	No	Yes	Good	High	Low	Indoor AMRs, shelf-lifts
Omni / mecanum	Yes	Yes	Poor	Low (slip)	Medium	Tight docking, mobile manipulation
Swerve (steered)	Near-holonomic	Yes	Good	High	High	Heavy/premium AMRs
Tricycle	No	No	Good	High	Low–Med	AGV-forklifts, tuggers
Ackermann	No	No	Good	High	Medium	Outdoor / yard robots

Rule: choose the least capable drive that meets your motion requirement. Every step up the holonomy ladder costs traction, money, odometry, or all three. Differential until you can prove you need lateral motion.

Locomotion hardware

Underneath the kinematics is real metal: motors, gearboxes, wheels, casters, suspension. This is where load capacity, ramp ability, and battery runtime actually get decided.

Drive motors: hub vs geared BLDC

The drive motors on essentially every modern mobile robot are brushless DC (BLDC/PMSM) for the efficiency, torque density, and lifetime — brushes are a maintenance item nobody wants on a 24/7 fleet. See the BLDC guide for the motor physics. Two packaging choices:

Direct-drive hub motors put the motor in the wheel. Clean, compact, no gearbox to maintain, and quiet. The problem is torque: an outer-rotor hub motor sized to fit a 150 mm wheel struggles to deliver the low-speed torque needed to break away a heavy load or climb a ramp without overheating. Hub motors suit lighter robots and flat floors.

Geared BLDC — a BLDC motor through a planetary reduction, typically 10:1 to 50:1 — is the workhorse. The reduction multiplies torque and lets a small, fast, efficient motor move a heavy robot up a dock ramp. The tradeoff is gearbox losses (a couple of percent per stage), backlash (matters for precise docking), and a wear item. Planetary is standard; for the very high reductions and zero-backlash some precision docking wants, you occasionally see cycloidal — see the gearbox guide.

Both are driven by field-oriented control (FOC) servo drives that give you smooth torque at low speed and clean velocity control for the differential-drive math above. The motor controller / FOC guide covers the drives; on a mobile robot the controller also feeds wheel-encoder ticks back as odometry, which the SLAM stack fuses with LiDAR.

Sizing the drive: a torque sanity check

To climb a ramp of grade α at acceleration a, each driven wheel must overcome gravity component, rolling resistance, and inertia:

m       = 300 kg          # robot + payload
g       = 9.81 m/s²
α       = 5°              # ramp grade (0.087 rad)
Crr     = 0.02            # rolling resistance coeff (poly wheel on concrete)
a       = 0.5 m/s²        # commanded accel
r_wheel = 0.10 m          # wheel radius
n_drive = 2               # driven wheels

F_total = m·g·sin(α) + Crr·m·g·cos(α) + m·a
        = 300·9.81·0.0872 + 0.02·300·9.81·0.996 + 300·0.5
        ≈ 257 + 59 + 150  ≈ 466 N

T_wheel = F_total · r_wheel / n_drive
        = 466 · 0.10 / 2  ≈ 23.3 N·m  per driven wheel

That 23 N·m per wheel is what sizes the gearmotor. Note the acceleration term (150 N) dominates the ramp term here — aggressive accel/decel, not slopes, is usually what overheats undersized drives. Always size for the worst-case payload plus the accel you actually command, not the nameplate flat-floor figure.

Wheels, casters, suspension

Drive wheels are typically polyurethane on an aluminium hub — good Crr, quiet, non-marking, decent grip. Hardness (Shore A) trades grip for life and rolling resistance. Pneumatic only shows up outdoors.

Casters carry the undriven load and define stability. The classic indoor AMR is two center drive wheels plus four corner casters — but that "rocking horse" layout can lift a drive wheel off the floor on an uneven surface, killing traction and odometry. The fix is suspension: spring-loaded drive modules that keep both drive wheels loaded with a defined normal force regardless of floor flatness. Any serious AMR (MiR, OTTO) has sprung drive modules. Skipping suspension is the classic cheap-AMR failure on a real, slightly-uneven warehouse floor.

Load capacity is set by the weakest of: motor/gearbox torque, wheel rating, caster rating, frame stiffness, and — critically — the safety case (a heavier robot needs longer stopping distance and bigger protective fields). Published payloads (MiR250 = 250 kg, MiR600 = 600 kg, MiR1350 = 1,350 kg; OTTO 100/600/1500 = 150/600/1,500 kg) are continuous safe ratings, not what the frame survives once.

Navigation sensing

A mobile robot needs to answer two sensing questions continuously: where am I (localization) and what's in front of me right now (obstacle/safety). Different sensors, often deliberately separate. The full sensor taxonomy is in the robot sensors guide; the ranging physics is in the LiDAR & depth camera guide.

The two-LiDAR architecture

This trips up newcomers constantly: a serious AMR often has two different LiDARs doing two different jobs.

The safety scanner is a safety-rated 2D LiDAR mounted low (≈10–20 cm above the floor) — SICK nanoScan3/microScan3, Pilz PSENscan, Hokuyo UAM. It is certified to IEC 61496-3 (electro-sensitive protective equipment) and its only job is to enforce protective stops: it watches configurable 2D fields and triggers a hardware-level slowdown or stop when something enters them. It is not primarily a mapping sensor; its data is trusted by the safety controller. Mounting it low catches feet, pallet jacks, and forklift tines.

The navigation scanner builds and matches the map. It can be the same physical unit on cheaper robots (a safety scanner whose measurement data is also fed to SLAM), or a separate non-safety LiDAR. Often it's mounted higher to see over low clutter and pick up stable wall/rack features.

Why two? The safety scanner's field must be certified and unchanging; the nav scanner's data can be filtered, downsampled, and fused freely. Conflating safety and perception is how you end up with a robot that's either unsafe or that nuisance-stops constantly.

2D vs 3D LiDAR

Most indoor AMRs navigate on 2D LiDAR — a single scanning plane. It's cheap, the data is light, and a 2D map is enough to localize against walls and racking. The blind spot is literal: a 2D plane at 15 cm misses a forklift tine at 40 cm or an overhanging shelf. That's why 2D-LiDAR AMRs add depth cameras angled down/forward to catch obstacles off the scan plane — low-hanging, overhanging, or floor-level (a dropped pallet, a step-down).

3D LiDAR (Ouster, Livox, Hesai — covered in the LiDAR guide) is appearing on outdoor and high-end AMRs where the environment is genuinely three-dimensional and a single plane isn't enough. It costs more and produces far more data to process. Indoors, 2D LiDAR + a couple of depth cameras remains the cost-effective sweet spot in 2026.

Depth cameras and the rest

Depth cameras (Intel RealSense-class, stereo, structured-light, ToF) fill the 3D gaps the 2D scanner misses and feed obstacle layers in the costmap. 3D ultrasonic / cliff sensors catch things lasers miss (glass walls, downward stairs/loading-dock edges) — glass is a notorious 2D-LiDAR failure because it passes the beam. Wheel encoders + IMU provide odometry that the SLAM filter fuses between LiDAR scans. A robot that relies on LiDAR alone will localize beautifully right up until it drives off a loading dock the laser couldn't see.

SLAM & localization

Two distinct phases get conflated under "SLAM": building the map (mapping) and figuring out where you are in an existing map (localization). Most production AMRs map once and then localize against the saved map; full online SLAM runs mainly during commissioning.

LiDAR SLAM and the map

SLAM — simultaneous localization and mapping — builds a map while estimating the robot's pose in it, solving the chicken-and-egg problem that you need a map to localize and a pose to map. Indoor AMRs overwhelmingly use 2D LiDAR SLAM: graph-based scan matching (Google Cartographer, slam_toolbox in ROS 2) that aligns successive scans, builds a pose graph, and runs loop closure to correct drift when the robot revisits a known place.

The output is an occupancy grid — a 2D bitmap where each cell is free, occupied, or unknown, at a resolution like 5 cm/cell. That map is the shared reference for everything: localization matches against it, the global planner routes on it, the costmap inflates obstacles on it.

AMCL — localizing in a known map

Once you have a map, you don't re-run full SLAM — you run AMCL (Adaptive Monte Carlo Localization), a particle filter. It scatters hundreds of candidate poses ("particles"), predicts how each would move given the odometry, scores each by how well the live LiDAR scan matches the map at that pose, and resamples toward the high-scoring ones. The particle cloud converges to the true pose and tracks it. "Adaptive" means it varies the particle count — more when uncertain (the "kidnapped robot" just powered on), fewer when confident.

The failure mode to know: AMCL needs features. Put an AMR in a long, featureless corridor or a wide empty floor with no walls in range and the scan matches equally well everywhere along the corridor — localization slides. The fix is environmental: keep stable features in sensor range, or add fiducials in feature-poor zones.

The navigation method spectrum

How a vehicle knows where it is spans a spectrum from zero infrastructure to total infrastructure, trading flexibility for repeatability:

• Natural-feature (free) navigation — pure map-based SLAM/AMCL, no infrastructure. The AMR default (MiR, Fetch, OTTO). Maximum flexibility; repeatability ±1–5 cm depending on feature richness.
• Reflector navigation — retroreflective targets surveyed onto walls; the scanner triangulates off them. Classic AGV method, very repeatable (sub-cm), but you must survey and maintain the reflectors.
• Magnetic-tape / magnetic-spot navigation — tape or embedded magnets in the floor. Dead simple, robust to lighting and dust, but it's a fixed path and the tape wears under forklift traffic.
• QR / fiducial-grid navigation — a grid of coded markers on the floor; the robot reads them with a downward camera and dead-reckons between. This is the Amazon/Kiva method: extremely deterministic, enables ultra-dense coordinated traffic, but it's an infrastructure-heavy AGV approach.

Most real deployments are hybrid: natural-feature nav for the open floor, plus a fiducial or magnetic spot at each dock for the last 20 cm of precision where ±1 cm matters and SLAM's ±3 cm doesn't cut it.

Path planning & traffic

Given a goal pose, the robot has to produce safe wheel commands while reacting to a world that changes. The standard architecture is a two-layer planner plus a fleet-level coordinator. The general planning theory is in the motion planning guide; the integration glue is in the ROS 2 guide.

Global planner

The global planner searches the map for a route from start to goal — A*, Dijkstra, or a state-lattice/Theta* variant — operating on the occupancy grid plus a static costmap (walls inflated by the robot radius, plus keep-out zones and preferred lanes you draw in). It produces a path but doesn't care about dynamic obstacles; it runs at low rate, e.g. on each new goal or every second.

Local planner

The local planner turns that global path into actual velocity commands at 10–20 Hz while dodging things the global planner never saw — a person stepping out, another robot, a dropped box. In the ROS 2 Nav2 stack the choices are:

• DWB (Dynamic Window Approach, the Nav2 default) — samples feasible (v, ω) commands within the robot's dynamic limits, simulates each forward, scores them against the path and obstacles, picks the best.
• TEB (Timed Elastic Band) — optimizes a trajectory with time, good for car-like/Ackermann constraints and tight spaces.
• MPPI (Model Predictive Path Integral) — sampling-based MPC, increasingly the choice for smooth, dynamics-aware control on differential and omni bases.

The local planner reads a local costmap — a rolling window around the robot fused from the safety scanner, nav LiDAR, and depth cameras — with obstacle inflation so the robot keeps clearance from its hull, not just its center point.

Nav2 in one breath

Nav2 (the ROS 2 navigation stack) wires this together: a behavior tree orchestrates "compute path → follow path → recover if stuck," the global and local planners are pluggable, AMCL provides the pose, and recovery behaviors (spin, back up, clear costmap, wait) handle the inevitable "I'm wedged" cases. It's the de-facto open stack; vendor AMRs run proprietary equivalents with the same shape.

Fleet & traffic management

One robot is a planning problem; fifty robots is a traffic problem. A fleet manager sits above the per-robot planners and prevents the failure modes of independent agents: two robots claiming the same narrow aisle head-on (deadlock), or both arriving at one intersection.

# Fleet sizing — back-of-envelope for a transport task
tasks_per_hour   = 120          # demand (moves/hour)
dist_per_task    = 80           # m (avg loaded + return)
avg_speed        = 1.2          # m/s effective (incl. accel/decel/turns)
load_unload      = 30           # s per task (dock + transfer)
charge_overhead  = 0.12         # 12% of time charging

travel_time = dist_per_task / avg_speed      # = 66.7 s
cycle_time  = travel_time + load_unload      # = 96.7 s
tasks_per_robot_hr = 3600 / cycle_time × (1 − charge_overhead)
                   = 37.2 × 0.88 ≈ 32.8 tasks/robot/hour

robots_needed = ceil(tasks_per_hour / tasks_per_robot_hr)
              = ceil(120 / 32.8) = ceil(3.66) = 4 robots
# Then add congestion margin: dense traffic erodes effective speed
# 10–25% as robot count rises — size for 5, not 4.

The coordinator uses reservation/zone allocation: a robot must reserve a path segment or intersection before entering, and the manager grants reservations to avoid conflicts, sometimes with priority rules (loaded beats empty). It also handles charging dispatch and job assignment. This congestion effect is real and nonlinear — adding robots past a point lowers throughput as they queue. Model it; don't just divide demand by per-robot rate.

Safety

This section is not optional reading. A mobile robot is a moving mass on a floor with people, and the safety case is a legal and ethical requirement, not a feature. The functional-safety background is in the industrial automation guide; here's what's specific to mobile robots.

The standards

Two regimes dominate in 2026:

• ISO 3691-4 — "Industrial trucks — Driverless industrial trucks and their systems." This is the standard for AGVs and AMRs treated as industrial trucks (the forklift/tugger/heavy lineage), widely referenced in Europe and globally. It specifies stability, control, protective devices, and the safety functions.
• ANSI/RIA R15.08 — the North American standard specifically for industrial mobile robots (IMRs), written for the AMR era. Part 1 covers the robot manufacturer, Part 2 the integrator, Part 3 the user. If you deploy AMRs in the US, R15.08 is your framework.

Both require that safety functions reach a rated integrity — typically Performance Level d (PL d) per ISO 13849 or SIL 2 per IEC 62061 for the protective stop. That rating drives the whole sensing/control chain: dual-channel, monitored, with diagnostic coverage.

Safety-rated scanners and speed zones

The enforcer is the safety-rated LiDAR scanner (SICK nanoScan3/microScan3, Pilz PSENscan, Hokuyo UAM/SafetyScanner), certified to IEC 61496-3, wired into a safety controller — not the navigation computer. It monitors configurable protective fields:

• A warning field (outer) that slows the robot.
• A protective field (inner) that triggers a safety stop.

Crucially, these fields scale with speed. At 1.5 m/s the protective field reaches far ahead because the stopping distance is long; as the robot slows for a turn or a tight aisle, the fields shrink so it doesn't nuisance-stop on nearby walls. This speed-dependent field switching is the heart of a mobile safety case — the field must always exceed the stopping distance at the current speed.

Stopping distance is the design driver. It is d = v²/(2a) + v·t_react, where t_react includes sensor latency, safety-controller response, and brake engagement. A 300 kg robot at 1.5 m/s with 0.7 m/s² braking and 0.2 s reaction needs ≈1.6 m + 0.3 m ≈ 1.9 m of protective field. That number sizes the scanner range and the aisle width.

E-stop and the rest

A hardware emergency stop — a physical mushroom button cutting motor power through the safety circuit, independent of software — is mandatory. Add warning lights/sounds (mandated motion indicators in many jurisdictions), and 2D-scanner blind-spot coverage with depth cameras and bumpers. The bumper is the last line: a compliant contact edge that triggers a stop on touch, because no scanner sees everything.

Remember the scanner sees a 2D plane. A forklift tine at 30 cm, an overhanging load, a child's hand reaching down — these are off-plane and the safety scanner misses them. The complete safety case layers the 2D protective field with 3D perception, contact bumpers, speed limits, and zoning. Anyone selling you a single-scanner safety story for a mixed human floor is cutting a corner you'll regret.

Power & charging

Battery and charging strategy decide your fleet's effective availability more than peak speed does. A robot that's charging is a robot that isn't working. The cell chemistry, BMS, and sizing detail is in the robot power & batteries guide; here's the mobile-robot-specific strategy.

Chemistry

Modern AMRs run lithium — predominantly LiFePO4 (LFP) for the cycle life (3,000–6,000 cycles), thermal safety, and tolerance of partial charging, or NMC where energy density matters more than longevity. LFP's flat discharge curve and abuse tolerance make it the fleet default. Lead-acid persists only on legacy/heavy AGVs and is fading — its ~500-cycle life and dislike of partial charging make it a poor fit for the duty cycle below.

The duty-cycle and opportunity-charging model

The old model was battery swap: run the battery flat over a shift, swap in a charged one, charge the dead one offline. It works but needs spare batteries (capital), a swap station, and labor.

The modern model is opportunity charging: the robot tops up in short bursts during natural dwell time — while waiting at a pick station, between jobs, parked for 8 minutes. Because LFP tolerates frequent partial charges, a robot can sustain a 20+ hour effective duty on a battery sized for only ~2 hours of continuous motion, as long as the dwell time and charger placement give it enough top-up windows.

# Opportunity-charging duty-cycle sanity check
batt_capacity   = 1.5 kWh           # usable
draw_moving     = 250 W             # avg while driving (incl. accessories)
draw_idle       = 40 W              # parked, computer on
charge_rate     = 1500 W            # 1C-ish fast charge at contacts

# In a 60-min window: 40 min moving, 12 min idle-waiting, 8 min charging
energy_out = (40/60)·250 + (12/60)·40 = 166.7 + 8 = 174.7 Wh
energy_in  = (8/60)·1500 = 200 Wh
net = +25.3 Wh per hour  → energy-positive, runs indefinitely

# If you cut charging to 4 min/hr:
energy_in  = (4/60)·1500 = 100 Wh  → net −74.7 Wh/hr
# At 1500 Wh usable, runs ~20 hr then must take a long charge.

The lesson: it's not battery size, it's the ratio of charge windows to work. Design the charger locations so every robot passes a charger during natural dwell, and the fleet runs nearly around the clock on small batteries.

Auto-docking

Auto-docking to a charger closes the loop without human help. The robot navigates to the charger, then uses a fiducial (reflector pattern or AprilTag) for the final precise approach, and engages contact charging — sprung blade contacts that mate to floor/wall pads. Contact charging is simpler and cheaper than inductive (wireless) charging, which exists but adds cost and ~10–15% efficiency loss for the convenience of no exposed contacts. The fleet manager schedules charging as just another job, sending robots to chargers based on state-of-charge and demand so the fleet never all charges at once.

Compute & software stack

The mobile robot is a distributed software system on wheels. The stack has three tiers, and the integration between them is where most project risk lives.

Onboard compute

The nav computer is typically an x86 industrial PC (for ROS 2 / Nav2 stacks) or an NVIDIA Jetson (Orin-class) where GPU perception matters — running the SLAM, costmaps, planners, and sensor drivers. Alongside it sits a safety controller (a separate, certified safety PLC) that owns the protective stop and e-stop circuit, independent of the nav computer — because you cannot put PL d safety on a general-purpose Linux box. Motor controllers (FOC drives, see the controller guide) hang off a real-time bus (CAN/EtherCAT), reporting odometry and taking velocity commands.

The nav stack: ROS 2 / Nav2

Open AMRs and most research/integrator platforms (Clearpath, AgileX, custom builds) run ROS 2 with Nav2. The ROS 2 guide goes deep; the relevant shape here: sensor drivers publish scans and point clouds, slam_toolbox or AMCL provides the pose, Nav2's behavior tree orchestrates planning, and tf2 keeps every frame (map → odom → base_link → sensors) consistent. The map → odom transform is AMCL's correction; odom → base_link is the wheel/IMU odometry. Get those frames wrong and nothing works — it's the single most common ROS 2 navigation bug.

Commercial vendors (MiR, OTTO, Geek+) run proprietary stacks of the same architecture, trading openness for a turnkey, supported, safety-certified product. The choice is build-vs-buy: ROS 2/Nav2 gives flexibility and no license fee at the cost of you owning the integration and the safety certification; a commercial AMR gives you a certified product and a support contract at the cost of a closed stack.

Fleet manager and WMS/MES integration

Above the robots, the fleet manager handles traffic, job assignment, charging, and a map shared across the fleet (MiR Fleet, OTTO Fleet Manager, Locus, or open frameworks like Open-RMF). It exposes an API the higher systems drive.

The top tier is your WMS/MES (warehouse/manufacturing execution system). This is the integration that makes the fleet do useful work: the WMS knows there's a pick at location A4 destined for pack station 3, and it must hand that as a job to the fleet manager, get status back, and reconcile inventory. That integration — message formats, error handling, what happens when a robot can't reach a station, how a human-cancelled job propagates — is the bulk of the engineering effort and the bulk of the project risk. The industrial automation guide covers the PLC/SCADA/MES world the fleet plugs into. VDA 5050 is the emerging standard interface between fleet managers and mixed-vendor AMRs — worth specifying if you ever want multi-vendor fleets.

Payload handling & top modules

The chassis is a transport base; what it carries is the top module, and a single base platform usually supports several. This modularity is a core economic argument for AMRs — one validated, safety-certified base, many jobs.

The common modules

• Flat top / shelf — the simplest: a deck you set a tote or bin on, or where a human loads/unloads. Locus and many fulfilment AMRs are essentially mobile shelves a picker walks to.
• Conveyor deck — a powered roller/belt top that auto-transfers a tote to/from a fixed conveyor or another robot. Removes the human from the transfer; demands precise docking (±1 cm) to line up the rollers.
• Lift / jacking module — a vertical lift table that raises a load, or the shelf-lift (Kiva/Amazon, Geek+) that drives under a mobile rack, lifts it, and carries the whole shelf to a human picker. The shelf-lift model — "goods-to-person" — was Kiva's 2012 revolution: instead of pickers walking miles, the shelves come to them. It needs a structured floor (the QR grid) and a fleet manager doing dense coordination.
• Tugger / tow — a hitch that pulls one or more passive carts (a "tugger train"). High effective payload (tow several hundred kg of cart) on a modest base; the AGV-classic for line-side delivery in automotive/manufacturing. OTTO and many AGVs offer tow variants.

Mounting a cobot arm

Put a collaborative arm on a mobile base and you get a mobile manipulator — a robot that can both drive to a location and do dexterous work there (machine tending, pick-and-place across a cell, sample handling in a lab). The arm is usually a cobot (UR, Doosan, Techman — see the cobots guide) precisely because the combined system shares space with people and the cobot's force-limiting safety complements the base's scanner safety.

The hard part of mobile manipulation is the base pose. A ±3 cm base localization error is fine for transport but is a disaster for a 6-DoF grasp — the arm's working envelope can't absorb it. The standard fix: drive to a rough pose, then use the arm's wrist camera (visual servoing) or a fiducial to refine the actual base/target transform before the grasp. The base gets you to the neighborhood; vision closes the last centimetres.

Payload interface matters mechanically too: a 10 kg arm reaching out 1 m puts a real overturning moment on the base, so a manipulation AMR needs a wider stance, lower CoG, and a stiffer frame than a pure-transport robot of the same payload.

Deployment realities

The demo always works. The deployment is where reality charges its tax. Here's what actually consumes the budget and the timeline.

Mapping and commissioning

Mapping is fast — drive the building once, save the occupancy grid, a few hours. Commissioning is not. It's defining keep-out zones, drawing preferred lanes and one-way aisles, placing and surveying docking fiducials, tuning protective-field sizes against real aisle widths, setting speed zones, validating the safety case with the actual robot at actual speed, and integrating the WMS jobs. Budget weeks, not days, for a non-trivial fleet — and budget a safety assessor's time.

Mixed human/robot floors

The single biggest operational reality is that warehouses are full of people, forklifts, and chaos the planner didn't model. Pallets get left in aisles. A forklift cuts off a robot. Someone stacks boxes against a wall the map says is clear, and AMCL gets confused. People learn to "bully" robots (they always yield, so people walk right at them and the robot freezes). These aren't bugs; they're the environment. Mitigations: clear AMR lanes where you can, train staff, set realistic protective fields (too conservative = constant freezing = people lose faith and unplug the robots), and accept that throughput in a shared aisle is lower than a caged route.

The integration tax and ROI

The robot's purchase price is a minority of the project. The integration tax is WMS/MES hookup, network/Wi-Fi coverage (AMRs need reliable coverage along every route — dead spots cause stalls), charger infrastructure, fiducials, commissioning labor, safety assessment, and staff training.

# Illustrative 5-robot AMR project cost split
robots (5 × $45k)         = $225k   # ~45%
fleet manager + licenses  = $40k    # ~8%
WMS/MES integration       = $90k    # ~18%   <- the tax
commissioning + safety    = $60k    # ~12%
charging + infrastructure = $35k    # ~7%
Wi-Fi / network upgrade   = $30k    # ~6%
training + contingency    = $20k    # ~4%
                          ---------
total                     = $500k   # robots are < half

ROI is throughput-per-dollar over the system life, dominated by labor displaced/redeployed and uptime. The math works when the robots run a high duty cycle on a stable task; it fails when the task changes constantly (re-commissioning eats the savings) or when nuisance-stops and integration gaps keep effective utilization low. The honest payback on a well-matched warehouse fleet is typically 1.5–3 years; a poorly-matched one never pays back because utilization never reaches the model.

Rule: the project succeeds or fails on utilization, not robot count. A fleet at 85% utilization on a stable task beats a bigger fleet at 40% utilization every time. Spend the engineering on the integration and the floor, not on buying more robots.

Selecting an AMR/AGV

Selection collapses to three questions, in order. Get these right and the rest is comparison shopping.

The three questions

1. Payload and form — what are you moving, how heavy, how big? A 30 kg tote is a different robot from a 1,200 kg pallet. This sets the chassis class and largely the vendor shortlist.
2. Environment — indoor/outdoor, floor flatness, aisle width, ramps, who shares the space, how often the layout changes. This sets drive type (differential indoors, Ackermann outdoors), nav method (free-nav for changing layouts, guided for fixed high-throughput), and the safety class.
3. Throughput — moves per hour, distances, dwell time. This sets fleet size (with the congestion margin from the path planning section) and charging strategy.

Decision shortcut: Changing layout + shared with people + moderate throughput → free-nav AMR (MiR/OTTO/Fetch class). Fixed high-throughput loop + heavy payload → guided AGV. Goods-to-person fulfilment at scale → Kiva/Geek+ shelf-lift on a structured floor. Drive + dexterous work → mobile manipulator (AMR base + cobot).

Real-product comparison

Representative platforms across the classes (figures are nominal published specs; confirm against current datasheets before you commit):

Platform	Class	Payload	Drive	Nav method	Top speed	Notable
MiR250	Indoor AMR	250 kg	Differential	Free-nav (2D LiDAR SLAM)	~2.0 m/s	Compact, large module ecosystem
MiR600 / 1350	Heavy indoor AMR	600 / 1,350 kg	Differential	Free-nav, IP52	~1.2–2.0 m/s	Pallet-class, ISO 3691-4
OTTO 100 / 600 / 1500	Indoor AMR	150 / 600 / 1,500 kg	Differential	Free-nav	~2.0 m/s	Heavy-duty, strong fleet mgr
Fetch / Zebra (e.g. FlexShelf/Freight)	Fulfilment AMR	~50–1,500 kg (range)	Differential	Free-nav	~1.5 m/s	Now Zebra; warehouse focus
Locus (LocusBots)	Goods-to-person assist	tote-class	Differential	Free-nav	~1.5–2.0 m/s	Picker-following model
Amazon (Kiva) drive	Shelf-lift AGV	~450–1,300 kg shelf	Differential	QR-grid (structured floor)	~1.7 m/s	Dense coordinated fleet
Geek+ P-series	Goods-to-person shelf-lift	~600–1,000 kg	Differential	QR-grid / fiducial	~1.5 m/s	Kiva-style, large installs
AgileX (Scout/Bunker/Hunter)	Outdoor / research base	~50–150 kg	Diff / tracked / Ackermann	Configurable (ROS)	~1.5–4.5 m/s	Dev platforms, outdoor-capable
Clearpath (Husky/Jackal/Dingo)	Research / outdoor	~20–75 kg	Diff / mecanum	ROS 2, BYO nav	~1–2 m/s	R&D, sensor integration

A note on context: companies like iRobot proved the consumer end of mobile autonomy (Roomba's vacuum-class SLAM and bump-and-coverage navigation) a decade before warehouse AMRs matured — different scale and safety case, same core problem of localizing and covering a space without infrastructure. The warehouse AMR is that consumer lineage grown up, hardened, and wrapped in a PL d safety case.

Final rule: don't buy the robot with the best spec sheet; buy the robot whose vendor support and software maturity match your team's integration capability. A team without ROS 2 depth should buy a turnkey commercial AMR; a team with strong robotics engineers can extract more value (and lower cost) from a ROS 2/Nav2 platform — but owns the integration and the safety case. The spec sheet is the easy 20% of the decision.

Frequently asked questions

What is the actual difference between an AGV and an AMR? An AGV follows fixed guidance infrastructure (wire, magnetic tape, reflectors, QR grid) and stops when an obstacle blocks its path. An AMR carries a map, localizes against it, and replans around obstacles autonomously. The test: if removing the floor/wall infrastructure breaks navigation, it's an AGV; if you can set it down in any mapped building and it drives, it's an AMR. See the comparison section.

Are AGVs obsolete now that AMRs exist? No. AGVs remain cheaper and more deterministic on fixed, high-throughput routes and for heavy payloads where a free-roaming safety case is hard. Amazon's massive fulfilment fleets run on a QR-grid (an infrastructure-guided system) precisely because determinism enables dense coordinated traffic. Choose by how often the layout changes and how deterministic the route must be.

Why is differential drive so common when omni/mecanum can strafe? Differential drive is the cheapest, simplest, most efficient configuration that can still turn in place, and its odometry is good. Mecanum's holonomic motion costs 15–30% of traction to roller slip, degrades odometry, hates floor debris and seams, and wears faster. You pay a lot for lateral motion you rarely need. Use mecanum only where tight-footprint lateral docking genuinely pays.

Do AMRs use one LiDAR or two? Serious ones often use two with different jobs: a safety-rated scanner (SICK/Pilz/Hokuyo, certified to IEC 61496) mounted low to enforce protective stops, and a navigation scanner for SLAM/localization. Cheaper robots feed the safety scanner's measurement data to nav too, but the safety function is always isolated in a certified controller, never on the nav PC.

What sensors does an indoor AMR actually carry? Typically a safety-rated 2D LiDAR (low), often a second nav LiDAR, two-plus depth cameras to catch off-plane obstacles (overhangs, low loads, floor edges), wheel encoders and an IMU for odometry, plus ultrasonic/cliff sensors for glass walls and dock edges that lasers miss. 3D LiDAR appears on outdoor/high-end units. See the LiDAR & depth camera guide.

How does an AMR know where it is — what's SLAM vs AMCL? SLAM (e.g. Cartographer, slam_toolbox) builds the map and estimates pose simultaneously, usually run once at commissioning. AMCL is a particle-filter localizer that tracks pose within a saved map at runtime — it scatters pose hypotheses, scores them against the live LiDAR scan, and converges. AMCL needs visible features; long featureless corridors are its classic failure mode.

What safety standards apply to mobile robots? Industrial trucks/AGVs fall under ISO 3691-4; AMRs (industrial mobile robots) in North America under ANSI/RIA R15.08. Both require safety-rated scanners with speed-dependent protective fields, a hardware e-stop, and protective-stop functions rated to PL d (ISO 13849) or SIL 2 (IEC 62061). The safety function must live in a certified controller separate from the nav computer.

Why do safety fields change size while the robot moves? Because stopping distance scales with the square of speed (d ≈ v²/2a + v·t_react). At 1.5 m/s a robot needs ~2 m of protective field ahead; at 0.3 m/s it needs only a fraction of that. Speed-dependent field switching keeps the field always larger than the current stopping distance while avoiding nuisance stops on nearby walls when the robot is slow.

Battery swap or opportunity charging? Opportunity charging wins for most fleets. With LFP cells (tolerant of frequent partial charges), a robot topping up during natural dwell can run 20+ hours on a battery sized for ~2 hours of motion, with no spare batteries, swap station, or labor. Battery swap survives on heavy/legacy AGVs. The key variable is the ratio of charge windows to work — place chargers where robots naturally dwell. See robot power & batteries.

Can I put a robot arm on a mobile base? Yes — that's a mobile manipulator, usually an AMR base plus a collaborative arm (UR, Doosan, etc. — see the cobots guide). The hard part is base-pose precision: ±3 cm localization is fine for transport but ruins a 6-DoF grasp, so you drive to a rough pose then use the wrist camera or a fiducial to refine the transform before manipulating. The base also needs a wider stance and stiffer frame to handle the arm's reach moment.

How many robots do I need? Compute per-robot tasks/hour from cycle time (travel + load/unload) minus charging overhead, divide demand by that, then add a congestion margin (10–25%) because dense traffic erodes effective speed nonlinearly. See the fleet-sizing calc in path planning. Always size for utilization, not just demand divided by per-robot rate.

What's the real cost driver in an AMR deployment? Not the robots — they're often under half the project. The integration tax dominates: WMS/MES integration, commissioning, safety assessment, charger and Wi-Fi infrastructure, and training. Plan for it. Projects fail on low utilization (constant re-commissioning, nuisance stops, integration gaps), not on robot price. Well-matched warehouse fleets pay back in roughly 1.5–3 years.