ISO 8373:2021 defines an industrial robot as “an automatically controlled, reprogrammable, multipurpose manipulator, programmable in three or more axes, which can be either fixed in place or mobile for use in industrial automation applications.” Pull that apart and you have the four properties that separate a robot from any other piece of factory automation:

The world had its first one in 1961 — the Unimate, a hydraulic polar-coordinate arm built by Unimation (George Devol & Joseph Engelberger) and installed at General Motors in Trenton, New Jersey, where it pulled hot die-cast parts and spot-welded them. Today, the IFR puts the global operational stock at 4.66 million industrial robots, with 542,000 new installations in 2024 alone.

A robot is a programmable manipulator. A cobot is one that can run in a collaborative mode. A mobile robot moves around. A service robot is anything else not bolted to a factory floor.

A six-axis articulated robot looks roughly like a human arm with a slightly weird wrist. From the ground up, you'll meet a base that rotates about the vertical (J1), a shoulder (J2) that lifts an upper arm (link 2), an elbow (J3) that bends a forearm (link 3), and a wrist cluster of three more rotational joints (J4, J5, J6) that orient the tool. At the very tip is the tool flange — a precision-machined face with a bolt circle that follows ISO 9409-1, the same on every brand so any gripper or torch with the matching pattern can bolt on.

The TCP — Tool Centre Point — is the actual point the robot is positioning. It's the “fingertip” you care about, not the flange.

When you tell a robot to move to (400, 200, 350) you're telling it to put the TCP there — not the flange. If you swap a 60 mm-long welding torch for an 80 mm-long sealant nozzle, every taught point becomes 20 mm off until you update the tool definition. This is why “TCP calibration” is the first practical task on any new tool.

Reach, payload, repeatability, accuracy

Robot designers don't pick joint layouts at random — each configuration is biased toward a particular kind of motion. SCARA is rigid vertically and compliant horizontally because that's how PCB insertion works. Delta is upside-down because keeping the motors still and the moving platform light is how you reach 100 g of acceleration. A 6-DOF articulated arm has the same joint count as a human arm because it solves the same general-purpose positioning problem.

A free rigid body floating in 3D space has six degrees of freedom: three translations (X, Y, Z) and three rotations (often called roll, pitch, yaw). That's why most industrial arms are 6-DOF — exactly enough to place the tool anywhere within reach, at any orientation.

ISO 9787:2013 defines the standard set: World(cell-level reference), Base (at the robot mounting surface), Mechanical interface (at the flange), and Tool(at the TCP). Every frame is built on the right-hand rule, with +Z pointing opposite to gravity. Every brand also adds a programmable work-object frame attached to whatever you're working on — a fixture, a pallet, a car body — so the whole program can shift with the workpiece without re-teaching anything.

How vendors name the same frames

Every industrial controller agrees on one thing: world coordinates are right-handed. +X points forward from the operator, +Y goes across to the operator's left, and +Z points up, always opposite to gravity. Hover the axes in panel A — the matching finger in the right-hand schematic lights up.

The same rule decides which way each joint rotates. Point your right thumb along the joint's axis (for a top-mounted base, that's +Z out of the page). Your fingers curl in the direction the controller calls positive. Panel B shows it live — pick J1 or J2, press Rotate + or Rotate −, and watch the gold curl-arrow match the right-hand rule.

Robotics math has been stable for fifty years. The names change between ABB, KUKA, FANUC, UR, Yaskawa, Kawasaki and Mitsubishi — the equations do not. When a brand says orientation drift, singularity, work-object shift or quaternion slerp, they are pointing at one of the eight cards below. Knowing the math is how you read a manual without getting lost in branded vocabulary.

Each card answers two questions: what does it do?— in plain English, no derivation — and when will you actually meet it?— the real teach-pendant button, error message or RAPID type where the formula shows its face. Filter by family (kinematics, orientation, motion & dynamics) if the grid feels dense.

T = ⎡ R  t ⎤
    ⎣ 0  1 ⎦

T₀ₙ = T₀₁(θ₁) · T₁₂(θ₂) · ⋯ · Tₙ₋₁,ₙ(θₙ)

q = IK(T_target)

Rᵀ R = I    det(R) = +1

R = R_z(γ) · R_y(β) · R_x(α)

q = (w, x, y, z)    ‖q‖ = 1

v = J(q) · q̇       det(J) → 0  ⇒  singularity

v(t):  accel ▲    cruise ─    decel ▼
   ∫ v dt = displacement

Forward kinematics is the easy direction. You know every joint angle (the encoders tell you), and you want to compute the position and orientation of the TCP in the base frame. It's deterministic, has exactly one answer, and is a small matrix multiplication.

Real industrial arms use Denavit–Hartenberg (DH) parameters— a 1955 convention for systematically attaching a reference frame to every joint and describing each link by four numbers (twist, length, offset, angle). Multiplying the per-link transformation matrices in order gives you the base-to-TCP transform. You don't need the math to use a robot — the controller does it 250+ times a second. You just need to know that the link lengths and joint offsets matter, and that swapping a gripper changes the tool offset, which changes the FK output.

