Section 5.4: Robot arms, joints, the kinematic chain

A Careful Control Loop

This section develops the technical contract for Robot arms, joints, the kinematic chain 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 in Robot arms, joints, the kinematic chain 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

For Robot arms, joints, the kinematic chain, 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.

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.

This is why joint ordering and frame naming are not administrative details. 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.

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 section useful to students, builders, and researchers at the same time: 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, 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.