Industrial Robots and Cobots in Practice

How industrial robots are programmed and run: teach pendants, the tool center point, vendor languages such as RAPID, KRL and URScript, offline programming, the robot cell, and the PLC around it.

The robot system

An industrial robot on a factory floor is never just the arm. It is a system of three parts:

  • The manipulator: the arm itself, usually six joints driven by servo motors with encoders and gearboxes.
  • The controller: a cabinet (or, for small robots and cobots, a compact control box) with the computer that runs the robot program and the kinematics, the motor drives, the safety controller and the I/O connections.
  • The teach pendant: the handheld unit used to move the robot by hand and to write and test programs.

A collaborative robot, or cobot, has the same three parts, packaged lighter: a smaller arm that senses contact forces (with joint torque sensors, motor currents or a force sensor at the flange), a small control box and a tablet as pendant. The difference that matters is in the application, not the label: ISO 10218-2:2025 no longer uses the term "collaborative robot" at all and speaks only of collaborative applications, whose safety is assessed as a whole (see Robot Safety and Standards). A cobot holding a knife is not safe to share a bench with.

The teach pendant

A teach pendant is the handheld control unit of an industrial robot, connected to the controller, used to jog the robot, record positions and write, test and run programs. It always carries an emergency stop button and an enabling switch: a three-position switch that must be held in its middle position for the robot to move in manual mode, and that stops it when it is released or squeezed hard, the natural reaction in a panic.

With the pendant a programmer:

  • Jogs the robot: joint by joint, or moving the tool along the axes of the base frame or the tool's own frame (see Coordinate Frames and Transforms).
  • Teaches positions: moves the tool to a point and stores it in the program. This is where the name comes from.
  • Tests a program step by step, then at reduced speed, before it ever runs in automatic mode.

The pendant is also the first place to look when a robot stops: the controller's messages (a collision detected, a joint limit, a safety input open, a lost signal from the PLC) appear there, with a message number to look up in the vendor manual. Write down the number and text before acknowledging it — after a reset the evidence is gone.

The tool center point

The tool center point (TCP) is the working point of the tool mounted on the robot — the tip of a welding torch, the center between gripper fingers, the nozzle of a glue gun — defined as an offset and orientation relative to the robot's flange. All programmed positions and speeds refer to the TCP, not to the flange. (In this topic TCP always means the tool center point, not the network protocol.)

The controller computes where the TCP is from the flange pose (from the joint angles, by forward kinematics) and the tool offset:

\mathbf{p}_{\text{TCP}} = \mathbf{p}_{\text{flange}} + R_{\text{flange}}\,\mathbf{t}_{\text{tool}} 
import math


def rot_y(degrees):
    a = math.radians(degrees)
    return [[math.cos(a), 0.0, math.sin(a)],
            [0.0, 1.0, 0.0],
            [-math.sin(a), 0.0, math.cos(a)]]


def tcp(flange_position, flange_rotation, tool_offset):
    """TCP in the base frame = flange position + rotated tool offset."""
    return [round(flange_position[i]
                  + sum(flange_rotation[i][j] * tool_offset[j] for j in range(3)), 3) + 0.0
            for i in range(3)]


flange = [0.600, 0.100, 0.500]     # meters, in the robot base frame
gripper = [0.0, 0.0, 0.150]        # TCP is 150 mm out along the flange's z axis

print("tool straight down:", tcp(flange, rot_y(180), gripper))
print("tilted 30 degrees: ", tcp(flange, rot_y(150), gripper))
tool straight down: [0.6, 0.1, 0.35]
tilted 30 degrees:  [0.675, 0.1, 0.37]

Why it matters: when the program says "turn the tool 30 degrees about its tip", the controller rotates about the configured TCP. If the configured TCP is off by a few millimeters, the real tip swings on a small circle around it and misses. The shift is the chord of that circle, 2e\sin(\alpha/2) for an error e and a rotation \alpha: 

import math

error_mm = 2.0     # the configured TCP is 2 mm away from the real tool tip

for angle in (10, 30, 60, 90):
    # Rotating about the configured TCP swings the real tip on a circle.
    shift = 2 * error_mm * math.sin(math.radians(angle) / 2)
    print(f"reorient {angle:2d} deg: real tip moves {shift:.2f} mm")
reorient 10 deg: real tip moves 0.35 mm
reorient 30 deg: real tip moves 1.04 mm
reorient 60 deg: real tip moves 2.00 mm
reorient 90 deg: real tip moves 2.83 mm

