Treat geometry as typed, directional, time-dependent data

Robot kinematics relates joint configuration to link and end-effector pose without first solving forces or accelerations. Forward kinematics maps known joint positions to pose. Inverse kinematics searches for joint positions that realize a requested pose. Velocity kinematics uses a Jacobian to map joint rates to spatial or body velocity. These calculations look like matrix arithmetic, but production correctness depends on frame direction, units, conventions, topology, limits, time, and calibration.

In an interview, this topic shows up as a design question ("walk me through getting a pose from a vision system to a robot"), a debugging question ("the robot is accurate at the flange but wrong at the tip"), or a derivation question ("derive the Jacobian for a 2-link planar arm"). Interviewers probe for three things: whether you name frames before you multiply matrices, whether you know where the math breaks (singularities, unreachable targets, unit mistakes), and whether you treat a solved pose as a claim that still needs validation. A weak answer recites "FK is matrices, IK is the inverse" without ever mentioning that IK is a constrained search with multiple branches, or that a transform and its inverse are not interchangeable. A strong answer states its conventions up front — column vectors, right-handed, radians, metres — and then works a concrete example.

The kinematic chain: links, joints, degrees of freedom

A serial manipulator is a chain of rigid links connected by joints, anchored at a base frame and terminating at a tool or end-effector frame. Each one-degree-of-freedom joint — revolute or prismatic — contributes one coordinate to the configuration vector q. The configuration space of a six-joint arm is a subset of R^6 bounded by joint limits; its topology matters because a revolute joint with limits is an interval, not a circle, so two configurations that "look" adjacent in angle may be far apart in reachable space.

Degrees of freedom at the tool are not the same as joint count. A rigid body in space has six DOF (three translation, three rotation). A 6-joint arm can, at best, place the tool at a generic pose; a 7-joint arm is redundant and has a one-dimensional null space at almost every pose, which is an asset for limit avoidance and a source of ambiguity you must resolve with a policy. Parallel and closed-chain mechanisms add loop constraints that couple joints, so they cannot be treated as an unconstrained tree.

Interviewers probe here: "why does a 6-axis arm sometimes fail to reach a pose inside its workspace?" (branch limits, self-collision, singularity — not workspace boundary alone) and "what does the extra joint on a 7-axis arm buy you, and what does it cost?" A weak answer says redundancy means "more flexibility" without naming the null space or the need for a secondary objective.

Rigid-body transforms and coordinate frames

A pose is meaningful only relative to a frame. A transform is directional: a transform that expresses frame B in frame A is not interchangeable with its inverse. Name source and target frames, document active versus passive interpretation, column versus row vector convention, multiplication order, handedness, axis directions, and translation units. Compose transforms only when adjacent frames match: to go camera → base when you have camera → tool and base → tool, you compose (base→tool)⁻¹ · (camera→tool), and getting the direction wrong is the single most common interview whiteboard error on this topic.

Use a connected, acyclic transform tree (the tf2 model) rather than ad-hoc pairwise transforms, and query measurements at a coherent timestamp: the newest transform from each sensor can still describe mutually inconsistent times, and a robot moving at 1 m/s with 50 ms of sensor skew is 50 mm of unmodelled error. Homogeneous transforms combine rotation and translation in one 4×4 matrix while preserving composition and inversion semantics — the inverse of [R | t; 0 | 1] is [Rᵀ | −Rᵀt; 0 | 1], not [Rᵀ | −t; 0 | 1]. That last mistake is a classic follow-up probe: "what's wrong with negating the translation to invert a transform?"

Rotation representations and their trade-offs

Rotation matrices must remain orthonormal with determinant +1 (SO(3)); after repeated composition, floating-point drift breaks both properties, so renormalize or re-orthogonalize. Euler angles are useful at interfaces but depend on axis sequence — the same three numbers mean different rotations under XYZ vs ZYX — and contain coordinate singularities (gimbal lock), where a rotation about the locked axis becomes unobservable in the angles. Unit quaternions compactly represent orientation (four numbers, no sequence dependence) and avoid Euler lock, but q and −q represent the same rotation, so any comparison, averaging, or interpolation must first bring quaternions into the same hemisphere. Do not average rotations as ordinary component vectors; average in a rotation-aware way (quaternion averaging, or chordal L2 on the manifold) or you will average 179° and −179° into 0°.

A likely follow-up: "why do game engines and robot middleware both use quaternions internally but Euler at the UI?" A weak answer says "quaternions avoid gimbal lock" and stops; a strong one adds the double cover, the hemisphere problem, and that slerp gives constant-angular-velocity interpolation while Euler interpolation does not.

Forward kinematics and its derivation

Forward kinematics follows the robot's joint graph, fixed origins, axes, and current configuration: given q, compute T_base_tool(q) as a product of per-joint transforms. Two standard derivations exist. Denavit–Hartenberg assigns each link a frame by rule (four parameters per joint: link length a, twist α, offset d, angle θ) and multiplies A-matrices; it is compact but the frames are unintuitive and the parameter assignment itself is error-prone. The product-of-exponentials formulation expresses each joint motion as a screw axis in the base frame and composes exponentials of se(3) elements: T(q) = e^{[S₁]q₁} ··· e^{[Sₙ]qₙ} · M, where M is the tool pose at zero configuration. PoE needs no link frames, uses only physically intuitive axes, and is what modern libraries (and URDF-style axis/origin descriptions) effectively encode. Both are valid when used consistently; mixing conventions mid-derivation is a guaranteed wrong answer.

