Skip to the lesson
FixTheRobot Explore Robotics / Localization & SLAM / M7 SLAM with ROS 2 / M7-T1

Localization & SLAM · Theory · M7

M7-T1 — SLAM System Architecture in ROS 2

A SLAM algorithm is only one node in a graph. Most failures in the field are in the wiring, not in the algorithm.

  • Lesson 1 of 8
  • Module 7: SLAM with ROS 2
  • Theory
  • About 8 minutes to read

Modules 1 to 6 treated SLAM as an algorithm that takes sensor data and returns a map and a pose. On a real robot, the algorithm lives inside a middleware: it receives messages from other processes, looks up coordinate transforms in a shared tree, reads its configuration from parameters, and publishes results for others to use. This lesson maps that system for ROS 2, so that when no map appears you know where to look.

Learning objectives

After this lesson, you should be able to:

  • Describe the nodes, topics, frames and parameters of a typical ROS 2 SLAM system.
  • List what a 2D lidar SLAM node subscribes to and publishes, with the message types and QoS that matter.
  • Use the standard introspection commands to check each link from sensor to map.
  • Estimate message rates and bandwidth and relate them to the compute budget.

The problem and the intuition

Think of a SLAM system as a factory line. Sensors are the loading dock; the SLAM node is the machine; the map and the transform are the products; Nav2 and the visualiser are the customers. If nothing reaches the customer, the machine may be perfectly fine and the conveyor belt simply disconnected: the scan is published on /scan but the node listens on /lidar/scan; the frames exist but no transform links them; the stamps are in the future and the node discards them. In every case the algorithm is innocent.

ROS 2 gives a standard vocabulary for the belts: nodes (processes), topics (named, typed streams with a quality-of-service profile), transforms (the TF tree), parameters (configuration) and launch files (how everything is started and wired). A good habit, used throughout this module, is to debug from the outside in: first topics, then frames, then timing, then parameters, and only last the algorithm.

When no map appears, work along the data path: sensor topic, message rate, frame, transform, timestamp, parameter. The first broken link is the cause.

A ROS 2 SLAM system as a graphSensor drivers publish scan, odometry and IMU topics. robot_state_publisher provides static transforms. The SLAM node subscribes to scan and TF and publishes the map and the map to odom transform. RViz and Nav2 consume the map./scanLaserScan/odomOdometry/imuImu (optional) robot_state_pubURDF → /tf_static SLAM nodeslam_toolbox /mapOccupancyGrid/tf: map → odomTFMessage Nav2 · RVizconsumers parameterslaunch fileuse_sim_time
A ROS 2 SLAM system: sensors, SLAM node, products and consumers.

The system: nodes, interfaces and checks

Problem. Wire a SLAM node to a robot’s sensors and to its consumers so that a map and a localised pose are produced reliably, and be able to localise a fault in the wiring quickly.

Assumptions. A ROS 2 distribution (Humble or Jazzy are the long-term-support releases used in this module), a 2D lidar or equivalent, wheel or other odometry, a URDF describing the sensor mounting, and a SLAM package such as SLAM Toolbox. The robot can run in simulation or on hardware with the same interfaces.

The cast

ComponentRoleTypical interface
Lidar driverPublishes range scans stamped at measurement time/scan, sensor_msgs/LaserScan, sensor-data QoS (best effort)
Odometry sourceWheel encoders / EKF; publishes odometry and the odom → base_link transform/odom, nav_msgs/Odometry; /tf
IMU (optional)Rotation rate, acceleration; fused in the odometry/imu, sensor_msgs/Imu
robot_state_publisherReads the URDF; publishes fixed transforms such as base_link → laser/tf_static (transient local QoS), /robot_description
SLAM nodeScan matching, pose graph, loop closure; publishes the map and the correction map → odomsubscribes /scan, /tf; publishes /map, /tf
Map server / Nav2Consumes the map for planning and costmaps/map (transient local), /tf, /cmd_vel
RViz 2Visualisation and the initial-pose toolsubscribes to everything