Controllers therefore have a TCP calibration routine: the programmer touches one fixed point with the tool tip from several different orientations, and the controller computes the offset that is consistent with all of them. Redo it after a crash, after a tool change, and whenever reorientations start to wander.

Motion instructions

Every robot language has the same handful of motion types:

  • Joint move (MoveJ, PTP, J): each joint goes to its target angle, all arriving together. Fast and kind to the mechanics, but the path of the tool in space is a curve you did not choose — fine in free space, risky near obstacles.
  • Linear move (MoveL, LIN, L): the TCP travels in a straight line at a programmed speed. Needed for approaching a part, welding a seam or inserting a pin; the controller solves inverse kinematics along the way and stops with an error if the line passes a singularity or out of reach.
  • Circular move (MoveC, CIRC, C): an arc through an intermediate point.
  • Zones or blending: whether the robot stops exactly at a point (fine) or rounds the corner to the next move without stopping. Blending saves cycle time; stopping is needed where the position must be exact, such as at a pick.

Speeds and accelerations follow the trapezoidal profile, so a cycle time can be estimated before the cell exists — which is often the first question a customer asks:

t = \frac{d}{v_{\max}} + \frac{v_{\max}}{a_{\max}} \quad \text{(if } d \ge v_{\max}^2/a_{\max}\text{)}, \qquad t = 2\sqrt{d/a_{\max}} \quad \text{(otherwise)} 
import math


def move_time(distance, v_max, a_max):
    """Time for a point-to-point move with a trapezoidal velocity profile."""
    if distance >= v_max ** 2 / a_max:          # reaches full speed
        return distance / v_max + v_max / a_max
    return 2 * math.sqrt(distance / a_max)      # triangular: never at full speed


# One pick-and-place cycle: (description, meters, max m/s, max m/s^2)
moves = [
    ("down to the part", 0.10, 0.5, 2.0),
    ("up again", 0.10, 0.5, 2.0),
    ("transfer to the box", 0.80, 1.5, 4.0),
    ("down into the box", 0.10, 0.5, 2.0),
    ("up again", 0.10, 0.5, 2.0),
    ("back to the conveyor", 0.80, 1.5, 4.0),
]
GRIP = 0.3   # seconds to close or open the gripper

total = 2 * GRIP
for name, d, v, a in moves:
    t = move_time(d, v, a)
    total += t
    print(f"{name:21} {t:.2f} s")
print(f"cycle time            {total:.2f} s")
print(f"parts per hour        {3600 // total:.0f}")
down to the part      0.45 s
up again              0.45 s
transfer to the box   0.91 s
down into the box     0.45 s
up again              0.45 s
back to the conveyor  0.91 s
cycle time            4.21 s
parts per hour        856

Real cycles are slower: the controller's own speed limits, wrist reorientations, waiting for the PLC and settling time all add up. A simple estimate like this is a lower bound and a sanity check, not a quotation.

Vendor languages

Each robot maker has its own programming language, tied to its controller. The ideas are the same; the syntax, units and conventions differ. The main ones, as of October 2026:

  • RAPID is ABB's robot programming language, a structured text language with modules, procedures, typed data (positions, tools, speeds) and motion instructions such as MoveJ and MoveL. It runs on ABB controllers such as OmniCore.
  • KRL (KUKA Robot Language) is KUKA's robot programming language, a structured text language with motion commands such as PTP and LIN and system variables for speeds and I/O. KUKA's iiQKA.OS2 operating system (launched in 2025) offers what KUKA calls "Advanced KRL" and combines "the proven core of the KUKA System Software (KSS)" with newer features; its controllers include the KR C5 and KR C5 micro.
  • FANUC robots run TP programs (teach pendant programs, a line-numbered instruction list edited on the pendant) and KAREL, a Pascal-like language for more complex logic. FANUC's R-50iA controller can also run Python scripts "called from the robot's TP program or from a KAREL program" (FANUC, January 2025).
  • URScript is Universal Robots' script language, which UR describes as "a python-based script language"; most users program UR cobots graphically in PolyScope 5 or its successor PolyScope X (which needs the CB5.6 control box), and the graphical program runs as URScript underneath.
  • INFORM is Yaskawa's (Motoman) robot language, edited on the pendant, including Yaskawa's Smart Pendant.

The same small task — move above a part, go down in a straight line, close the gripper, go back up — in four of them. None of these controllers are available on the machine that checks this site, so the blocks are illustrative; the exact syntax depends on the controller version. 