A model format is not ground truth merely because it parses: joint axis sign, zero offset, link length, mimic relation, tool frame, and base mounting must match the actual machine. Validate model poses against independently measured configurations — a taught point that disagrees with the model by more than repeatability means the model is wrong, not the measurement.

The Jacobian is configuration-dependent: J(q) maps joint velocity to end-effector twist, and its transpose relates an end-effector wrench to generalized joint forces under stated conventions. Space and body Jacobians express twists in different frames and are related by the adjoint of the current pose. At a singularity, some Cartesian motion direction becomes unavailable or requires unbounded joint rate in an ideal inverse; near one, a pseudoinverse amplifies noise and demand. Monitor singular values or condition number, use damping (damped least squares) and speed limits, and choose a safe fallback. Interviewers probe: "derive the Jacobian for a 2-link planar arm" — the answer is a 2×2 matrix whose columns are the perpendiculars from each joint axis to the tip, and whose determinant vanishing is exactly the arm fully extended or folded, which is the singularity you should name unprompted.

Inverse kinematics is a constrained search

IK is not simply a matrix inverse. A target can be unreachable, have one solution, many branches, or infinitely many redundant solutions. A useful solver must define position and orientation error, tolerances, joint and velocity limits, collision constraints, seed and continuity preference, timeout, and failure semantics. Numerical methods (Jacobian pseudoinverse, damped least squares, nonlinear optimization) need well-scaled residuals and may converge to a local solution; analytic solvers still require branch filtering. Never execute a partial or stale answer as though it were a valid full solution.

Redundant manipulators can use null-space motion for joint-limit avoidance, posture, manipulability, or other secondary objectives while preserving the primary task locally. Priorities, weights, and constraints must be explicit because objectives can conflict. Differential IK handles incremental velocity commands but needs integration, bounds, singularity handling, and drift correction.

Branch selection is a policy, not an implementation detail

This is where a working cell turns into an unexpected collision. A six-axis arm typically offers up to eight closed-form solutions for a reachable pose — shoulder left or right, elbow up or down, wrist flipped or not — and every one places the same tool at the same point while sweeping a completely different volume. Choosing the branch nearest the current joint vector keeps motion continuous but can silently migrate the arm across configurations over a long program; choosing a fixed branch keeps the workspace predictable but fails outright when the target leaves that branch's reachable set. State the rule, log the branch actually taken with each solve, and treat a branch change during a taught path as an event requiring a collision re-check, not a routine solver outcome. Wrist singularities deserve the same treatment: when two axes become collinear, their individual values stop being determined even though the tool pose is well defined, so a naive nearest-solution rule can command a large, fast joint reversal to hold the tool still.

Units and small-angle arithmetic

Units cause more field failures than the mathematics does. Joint values arrive as encoder counts, degrees, or radians depending on the layer that produced them, and a single unconverted degrees-for-radians value is a factor of 57.3 that will still parse, still solve, and still command motion. Length has the same problem across millimetres and metres, and a tool-centre point entered in the wrong one is the classic cause of a robot that is accurate at the flange and wrong at the tip.

The magnitudes are unforgiving at reach. On a 1.5-metre arm, a tenth of a degree of unmodelled joint offset is about 2.6 millimetres at the tool (1.5 m × 0.1° × π/180 ≈ 1.5 × 0.001745 ≈ 2.6 mm), so a calibration residual that looks negligible in joint space can exceed the entire positional tolerance of the task. Carry units in the type where the language allows it, assert ranges at every boundary, and validate accuracy at the tool over the working envelope rather than near the base, where the same angular error is invisible.

Calibration and validation

Calibration closes the gap between nominal geometry and the physical system. Establish encoder zero, axis direction, joint offset, link parameters, base frame, tool-centre point, camera or sensor extrinsics, and timestamp alignment. Version model and calibration together — a model without its calibration version is unreproducible. Validate position and orientation over a spatially diverse set rather than a single pose, reserve holdout measurements, and separate repeatability (spread on re-visiting a taught point) from absolute accuracy (error against an external measurement), because a robot can repeat to ±0.02 mm and still be absolutely wrong by 3 mm.

Kinematics does not prove dynamic feasibility. A collision-free pose may demand impossible speed, acceleration, torque, braking distance, cable motion, or payload behavior. Motion planning, trajectory generation, collision checking, control, dynamics, and safety protection remain separate consumers and constraints. Review the complete path from requested target through frame resolution, IK, branch selection, planning, time parameterization, controller execution, measured state, and protective stop.

What to log and what to test

Record target and resolved frames, timestamps, model and calibration versions, seed, solver, tolerances, residuals, iterations, timeout, selected branch, minimum joint-limit and collision margins, Jacobian singular values or condition, commanded and measured joints, and failure reason. Test known analytic geometries, transform identities, finite-difference Jacobians against the analytic one, random reachable configurations, unreachable targets, frame and unit mistakes, joint-limit boundaries, singularities, multiple branches, stale transforms, calibration perturbations, and hardware motion at reduced speed before widening the envelope.