In Chapter 9 we assumed a map already existed and we just needed to estimate ARCHO's position on it. But a real day one doesn't work that way: you unbox ARCHO and roll it into a new warehouse that nobody has ever mapped. Now what?
This simple question gave rise to one of the most important branches of all of robotics: SLAM (Simultaneous Localization and Mapping) — discover the environment, build a map, and find your own position on that same map you're building, all at the same time.
To find your position, you need a map; but to build an accurate map, you need to know where you are. This appears to be an unsolvable two-way dependency — a classic chicken-and-egg problem. SLAM breaks this loop by cleverly combining odometry (which we built in the previous chapter) with successive comparisons of LiDAR scans.
In this book, we use the most widely-used LiDAR SLAM package in ROS 2: SLAM Toolbox.
It uses LiDAR data, simultaneously estimates the robot's position, builds a map, detects when it returns to a previously visited place (Loop Closure), keeps this entire history in a structure called a Pose Graph, and finally saves the map so it can be reloaded later.
A point that confuses many people: SLAM Toolbox does not replace the work from Chapter 9 — it uses its output. Filtered odometry estimates moment-to-moment motion; SLAM Toolbox uses this same estimate to improve the accuracy of comparing successive scans (Scan Matching). The two are complementary, not competing.
| Mode | When it's used | Input | Output |
|---|---|---|---|
| Mapping | Day one, the environment is completely unknown | LiDAR + Odometry | New map (Occupancy Map) |
| Localization | Map already built and saved | Saved map + LiDAR | Just the robot's position on the map |
The workflow for ARCHO's first two days in a new warehouse branch usually looks like this:
Many people think SLAM should always stay on. In most industrial projects, the map is built only once, saved, and from then on only Localization (with AMCL, next chapter) is performed — it's both lighter and more stable. The exception is environments that constantly change, like a warehouse under renovation; there, SLAM might stay active permanently.
sudo apt install ros-jazzy-slam-toolbox| Main inputs | Outputs |
|---|---|
/scan | /map |
Transform: odom → base_link | Transform: map → odom |
Transform: base_link → laser_link | Pose Graph |
Configuration file for ARCHO:
# archo_slam/config/mapper_params.yaml
slam_toolbox:
ros__parameters:
use_sim_time: true
mode: mapping
map_frame: map
odom_frame: odom
base_frame: base_link
scan_topic: /scan
resolution: 0.05
max_laser_range: 12.0
minimum_time_interval: 0.2
transform_publish_period: 0.05
map_update_interval: 2.0
minimum_travel_distance: 0.15
minimum_travel_heading: 0.15
use_scan_matching: true
do_loop_closing: true| Parameter | Meaning |
|---|---|
resolution | Size of each map cell in meters — 0.05 means each map pixel is 5 centimeters |
minimum_travel_distance | The robot must travel at least this far before a new scan is recorded into the map |
do_loop_closing | Whether the map corrects itself when you return to a previous location |
To build the map, you need four separate terminals:
| Terminal | Task |
|---|---|
| 1 | Gazebo + ARCHO (Chapters 7 and 8) |
| 2 | SLAM Toolbox |
| 3 | Teleoperation (manual drive command) |
| 4 | RViz — with Fixed Frame set to map and Displays for Map, LaserScan, TF, RobotModel, Odometry |
Once you're confident you've covered the whole warehouse:
ros2 run nav2_map_server map_saver_cli \
-f ~/archo_ws/src/archo_navigation/maps/warehouseThis command creates two files:
| File | Content |
|---|---|
warehouse.pgm | The map image itself — a grayscale image showing walls and open space |
warehouse.yaml | Map metadata: cell size, origin, and the PGM file's path |
# warehouse.yaml
image: warehouse.pgm
mode: trinary
resolution: 0.05
origin: [-5.0, -5.0, 0.0]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.25The next day, these same two files are loaded by the Map Server and fed to AMCL (next chapter) to find ARCHO's position without needing to rebuild the map.
| Symptom | Likely causes |
|---|---|
| Walls appear doubled or blurred | Poor odometry, excessive speed, wheel slip, incorrect TF, low scan rate |
| The map rotates or is wavy | Incorrect IMU yaw axis, invalid timestamps, poor scan matching |
| Extra stray points remain on the map | People or moving objects during scanning, an overly dynamic environment |
A good map isn't just the product of a good algorithm; it's the result of proper odometry (Chapter 9), correct TF (Chapter 5), gentle motion, and adequate coverage of the environment. If you didn't work carefully through the earlier chapters, no amount of SLAM Toolbox tuning can make up for that shortfall.
Suppose that after building the map, you notice the walls of one aisle appear doubled and slightly offset from each other. Using the table in this section, rank three likely causes and, for each, propose an experiment that would identify the actual cause.
ARCHO can now enter a completely unknown warehouse and, without any pre-built map, simultaneously discover the environment, build a map, and find its own position on that same map as it's being built. This saved map is the launching pad that the next chapter — Navigation2 — builds upon.
ARCHO Project now has an archo_slam package with a complete Mapping configuration, and has built and saved its first real warehouse map (warehouse.pgm and warehouse.yaml).
In Chapter 11, we'll load this saved map and step into the full Navigation2 architecture: Map Server, AMCL, Costmap, Global Planner, and Local Controller — where ARCHO plans its own path through the warehouse fully autonomously for the first time.