Interfaces that carry the meaning

  • Topic name and type. Both must match for a connection. A name mismatch (a remap forgotten in the launch file) is silent.
  • QoS. Reliability (reliable or best effort), durability (volatile or transient local), history depth. Publisher and subscriber must be compatible (M7-T3).
  • Frame id and stamp in the message header: which coordinate frame the data is in, and when it was measured (M7-T2, M7-T3).
  • Parameters. The SLAM node reads frame names, topic names, resolution and mode from its parameters (M7-T4).
  • Simulated time. In simulation every node must use use_sim_time:=true so that all agree on the clock; one node on wall time and the rest on sim time gives stamps that differ by years.

Introspection: the five commands

ros2 node list                    # is the node running?
ros2 topic list -t                 # are the topics there, with their types?
ros2 topic info /scan -v           # who publishes, who subscribes, which QoS?
ros2 topic hz /scan                # what rate? (and ros2 topic delay /scan, ros2 topic bw /scan)
ros2 run tf2_tools view_frames     # which frames, which parents?

Each command answers one question on the path from sensor to map. ros2 doctor checks the installation, ros2 param list /slam_toolbox and ros2 param get read the parameters actually in effect, and rqt_graph draws the node graph.

node
a process (or component) that publishes, subscribes, serves or acts.
QoS
quality-of-service profile: reliability, durability, history and deadlines.
launch file
Python (or XML/YAML) description of which nodes to start, with which parameters and remaps.
use_sim_time
parameter making a node take its clock from /clock instead of the system clock.

Failure modes of the wiring

SymptomLikely causeCheck
No /map topicSLAM node not running, crashed or lifecycle not activatedros2 node list, the launch log
/map exists, emptyNo scans received (topic name, QoS), or scans dropped (transform or timestamp)ros2 topic info /scan -v, node log
“Message Filter dropping message”Transform not available at the scan time: wrong frame, missing static transform, stamp in the futureview_frames, ros2 topic delay
Map drifts or smearsOdometry quality, bad parameters, timingM7-T3, M7-T4, M7-T8
Works in one terminal, not in anotherDifferent ROS_DOMAIN_ID or environment, sim-time mismatchPrint the environment; ros2 param get … use_sim_time

A worked example: from “no map” to the cause

  1. Is the node there? ros2 node list shows /slam_toolbox. Yes. ros2 topic list -t shows /map [nav_msgs/msg/OccupancyGrid] exists but ros2 topic echo /map --once times out.
  2. Is the input arriving? ros2 topic hz /scan reports 10 Hz, so the lidar works. ros2 topic info /scan -v shows the publisher with QoS reliability BEST_EFFORT and one subscription, from /slam_toolbox, also best effort: compatible. The topic name in the SLAM parameters is scan_topic: /scan: matches.
  3. Do the frames connect? The node log says “Failed to compute odom pose” and view_frames shows two separate trees: odom → base_footprint and base_link → laser. The SLAM parameter base_frame is base_link, but the odometry publishes base_footprint, and there is no transform between them. This is the cause; the lab M7-L2 is this class of failure.
  4. Bandwidth sanity check. A 2D lidar message with 360 ranges and 360 intensities in 32-bit floats is about 360 × 4 × 2 ≈ 2.9 kB plus header, so a 10 Hz scan is about 30 kB/s: negligible. A 3D lidar with 100 000 points of 16 bytes each (x, y, z, intensity) is 1.6 MB per message, or 16 MB/s at 10 Hz, enough to saturate a Wi-Fi link or a slow serial bus and to dominate CPU time for serialisation. Process it on the robot, not across a network.
  5. Time check. In simulation ros2 param get /slam_toolbox use_sim_time returns False while the simulator publishes /clock: the SLAM node stamps its outputs with wall time, and every lookup fails by about fifty years. The fix is a single launch argument. Always check the clock source first in simulation (M7-L1).

