🗺️ ROS 2 and navigation
The leap from a robot that reacts to one that knows where it is. You’ll learn ROS 2, describe and simulate your robot in Gazebo, connect the ESP32 to ROS with micro-ROS, make maps with a LiDAR, and finish with a robot that maps the room and navigates on its own to a point. You can do everything in simulation first, on your PC.
How to read this map: The upper track (amber) runs entirely on your computer, without any hardware. The lower track (cyan) follows the same steps on a real robot: the ESP32 joins ROS through micro-ROS, and the real LiDAR replaces the simulated one. Both arrows lead to project 4.6. You can follow only the upper track and return to the lower one when you have the hardware.
🧭 What you’ll build in this track
A differential-drive robot (two wheels and a caster) that exists in two places: as a model in Gazebo and as the robot from the previous tracks, now with a LiDAR. It publishes odometry and laser scans to ROS 2, builds an environment map with slam_toolbox, and uses Nav2 to travel on its own to the point you click on the map, avoiding anything in its path.
- ✓Commands that work in Lyrical and Jazzy
- ✓Robot described in URDF/xacro and simulated in Gazebo
- ✓ESP32 communicating with ROS 2 through micro-ROS
- ✓Saved map and point-to-point navigation with Nav2
💡 Don’t have a LiDAR yet?
Modules 4.1, 4.2, 4.4, and 4.5 run entirely in simulation: a PC with Ubuntu, a virtual machine, or a Docker container is enough. Hardware is required only for 4.3 and the real-robot part of 4.6.
Track map
🧩 ROS 2 without fear
Nodes, topics, and your first Python node
🧱 Describe and simulate the robot
URDF, TF, RViz2, and Gazebo
🔌 micro-ROS on the ESP32
Bring the microcontroller into ROS
📡 LiDAR and maps (SLAM)
Map and position at the same time
🚩 Navigation with Nav2
Click on the map, and the robot goes
🏠 Project: map and navigate
From simulation to your room
Detailed content
🧩 ROS 2 without fear
What ROS 2 is, which distro to choose, how to install it, and the parts of the graph: nodes, topics, services, actions, and parameters. You’ll finish with your first Python node.
A set of libraries and tools that lets different robot programs exchange data by name, on the same machine or over a network.
It’s the research and industry standard; mapping, navigation, and sensor drivers are ready to use.
Middleware · DDS · ROS graph · package.
Lyrical Luth (May 2026 LTS, Ubuntu 26.04) and Jazzy Jalisco (the previous LTS, Ubuntu 24.04), each with its own Gazebo.
The wrong distro is the number one reason a tutorial doesn’t work.
LTS · Ubuntu ↔ ROS ↔ Gazebo pairing · end of support.
Three options: packages on Ubuntu, a ready-to-use Docker container, or Raspberry Pi 5 with Ubuntu.
Docker gets you up and running in minutes on any system.
ros-<distro>-desktop · source · talker/listener.
A node is a program; a topic is a named channel; a message is the format of the data that passes through it.
Every ROS robot is a graph of these; reading it from the terminal is your first debugging tool.
Publisher · subscriber · /cmd_vel · ros2 topic echo.
Question and answer (service), a long-running task with progress (action), and node settings (parameter).
Choosing the right pattern avoids workarounds; Nav2 works entirely through actions.
Request/response · goal/feedback/result · ros2 param.
A Python package with two complete nodes, one that publishes and one that listens, built with colcon.
It’s the template for every node you’ll write in the rest of the track.
rclpy · create_publisher · create_subscription · timer.
🧱 Describe and simulate the robot
Workspace and colcon, the robot in URDF/xacro, TF frames, RViz2, Gazebo with ros_gz, and the first drive with the keyboard.
The working folder, how packages are organized, and how colcon builds and installs everything.
Half of beginner errors come from a workspace that hasn’t been sourced or a missing dependency.
Underlay · overlay · rosdep · --symlink-install.
An XML file with the robot’s parts (links) and joints; xacro adds variables and macros.
RViz, Gazebo, TF, and Nav2 all read the same description.
Link · joint · inertia · macro.
The tree that shows where each part is relative to the others, at every moment.
Without correct TF, the laser appears in the wrong place and the map gets distorted.
map · odom · base_link · tf2_echo.
The window that shows what the robot believes: model, frames, laser, map.
This is where you check the model before simulating and the sensor before mapping.
Fixed Frame · RobotModel · LaserScan · robot_state_publisher.
The simulator with physics and sensors, connected to ROS 2 through the ros_gz bridge.
You can test mapping and navigation without a battery, a crash, or buying LiDAR.
Harmonic ↔ Jazzy · Jetty ↔ Lyrical · parameter_bridge · launch.
Send velocity commands from the keyboard on /cmd_vel and watch the odometry and laser respond.
This closes the loop: a command comes in, the robot moves, and the sensors change. It’s the smoke test for the whole learning path.
teleop_twist_keyboard · Twist · /odom · /scan.
🔌 micro-ROS on the ESP32
The ESP32 becomes a ROS 2 node: it publishes encoder data, listens to /cmd_vel, turns the motors, and provides odometry to the rest of the robot.
The version of ROS 2 for microcontrollers, which communicates with the rest of the graph through an agent.
The motors and encoders run on the ESP32 in real time and appear in ROS like any other node.
Client · agent · XRCE-DDS · rclc.
The program on the PC or Pi that translates micro-ROS to DDS; it runs in Docker with a single command.
Without an agent, the ESP32 is talking to itself; it’s the first thing to check.
Serial · UDP · port 8888 · /dev/ttyUSB0.
The firmware that counts the wheel pulses and publishes them on /ticks every 50 ms.
Sensor data in ROS is the foundation for odometry and mapping.
micro_ros_arduino · publisher · timer · executor.
Convert linear and angular velocity into the speed of each wheel, and stop if the command disappears.
It’s the same /cmd_vel used by teleop and Nav2: the real robot starts following ROS commands.
Differential drive kinematics · subscriber · watchdog · TB6612FNG.
A Python node on the PC that converts /ticks into /odom and the odom → base_link frame.
This is what SLAM and Nav2 expect to receive from the real robot.
nav_msgs/Odometry · TransformBroadcaster · ticks per revolution.
The issues that come up most often: agent not connected, port in use, wrong distro, clock out of sync.
A troubleshooting guide saves you nights of trial and error.
Transport · agent ping · time sync · reconnection.
📡 LiDAR and maps (SLAM)
How LiDAR sees, how to connect it to ROS 2, and how slam_toolbox builds the map while figuring out where the robot is.
A spinning laser that measures distance at hundreds of angles per revolution, published as LaserScan.
Understanding range and resolution explains why a map turns out well or poorly.
ranges · angle_increment · range · /scan.
The manufacturer’s driver (RPLIDAR C1/A1 or LD19), a USB port, and the laser frame in TF.
This step brings the real robot to the same point as the simulated one.
Driver · udev rule · frame_id · ros2 topic hz.
Build the map and locate yourself in it at the same time, correcting odometry based on what the laser sees.
Without a map, there’s no real autonomous navigation.
Scan matching · loop closure · occupancy grid.
The standard SLAM package in ROS 2 running on the Gazebo robot.
You learn to map without hardware and already know what to expect from the real robot.
Asynchronous online mode · parameters · /map.
A real-world mapping guide: low speed, tight turns, surfaces that confuse the laser.
A well-made map determines whether navigation will work.
Glass and mirrors · speed · revisiting places.
Save the map to a file (image + YAML) and reopen it later for navigation.
Map once, navigate many times.
map_saver · .pgm and .yaml · resolution · origin.
🚩 Navigation with Nav2
The ROS 2 navigation stack: locate yourself on the saved map, plan, avoid obstacles, recover, and run waypoint patrols.
The servers that locate, plan, control, and recover, coordinated by a behavior tree.
It’s the same type of software used by warehouse robots.
nav2_bringup · behavior tree · lifecycle.
A particle filter that estimates where the robot is by comparing the laser data with the map.
Without knowing where it is, the robot doesn't know where to go.
Particles · initial pose · map → odom.
Maps that mark where it’s costly to travel, and algorithms that plot and follow the path.
Adjusting inflation and the robot radius solves most “won’t fit through the door” problems.
Global and local costmaps · inflation · planner · controller.
Set the goal by clicking in RViz or with code using the Nav2 Python API.
With Python, navigation becomes a building block other programs can use.
Nav2 Goal · NavigateToPose · action · feedback.
Recovery behaviors: clear the costmap, spin, back up, wait.
In the real world, the robot will get stuck; what matters is how it gets unstuck.
Spin · BackUp · Wait · retries.
A list of points the robot visits in order, like a patrol.
This is the foundation for delivery, inspection, and surveillance.
followWaypoints · order · repetition.
🏠 Project: a robot that maps and navigates
Bring it all together on the real robot: architecture, a launch file that starts the system, an environment map, and safe navigation between rooms.
What runs where: ESP32 for the motors, Pi 5 with LiDAR and ROS 2, PC for visualization.
A clear architecture makes it easier to find faults and replace parts.
Task division · network · ROS_DOMAIN_ID.
One command that starts the agent, description, LiDAR, odometry, SLAM, or Nav2 in the right order.
Opening ten terminals every time doesn’t scale, even in a classroom.
Arguments · include · conditions.
Noise, slippage, delay, and real-time constraints: what Gazebo hides and how to compensate.
This is where most projects stall; knowing what to expect helps you avoid frustration.
use_sim_time · calibration · speed limits.
Create and save a real map of the space where the robot will work.
This is the project’s first visible result.
slam_toolbox · teleop · map_saver.
Nav2 on the real map, with named points (kitchen, living room) and a patrol route.
This is the complete autonomous robot the learning path promised.
Named points · waypoints · success metrics.
Emergency stop, maximum speed, battery, and the path to Learning Path 5.
A robot that moves on its own near people needs safety limits from the very first test.
E-stop · limits · watchdog · logging.
🧰 Trail kit
You can start from scratch in simulation. For the real robot, in addition to the robot from Learning Path 3, the approximate cost is R$ 450 a R$ 1.100, with most of it going toward the LiDAR (Oct 2026; check before buying: prices vary by store, shipping, and exchange rate).
PC with Ubuntu 24.04 (Jazzy) or 26.04 (Lyrical), a virtual machine, or Docker. 8 GB of RAM works; 16 GB makes Gazebo run comfortably.
The robot from Learning Path 3: Raspberry Pi 5 with official power supply and cooler, ESP32 and TB6612FNG or DRV8833 driver, two-wheel chassis, and caster wheel.
RPLIDAR C1 or A1 (Slamtec) or LD19 (LDRobot), with the included USB adapter. It’s the most expensive part of the learning path.
The encoder motors from Learning Path 2 (N20 or TT with disk). Without an encoder, there’s no odometry, and the map will be skewed.
Separate battery for the motors and the Pi (or a 5 V, 5 A buck converter), common GND, and an easy-to-reach stop switch.
USB data cables (ESP32 and LiDAR) and a stable local Wi-Fi network between the robot and the PC.
✓ Worthwhile optional item
MPU-6050 or ICM-20948 IMU (improves odometry on turns) and an emergency stop button that cuts power to the motors.
✗ Don’t buy these for this trail
3D LiDAR, an expensive depth camera, or a second onboard computer. 2D LiDAR with encoders is enough for mapping and indoor navigation.