ROS 2 Differential-Drive Robot with SLAM Mapping Study for a Warehouse Aisle

ROS 2 Differential-Drive Robot with SLAM Mapping Study for a Warehouse Aisle builds a working differential-drive robot on ROS 2 Humble and then uses it to answer a measurement question, not just to demo: how fast does wheel-odometry drift grow on a repeatable route, and how much of that drift does a 2D SLAM system actually remove?

Warehouse robotics is today's biggest industrial deployment of mobile robots in India — fulfilment centres around Bengaluru, Hyderabad and Bhiwandi run hundreds of aisle AMRs — and nearly all are differential-drive platforms with a 2D lidar, exactly what a student team can reproduce. Our robot pairs a Raspberry Pi 4 on Ubuntu 22.04 with an Arduino Nano motor controller: the Nano receives velocity commands and reports encoder ticks, the Pi integrates them into odometry, an MPU6050 IMU supplements the heading estimate, and an LD19-class 2D lidar feeds slam_toolbox, the pose-graph SLAM package behind ROS 2's Nav2 stack.

The study surface is a modelled warehouse aisle — cardboard shelving, pallets and a marked 10-metre closed loop on the lab floor. The team drives a fixed route, records the odometry trail against a taped floor plan, repeats the route with SLAM mapping active, and compares the two: drift in metres per loop, map quality against the floor plan at two grid resolutions, and the effect of loop closure. The complete ROS 2 workspace, firmware, launch files and evaluation scripts form the source bundle, so the next batch can rebuild the robot or the Gazebo-only simulation.

Warehouse AMRs are differential-drive robots that localise with 2D lidar SLAM, and they are now a major employment sector for robotics graduates in India's e-commerce supply chain. Yet students meet this technology either as black-box commercial platforms they cannot inspect, or as kit tutorials they cannot extend into a defensible study. Without building the stack themselves, graduates cannot explain where odometry comes from, why it drifts, what a pose graph does, or how map resolution trades detail against memory.

There is a need for a buildable, budget-scale differential-drive robot on ROS 2 Humble — with team-written firmware bridge, odometry, transforms and SLAM integration — together with a repeatable mapping study protocol on a modelled warehouse aisle that quantifies odometry drift, measures SLAM-corrected map quality against a floor plan, and makes the numbers reproducible by others, all within a two-semester major-project structure.

Abstract

This project constructs a differential-drive mobile robot on ROS 2 Humble with encoder odometry, an IMU, a 2D lidar and slam_toolbox, and conducts a quantitative mapping study on a modelled warehouse aisle. The study measures wheel-odometry drift over repeated closed loops, evaluates SLAM-corrected maps against a taped floor plan at two resolutions, and shows where the correction comes from.

Introduction

Every mobile robot answers two questions — where are my wheels, and where am I really? Wheel odometry answers the first cheaply but integrates error: wheel slip, unequal radii and encoder quantisation accumulate until the estimate is useless. SLAM answers the second by matching lidar scans into a consistent map, correcting drift when the robot recognises places it has seen. Industrial AMRs run this loop thousands of times a day in controlled, structured aisles — which makes the warehouse aisle the right first problem for a student-built platform.

Existing System and Its Limits

• Commercial AMR platforms (₹1.5–4 lakh) are black boxes: students see behaviour, never the TF tree, the QoS choices or the pose graph.
• Kit platforms like TurtleBot3 demonstrate SLAM convincingly but ship canned tutorials; the mapping study — numbers, drift curves, resolution trade-offs — is left as an exercise.
• Most college robotics projects stop at line-following or bluetooth cars, with no odometry model and no evaluation metric.
• Limitation: an affordable, buildable ROS 2 platform paired with a repeatable protocol that quantifies what SLAM buys over odometry alone.

Proposed System

• A hardware stack within student budget: 12 V encoder gear motors with a BTS7960 driver, an Arduino Nano running real-time motor firmware (velocity command → PWM, 20 Hz tick reporting), a Raspberry Pi 4 on Ubuntu 22.04 with ROS 2 Humble, an MPU6050 IMU and an LD19-class 2D lidar.
• A ROS 2 software stack the team writes and owns: a firmware-bridge node, a kinematics node implementing the differential-drive model (v = (vL+vR)/2, ω = (vR−vL)/b) to publish /odom and the odom→base_link transform, IMU heading fusion via a complementary filter, lidar bring-up, and slam_toolbox for online mapping with the map→odom transform.
• A modelled warehouse aisle: cardboard shelving and pallet mock-ups forming a 10-metre closed loop on a taped floor plan — the controlled environment a real aisle provides.
• A mapping study protocol: five fixed-speed laps under odometry-only dead reckoning with the trail logged; five laps with slam_toolbox; map quality scored against the floor plan (wall alignment, corridor-width fidelity) at 0.05 m and 0.10 m resolutions; loop closures marked on the pose graph.