MODULE PickDemo
  ! positions in mm; orientation as a quaternion (here: tool pointing down)
  PERS tooldata tGripper := [TRUE, [[0, 0, 150], [1, 0, 0, 0]],
                             [0.8, [0, 0, 60], [1, 0, 0, 0], 0, 0, 0]];
  CONST robtarget pAbove := [[400, 0, 300], [0, 0, 1, 0], [0, 0, 0, 0],
                             [9E9, 9E9, 9E9, 9E9, 9E9, 9E9]];

  PROC main()
    MoveJ pAbove, v500, z50, tGripper;                    ! joint move
    MoveL Offs(pAbove, 0, 0, -100), v100, fine, tGripper; ! 100 mm straight down
    SetDO doGripper, 1;                                   ! close the gripper
    WaitTime 0.5;
    MoveL pAbove, v100, z10, tGripper;                    ! back up
  ENDPROC
ENDMODULE
DEF pick_demo()
  ; positions in mm, angles in degrees
  DECL FRAME above, down
  above = {X 400, Y 0, Z 300, A 0, B 90, C 0}
  down = {X 400, Y 0, Z 200, A 0, B 90, C 0}

  BAS(#INITMOV, 0)        ; default speeds and accelerations
  PTP above               ; joint move
  $VEL.CP = 0.1           ; path speed for linear moves, m/s
  LIN down                ; straight down
  $OUT[1] = TRUE          ; close the gripper
  WAIT SEC 0.5
  LIN above               ; back up
END
   1:J P[1] 50% FINE    ;
   2:L P[2] 100mm/sec FINE    ;
   3:  DO[1]=ON ;
   4:  WAIT   0.50(sec) ;
   5:L P[1] 100mm/sec CNT50    ;
def pick_demo():
  # poses in meters; orientation as a rotation vector in radians
  above = p[0.400, 0.000, 0.300, 0.0, 3.1416, 0.0]
  movej(above, a=1.2, v=0.5)                                     # joint move
  movel(pose_trans(above, p[0, 0, 0.100, 0, 0, 0]), a=0.5, v=0.1)  # 100 mm down the tool axis
  set_digital_out(0, True)                                       # close the gripper
  sleep(0.5)
  movel(above, a=0.5, v=0.1)                                     # back up
end

Things to notice:

  • Units differ. ABB, KUKA and FANUC programs use millimeters and degrees for positions (KUKA's path speed $VEL.CP is in m/s, as in the example); URScript uses meters and radians, like ROS. Mixing them up is a classic, and dangerous, mistake.
  • Orientation is written differently: a quaternion in RAPID, three angles A, B, C in KRL, a rotation vector in URScript (see Coordinate Frames and Transforms). The same physical orientation has a different set of numbers in each.
  • FANUC TP stores positions separately: P[1] and P[2] are taught on the pendant; the program only refers to them.
  • I/O is just numbered signals: doGripper, $OUT[1], DO[1] and digital output 0 only mean "gripper" because someone wired and documented them that way.

Robotics skills are mostly certified per vendor (FANUC, KUKA, ABB, Universal Robots); vendor-neutral options such as SME's Robotics in Manufacturing Fundamentals exist but are not an industry-wide standard (as of October 2026).

Offline programming

Offline programming is writing and testing robot programs on a computer, in a 3D simulation of the robot and its cell, instead of teaching them on the real robot. The production line keeps running while the next program is being made; paths can be generated from CAD (computer-aided design) data (a weld seam, a glue track) instead of being taught point by point; and reach, collisions and cycle time are checked before anything is built (see Simulation and Digital Twins).

Each vendor has its own tool. ABB describes RobotStudio as "the world's most popular offline programming and simulation tool"; KUKA calls KUKA.WorkVisual its "engineering suite", and iiQKA.OS2 includes a complete virtual robot controller. Vendor-independent tools such as RoboDK can generate programs for several brands.

The catch is the difference between the model and reality. A part or fixture that is 3 mm away from where the CAD drawing has it makes every offline point 3 mm wrong. In practice an offline program is calibrated to the real cell — by measuring a few reference points on the fixture with the real robot and shifting the work-object frame — and then touched up on the pendant at reduced speed.

Programming by demonstration

Programming by demonstration is teaching a robot a task by showing it rather than writing it: a person guides the robot (or a teleoperated copy of it) through the motion, and the robot records and reproduces it. On cobots the common form is hand guiding or lead-through: the operator presses a button on the arm and pulls the tool to each position, and the cobot stores the points. It makes simple pick and place jobs quick to set up, also for people who never wrote a line of RAPID.

Recorded points still need cleaning up: hand-guided paths are shaky, and the program needs proper approach moves, speeds and error handling around them. The research version of the same idea — learning a whole skill from many teleoperated demonstrations — is imitation learning, on AI in Robotics.

The robot cell

A robot cell is the complete working unit around one or more robots: the robot itself, its tool, the fixtures and conveyors it works with, the sensors, and the guards and safety devices that keep people out of harm's way while it moves. The international safety standard for this level, ISO 10218-2:2025, is titled "Industrial robot applications and robot cells".

Top view of a robot cell. A guard fence surrounds a robot whose reach is shown as a dashed circle, a fixture, and the inner end of a conveyor that leaves the cell on the right. On the left the fence has an opening to a loading station, protected by a light curtain. At the bottom the fence has an interlocked door. Outside the cell, a PLC is connected to the robot controller. guard fence light curtain load interlocked door robot reach fixture conveyor PLC controller I/O
A typical cell: people load parts from outside through a light curtain; the robot works inside the fence; maintenance enters through an interlocked door that stops the robot when opened. The PLC outside coordinates the cell with the rest of the line.

Typical safety devices in a cell, and what they do:

  • Fixed guards (fences) keep people out of the robot's reach.
  • Interlocked doors stop the robot safely when opened.
  • Light curtains and laser scanners detect a person entering a zone and slow or stop the robot.
  • Emergency stops on the pendant, at the doors and at the operator stations.
  • Safety functions in the controller: limits on speed, force and the space the robot may enter, monitored by a certified safety controller.

How these are chosen and validated — risk assessment, the 2025 standards, collaborative applications — is the subject of Robot Safety and Standards.

The PLC around the robot

In a production line, the robot is rarely in charge. A programmable logic controller (PLC) runs the line and treats the robot controller as one station: it tells the robot which program to run and when, and the robot reports back. They exchange signals over hard-wired I/O or an industrial network such as PROFINET or EtherNet/IP. A typical handshake for one cycle:

Step Signal Direction
1 Robot ready, in automatic mode, at home position robot → PLC
2 Program number (which product) and "start" PLC → robot
3 Part picked; "clear of the conveyor" robot → PLC
4 Conveyor indexes the next part PLC (to the conveyor)
5 Cycle done, or an error code robot → PLC

Signals like "clear of the conveyor" are interlocks between machines that prevent collisions; they are part of the program logic. Safety signals that protect people (emergency stop, door, light curtain) run separately, over safety-rated circuits or safety protocols, to the robot's safety controller. When a robot "waits for nothing", the cause is usually a handshake signal that never came: the I/O screen on the pendant and the PLC's diagnostics show which one.

ROS 2 and industrial robots

Industrial robots traditionally run only their vendor's language, but more and more vendors provide ROS 2 drivers so that research tools such as MoveIt can plan their motions. As of October 2026 there are official drivers on GitHub from Universal Robots (Universal_Robots_ROS2_Driver, with branches up to Lyrical), FANUC (fanuc_driver, for Jazzy), KUKA (kuka_drivers, for iiQKA.OS2 and for KSS through RSI) and Yaskawa (motoros2). For ABB there are only community drivers, not an official ABB repository. Universal Robots' PolyScope X even runs a ROS 2 layer inside the controller; it moved from Humble to Jazzy in version 10.13 (May 2026).

ROS-Industrial, an open-source project with consortia in the Americas, Europe and Asia-Pacific, brings vendors, research institutes and users together around these drivers and offers training courses. In a typical installation the vendor controller remains responsible for motion execution and safety; ROS 2 sends it goals or paths.

Security of robot controllers

A robot controller on a factory network is an OT asset like a PLC, and is protected the same way (see OT Security Fundamentals and IEC 62443). The 2025 editions of ISO 10218-1 and -2 added cybersecurity requirements — recognition that a changed program or a changed safety setting is a safety problem, not only an IT problem.

Defensive basics for a robot cell:

  • Put robot controllers in their own network zone, reachable only from the PLC and the engineering workstations that need them.
  • Change default passwords and use the controller's user levels: operators run programs, only programmers change them, and only designated people change safety configuration.
  • Control remote access for vendor support: on request, time-limited and logged.
  • Back up programs and configuration, including the safety configuration, and compare them with the backup after every change: an unexplained difference is an incident to investigate.