Robotics Field Guide
Topic hub

Mobile robots

How wheeled robots move and find their way. Differential, Ackermann and omnidirectional kinematics, the map, odom and base_link frames, the Nav2 stack, and how warehouse fleets are coordinated.

Updated 14 Nov 2026 · differential drive, Ackermann steering, mecanum wheel, odometry, Nav2, costmap, REP 105, AMR, fleet management, VDA 5050, Open-RMF

Overview

A mobile robot carries its own workspace with it. Instead of a fixed base and a reachable volume, it has a pose in the world that it must estimate, and a route that it must plan and follow while people and pallets move around it. This hub covers wheeled robots on flat floors: how the wheel layout limits motion, how a navigation stack is put together, and how warehouse fleets of autonomous mobile robots (AMRs) are coordinated. It is for engineers bringing up a base, tuning navigation or integrating robots into a site.

Key ideas

Wheel layout decides the kinematics

A differential drive robot has two driven wheels on one axle. With wheel radius r, track width L and wheel speeds ωR and ωL, the forward speed is v = r(ωR + ωL)/2 and the turn rate is ω = r(ωR − ωL)/L. It can spin on the spot but cannot move sideways, a nonholonomic constraint that planners must respect. Ackermann steering, as on a car, is well described by the bicycle model. Its minimum turning radius is the wheelbase divided by the tangent of the largest steering angle, so it cannot turn in place and needs room to manoeuvre. Omnidirectional bases with mecanum or omni wheels are holonomic. They can translate in any direction while rotating, at the cost of rollers that slip, wear and lose traction on dirty floors. Integrating wheel speeds gives odometry, which drifts without bound because of wheel slip and errors in r and L.

REP 105 fixes three frames that most ROS 2 navigation code assumes. The robot body is base_link, with x forward, y left and z up. The odom frame is continuous but drifts, so it suits short-term local control. The map frame does not drift, but the pose in it can jump when the localiser corrects itself, so it suits long-term goals and is a poor reference for a controller. The localiser publishes the transform from map to odom, and the odometry source publishes odom to base_link. Getting this tree right, through tf2, is the first job when bringing up a new base.

The navigation stack

Sensorslidar, IMU, cameraLocalisationmap to odomGlobal plannerpath on mapControllerv and w commandsBase controlwheel speedsOdometryodom to base_linkCostmapsencodersobstaclespathframes (REP 105):mapto odomto base_link
Data flow in a typical ROS 2 navigation stack for a wheeled base. Localisation corrects the drift of odometry. The global planner works on the map, the controller works on a small local costmap, and the base controller turns velocity commands into wheel speeds.

Nav2, the ROS 2 navigation stack described by Macenski et al. (2020), splits navigation into servers coordinated by a behaviour tree. A localiser such as AMCL, a particle filter, estimates the pose on a prebuilt occupancy grid, or a SLAM system builds the map as it goes. A global planner finds a path on the map. A controller follows it many times a second, using a local costmap built from recent sensor data. Nav2 ships several controllers, including DWB (the successor to the ROS 1 DWA controller, which follows the dynamic window approach of Fox, Burgard and Thrun, 1997), Regulated Pure Pursuit and MPPI. The behaviour tree decides what to do when progress stalls: clear the costmap, back up, wait, or replan.

Warehouse AMRs and fleets

One robot on a clear floor is a navigation problem. Fifty robots sharing aisles, lifts and doors with people is a traffic problem. A fleet manager assigns jobs, reserves routes and junctions, and sends robots to charge. Two open efforts address the interface between robots and that layer. VDA 5050, developed by the German automotive association VDA with VDMA and the Karlsruhe Institute of Technology, defines messages between a central fleet controller and vehicles from different makers. Version 3.0.0 is the latest published on its GitHub repository at the time of writing. Open-RMF, from Open Robotics, coordinates several fleets with shared building infrastructure such as doors and lifts.

Where to start

Begin with Differential drive, which derives and simulates the kinematics above. Sensors and noise shows why odometry drifts, and Grid path planning builds the global planner. The differential drive A* project joins them with a Kalman filter. For ROS 2, start with Hello ROS 2 and the state estimation hub.

Tools and platforms

Tool What for Licence
Nav2 ROS 2 navigation: localisation, planners, controllers, behaviour trees, docking Mixed: Apache-2.0, BSD-3-Clause, LGPL-2.1-or-later by package
slam_toolbox 2D lidar SLAM and localisation for ROS 2 LGPL-2.1
robot_localization EKF and UKF fusion of odometry, IMU and GPS BSD-3-Clause
ros2_controllers Differential, Ackermann, tricycle, mecanum and omni-wheel drive controllers Apache-2.0
Open-RMF Multi-fleet traffic and building infrastructure integration Apache-2.0
VDA 5050 Fleet controller to vehicle interface specification and JSON schemas MIT (repository)

Common mistakes

  • Wrong wheel radius or track width in the base controller. Drive 5 m straight and rotate 10 turns in place, then correct both from the measured error.
  • Publishing odom to base_link from two nodes at once, for example the base controller and an EKF. Exactly one node must own each transform.
  • Running the local controller in the map frame, so that each localisation correction causes a jerk.
  • Inflating the costmap by the robot’s radius only, then wondering why the robot scrapes corners. Add a safety margin and model the real footprint.
  • Tuning navigation in an empty corridor. Test with people walking past, glass walls and narrow doors.
  • Treating a fleet manager as optional until the third robot arrives.

Going deeper