Skip to the lesson
FixTheRobot Explore Robotics / Localization & SLAM / M1 SLAM Foundations / M1-T4

Localization & SLAM · Theory · M1

M1-T4 — Robot Poses and Coordinate Frames

A number for a position means nothing until you say in which frame it is expressed.

  • Lesson 4 of 6
  • Module 1: SLAM Foundations
  • Theory
  • About 8 minutes to read

Half of all “my SLAM is broken” bug reports are frame bugs: the data are fine, but a point from one frame is used as though it were in another. This lesson gives you the language to describe a pose, to compose transforms in the right order, and to read the frame chain every real robot uses.

Learning objectives

After this lesson, you should be able to:

  • Write a 2D pose and apply it to a point, converting between the robot and world frames.
  • Compose and invert 2D transforms and explain why the order matters.
  • Describe the map, odom, base_link and sensor frames and what each is for.
  • Read a statement such as “the pose of the lidar in the map” unambiguously.

The intuition

Say “the door is 3 metres ahead.” Ahead of whom? If you face north and the door is north, then it is also “north of me”. But in a building map the door is at (24, 7), not 3 m anywhere. Both statements are true. They are the same fact written in two coordinate frames.

A pose is a position and an orientation. A frame is a coordinate system attached to something: the building, the robot body, a sensor. A pose is always the pose of one frame expressed in another. “The robot is at (3, 2)” really means “the robot frame’s origin is at (3, 2) in the world frame”.

Always say which frame a pose is in. A point has no coordinates until you say in which frame they are written.

Frame chain: map, odom, base, sensorFour coordinate frames drawn as axes: map at the top left, odom to its right, base_link on the robot, and a lidar frame mounted ahead of the base. Arrows show the transforms map to odom, odom to base, base to lidar.map odom base lidar map→odom odom→base base→lidar map→odom is slow and corrective. odom→base is smooth but drifts. base→lidar is fixed by the mount.
The frame chain on a typical wheeled robot. Each arrow is a transform. To express a lidar point on the map you apply the chain from lidar to base to odom to map.

The mathematics

A 2D pose is three numbers: x, y and a heading θ. It defines a rigid transform: rotate by θ, then translate by (x, y). A point written p in the robot frame is written in the world frame as

Transform a point from robot to world frame
pworld=R(θ)⋅probot+tp_{\text{world}}=R(\theta )\cdot p_{\text{robot}}+t
t=(x, y)t=(x,\,y)
R(θ)=[cos⁡θ−sin⁡θsin⁡θcos⁡θ]R(\theta )=\begin{bmatrix}\cos \theta & -\sin \theta \\ \sin \theta & \cos \theta \end{bmatrix}
R(θ)
the rotation matrix for heading θ, in radians, counter-clockwise positive.
t
the translation: where the robot frame’s origin sits in the world frame.
TAB
the pose of frame B expressed in frame A. Read it as “B in A”.
θ
heading, measured from the +x axis of the parent frame. Always wrap it to (−π, π].

Composing and inverting

If B is at pose TAB = (x1, y1, θ1) in A, and C is at TBC = (x2, y2, θ2) in B, then C in A is

Pose composition
TAC=TAB⊕TBCT_{\text{AC}}=T_{\text{AB}}\oplus T_{\text{BC}}
x=x1+cos⁡θ1⋅x2−sin⁡θ1⋅y2x=x1+\cos \theta 1\cdot x2-\sin \theta 1\cdot y2
y=y1+sin⁡θ1⋅x2+cos⁡θ1⋅y2y=y1+\sin \theta 1\cdot x2+\cos \theta 1\cdot y2
θ=θ1+θ2\theta =\theta 1+\theta 2

The inverse pose TBA is the pose of A in B:

Pose inverse
xinv=−(cos⁡θ⋅x+sin⁡θ⋅y)x_{\text{inv}}=-(\cos \theta \cdot x+\sin \theta \cdot y)
yinv=(sin⁡θ⋅x−cos⁡θ⋅y)y_{\text{inv}}=(\sin \theta \cdot x-\cos \theta \cdot y)
θinv=−θ\theta _{\text{inv}}=-\theta

Composition is not commutative. TAB ⊕ TBC and TBC ⊕ TAB are different poses: “drive 1 m, then turn 90°” is not “turn 90°, then drive 1 m”.

The frames of a real robot

FrameAttached toPropertyUsed for
mapThe world, anchored by SLAMGlobally consistent, but can jump when the estimate is correctedNavigation goals, long-term localization
odomA starting point of the odometrySmooth and continuous, but drifts without boundLocal control, short-term motion
base_linkThe robot bodyMoves with the robotReference for all sensors
lidar, cameraA sensor mountFixed relative to base_link (calibrated)Interpreting raw measurements

The chain is map → odom → base_link → sensor. Odometry gives odom → base_link. SLAM computes map → base_link and publishes the difference as map → odom, so the smooth odometry is not disturbed by corrections. REP-105 documents this convention for ROS.