Engineering implications and limitations

Engineering implications

  • Make the launch file the single source of truth. Topic names, remaps, frames, parameter files and use_sim_time in one place; keep it under version control.
  • Bring up in layers. Sensors, then TF, then odometry, then SLAM, then Nav2. Verify each layer with the introspection commands before adding the next.
  • Record bags for debugging. ros2 bag record /scan /odom /tf /tf_static lets you replay a failure offline with --clock and use_sim_time.
  • Check QoS explicitly. Sensor topics are best effort; maps are transient local. A QoS mismatch gives no messages and, at best, a warning in the log.
  • Name frames once. A single document of frame names for the robot avoids the classic base_link versus base_footprint error.
  • Watch the data rates. Know the expected rate and bandwidth of each topic; log them. A sudden drop is the earliest symptom of many failures.

Limits

The commands and conventions here apply to ROS 2 (Humble, Jazzy and neighbouring releases); package names, parameter names and defaults change between releases, so check the documentation of the version you run. The introspection tools tell you what the graph looks like, not whether the algorithm’s output is good; for that you need the evaluation methods of Module 4 and the failure analysis of Modules 5 and 6.

Common misconceptions

“If the node is running, it is working.”

A running node can receive nothing (wrong topic, incompatible QoS) or drop everything (missing transform, bad stamps).

“Topics with the same name always connect.”

The type must match, and the QoS profiles must be compatible; otherwise no data flows.

“The map frame is published by the map server.”

In a SLAM system the SLAM node publishes map → odom; the map server is for a saved map with a localiser.

“Simulation and hardware differ only in the driver.”

The clock source also differs; forgetting use_sim_time in one node breaks every transform lookup.

Engineering takeaways

  1. A ROS 2 SLAM system is nodes, topics, frames, parameters and a launch file; the algorithm is one node.
  2. Debug from the outside in: topic, rate, QoS, frame, transform, timestamp, parameter.
  3. The five commands node list, topic list -t, topic info -v, topic hz and view_frames answer most “no map” questions.
  4. Message sizes and rates set the compute and network budget; process 3D lidar data on the robot.
  5. Use simulated time consistently in simulation and keep one launch file as the single source of truth.

References and further reading

Primary papers and authoritative documentation.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

Question 1

/map exists but is empty and ros2 topic hz /scan shows 10 Hz. What do you check next?

Explanation

That the SLAM node actually receives the scans (subscription on the right topic name with compatible QoS, via ros2 topic info /scan -v) and then that it can transform them (frames and timestamps). A healthy sensor topic does not prove the SLAM node receives it.

Question 2

Why is a 3D lidar at 10 Hz with 100 000 points per message a problem to send over Wi-Fi, but a 2D scan is not?

Explanation

The 3D message is about 1.6 MB, or 16 MB/s at 10 Hz, which exceeds what many wireless links sustain and costs heavy CPU for serialisation; a 2D scan is about 3 kB, or 30 kB/s. The 3D data should be processed on the robot and only results sent.

Question 3

A simulation runs, but every transform lookup fails with a huge time difference. What is the most likely cause?

Explanation

A node (often the SLAM node) is using wall time while the rest use simulated time from /clock; its stamps differ by decades from the simulator’s. Setting use_sim_time:=true in that node fixes it.

What’s next

The wiring diagram showed a tree of coordinate frames connecting the sensors, the odometry and the map. The next lesson explains the rules of that tree and who is allowed to publish each link.

Practice this lesson

Debug a ROS 2 SLAM Pipeline

Bring up a SLAM stack in simulation, find why no map appears and verify with the standard introspection tools.

Next lesson

M7-T2 — TF Frames and Coordinate Consistency

Apply REP 105 (map, odom, base_link) and know who publishes each transform.

Nothing below is required to finish this lesson.