IK is the hard direction. For a 6-DOF arm with a spherical wrist (three wrist axes meeting at one point — Pieper's condition) there is a closed-form solution with up to eight distinct joint configurations that reach the same TCP pose: two shoulder choices, two elbow choices, two wrist choices.

Production robots ship with a way to pin down which solution to use — ABB calls it confdata, KUKA stores STATUS and TURN integers, FANUC writes a “configuration string” like F U T, 0, 0, 0. Without it, the controller picks the nearest solution by default, which can flip the wrist 180° between two nearby waypoints and crash the robot into its own fixture.

Every robot vendor calls them slightly different names, but the three primitives are universal:

Vendor command names

MoveJ pHome, v1000, fine, tool0;
MoveL pPick, v500,  fine, tool0;
SetDO doGripper, 1;
WaitTime 0.5;
MoveL pHome, v1000, fine, tool0;

PTP XHOME
$VEL.CP = 0.5
LIN XPICK
$OUT[1] = TRUE
WAIT SEC 0.5
LIN XHOME

movej([0, -1.57, 1.57, -1.57, -1.57, 0], a=1.4, v=1.05)
movel(p[0.4, 0.0, 0.3, 0, 3.14, 0], a=1.2, v=0.25)
set_digital_out(1, True)
sleep(0.5)

Blending — rounding the corners

If a robot decelerates to a full stop at every taught point, cycle times suffer. Blending tells the controller it's allowed to round the corner — to start the next motion segment before the previous one has fully reached its target. You specify a tolerance radius around the corner waypoint; inside that radius the controller is free to interpolate.

Velocity profiles — trapezoidal vs S-curve

A motion segment isn't executed at one constant speed — the controller ramps up from zero, cruises, and ramps back down. The shape of the ramp matters. A trapezoidal profile has constant acceleration in each phase, which makes the time derivative of acceleration — jerk — go to infinity at the phase boundaries. The mechanical structure rings; the gripper shakes; precision parts settle slowly. An S-curve (or any jerk-limited polynomial) inserts smooth ramp-in / ramp-out phases for the acceleration itself, so jerk stays bounded.

A singularity is a robot pose where the Jacobian matrix — the linear map from joint velocities to TCP velocity — loses rank. The geometric consequence: a small movement of the TCP in a certain direction would require enormous joint speed. The real controller will saturate the joints, slow the path down dramatically, or refuse to execute the motion.

Without an end-effector the robot is just an expensive metronome. The five broad families:

Robot safety lives at the intersection of two ISO families. ISO 10218-1:2025 governs what the robot manufacturer must guarantee about the arm itself. ISO 10218-2:2025 governs what the integrator must do when wrapping it into a workcell. The 2025 revision folded in everything from the older ISO/TS 15066 on collaborative operation — the cobot biomechanical limits are now part of the headline 10218 standards.

Stop categories (IEC 60204-1 §9.2.2)

The four collaboration modes

Power-and-force-limiting thresholds (ISO/TS 15066 Annex A)

The numbers below come from the biomechanical study underlying ISO/TS 15066 (the University of Mainz pain-onset study + BG/BGIA force tolerance research). They are quasi-static limits — what a person can experience without injury during a clamping contact. Transient (dynamic impact, no clamping) limits are roughly twice these values for non-critical body regions. Skull and face contact must be prevented; the standard does not publish a “safe” force for them.

In a typical workcell the PLC is the master conductor — sequencing conveyors, fixtures, sensors, and the robot. The robot runs whatever program the PLC asks for, signals back when it's done, and waits for the next request. There's a textbook six-step handshake that ABB, KUKA, FANUC, UR, and Yaskawa all reduce to — only the signal names change.

How the major vendors name those signals

The PLC side of the handshake in Structured Text

On the PLC side you typically write a state-machine that drives the program-number bits, raises START, waits for BUSY, then waits for DONE. A CASE statement is the standard pattern — see the matching entry on the ST Language Guide (control-flow → CASE) and the Symbol Reference (TON timers for the wait-for-done watchdog).

(* PLC-side robot handshake. Mirrors the timing diagram above. *)
CASE State OF
  IDLE:
    IF NewJob THEN
      ProgNo  := JobNumber;        (* write program number bits *)
      State   := REQ_START;
    END_IF;

  REQ_START:
    Start := TRUE;                 (* raise edge on START output *)
    IF Robot_Busy THEN             (* robot acknowledged *)
      State := WAIT_DONE;
      WatchdogTimer(IN := TRUE, PT := T#30S);
    END_IF;

  WAIT_DONE:
    Start := FALSE;                (* drop START once Busy is high *)
    IF Robot_Done THEN
      State := CLEANUP;
    ELSIF WatchdogTimer.Q THEN
      State := FAULT;              (* robot took too long *)
    END_IF;

  CLEANUP:
    ProgNo := 0;
    WatchdogTimer(IN := FALSE);
    State := IDLE;

  FAULT:
    (* alarm, operator intervention *)
    ;
END_CASE;

Fieldbus options — what carries those signals