B grade Authoritative secondary, traced to origin

Build a ROS 2 rover: the smallest loop from SLAM to navigation

The most learning per dollar of any robot type. The MVP is not driving around by remote control; it is building a map yourself and navigating to a goal on it, autonomously.

Type: Differential drive + 2D lidar SLAM + autonomous navigation
Budget: About USD 250–400
Compute: Raspberry Pi 5 + ESP32/Pico (micro-ros bridge)
Lidar: RPLIDAR A1 tier (about USD 100; used cheaper)
Software: ROS 2 Jazzy + slam_toolbox + nav2
MVP check: Reusable map + autonomous arrival at a goal

ROS 2 rover: how the body goes togetherTap a number — or the legend below — to jump to its entry

What counts as moving: MVP = a reusable, drift-free map, plus autonomous arrival at a goal while avoiding obstacles. Concrete checks: rebuild the map of the same area three times with consistent boundaries (no drift); nav2 plans and executes a goal successfully; the rover slows and detours around a new obstacle in its path. Remote-controlled laps are not an MVP — they validate the chassis, not the system. The hardest part of the system is not any single component; it is making all components agree on timestamps and data.
Parts and sourcing: A differential chassis kit (two driven wheels + caster, encoded motors, USD 30–60), a motor driver board (TB6612 — more efficient and cooler-running than an L298N), a Raspberry Pi 5 (4 GB is enough) plus one MCU (ESP32 or Pico for encoder counting and velocity PID), a lidar on the RPLIDAR A1 tier (about USD 100), an IMU (MPU6050 to start), and a 12 V lithium pack with a 5 V buck (power the Pi separately and share ground with the motors — the sag when motors start is the number-one cause of Pi blackouts). About USD 250–400 all in.
Assembly order: Chassis (an hour) → motors and encoders → driver board → MCU firmware (odometry: encoder counting + velocity PID) → ROS 2 Jazzy on the Pi + the micro-ros bridge → lidar driver + TF tree → power up and cross-check odometry and lidar in rviz. Sequencing rule: make odometry drive straight before you attempt SLAM (calibrate wheel diameter and track width). A map built on crooked odometry is not fixable by tuning SLAM — recalibrate odometry and start over; tuning SLAM parameters against bad odometry is a scenic route to nowhere.
Software stack: ROS 2 Jazzy (LTS); slam_toolbox for 2D SLAM (the most mature option); nav2 for navigation; Gazebo for simulation (strongly recommended: get nav2 working in sim before the hardware does — the parameter files transfer). micro-ros joins the chassis's /odom and /cmd_vel into the ROS graph. Two-layer architecture: the MCU does only the deterministic work (encoders, PID, safety stop); the Pi does SLAM and navigation. The classic reversed move is pushing navigation into the MCU — that is not architecture, that is penance.
Bring-up to first motion: Order: raw data in rviz → odometry calibration (ten straight runs, ten rotations; measure the real distances and angles) → map by hand-pushing with slam_toolbox → save the map → nav2 localisation and navigation. Three classic traps: ① TF timestamps out of sync — lidar and map jitter apart in rviz; check publish rates and use_sim_time; ② cmd_vel sign flipped — ROS convention is forward = +x, counter-clockwise = +z; flipped means forward drives backward; ③ lidar serial permissions — no udev rule and the permission vanishes on reboot. Stable symptoms all three, which is good news: stable symptoms are searchable symptoms.
Where to go next: After MVP: add a camera for line following or object tracking — this is where a Jetson starts earning its price (see the compute entry); swap differential drive for Ackermann or mecanum and learn how kinematics enter nav2; write the architecture down and version your parameters — the rover's biggest hidden return is that ROS 2 experience transfers completely, which no other robot type offers. Not yet: multi-sensor fusion. Get the single-lidar setup boring first.
What we checked: We verified: this component combination (RPLIDAR A1 + Raspberry Pi + slam_toolbox + nav2) is the mainstream community route with documentation that cross-checks; micro-ros officially supports ESP32 and RP2040; ROS 2 Jazzy's LTS status. We did not build this one — kit quality varies by batch more than reviews admit, and your mapping results are yours alone to find out. The grade stays accordingly.

This site's call

If the goal is 'learn robotics' rather than 'own a robot', start here. Every layer has an open implementation, a community answer, and a simulation stand-in; when something breaks you can localise it to a layer. It is not glamorous — but ROS 2 skills outlast any specific machine, and the systems view you build here (messages, timestamps, layering) applies to everything after.

Why 'calibrate odometry before SLAM' is not a platitude

SLAM output quality depends on two things: the matching algorithm and the motion prior. Odometry is the motion prior. When it is wrong, the matcher receives systematically wrong position predictions and produces a map that is not 'ugly' but self-contradictory — loop the building and the walls do not close. Tuning SLAM parameters at that point is putting a finer scale on an unbalanced beam.

The two-layer test

The dividing rule between MCU and SBC is one question: does this loop need timing determinism? Encoder counting, motor PID, collision stop — yes. Mapping, navigation, logging — no. Putting the non-deterministic work on the MCU, or the deterministic work on the Pi, are the two symmetric architecture errors.

Sources

ROS 2 Jazzy documentation; nav2 and slam_toolbox project pages
micro-ROS official supported-board list
Community tutorials and build logs (calibration flow, fault symptoms)

Objects in this entry

Last checked 2026-09-28