Feasibility

• Technical: every component is documented and hobby-grade; ROS 2 Humble has LTS binaries for Ubuntu 22.04, and a Gazebo twin lets software work proceed before hardware is complete.
• Economic: the BOM is ₹15,000–20,000, in line with a funded final-year project; the simulation-only path is free and exercises every software module.
• Operational: 16 weeks cover build (6), integration (4), study campaign (3) and documentation (3), matching the VTU build-then-study phase structure.

In scope

• One differential-drive platform (two driven wheels plus caster(s)) with manual teleop control; no autonomous navigation stack.
• Odometry from wheel encoders with IMU heading fusion; 2D SLAM via slam_toolbox in online mapping mode.
• A modelled single-aisle-plus-loop environment and a manually driven fixed route at fixed speed.
• Map-quality and drift metrics computed by team-written Python scripts from recorded rosbag data.

Out of scope

• Autonomous goal navigation with Nav2, path planning or obstacle avoidance behaviours (planned follow-up).
• Multi-floor or 3D SLAM; visual SLAM and cameras.
• Multi-robot coordination; fleet software.
• Outdoor operation and uneven terrain.

The project follows a build → integrate → study sequence over 16 weeks, aligned to the two VTU project phases.

Testing approach: unit level (firmware command/tick loopback tests, kinematics node verified against hand-computed poses), integration level (TF tree audit with tf2 tools, odom-vs-ground-truth straight-line and rotation tests), and system level (the study protocol itself: five laps per condition, logged rosbags, scripted metrics). The Gazebo twin doubles as a regression harness — every node is verified in simulation before it touches hardware.

The robot follows the standard ROS 2 layered architecture: real-time firmware, driver nodes, state estimation, SLAM and operator tools, connected by a documented TF tree and topic graph.

1. Real-time layer — the Arduino Nano runs a fixed 50 Hz control loop: it parses velocity commands, drives the BTS7960 outputs, and reports left/right encoder ticks; timing here is deterministic because it is the only place PWM must not jitter.
2. Driver layer — a Python firmware-bridge node on the Pi publishes /cmd_vel down and /ticks up over USB serial; lidar and IMU drivers publish /scan and /imu.
3. Estimation layer — the kinematics node implements the differential-drive model to publish /odom and the odom→base_link transform; a complementary filter fuses gyro heading with the encoder-derived heading.
4. SLAM layer — slam_toolbox consumes /scan and /odom, builds the pose graph, publishes the map and the map→odom transform, correcting odometry drift at loop closures.
5. Operator layer — RViz2 visualisation, keyboard teleop, rosbag recording and the evaluation scripts that turn bags into the study's metric tables.

flowchart LR
  TEL["Keyboard teleop"] -->|"/cmd_vel"| BR["Firmware bridge node"]
  BR -->|"velocity frame over USB"| NANO["Arduino Nano motor firmware (C)"]
  NANO -->|"PWM + direction"| DRV["BTS7960 driver"]
  DRV --> MTR["Encoder gear motors"]
  MTR -->|"ticks at 20 Hz"| BR
  BR -->|"/ticks"| KIN["Kinematics node: v = (vL+vR)/2, omega = (vR-vL)/b"]
  IMU["MPU6050"] -->|"/imu"| KIN
  KIN -->|"/odom + odom->base_link TF"| SLAM["slam_toolbox pose-graph SLAM"]
  LID["2D lidar"] -->|"/scan"| SLAM
  SLAM -->|"/map + map->odom TF"| RV["RViz2 + rosbag + evaluation scripts"]
  KIN --> RV
  AISLE["Modelled warehouse aisle + taped floor plan"] -->|"scans and laps"| LID

The TF tree is the architecture's contract: map→odom published only by SLAM, odom→base_link only by odometry. Keeping that ownership strict is what makes the drift study meaningful — the gap between map→odom and identity is the drift that slam_toolbox removes.

• Autonomous navigation: layer Nav2 on the saved map with AMCL localisation for goal-driven aisle traversal, completing the AMR pipeline.
• Fleet slice: two robots sharing the aisle with ROS 2 domain partitioning and a simple traffic rule, demonstrating coordination basics.
• Sensor upgrade study: replace the LD19 with a higher-grade lidar and quantify the map-quality delta under the same protocol.
• micro-ROS migration: move the motor firmware onto a micro-ROS node to unify the stack under ROS 2, removing the custom serial bridge.
• Field trial: run the mapping protocol in a real storeroom or the college library stack area and compare metrics against the modelled aisle.