Rigid body motion
A rigid body motion (rigid transformation) preserves distances between all points. In 3D it consists of a rotation and a translation, and the mathematical structures that represent it — and — are central to SLAM: a camera pose is an element of .
Rotation Representations
Euler angles. A rotation can be parameterized by three angles representing successive rotations about fixed or body axes; the 12 possible conventions (ZYX, XYZ, …) each give different angle sequences. The gimbal lock problem occurs when two rotation axes align, reducing the effective degrees of freedom to 2. Euler angles are intuitive for display but numerically problematic — avoid them for iterative optimization.
Rotation matrices. A rotation matrix satisfies and . The set of all such matrices forms the Special Orthogonal Group:
Rotation matrices are the preferred representation for computation: matrix multiplication is the composition law, and the inverse is simply the transpose.
Quaternions. A unit quaternion with represents a rotation by angle around axis . They are compact (4 numbers vs. 9), have no gimbal lock, and compose via the Hamilton product. Note the double cover: and represent the same rotation.
Conversion from quaternion to rotation matrix:
A quick NumPy sanity check that a matrix is a valid rotation:
import numpy as np
# R is a rotation iff R^T R = I and det(R) = +1
print(np.allclose(R.T @ R, np.eye(3)), np.isclose(np.linalg.det(R), 1.0))
Homogeneous Transformation:
A rigid body motion combines rotation and translation into one matrix acting on homogeneous coordinates:
Composition is matrix multiplication, with rotation and translation interleaving:
— note that gets rotated by , which is why translations of chained transforms do not simply add. The inverse has the closed form:
Homogeneous coordinates come from projective space: appending a 1 (points) or 0 (directions) lets one matrix express rotation and translation together. In projective geometry, parallel 3D lines meet at a vanishing point in the image — a useful cue for rotation estimation in man-made environments and a reminder that image formation is projective, not Euclidean.
Keeping frames straight
The most effective habit is a subscript convention that makes composition self-checking: let map coordinates from frame to frame . Then
and adjacent subscripts must “cancel” like units. If they don’t, the expression is wrong — this catches a remarkable fraction of pose-arithmetic bugs at a glance. Be explicit about whether a stored “camera pose” means (camera-to-world, the camera’s position in the world) or its inverse (the extrinsics used in projection); both conventions are common across codebases.
Common pitfalls
- Hamilton vs. JPL quaternion conventions: two incompatible definitions of quaternion multiplication coexist in the literature (Eigen and ROS use Hamilton); mixing them silently conjugates rotations.
- Quaternion storage order:
(w, x, y, z)vs.(x, y, z, w)differs between libraries (e.g., Eigen’s constructor vs. its internal layout, ROS messages); always test with a known rotation. - Drifting off the manifold: repeatedly multiplying rotation matrices or integrating quaternions accumulates numerical error; re-orthonormalize matrices (e.g., via SVD) or re-normalize quaternions periodically.
- Sign flips under the double cover: interpolating between and a nearby takes the long way around; flip the sign first if the dot product is negative.
Why it matters for SLAM
Every SLAM system is, at bottom, estimating a trajectory of elements. Chaining relative motions (), inverting transforms, and converting between quaternions (compact storage, ROS messages) and rotation matrices (computation) are daily operations. Getting frame conventions right — which frame a transform maps from and to — is the most common source of bugs for newcomers, so nail this before moving on.