Coordinate Frames & Transforms

A robot doesn't have a single notion of "here." It carries a small zoo of coordinate systems, one bolted to each link, the camera, the wheels, the workpiece, the room, and spends its whole life translating between them. Get the bookkeeping right and the arm drops the screw exactly into the hole. Get it wrong by one frame and it confidently drives the gripper through the table.

Pose: position and which way you're facing

The fundamental object here is pose. Not just where a body is, but how it is oriented: the two welded together. A drone hovering at the same point but tilted thirty degrees has a different pose. A coordinate frame is just pose made concrete: a little set of perpendicular axes rigidly glued to a body, riding along wherever that body goes.

Pose splits cleanly into two pieces:

• Translation: a vector saying how far the frame's origin sits from some reference origin. Three numbers in 3D: $x, y, z$.
• Rotation: how the frame's axes are twisted relative to the reference. This is the subtle half.

In 2D the rotation is a single angle. In 3D it takes three numbers, and three is exactly where the trouble starts.

Before the trouble, one promise the whole system rests on: which way is positive. Curl the fingers of your right hand around an axis with your thumb pointing along it, and your fingers sweep the direction of positive rotation. That's the right-hand rule, and it is not decoration. In the basic 3D rotation matrices, it is exactly what fixes the alternating plus and minus signs on the sine terms. Flip to a left hand and every one of those signs flips with you, which is precisely how a sim ends up spinning the wrong way for reasons nobody can find for an afternoon.

Spin it yourself. Drag the yaw, pitch, and roll sliders, or drag on the cube to orbit your view. Push pitch toward ±90° and watch the warning fire: two of the three axes line up and you lose a degree of freedom. That collapse is gimbal lock, and it's the reason the next chapter reaches for quaternions.

Rotations refuse to play nice

Translations are polite. Walk three steps north, then four steps east; or four east then three north. You land in the same spot either way. Addition doesn't care about order.

Rotations are not polite. They do not commute. Stand up, then try this for real: turn 90 degrees to your right, then step forward, versus step forward, then turn. You end up facing the same way but standing in two completely different places. Turn-then-step and step-then-turn are different operations, and a robot that confuses them will reach for the wrong shelf every time.

The homogeneous transform: one matrix to rule them

Here's the elegant trick. Translation is addition; rotation is multiplication; juggling both by hand is misery. So we glue them into a single $4 \times 4$ matrix (the homogeneous transform) and suddenly every pose change is just one matrix multiply.

$$T = \begin{bmatrix} R & \mathbf{t} \\ \mathbf{0}^{\top} & 1 \end{bmatrix}$$

The top-left $3 \times 3$ block $R$ is the rotation; the right column $\mathbf{t}$ is the translation; the bottom row is padding that makes the algebra work. One object now carries the entire pose of a frame.

The payoff is chaining. The transform from the world to the robot's base, times base-to-shoulder, times shoulder-to-elbow, all the way out to the gripper:

$$T^{\text{world}}_{\text{gripper}} = T^{\text{world}}_{\text{base}}\, T^{\text{base}}_{\text{arm}}\, T^{\text{arm}}_{\text{gripper}}$$

Multiply the chain and you get a single matrix that says exactly where the gripper sits in the room. Want to ask the reverse question: where is that screw, as the gripper sees it? You don't rebuild anything; you just invert the transform. (And because $R$ is a rotation, the inverse is cheap, with no general matrix inversion required; see below.)

Why a robot juggles dozens of frames

It sounds like overkill until you watch a real machine work. The KUKA arm at the top has a frame at its base, then one at every joint, marching link by link out to the tool. Add a wrist camera (its own frame), the part being machined (its own frame), the conveyor, the cell, the factory. A self-driving car carries frames for each wheel, the IMU, every lidar and camera, the car body, and the map.

None of them agree on where "here" is, and that's fine, because the transforms are the dictionary. Each sensor reports in the frame it's bolted to; the robot composes transforms to translate every observation into whatever frame it needs to act in. Coordinate frames are not bureaucracy. They are how a machine made of rigid parts keeps a coherent picture of a world that refuses to hold still.

When physicists study a tumbling rigid body, they keep two frames side by side: a still space frame and a body frame welded to the object, riding along as it spins. The math for spin and momentum comes out far cleaner in the body frame, because the object's mass distribution stops changing in time. Robotics inherited exactly this split. The world frame is the room; the body frame is the robot. Almost every "where is it?" question is really "in which of these two frames, and how do I hop between them?"

↘ The math: rotation matrices, SE(3), and why inverting is cheap

A rotation matrix $R$ lives in the special orthogonal group $SO(3)$: its columns are orthonormal and its determinant is $+1$. Orthonormality means

$$R^{\top} R = I, \qquad \text{so} \qquad R^{-1} = R^{\top}.$$

The inverse of a rotation is just its transpose, with no expensive inversion needed.

Stack rotation and translation together and the full pose lives in the special Euclidean group $SE(3)$ (or $SE(2)$ in the plane). A point $\mathbf{p}$ is written in homogeneous coordinates as $\tilde{\mathbf{p}} = [\,x, y, z, 1\,]^{\top}$, and the transform acts by a single multiply:

$$\tilde{\mathbf{p}}' = T\, \tilde{\mathbf{p}}, \qquad T = \begin{bmatrix} R & \mathbf{t} \\ \mathbf{0}^{\top} & 1 \end{bmatrix}.$$

Inverting the whole transform exploits $R^{-1} = R^{\top}$, so there is a clean closed form:

$$T^{-1} = \begin{bmatrix} R^{\top} & -R^{\top}\mathbf{t} \\ \mathbf{0}^{\top} & 1 \end{bmatrix}.$$

Chaining is associative but not commutative, exactly because $SO(3)$ isn't. Compose in frame order, never alphabetical order.

Key takeaways

• A pose is position and orientation; a frame is that pose made concrete: axes rigidly attached to a body.
• Translations commute, rotations don't: turn-then-step lands somewhere different from step-then-turn, which is why rotations need matrices.
• A homogeneous $4 \times 4$ transform bundles rotation and translation so poses chain by multiplication (world → base → arm → gripper) and reverse by inversion.
• Real robots run dozens of frames at once; ROS gathers them into a live TF tree so every sensor's view can be re-expressed in any other frame.