Section 5.4: Robot arms, joints, the kinematic chain

"Each joint buys you one freedom and sells you one responsibility. The chain collects both debts."

An Arm Assembler

Six revolute joints, each free to swing a few hundred degrees, multiply into a configuration space so vast that a robot arm can reach the same point three ways: elbow up, elbow down, or wrist flipped through the middle. One thing stands between that freedom and a crashed gripper: a strict accounting of how each joint feeds the next. This section builds that accounting into a usable mental model. First we define the object of study, then we connect it to the agent loop, then we test it with a compact implementation.

The key question is practical: what must the agent know, what can it observe, what action is available, and what evidence shows that the action worked under the stated conditions?

Theory

Figure 5.4A shows the full picture this section builds toward: a 6-DOF arm with each joint labeled by type, its DH parameter table (a standard four-number-per-joint convention, link length, link twist, link offset, and joint angle, that fixes each joint's transform without ambiguity), and the resulting chain from base link to end-effector. The kinematic chain abstraction exists to solve a concrete mapping problem. A robot arm must map a high-level task goal, such as "place the gripper 30 cm above the conveyor," into specific motor commands for each of its joints. Without a systematic way to track how each joint rotation propagates through the structure, a planner would need to re-derive geometry from scratch for every configuration. The kinematic chain gives the agent a single composable model: multiply the transforms in order and you immediately know where every link and the end-effector sit in the world frame. This composability is what makes motion planning, workspace analysis, and closed-loop control tractable.

A six-joint arm needs 6 transform multiplications to reach any configuration. Without the chain, each query recomputes up to 36 frame relationships from scratch. A motion planner that samples 10,000 candidate configurations then runs that recomputation 360,000 times instead of 60,000 multiplications. The chain abstraction is therefore not a convenience but a prerequisite for real-time planning. Without the chain, embodied systems cannot reliably reason about reachability, avoid collisions, or hand off a grasp target to a controller.

The practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

The diagram above traces this structure concretely: a base frame, three links joined by two revolute joints and one prismatic joint, and an end-effector whose pose is the ordered product of every per-joint transform. A robot arm is a sequence of rigid links connected by joints. Each joint contributes one controlled motion, usually a rotation for a revolute joint or a translation for a prismatic joint. The kinematic chain is the ordered product of those link transforms, so a small upstream joint change moves every downstream frame. Counting joints tells you what the chain can reach at all: a full 6-DOF pose in 3D space (position plus orientation) typically needs at least six independent joints, which is why most industrial arms carry six or seven revolute joints rather than three or four.

Why joint type shapes the workspace

That ordered product is identical in form for every joint, but the shape of the reachable space it carves out depends entirely on what kind of motion each joint contributes. Joint type matters for embodied AI because it determines the workspace geometry and the actuator hardware. A revolute joint sweeps a circular arc, so its reach depends on the arm's posture; stacking multiple revolute joints produces the curved, dexterous workspaces seen in industrial arms. A prismatic joint translates linearly, offering direct, predictable reach extension but limited angular coverage. Choosing the wrong joint type for a task (for example, a prismatic wrist trying to reorient a screwdriver) forces awkward compensations across the entire chain, often pushing the arm toward singularities (configurations where the arm loses a degree of freedom in task space, covered fully in section 5.7) or joint-limit boundaries in real operation.

Before reading on, consider this: if you swap the order of just two joints in the kinematic chain description while leaving the physical arm unchanged, where does the end-effector end up, and does any error get raised?

Mechanically, a revolute joint pivots two links about a shared axis on a bearing, and its encoder (the sensor that reports the joint's current angle or position back to the controller) reads the swept angle. A prismatic joint slides one link along another on a rail, and its encoder reads linear displacement. The chain model abstracts both as a single bounded degree of freedom and treats them identically in the transform product; only the column of the homogeneous matrix that the joint variable updates differs.

This is why joint order is load-bearing geometry, not an administrative detail. If the URDF frame tree, the controller's joint vector, and the planner's joint vector disagree by one index, the end-effector pose can look plausible while the physical arm moves the wrong link. A kinematic chain that reaches the right pose for the wrong reason is not a solution: it is a failure waiting for a different target.

Worked Example

The example builds a 3-link planar chain as an ordered product of per-joint transforms, records every intermediate link frame, then perturbs one joint and verifies the topology invariant: moving joint \(k\) must displace link \(k\) and all its descendants, and nothing upstream.

import numpy as np

def Tz(theta, length):
    """Revolute joint about z, then translate 'length' along local x."""
    c, s = np.cos(theta), np.sin(theta)
    return np.array([[c, -s, 0, length*c],
                     [s,  c, 0, length*s],
                     [0,  0, 1, 0],
                     [0,  0, 0, 1]])

lengths = [0.30, 0.25, 0.15]   # link lengths, base -> tool

def chain_frames(q):
    T = np.eye(4)
    frames = [T[:3, 3].copy()]          # base origin
    for qi, Li in zip(q, lengths):
        T = T @ Tz(qi, Li)
        frames.append(T[:3, 3].copy())  # each downstream link origin
    return np.array(frames)

q0 = np.deg2rad([20, -35, 50])
F0 = chain_frames(q0)

# Perturb ONLY joint index 1 (the middle joint)
q1 = q0.copy(); q1[1] += np.deg2rad(10)
F1 = chain_frames(q1)

moved = np.linalg.norm(F1 - F0, axis=1) > 1e-9
print("frame moved? (base, link0, link1, link2):", moved.tolist())
print("tool pose:", np.round(F0[-1], 4))
assert not moved[0] and not moved[1], "upstream frame moved: joint order bug"
assert moved[2] and moved[3],         "downstream frame frozen: chain broken"
print("topology invariant holds: only joint-1 descendants moved.")

The assertions are the cheap diagnostic that catches a one-index mismatch between the URDF, the controller joint vector, and the planner: when an upstream frame moves under a downstream perturbation, the chain ordering is wrong even if the tool pose looks plausible.

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Production Pattern

Robot arms, joints, the kinematic chain sits inside the Part II robotics contract: geometry defines where things are, kinematics defines what motion is possible, dynamics defines what motion costs, control defines how errors are corrected, and sensing defines what the agent can know on time.

Separate joint topology, joint limits, link frames, and end-effector task frames before solving motion. This makes the treatment useful to practitioners, builders, and researchers alike: the idea has an intuitive role, a formal interface, a runnable check, and a failure mode that can be reproduced.

Use this recipe when turning Robot arms, joints, the kinematic chain into code, a simulator experiment, or a robot diagnostic. The point is not to use every library. The point is to keep the hand-built baseline and the maintained-tool path comparable.

1. Write the joint vector, frame target, velocity convention, and constraint set before solving.
2. Check forward kinematics on a known posture, then perturb one joint and inspect the end-effector delta.
3. Compare an analytic or numerical Jacobian with Pinocchio, Robotics Toolbox, or Drake on the same robot model.
4. Log residual error, joint-limit distance, manipulability (a scalar measure of how easily the end-effector can move in every direction from the current posture, near zero at a singularity), and solver iteration count in one artifact.
5. Treat singularities and infeasible targets as design signals, not as solver annoyances.

Kinematic failures often arrive as a plausible pose with an impossible motion. Inspect joint order, parent-child frames, link lengths, joint limits, and mimic joints before blaming the planner. For this section, first reproduce one two-link chain by hand, then rerun it through Pinocchio, Robotics Toolbox for Python, MoveIt 2, Drake, or ROS 2 tf2. If the two disagree, inspect conventions and timing before changing the model.