Rigid-body transformations

The formula (the core equation(s), each with a one-line reading of what it says)

T = | R  t |      R: 3×3 rotation matrix (RᵀR = I, det R = +1)
    | 0  1 |      t: 3×1 translation vector

Reads: a pose is a rotation and a translation packed into one 4×4 block matrix — the bottom row (0 0 0 1) is bookkeeping that makes the rest of the algebra work.

p' = R·p + t      or, homogeneous:  (p', 1) = T · (p, 1)

Reads: rotate the point, then shift it. Padding the point with a trailing 1 lets the addition hide inside a single multiply. Example, verified: R = 90° about z, t = (1, 0, 0), p = (2, 0, 0) gives p' = (1, 2, 0).

T_total = T_base→shoulder · T_shoulder→elbow · T_elbow→tool

Reads: chaining frames is multiplying their transforms, in order. This one line is robot forward kinematics, CAD assembly mates, and camera extrinsics — the same math wearing three badges.

T⁻¹ = | Rᵀ  −Rᵀ·t |
      | 0     1   |

Reads: the inverse comes for free — transpose the rotation, back out the translation. For the example above, −Rᵀ·t = (0, 1, 0). Never call a general matrix inverter on a pose; the closed form is exact and cheaper.

d(p, q) = d(T·p, T·q)

Reads: "rigid" is the whole contract — distances and angles between points survive the transform. Two points 5.000 apart are 5.000 apart afterward, always. If your matrix doesn't keep that promise, it isn't a pose anymore (see below, because it will stop keeping it).

Where you meet it (2-4 concrete engineering situations, specific: bench, test stand, review board)

The robot cell, teach pendant in hand. Every industrial arm computes tool position by multiplying one transform per joint, base to flange, plus your tool offset on the end. A planar sanity check you can do on paper: link 1 at 0.5 m and 30°, link 2 at 0.3 m and another 45° relative — multiply the four transforms and the tooltip lands at (0.5107, 0.5398) m. When the arm plants a dowel 2 mm off, the debugging question is always which single matrix in that chain is lying: the DH table, the tool definition, or the work-object frame someone re-taught on night shift.

The test stand, laser tracker on a tripod. The tracker reports targets in its own frame; the article under test has a frame from tooling balls; the drawing has a third. Aligning them is solving for the rigid transform between point sets — the "best-fit" button in SpatialAnalyzer is computing exactly one T. When the fit residuals are small but everything downstream is skewed, somebody applied T where T⁻¹ belonged. It is the single most common alignment bug in a metrology lab.

The CAD assembly review. Every mate constraint in the model resolves to a transform between component frames, and "the bracket interferes with the harness in build 4 but not build 3" usually traces to one constraint that flipped a frame 180°. The reviewer asking "which coordinate system is that dimension in?" is asking which T you silently multiplied by.

The vision bench. A camera's extrinsic calibration is a rigid transform from world to camera frame. Hand–eye calibration — where is the camera relative to the robot flange — is solving A·X = X·B for an unknown pose X. If pick-and-place accuracy degrades after someone re-mounts the camera, the extrinsic T is stale, not the lens model.

How it works (the real substance — behavior, gotchas, limits of validity, the mistake people make)

The trick under the hood is homogeneous coordinates: a rotation is linear, but rotation-plus-translation is not — f(p) = R·p + t doesn't satisfy f(a+b) = f(a)+f(b). Append a 1 to every point and the affine map becomes linear one dimension up, so composition, inversion, and chaining all collapse into ordinary matrix algebra. That is the entire reason the 4×4 form won: not elegance, composability. The set of all such matrices is the special Euclidean group SE(3) — closed under multiplication, every element invertible, nothing else required.

Order is not optional. Rotating 90° about z then translating (0, 2, 0) puts the origin at (1, 2, 0); translating first puts it at (−1, 0, 0) (both verified numerically, with the rotation-transform carrying t = (1,0,0)). Same two operations, different answers. The practical version of this gotcha: post-multiplying T·ΔT moves you relative to the tool frame, pre-multiplying ΔT·T moves you relative to the base frame. Jog a robot in the wrong one and it walks off the fixture in a direction that looks insane until you realize both motions were "correct."

