Kinematics & Motion

Start with the anatomy. A robot arm is a chain of rigid links connected by joints. On an industrial arm every joint is revolute - it rotates - and each contributes one degree of freedom (DOF): one independent way the arm can move. Six joints, six degrees of freedom. That number is meaningful: to fully place a rigid tool in space you need exactly six values - three for position (x, y, z: where the tip is) and three for orientation (how the tool is rolled, pitched and yawed - which way it points and how it is twisted). Six DOF, six numbers, a perfect match.

The set of all joint-angle combinations is called joint space; the set of all tool positions-and-orientations is Cartesian space or tool space. You design and think in tool space ("tip here, angle this"); the robot lives in joint space ("A1 = 45 degrees, A2 = -30..."). Everything in this lesson is about moving between those two spaces. The tool position-plus-orientation together is called a pose or a frame - remember it always carries orientation, not just a point. A drill wants to hit a coordinate; a milling tool wants that coordinate AND the right tilt, and orientation is exactly what the extra wrist axes buy you. This is also why the six-DOF arm beats a 3-axis machine for so much architectural work: a router on a gantry can only ever point straight down, but an arm can present the same bit to the same point at any tilt, reaching undercuts and sculpting surfaces a fixed spindle never could.

There are two directions of translation. Forward kinematics goes from joint angles to tool pose: given all six angles, where exactly is the tip and which way does it point? This is the easy direction - there is exactly one answer, computed directly from the arm's geometry. If you jog each joint to a known angle, the controller always knows precisely where the tool ended up.

Inverse kinematics (IK) goes the other way, and it is the one that matters for fabrication: given the tool pose you WANT, what six joint angles achieve it? This is hard, because there is usually more than one solution - the classic 'elbow-up or elbow-down' choice, and often eight or more valid configurations reach the same tool pose. The controller must pick one, avoid flipping between them mid-path, and respect joint limits. When people say a path 'won't solve' or the robot 'can't reach that orientation', they mean inverse kinematics found no valid joint set. You will not compute IK by hand - the controller and your offline software do it every step - but knowing that the wanted pose maps to several joint solutions, and sometimes none explains most robot surprises.

The tool centre point (TCP) is the single most important setting on a fabrication robot. It is the exact point - and orientation - that the robot actually controls: the tip of the router bit, the nozzle of the extruder, the centre of the gripper's grasp. Out of the box, a robot controls its bare flange (the wrist face); you must tell it where your tool's working point sits relative to that flange - so many millimetres out, so many across, twisted so far. That definition is the TCP.

Why it is everything: all your commanded poses are TCP poses. Define the TCP correctly and "move to this point on the panel" puts the actual bit tip there. Define it 5 mm short, or at the wrong angle, and every single move is off by that error - the arm will happily and precisely mill 5 mm too deep across the whole job. Worse, a wrong TCP orientation makes the arm rotate around the wrong pivot, so a move you expected to keep the tip still instead swings it. TCPs are measured by a calibration routine (touching the tip to a fixed reference point from several angles) and stored per tool, so when you tool-change, the correct TCP loads with the tool. A worked feel: a spindle whose tip is 210 mm beyond the flange has a TCP offset of about 210 mm along the tool axis; get that number wrong and your depths and your pivot both lie.

Two things bound where and how an arm can move. Reach limits are the simple one: each joint has a rotation range, and combined they define the work envelope - poses outside it, or requiring a joint past its stop, simply cannot be reached. Singularities are subtler and more dangerous. A singularity is a pose where the arm momentarily loses a degree of freedom - classically when two wrist axes line up, so the maths would need a joint to spin infinitely fast to keep the tool moving smoothly. Near one, a gentle tool move can command a joint to whip round at alarming speed. Wrist singularities (axes 4 and 6 aligned), shoulder and elbow singularities are the common ones. You avoid them by planning paths that keep the arm in comfortable, well-articulated postures - and by simulating first, because good software flags a singularity before you ever run.

How the arm travels between poses is a deliberate choice too. A joint move (point-to-point, PTP) lets every joint rotate freely to the target - fast, but the tool sweeps an unpredictable curved path, fine for moving through open air. A linear move (LIN) forces the TCP along a straight line in space, which is what milling, welding, printing and cutting demand - the controller continuously solves inverse kinematics to keep the tip on the line, and this is exactly where reach and singularity trouble bites. Choosing PTP for rapids and LIN for process moves, while steering clear of singularities and limits, is the everyday craft of programming an arm.

One more idea makes robot programming click: everything is expressed relative to a coordinate frame, and a robot juggles several at once. The base frame (or world frame) is fixed at the robot's foot - the master reference. The tool frame rides at the TCP, moving with the tool, so 'advance 10 mm along the tool axis' means something even as the wrist tilts. And the work object frame (or user frame) is attached to the workpiece or its jig - you program the path relative to that.

Why this matters is entirely practical. Program a milling path in the work object frame and you can then move the jig anywhere in the cell, re-teach where that frame sits, and the whole path follows - no re-programming. Fixture the next identical part, and the same program runs. It is the robotics version of drawing relative to a datum rather than absolute coordinates. Frames also let you tilt the whole job: define the work object on an angled table and the path re-orients with it. A worked feel: you design a screen-carving path once in its own work object frame; to make ten of them at different stations you only tell the robot where each station's frame is - the six-axis motion regenerates itself for each. Getting frames straight - base for the cell, tool for the TCP, work object for the part - is what separates a program that survives a moved fixture from one that breaks the moment anything shifts. The offline software in the next lesson is largely a machine for managing these frames.