The bookkeeping problem
Imagine you are handed a six-joint robot arm and asked to write down its shape so a computer can predict where the gripper ends up. That sounds simple until you start counting: each joint sits at some distance from the next, each link is a certain length, each segment may be twisted relative to the one before it, and each motor turns by some angle. A six-joint arm has dozens of these little geometric facts. Without a discipline for recording them, two engineers will describe the same robot in two different ways — and their numbers will not agree.
What we want is a kinematic model: a faithful description, in numbers, of how the rigid pieces of a serial manipulator are connected. The trouble is that geometry has too much freedom. You could measure each link in your own arbitrary coordinate frame, place your reference axes wherever feels convenient, and end up with a correct-but-incompatible description. We need a convention — a shared rule for where to put the rulers and protractors — so that everyone, given the same robot, writes down the same table.
Four numbers per joint
The Denavit–Hartenberg recipe starts by attaching a coordinate frame to every link, with a strict rule: the z-axis of each frame points along its joint's axis of motion — the line a revolute joint spins about, or the direction a sliding joint travels. Once the z-axes are fixed, the convention places each x-axis along the common perpendicular between one joint axis and the next. That one rule is the whole trick: it pins down the frames so tightly that moving from one link's frame to the next takes only four parameters.
Those four parameters have plain physical meanings. Link length a is how far apart consecutive joint axes are, measured along the common perpendicular. Link twist α is the angle between consecutive joint axes — how much the next axis is tilted relative to this one. Link offset d is how far you slide along the joint axis to reach the next link's common perpendicular. And joint angle θ is the rotation about the joint axis. Picture walking from one joint to the next: you travel a along a bridge, twist by α, slide d up the post, and turn θ around it.
So the whole robot collapses into a small table: one row per joint, four columns for a, α, d, and θ. A six-joint arm becomes a tidy six-by-four grid. That table is the robot's geometric fingerprint — compact enough to email, precise enough to rebuild the math from scratch.
From a table row to forward kinematics
Each row of the table turns into a single homogeneous transformation — a 4×4 matrix that bundles a rotation and a translation into one object, so that multiplying it by a point's coordinates moves and reorients that point in one stroke. The four DH parameters slot directly into a fixed formula: two screw-like steps along and about the x-axis (using a and α), and two along and about the z-axis (using d and θ). Plug in the four numbers and you get the matrix that carries you from one link's frame to the next.
Now the chaining is beautifully simple. To find where the gripper sits in the base coordinate frame, you multiply the per-joint matrices together in order: base-to-joint-1, then joint-1-to-2, and so on out to the end. The product is one final 4×4 matrix giving the gripper's position and orientation. That multiply-them-all-together step is exactly forward kinematics: given the joint angles, compute where the hand is.
T_base_to_tool = A1 * A2 * A3 * A4 * A5 * A6 # Each A_i is the 4x4 transform built from one DH row: # A_i = RotZ(theta_i) * TransZ(d_i) * TransX(a_i) * RotX(alpha_i) # For a revolute joint, theta_i is the moving variable. # For a prismatic joint, d_i is the moving variable. # Multiply in order; the result gives the tool's pose in the base frame.
This is why the DH table is so valued: it is not just a way to write the robot down, but a recipe that hands you the forward-kinematics calculation for free. Change a joint angle, swap in the new θ, re-multiply, and you instantly know the new gripper pose.
Gotchas and modern alternatives
A first gotcha: which parameter moves depends on the joint type, and mixing this up silently breaks the model. For a revolute (rotary) joint the angle θ is the variable and d is a fixed constant; for a prismatic (sliding) joint the offset d is the variable and θ is fixed. Always label each row with its joint type before you start filling in numbers.
A second gotcha: there are two flavors of the convention. Classic (standard) DH and modified DH attach each link's frame at a different end and reorder the four steps in the matrix. Both are correct, but a table written in one flavor produces wrong answers if fed into software expecting the other. Always state which flavor a table uses.
DH parameters also struggle with parallel or nearly-parallel joint axes, where the common perpendicular becomes ill-defined and tiny measurement errors blow up. Partly for this reason, modern toolchains often skip hand-derived DH tables. Robots are increasingly described in URDF — an XML file that lists each link and joint with its full pose, no special axis rules required — or with screw-theory descriptions that assign each joint a motion axis directly in the base frame. These are easier to author, less error-prone, and play well with simulators and visualizers.