The rotation block rots. R must stay orthogonal with determinant +1, and floating point does not care about your constraints. Compounding 100,000 single-precision incremental rotations of 0.01° each left R·Rᵀ off identity by 3×10⁻³ and the determinant at 1.003 — the "rigid" transform is now quietly scaling your geometry by a part in three hundred. Any loop that accumulates poses needs periodic re-orthogonalization (SVD, or convert through a quaternion and back). This is also why odometry and SLAM stacks store orientation as a quaternion and build T on demand.

Point transform vs frame transform. T_A→B can mean "maps coordinates of a point from frame A to frame B" or "the pose of frame A expressed in frame B," and the two conventions are inverses of each other. Textbooks split roughly evenly. Nothing errors out; the part just gets machined mirror-wrong. Write the convention on the ICD, and unit-test one known point through every interface — the same discipline quaternion users learned about scalar-first versus scalar-last.

What it can't do. A rigid transform has exactly six degrees of freedom — three rotation, three translation. No scaling, no shear, no reflection (det = −1 is a mirror, and a mirrored R means your point cloud registration matched a part to its enantiomer — it happens with symmetric parts). Deformable bodies, thermal growth, and fixture compliance all violate the rigidity assumption; a laser-tracker best-fit over a structure that sagged between measurements will split the sag into fake rotation and fake translation rather than flag it. Check residuals, not just the fit.

The screw view. Chasles' theorem says any rigid displacement, however messy, equals one rotation about some axis plus a slide along that same axis — a screw motion. That is why smooth interpolation between two poses (for a robot path or an animation) is done along the screw, not by interpolating matrix entries, which produces a path that is neither rigid nor straight.

History (who derived it and when, told as a short story with inline [n] citations)

The rotation half came first. Euler presented the result in St. Petersburg in October 1775: any motion of a rigid body about a fixed point is a single rotation about some axis — published the next year as Formulae generales pro translatione quacunque corporum rigidorum ^[1]^[2]. The title says "translatione," and the paper indeed handles general displacement, but the theorem everyone kept is the fixed-point one.

The full statement — rotation plus translation, and the two can share an axis — has a disputed byline. Giulio Mozzi, a Florentine, proved in 1763 that a rigid body's instantaneous motion is a rotation about an axis combined with a slide along it; Italians still call the screw axis the asse di Mozzi ^[3]^[4]. Michel Chasles published the version textbooks cite in 1830, sixty-seven years later, and the theorem carries his name almost everywhere else ^[3]^[5]^[11]. Robert Stawell Ball built the idea out into a full mechanics of screws in 1876, which is where modern spatial-mechanism analysis gets its twists and wrenches ^[5]^[12].

The packaging is separate history. Homogeneous coordinates — the trailing 1 that makes translation a matrix — come from August Ferdinand Möbius's 1827 Der barycentrische Calcul, where points were centers of mass of weighted triangle vertices ^[6]^[7]. The pieces sat apart for over a century until two Northwestern University mechanism researchers, Jacques Denavit and Richard Hartenberg, published a 1955 ASME paper showing that any chain of joints and links could be described by multiplying 4×4 matrices built from four parameters per link ^[8]^[9]. Their notation was aimed at linkages; robotics adopted it wholesale after Richard Paul's 1981 MIT Press book made homogeneous transforms the working language of manipulator control ^[8]^[10]. Every DH table in every robot datasheet today is that 1955 paper, unretired.

Related tools (bullet list of HE calculator slugs that use or neighbor this topic, as /tools/ links)

/tools/convert-angle — joint angles arrive in degrees from the pendant and leave in radians for the math; convert at the boundary, once
/tools/convert-length — the translation vector and every point must share one unit system, or the pose is confidently wrong by a factor of 25.4
/tools/gear-ratio — the drivetrain between the encoder and the joint angle that feeds each transform in the chain
/tools/moment-of-inertia-shapes — the dynamics that take over once the kinematic chain tells you where the mass ended up

Sources

Written by HE in our own words from the cited sources — engineering judgment included, your stamp still required. All entries →