A worked example: a lidar point on the map

The robot is at Tmap,base = (4, 2, 90°) in the map, so it faces +y. A lidar is mounted at Tbase,lidar = (0.3, 0, 0°): 0.3 m ahead of the base centre, facing the same way. The lidar sees an obstacle at (2, 0) in its own frame.

  1. Lidar to base. Rotation is 0°, so the point in the base frame is (2, 0) + (0.3, 0) = (2.3, 0).
  2. Base to map. With θ = 90°: cos θ = 0, sin θ = 1. x = 4 + 0 · 2.3 − 1 · 0 = 4. y = 2 + 1 · 2.3 + 0 · 0 = 4.3. The obstacle is at (4, 4.3) on the map.
  3. Sanity check. The robot faces +y, so “2.3 m ahead of the base” should be 2.3 m up from (4, 2): (4, 4.3). ✓
  4. Now make frame mistakes. Forget the 0.3 m mount offset and the obstacle is placed at (4, 4.0): 0.3 m too close. Add the offset in the world frame instead of the base frame and it lands at (4.3, 4.0): off by 0.42 m, because the offset was not rotated with the robot. Frame errors are systematic: they do not average out, and they scale with the lever arm and with the heading.

Another typical bug is a heading sign error: using θ instead of −θ rotates the point the wrong way. At θ = 90° with the point (2.3, 0), the wrong sign would place it at (4, −0.3): the robot would see a wall behind it.

Engineering implications and limitations

Where frame bugs hide

  • Composition order: confusing TAB ⊕ TBC with TBC ⊕ TAB. Rule: the chain reads from the outer frame inwards.
  • Angle units: degrees given where radians are expected. A heading of 90 treated as radians is 5157°, which looks plausible after wrapping.
  • Inverse vs forward: using TBA where TAB was needed. Symptom: errors are fine at the origin and grow with distance.
  • Sensor mount: a forgotten or mis-measured extrinsic. Symptom: the walls double up as the robot turns, because the lever arm swings the points.
  • Time: correct transforms at the wrong moment. A sensor reading must be transformed with the pose at the measurement time (Module 2).
  • Handedness and axis conventions: camera frames conventionally use z forward and y down, robot frames x forward, y left, z up. Mix them and everything rotates by 90°.

Limits of the 2D model

A planar pose ignores tilt. On ramps or uneven ground a 2D lidar sees the floor or the ceiling and the 2D assumption fails. Three-dimensional poses add roll and pitch and require SE(3) maths (Module 2). The ideas of frames, composition and inversion carry over unchanged.

Common misconceptions

“Odometry and the map frame are the same thing.”

odom is smooth but drifts; map is corrected by SLAM and can jump. Keeping them separate lets local control stay smooth while global localization improves.

“Composition order does not matter.”

Rotations and translations do not commute. Turn then drive differs from drive then turn.

“A pose is a point.”

A pose is a position and an orientation. A point has no orientation, which is why a point can be transformed but a pose is composed.

“The sensor is at the robot centre.”

Rarely. The mount offset is a lever arm that couples rotation into position error.

Engineering takeaways

  1. A pose is the position and orientation of one frame expressed in another: always name both frames.
  2. Compose transforms in chain order; the order matters because rotation and translation do not commute.
  3. The inverse of a pose swaps the two frames; the formula is not simply negating x, y and θ.
  4. The standard chain is map → odom → base_link → sensor; odom is smooth, map is globally consistent.
  5. Check a frame chain with one landmark you can reason about by hand: it catches sign, order and offset errors quickly.

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

The robot is at (0, 0, 90°) in the world and sees an obstacle at (1, 0) in its own frame. Where is the obstacle in the world?

Explanation

Rotating (1, 0) by 90° gives (0, 1), and adding the position (0, 0) leaves (0, 1). The robot faces +y, so something directly ahead is directly up the world y axis.

Question 2

Why does SLAM publish map → odom rather than overwriting odom → base_link when it corrects the pose?

Explanation

Odometry is smooth and continuous, which controllers rely on. A SLAM correction can be a sudden jump. By putting the jump in the map → odom link, the odom → base_link stream stays smooth, and the full map → base_link pose is still correct.

Question 3

After you fix a mounting offset, the walls stop doubling while the robot rotates. Why does a mount error show up mainly when the robot turns?

Explanation

The mount offset is a lever arm: when the robot rotates, a sensor off the rotation centre swings in space. Using the wrong offset places the same wall at a different position at each heading, so repeated views of one wall no longer agree.

What’s next

Frames tell you where things are expressed. Next, how the robot’s own pose changes as it moves, and why that is where drift begins.

Practice this lesson

Fix Incorrect Coordinate Frames

Sensor points land in the wrong place on the map: find the broken frame transform and fix the chain.

Next lesson

M1-T5 — Odometry and Motion Models

Derive how wheel odometry integrates into a pose and why its error grows without bound.

Nothing below is required to finish this lesson.