ROS 2 Lyrical Luth · Lesson 41 of 86

Robot frames: map, odom, base_link and sensors

REP 105 frame conventions and who publishes each transform.

Estimated time · 45–75 min

Learning goals

What you will understand

Explain robot frames: map, odom, base_link and sensors in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

REP 105 defines the standard mobile-robot frames: map (a fixed world frame, may jump when localization corrects), odom (smooth and continuous but drifts over time), base_link (attached to the robot) and sensor frames such as lidar_link. The chain is map → odom → base_link → sensors.

Odometry (wheel encoders, visual odometry) publishes odom → base_link. Localization (AMCL or SLAM) publishes map → odom, so map → base_link is correct while odom → base_link stays smooth. Use odom for local control and obstacle avoidance and map for goals.

Guided lesson

Work through these steps

1.
Source the ROS 2 Lyrical environment in a fresh terminal.
2.
Read the robot frames: map, odom, base_link and sensors example and identify what each line does.
3.
Build only the affected package, source the workspace overlay, and run the example.
4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

map -> odom
# Published by localization (AMCL or SLAM Toolbox); may jump to correct drift.
odom -> base_link
# Published by odometry or the diff drive controller; smooth but drifts.
base_link -> lidar_link
# Fixed sensor mount from the URDF (robot_state_publisher).
base_link -> camera_link
# Another fixed mount from the URDF.
ros2 run tf2_ros tf2_echo map base_link
# The pose of the robot in the map: what navigation goals use.

What the example is doing

1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Mobile robot

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

# Provide the missing map -> odom transform so the tree is connected
# TODO: publish an identity static transform from frame map to frame odom
ros2 run tf2_ros tf2_echo map base_link

Expected output

map -> odom -> base_link -> lidar_link

Stuck? Show the full solution (try it yourself first)

# Provide the missing map -> odom transform so the tree is connected
ros2 run tf2_ros static_transform_publisher --frame-id map --child-frame-id odom
ros2 run tf2_ros tf2_echo map base_link

Expected result

How you know it worked

ROS_DISTRO is lyrical in every terminal used for the exercise.
The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

In a simulated robot, list which node publishes each transform in the chain, then stop the localization node and observe which transform disappears while odom → base_link keeps updating.

Before you continue

ROS_DISTRO reports lyrical in every terminal you used
The example builds and runs without errors
You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.