Collaborative Robots (Cobots): The Ultimate Guide

There is a stubborn myth in this industry that a "cobot" is a category of robot — a small, rounded, friendly arm you can buy and then, by virtue of having bought it, work safely beside a human. That myth has sold a lot of hardware and produced a lot of badly deployed cells. The reality is narrower and more useful: collaboration is a property of the application, established by a risk assessment, achieved through one of four safety-rated modes. The robot is just the enabling hardware.

This guide is the long version, written for the people who actually have to make the decision and sign off on the cell: the integrators, the controls engineers, the manufacturing engineers, and the safety engineers who own the risk assessment. We'll go through what "collaborative" really means under ISO 10218 and ISO/TS 15066, take power & force limiting (PFL) apart down to the biomechanical force tables, look at the joint hardware that makes contact sensing possible, cover force control and programming, and then get honest about deployment, applications, ROI, and product selection. Real numbers with units. Real products. Opinions with the reasons attached.

The take: A cobot is not inherently safe — it is a robot capable of being run in a collaborative mode, and whether your specific cell is safe depends entirely on the risk assessment of the robot, the end effector, the workpiece, the process, and the speed you actually run. The single biggest lie in cobot marketing is "no fencing required." Sometimes true, often not, and never something you get to assume. Buy the safety functions and the sensing, then earn the fence-free deployment with a CE-marked risk assessment — or accept that most "cobots" in production today run fenced, at full speed, as cheap, easy-to-program light industrial arms. Both outcomes are fine. Pretending they're the same thing is not.

Companion reading: industrial robot arms, robot actuators, robot sensors, and end effectors & grippers.

Table of contents

1. Key takeaways
2. What makes a robot "collaborative"
3. Cobot vs traditional industrial arm
4. The four collaboration modes (ISO 10218 / ISO/TS 15066)
5. Power & force limiting deep-dive
6. How cobots sense contact
7. Cobot joint hardware
8. Force control & compliance
9. Programming cobots
10. Risk assessment & deployment
11. Real applications & ROI
12. The 2026 cobot market & landscape
13. Selecting a cobot
14. Frequently asked questions

What makes a robot "collaborative"

Start with the definition, because almost everything that goes wrong downstream traces back to getting this wrong.

A collaborative operation is a state in which a purpose-designed robot system works in direct cooperation with a human within a defined collaborative workspace. That's the language of ISO 10218. Note what it does not say: it does not say "a robot under 10 kg payload," or "a robot with rounded edges," or "a robot you bought from a company that uses the word cobot in its marketing." Collaboration is a mode of operation in a defined workspace, validated by a risk assessment.

Safety rule: The robot is never certified "collaborative" on its own. The application — robot + end effector + workpiece + process + layout + speed — is what a risk assessment can declare collaborative. A cobot arm shipped from the factory is collaborative-capable, nothing more.

The UR origin story

The modern cobot starts in Odense, Denmark, in the mid-2000s. Three researchers — Esben Østergaard, Kasper Støy, and Kristian Kassow — founded Universal Robots in 2005 on a thesis that the robotics industry had it backwards: robots were powerful, fast, expensive, dangerous, and miserable to program, so they sat behind fences serving high-volume lines, and the vast middle of manufacturing — the small and medium shops doing short runs — couldn't justify them.

UR's bet was to invert every one of those properties. Make the arm light (the UR5 launched in 2008 at ~18 kg arm mass for a 5 kg payload). Make it slow enough to be safe. Make it programmable by a shop-floor operator with a 3D-graphical pendant instead of a robotics PhD. And — the killer feature — make it monitor its own forces so it could stop on contact, which under the right risk assessment meant it could run without a fence.

That last property is the one everyone fixated on, and it's the one most misunderstood. UR didn't invent a "safe robot." They built a robot with safety functions — force/torque monitoring, safety-rated speed and position limits — that an integrator could use to construct a safe application. The robot enabled collaboration. It did not guarantee it.

The myth that cobots are inherently safe

Here is the dangerous mental shortcut: "It's a cobot, so I can stand next to it." No.

A cobot running PFL at low speed with a smooth, rounded, lightweight payload and no pinch points is genuinely safe to touch — that's the design intent and it works. The same cobot moving 1,000 mm/s with a 5 kg steel fixture, or holding a deburring spindle, or carrying a sheet-metal blank with a 0.2 mm edge, is a hazard like any other robot. The arm hasn't changed. The application has.

Safety rule: Speed, payload, end-effector geometry, and workpiece hazards all leave the "collaborative" envelope independently. Any one of them can turn a collaborative-rated arm into a machine that needs guarding. Re-run the risk assessment whenever any of them changes.

The practical consequence: a huge fraction of installed cobots run guarded — behind light curtains, area scanners, or physical fencing — at or near full speed, used purely as cheap, fast-to-deploy, redeployable light industrial robots. That is a completely legitimate use. It is just not "collaborative operation," and calling it that muddies the risk assessment.

Cobot vs traditional industrial arm

The honest framing is a set of tradeoffs, not a winner. For the full treatment of conventional six-axis arms, see the industrial robot arms guide. Here's how the two classes actually differ.

Attribute	PFL cobot (e.g. UR10e, FANUC CRX-10iA)	Industrial arm (e.g. FANUC M-10iD, ABB IRB 1300)
Payload (typical class)	3–30 kg	5–1,300 kg
TCP speed, collaborative mode	250–1,000 mm/s	n/a
TCP speed, full / guarded	1,000–2,000 mm/s (cobot guarded)	2,000–8,000+ mm/s
Repeatability	±0.03–0.10 mm	±0.02–0.05 mm
Arm mass : payload ratio	~3:1 to 5:1	~10:1 to 30:1
Fencing	Often none (PFL) or reduced	Hard guarding / interlocked enclosure
Force/torque sensing	Built in (every joint or wrist)	Optional, add-on F/T sensor
Programming	Graphical, operator-level	Vendor language + trained programmer
Redeployability	High — wheel it to the next job	Low — bolted, fenced, re-engineered
Mounting	Floor, wall, ceiling, table, cart	Typically heavy floor pedestal
Cost (arm + controller)	€20k–€55k	€25k–€120k+ (then add guarding)
Cell integration cost	Low — guarding often minimal	High — guarding, safety PLC, layout
Duty cycle / lifetime	Good; gearing sized lighter	Excellent; built for 24/7 at speed

A few things worth stating plainly:

The cobot's payload-to-mass ratio is its core compromise. To be safe on contact, the arm must be light and the joints relatively low-inertia, which means smaller motors and lighter gearing for a given payload. That's why a 10 kg cobot weighs ~33 kg while a 10 kg industrial arm might weigh 130 kg — the industrial arm's mass buys it stiffness, speed, and brutal duty cycle that the cobot deliberately trades away.

Repeatability is close but not equal. A UR10e is ±0.05 mm; a comparable FANUC industrial arm is ±0.02–0.03 mm. For most assembly and tending that gap is irrelevant. For precision insertion or laser work it can matter, and you'd compensate with force control or vision rather than raw repeatability.

The economics flip on guarding and engineering, not the arm. A cobot arm isn't dramatically cheaper than a small industrial arm. The savings are in the cell: less guarding, less safety-PLC integration, less layout engineering, and dramatically less programming time. On a short-run or frequently-changed job, redeployability is the whole value proposition.

Safety rule: If you intend to run a cobot guarded at full speed, you've bought an industrial arm with a nice pendant. Size it, fence it, and validate it like one — don't let "it's a cobot" shortcut the guarding decision.

The four collaboration modes (ISO 10218 / ISO/TS 15066)

This is the conceptual core of the entire field, and it is where most confusion lives. There are exactly four collaborative methods. They are defined in ISO 10218-2 (the system/integration standard) and elaborated in ISO/TS 15066:2016, the technical specification that put real numbers behind collaborative operation. The 2025 revision of ISO 10218-1/-2 folded much of TS 15066's content into the normative standards, but the four modes are unchanged.

A cell can use one mode, or several in combination (e.g. SSM during transit, PFL at the workstation). They are not a ranking — each suits different applications.

Mode	What it controls	Human–robot contact	Typical hardware	Best for
Safety-rated monitored stop (SRMS)	Robot is stationary (Cat 2 stop, power on) when human is in workspace	Robot must be stopped before human is present	Safety scanner / light curtain + safe-stop function	Manual load/unload of a station; robot resumes when human leaves
Hand guiding (HG)	Operator physically moves the robot via a safety-rated guiding device	Yes — operator holds an enabling/guiding handle	Hand-guide device, enabling switch, safe speed monitoring	Teaching, heavy-part assist, lift-assist devices
Speed & separation monitoring (SSM)	Robot speed scaled to distance from human; full stop if too close	No — separation maintained at all times	Safety laser scanners / 3D vision zones + safe speed	Shared workspace, sequential collaboration, transit at speed
Power & force limiting (PFL)	Contact forces/pressures kept below biomechanical limits	Yes — intended or incidental contact permitted	Joint torque / current sensing, safe force monitoring	True side-by-side work, light assembly, tending

Safety-rated monitored stop (SRMS)

The simplest and most common in practice. The robot does its work autonomously; when a human needs to enter — to load a part, clear a jam, inspect — a safety device (scanner, light curtain) triggers a safety-rated stop with power maintained (effectively a Stop Category 2 per IEC 60204-1). The robot holds position, motors energized, monitored. When the human clears the zone, it resumes without a re-home.

This is collaboration by time-sharing the space: human and robot are never both moving in the workspace simultaneously. Cheap, robust, easy to validate. It's how the majority of "collaborative" machine-tending cells actually work.

Hand guiding (HG)

The operator grasps a safety-rated guiding device and physically moves the robot. The robot is in a safe-speed-monitored state; let go (or release the enabling switch) and it stops. This is the basis of lift-assist and direct teaching, and it's what makes "grab the arm and show it the path" possible. It depends utterly on backdrivability and torque sensing — see force control below.

Speed and separation monitoring (SSM)

The robot and human share the workspace, but a safety system continuously measures the separation distance and scales robot speed accordingly: full speed when far, slower as the human approaches, full stop below a protective separation distance. Implemented with safety laser scanners (SICK microScan3, Omron OS32C) defining warning and protective fields, or increasingly 3D safety vision (e.g. Veo Robotics-style systems, now part of broader offerings).

The math behind the protective separation distance (S_p) comes straight from ISO/TS 15066:

Protective separation distance (ISO/TS 15066 §5.5.4):

S_p(t0) = S_h + S_r + S_s + C + Z_d + Z_r

  S_h = human movement contribution during robot stopping
        = ∫ v_h dt  (use 1600 mm/s if directed speed unknown)
  S_r = robot movement during reaction time T_r
  S_s = robot stopping distance during T_s (braking)
  C   = intrusion distance (per ISO 13855; e.g. 1200 mm for hands)
  Z_d = position uncertainty of the human (sensor)
  Z_r = position uncertainty of the robot

Worked example (hand approach, modest robot):
  v_h = 1600 mm/s, T_r = 0.10 s, T_s = 0.25 s,
  robot speed v_r = 500 mm/s
  S_h = 1600 * (0.10 + 0.25) = 560 mm
  S_r = 500 * 0.10            = 50 mm
  S_s = 0.5 * 500 * 0.25      = 63 mm   (linear decel approx)
  C   = 1200 mm (hand intrusion, sensor resolution dependent)
  Z_d + Z_r ≈ 100 mm
  S_p ≈ 560 + 50 + 63 + 1200 + 100 = 1973 mm  (~2.0 m)

That ~2 m number is why SSM cells need real floor space, and why people are often surprised that "collaborative" can mean "keep two meters apart." The dominant term is the human's own approach speed and the standardized intrusion distance.

Power and force limiting (PFL)

The only mode where a moving robot is permitted to contact a human, intentionally or by accident, because the system guarantees that any contact stays below biomechanical injury thresholds. This is the mode people mean when they say "cobot." It's also the hardest to validate, and it gets its own section.

Power & force limiting deep-dive

PFL is where the engineering gets genuinely interesting, because the limits aren't set by the robot — they're set by human pain and injury physiology, codified in ISO/TS 15066:2016 Annex A.

Quasi-static vs transient contact

The standard splits contact into two physically distinct cases, and they matter enormously:

• Quasi-static (clamping/crushing) contact: the body part is trapped between the robot and a fixed surface, so the force can be sustained. This is the dangerous case — there's no escape, and force builds. Limits are lower.
• Transient (dynamic/free-impact) contact: the robot hits a body part that is free to recoil or move away. The contact is brief (typically modeled at ≤0.5 s). The body absorbs energy and moves; injury threshold is higher — roughly 2× the quasi-static force limit for most regions.

Safety rule: Design out the clamping case first. A pinch point between the robot and a fixed table, wall, or fixture is governed by the quasi-static limits — the strict ones — and no amount of force monitoring undoes a geometric trap. Eliminate fixed surfaces near the path before you tune forces.

The biomechanical limit tables

ISO/TS 15066 Annex A specifies, for 29 specific body regions, a maximum permissible pressure (N/cm²) and force (N). Pressure governs local tissue/contusion injury; force governs the whole-body push. Both must be satisfied. Representative quasi-static values:

Body region	Quasi-static force limit (N)	Quasi-static pressure (N/cm²)
Skull / forehead	130	130
Face	65	110
Neck (sides/muscle)	150	140
Back / shoulders	210	160
Chest (sternum)	140	120
Abdomen	110	110
Hand / fingers (non-dominant)	140	190–280
Upper arm / elbow joint	150	190
Forearm / wrist joint	160	180–190
Thigh / kneecap	220	220
Lower leg (shin)	130	220

Two engineering takeaways. First, the skull and face are the binding constraints for most overhead or eye-level work — 130 N quasi-static is not much. Second, pressure is often the real limiter, not force. A 130 N contact through a sharp edge or small radius concentrates pressure far above the limit even though the total force is fine. This is why PFL applications mandate rounded, blunt, large-radius contact surfaces on the arm and the end effector.

Transient limits are roughly double, but you don't get to assume transient. If the body part can be trapped, it's quasi-static — full stop.

Building a PFL force budget

You work the problem backward from the limit. The robot's effective contact force depends on its speed and its effective mass at the contact point (a function of robot inertia, payload, and configuration):

PFL contact-energy / force budget (simplified, transient case)

Effective mass at TCP:
  m_eff = M / 2 + m_L     (M = lumped moving robot mass,
                            m_L = payload + end-effector mass)

Transient contact treated as a spring collision:
  F_max = v_rel * sqrt(k * m_eff)

  v_rel = relative speed at contact (m/s)
  k     = effective contact stiffness (N/m), body-region dependent
          (ISO/TS 15066 Annex tabulates spring constants, e.g.
           ~75 N/mm for the back, ~150 N/mm for the skull region)

Worked example — limit chest force to 280 N transient:
  k_chest   ≈ 25 N/mm = 25,000 N/m
  m_eff     ≈ 4 kg (small cobot + light tool)
  F_max     = 280 N target
  => v_rel  = F_max / sqrt(k * m_eff)
            = 280 / sqrt(25000 * 4)
            = 280 / 316  ≈ 0.89 m/s  (≈ 885 mm/s)

So below ~0.9 m/s, a chest impact stays under the transient limit
for this effective mass. Halve m_eff or k and the safe speed rises;
add payload mass and it falls. This is why heavier payloads force
lower collaborative speeds.

This is the crux of why higher payload forces lower collaborative speed: (F_{max}) scales with (\sqrt{m_{eff}}), so doubling effective mass cuts your safe speed by ~30%. A 20 kg-payload cobot carrying a real load simply cannot move fast and stay collaborative — which is why even the UR20/UR30 typically run PFL work at reduced speed and reserve full speed for guarded operation.

Validation: you measure it, you don't calculate it

Calculation gets you a design target. Certification requires physical measurement, and this is non-negotiable in a real CE/risk-assessment process.

The instrument is a biofidelic force/pressure measurement device — a spring-and-load-cell apparatus with a calibrated spring constant matching the relevant body region (commercial units: GTE Industrieelektronik / PILZ PRMS, or the CBSF-75 / "Cobot pressure-and-force measurement system"). You command the robot to drive into the device at the worst-case point in the trajectory, and read peak force.

Pressure is measured separately with pressure-indicating film (Fujifilm Prescale) placed over the contact patch: the film changes color in proportion to local pressure, and you scan it to read the distribution. This catches the sharp-edge / small-radius problem that a single-axis force gauge misses entirely.

Safety rule: Measure at the worst point in the trajectory and the worst configuration, not a convenient one. Effective mass and speed vary across the workspace; the binding case is usually full extension at the highest-speed segment near a pinch geometry. One green measurement at the home position proves nothing.

How cobots sense contact

PFL and hand guiding both depend on the robot knowing the external force applied to it, continuously and fast. There are two fundamentally different ways to get that, and the choice ripples through cost, performance, and which applications are viable. For the broader sensor landscape see the robot sensors guide.

Motor-current estimation (the cheap way)

If you know the current in each joint motor, you know the motor torque (torque ≈ (k_t \times I)). Subtract the torque you expected for the commanded motion — from a dynamic model of the arm (inertia, gravity, friction, Coriolis) — and the residual is the external torque. Map joint torques through the Jacobian and you get the external force at the TCP. No extra sensors; it's "free."

The catch is everything that corrupts the estimate: gearbox friction (especially the stiction and hysteresis of strain-wave gears), unmodeled payload inertia, temperature drift, and the fact that current sensing is upstream of the gearbox so it can't see what the gearbox eats. At low speed, friction dominates and the external-force estimate gets noisy — exactly the regime where gentle contact happens. Early Universal Robots (CB-series) used this approach. It works, but its force resolution and low-speed sensitivity are modest, which forces conservative limits. See motor controllers & FOC for how the current loop and torque estimation actually work.

Joint torque sensors (the good way)

Put a dedicated torque-sensing element on the output side of each joint — typically a strain-gauged or optical flexure — and you measure the actual joint torque after the gearbox, directly. Subtract the model-predicted torque and the residual external torque is far cleaner: gearbox friction is now inside the measurement, not corrupting it.

This is the architecture of the KUKA LBR iiwa (the pioneer — torque sensors in all 7 joints), Franka Emika (link-side torque sensors, exceptional sensitivity), FANUC CRX (torque sensing enabling its smooth contact behavior), Doosan (torque sensors in all six joints), and Techman on some models. The payoff: fine force control, reliable low-speed contact detection, true impedance control, and the ability to do delicate force-controlled assembly (insertion, polishing) that current-estimation cobots struggle with.

The cost: torque sensors add money, complexity, and a calibration burden to every joint. That's the central cost/performance fork in cobot design.

Wrist force/torque sensors

A third option: a single six-axis F/T sensor at the wrist (ATI, OnRobot HEX, Bota Systems). This measures force at the tool precisely — great for assembly and polishing — but it only sees forces through the flange. A contact on the elbow or forearm link is invisible to a wrist sensor. So wrist F/T is excellent for process force control but cannot, by itself, provide whole-arm PFL safety. Many cells use joint sensing for safety and a wrist sensor for fine process control.

Cobot joint hardware

Open up almost any modern cobot and you find the same elegant idea repeated six (or seven) times: a self-contained modular actuator cartridge. Understanding it explains nearly every spec on the datasheet. The deep treatments live in robot actuators, gearboxes, and encoders; here's how they combine in a cobot joint.

The five ingredients

1. Frameless BLDC motor. A pancake permanent-magnet synchronous motor, rotor bonded to the joint shaft, stator into the housing — no separate motor housing or coupling, saving mass and length. Driven by field-oriented control. High pole count for smooth low-speed torque.
2. Strain-wave (harmonic) gearbox. The defining cobot reduction: 50:1 to 160:1 in a single thin, coaxial, near-zero-backlash stage. Zero backlash matters because backlash destroys both repeatability and force-sensing fidelity. The downside — strain-wave gears have meaningful friction and some flexibility — is exactly what torque sensing and good models exist to handle. (Cycloidal drives show up in the heavier base joints of larger cobots for higher torque density.)
3. Dual encoders. A motor-side encoder (high resolution, for the fast commutation/velocity loop) and an output-side encoder (after the gearbox, for true joint angle). The output encoder is what lets the controller measure actual joint position despite gearbox flex and lash — essential for repeatability and for clean torque estimation. See encoders.
4. Joint torque sensor (on torque-sensing cobots). The flexure + strain gauges or optical element discussed above, integrated into the joint output.
5. Safety brake. A spring-applied, electrically-released holding brake so the arm holds position (and a payload) on power loss — and so a safe-stop can hold against gravity.

Wrap that in a hollow-shaft design for cable routing and you have one joint. Stack six, scale the sizes down toward the wrist, and you have the arm.

Why this architecture won

It's manufacturable and serviceable. Identical joint modules in a few sizes mean fewer part numbers, easier repair (swap a joint cartridge, not the arm), and a clean mapping from joint size to torque rating. It also makes the control problem tractable: each joint is a well-characterized torque source with known dynamics, which is what makes whole-arm dynamic modeling — and therefore force estimation — feasible.

The tradeoff returns us to the central compromise: strain-wave gears and pancake motors are light but not as stiff or as overload-tolerant as the big spur/bevel trains in industrial arms. That's the hardware reason cobots run slower and carry less.

Force control & compliance

Sensing contact is half the story. Responding to it — yielding, pushing with controlled force, being shoved into place by an operator — is force control, and it's what separates a robot that merely detects a collision from one that collaborates. The actuator-level foundations are in the robot actuators guide.

Impedance vs admittance control

Two ways to make an arm behave springy and compliant:

• Impedance control: measure position/velocity deviation, command force/torque. The arm behaves like a programmable spring-damper: push it and it yields with a stiffness you set. Needs good torque control (and ideally torque sensing) at every joint. This is the KUKA iiwa / Franka native mode — you can set a 50 N/m "soft" wrist that floats, or a stiff one that resists. Naturally stable in contact, excellent for delicate insertion.
• Admittance control: measure force (e.g. wrist F/T sensor), command position. The arm reads the force you apply and moves accordingly. Works on a position-controlled robot with one F/T sensor — cheaper to retrofit — but can go unstable against stiff environments and feels less natural at low force.

Most current-estimation cobots do a pragmatic admittance-flavored compliance; torque-sensing cobots do real joint-level impedance. The difference is palpable when hand-guiding: a Franka or iiwa floats like it's weightless; a position-controlled arm with admittance feels like pushing through molasses by comparison.

Why backdrivability matters

Backdrivability is the ability to move the joint by pushing on the output — i.e. the gearbox doesn't lock you out. It's set mostly by gear ratio and friction: low-ratio, low-friction drives backdrive easily; high-ratio worm or highly-loaded strain-wave gears resist. Backdrivability matters for two reasons:

1. Hand guiding feels natural when the arm offers little resistance and the controller cancels gravity and friction.
2. Contact is gentler — a backdrivable joint can physically give way during the milliseconds before the controller even reacts, providing a layer of intrinsic (mechanical) compliance on top of the active (controlled) compliance.

Franka Emika built much of its reputation on exceptional backdrivability and torque control; that's why it became the research-and-fine-manipulation darling. Strain-wave gears aren't naturally very backdrivable, so torque sensing + active compensation does the heavy lifting.

Lead-through (teach-by-demonstration)

Hand guiding's everyday payoff: free-drive mode. Press the button, the arm goes compliant and gravity-compensated, you physically drag the TCP through the path, releasing waypoints as you go. Thirty seconds to teach a pick pose that would take minutes of jogging. It's a direct consequence of torque sensing + compliance + a released brake, and it's one of the genuine usability leaps cobots delivered.

Programming cobots

If safety is the headline, programming is the actual reason cobots conquered the SME market. A traditional industrial robot needs a trained programmer and days of work; a cobot can be deployed by a process engineer in an afternoon. That's the disruption.

Graphical / no-code teaching

Universal Robots' PolyScope pendant pioneered the model: a 3D-graphical, flowchart-style interface where you build a program by adding nodes (Move, Set, Wait, If, gripper actions) and teach waypoints by free-driving or jogging. No text. FANUC's CRX tablet TP uses drag-and-drop icon programming; Techman's TMflow is a visual node-graph; Doosan's DART and ABB Wizard (block-based, Scratch-like) follow the same philosophy. An operator who can use a smartphone can build a useful pick-and-place in an hour.

Scripting underneath

The graphical layer sits on a real language. UR's is URScript — a Python-like scripting language you can write directly for anything the GUI can't express (custom math, socket comms, complex flow). Example of the readable, approachable style:

# URScript: force-controlled insertion until 30 N reached, then settle
def insert_part():
    # move to approach pose above the hole
    movej(p[0.40, -0.20, 0.30, 0, 3.14, 0], a=1.0, v=0.25)
    # enable force mode: push down (Z) with up to 30 N,
    # stay compliant in X/Y so the part self-aligns
    force_mode(tool_pose(),                # task frame = tool
               [1, 1, 1, 0, 0, 0],         # compliant axes: X,Y,Z
               [0, 0, -30, 0, 0, 0],       # 30 N downward in Z
               2,                          # type: simple force
               [0.05, 0.05, 0.15, 0.17, 0.17, 0.17])  # limits
    while force() < 30:
        sync()
    end
    end_force_mode()
    set_digital_out(0, True)               # signal "seated"
end

That snippet — compliant in two axes, force-controlled in the third — is a textbook PFL-era assembly trick: let the part find the hole instead of demanding perfect position. It's only practical because of force sensing.

The ecosystem: UR+ and friends

UR's second masterstroke was UR+, a certified-hardware-and-software marketplace: grippers, vision, screwdrivers, sensors, and "URCaps" plugins that drop into PolyScope as native nodes. Plug in a Robotiq gripper and a "Grip" node appears in your program — no driver wrangling. FANUC, Techman, and Doosan all built analogous partner ecosystems. This ecosystem effect is a real moat: it's why UR's market share outlasted its technical lead.

Offline, simulation, and ROS

For complex cells there's offline programming and digital twins (URSim, RoboDK, vendor sims) and, increasingly, ROS / ROS 2 drivers for research and advanced integration. Most production cobot work, though, still happens on the pendant — and that's a feature, not a limitation.

Risk assessment & deployment

This is where good intentions meet legal and physical reality. Deploying a cobot collaboratively is an engineering process with a paper trail, not a purchase decision.

The application is collaborative, not the robot (again)

Worth repeating because it's the whole game. The CE mark / conformity you produce is for the robot system / cell, under the Machinery Directive (now Machinery Regulation EU 2023/1230) in Europe, or the relevant OSHA/ANSI/RIA framework in the US (ANSI/RIA R15.06, harmonized with ISO 10218; RIA TR R15.806 mirrors ISO/TS 15066). The integrator owns this.

The process: ISO 12100

The backbone is ISO 12100 (risk assessment and risk reduction): identify hazards, estimate risk (severity × probability × exposure × avoidance), reduce by the hierarchy of controls (inherently safe design → safeguarding → information for use), then re-assess. For a cobot cell you enumerate every hazard — the moving arm, the end effector, the workpiece, the process, electrical, the surrounding equipment — and decide, per hazard, which collaboration mode or guard addresses it.

Safety rule: The hierarchy of controls is ordered for a reason. Eliminate the hazard (round the corners, remove the pinch point) before you guard it (scanner, fence) before you warn about it (signage, training). PFL is an inherently-safer-design control for the arm; it does nothing for a hazardous tool.

Speed throttling and zones

A common, robust pattern: the arm runs fast in a guarded transit zone (SSM or fenced) and slow in the collaborative workstation (PFL), switching modes via safe-rated zone monitoring. You get throughput where no human is and collaboration where they are. Safety-rated speed and position limits (configured in the safety controller, validated, and locked) enforce the switch.

The end effector and workpiece are hazards too

This kills more "collaborative" deployments than anything else. The arm can be perfectly PFL-compliant while the application is not:

• The gripper: pinch points between fingers, or a part-present sensor that doesn't stop closing on a finger. See end effectors & grippers — collaborative grippers (Robotiq, OnRobot, Schunk Co-act) are explicitly designed with rounded jaws and force limits for exactly this reason.
• The workpiece: sharp sheet-metal edges, hot parts, glass, anything with a small contact radius. ISO/TS 15066 limits assume blunt contact; a sharp edge blows the pressure limit at trivial force.
• The process: a deburring spindle, a welding torch, a laser, a fluid jet — none of these are collaborative regardless of how the arm moves.

Why most "cobots" run fenced at full speed

Given all of the above, many integrators reach the rational conclusion: it's cheaper and faster to guard the cell (a small light curtain or scanner is inexpensive) and run the cobot fast than to do the full PFL validation, derate the speed, and re-validate every time the part changes. So they buy the cobot for the programming and redeployability, fence it, and run it at 1,500 mm/s. That's not a failure — it's often the correct engineering tradeoff. Just call it what it is.

Real applications & ROI

Where cobots actually earn their keep, with the honest economics.

Machine tending

The number-one cobot application. A CNC mill, lathe, injection molder, or press needs parts loaded and unloaded — dull, repetitive, sometimes ergonomically nasty work. A cobot on a cart rolls up to the machine, an operator teaches the load/unload in an hour, and it runs lights-out or frees an operator to tend three machines instead of one. Often deployed SRMS (robot stops when operator enters) or lightly guarded. ROI is typically 6–18 months, driven by labor reallocation and machine uptime, not headcount elimination.

Palletizing

The killer app for the new high-payload cobots (UR20/UR30, FANUC CRX-25iA, Doosan H-series). End-of-line palletizing is heavy, repetitive, injury-prone (lower-back claims are expensive). A 20–30 kg cobot with a vacuum or clamp gripper on a lift column stacks boxes all shift. Cobot palletizers from vendors like Robotiq, Premier Tech, and Columbia/Okura's cobot lines productized this. ROI often under 12 months where you're displacing a manual palletizing station with real injury risk.

Assembly

Screwdriving, press-fits, snap assembly, small-part insertion. This is where force control earns its money — compliant insertion, torque-verified screwdriving (UR+ screwdriving tools log torque per fastening for traceability). Genuinely collaborative side-by-side work shows up here: human does the dexterous bit, cobot does the repetitive fastening.

Inspection & quality

Cobot + camera or laser profilometer running a fixed inspection path: dimensional checks, surface inspection, reading gauges, taking measurements at stations a human can't reach repeatably. The cobot's modest repeatability (±0.05 mm) is plenty for most vision-based inspection, and free-drive makes path teaching trivial.

Lab automation & life sciences

A fast-growing segment: pipetting, plate handling, sample sorting in labs where the bench is shared with humans and space is tight. Cleanroom-rated cobots and the smaller arms (UR3e, Franka, ABB YuMi for dual-arm dexterous tasks) fit because they're compact, quiet, precise enough, and safe around lab staff. Throughput is modest but the value is 24/7 unattended runs and freed scientist time.

The ROI honesty check

Cobots rarely win on raw speed or cost-per-part against a dedicated fixed automation cell at high volume — a hard-tooled machine will out-throughput them every time. They win on flexibility, fast deployment, low integration cost, and redeployability at low-to-medium volume and high mix. If you run one product a million times, build fixed automation. If you run fifty products a few thousand times each and the mix changes quarterly, the cobot's redeployability is the entire business case.

The 2026 cobot market & landscape

The field in 2026 is mature, crowded, and segmenting.

The vendors

• Universal Robots (Teradyne-owned) remains the volume and ecosystem leader — the e-Series (UR3e/5e/10e/16e), plus the higher-payload UR20 (20 kg) and UR30 (30 kg). Strength: ecosystem (UR+), maturity, resale, training base. Sensing: motor-current-based with refined estimation.
• FANUC brings industrial pedigree to the CRX line (CRX-5iA/10iA/20iA/25iA), torque-sensing, famously smooth contact behavior, the green-and-white styling, and FANUC's legendary reliability and service network. The CRX-25iA pushed FANUC cobots into palletizing.
• Techman Robot (Quanta-affiliated, Taiwan) differentiates with a built-in vision system and TMflow's flow-based programming — vision-native cobots for inspection and pick-and-place.
• Doosan Robotics (Korea) offers one of the broadest ranges (A/M/H/E/P series), torque sensors in all six joints, and the heavy H-series (up to 25 kg); aggressive on payload and price.
• KUKA LBR iiwa is the 7-axis, torque-sensing-in-every-joint pioneer — the gold standard for sensitive, redundant-kinematics collaborative work, priced accordingly. The newer LBR iisy targets easier deployment.
• ABB offers GoFa (CRB 15000, up to 12 kg, torque sensing) for single-arm collaborative work and the iconic dual-arm YuMi (IRB 14000) for small-parts dexterous assembly.
• Franka Emika (now Franka Robotics) is the research/fine-manipulation favorite — exceptional torque sensing and backdrivability, link-side sensors, the natural platform for force-rich and learning-based manipulation.
• Plus a long tail: Fanuc-adjacent and Chinese entrants (AUBO, JAKA, Han's, Elite, Dobot), Hanwha, Kassow (high-payload 7-axis), Rethink's legacy (Baxter/Sawyer, defunct but influential).

Trends: higher payload, vision-native, easier still

Three vectors define 2026: payload climbing (20–30 kg cobots are now normal, opening palletizing and heavy tending), vision baked in (Techman-style integrated vision, AI pick), and deployment getting even easier (AI-assisted programming, natural-language task setup creeping in).

The humanoid overlap

The most interesting 2026 dynamic: the humanoid wave runs on cobot DNA. A torque-controlled, backdrivable, force-limited joint is exactly the cobot actuator — humanoids just use more of them, arranged as legs and dual arms, with whole-body force control instead of a single arm's. The sensing (joint torque), control (impedance), and safety philosophy (force limiting around humans) are continuous from cobot to humanoid. Several cobot vendors and their suppliers are now also humanoid-actuator suppliers. If you understand cobot joints, you're 80% of the way to understanding a humanoid limb — see the humanoid robot hardware guide.

Selecting a cobot

A disciplined selection sequence, then a real spec table.

Step 1: define the application and the safety case first

Before payload and reach, answer: Will this run collaboratively (PFL/SSM/SRMS/HG), or guarded? If guarded, you're choosing on speed/payload/price like an industrial arm and the "collaborative" features are just nice-to-haves. If truly collaborative, the gripper, workpiece, and acceptable speed constrain everything — settle those before the arm.

Step 2: payload and reach with margin

Payload must include the end effector and the workpiece, with the gripper mass often eating 1–3 kg before you pick anything. Size with ~20–30% margin, and remember collaborative-mode speed drops as payload rises (the (\sqrt{m_{eff}}) effect). Reach must cover the worst-case point in the work envelope plus tool length — and check that the useful envelope (where the arm has good dexterity, not folded against a singularity) covers it.

Step 3: sensing and force-control needs

Fine force-controlled assembly or research → torque-sensing cobot (Franka, iiwa, FANUC CRX, Doosan). Simple pick/place/tend → current-estimation is fine and cheaper (UR e-Series). Vision-heavy → Techman or add a vision system.

Real-product comparison table

Model	Payload	Reach	Repeatability	Sensing	Collab. TCP speed	Weight	Notes
UR3e	3 kg	500 mm	±0.03 mm	Motor current	~1 m/s	11 kg	Tabletop, light assembly, lab
UR5e	5 kg	850 mm	±0.03 mm	Motor current	~1 m/s	20.6 kg	The workhorse SME cobot
UR10e	12.5 kg	1300 mm	±0.05 mm	Motor current	~1 m/s	33.5 kg	Tending, packaging, longer reach
UR20	20 kg	1750 mm	±0.05 mm	Motor current	~1 m/s (derated)	64 kg	Palletizing, heavy tending
UR30	30 kg	1300 mm	±0.05 mm	Motor current	(derated)	63.5 kg	High payload, compact reach
FANUC CRX-10iA	10 kg	1249 mm	±0.04 mm	Joint torque	~1 m/s	39 kg	Smooth contact, FANUC reliability
FANUC CRX-25iA	25 kg	1889 mm	±0.04 mm	Joint torque	(derated)	~95 kg	Palletizing-class cobot
Techman TM12 / TM14	12 / 14 kg	1300 / 1100 mm	±0.1 mm	Joint torque	~1.3 m/s	~33 kg	Built-in vision system
Doosan H2515	25 kg	1500 mm	±0.1 mm	6× joint torque	~1 m/s	76 kg	Heavy-payload, torque in all joints
Doosan M1013	10 kg	1300 mm	±0.05 mm	6× joint torque	~1 m/s	33 kg	Versatile mid-range
KUKA LBR iiwa 14	14 kg	820 mm	±0.10 mm	7× joint torque	varies	29.9 kg	7-axis, sensitive assembly
ABB GoFa CRB 15000	5–12 kg	950–1620 mm	±0.02–0.05 mm	Joint torque	~1 m/s	27–63 kg	Single-arm collaborative
ABB YuMi IRB 14000	0.5 kg/arm	559 mm	±0.02 mm	Current + design	~1.5 m/s	38 kg	Dual-arm small-parts assembly
Franka Research 3	3 kg	855 mm	±0.1 mm	7× link torque	varies	18 kg	Research, fine force manipulation

(Numbers are nominal manufacturer figures for orientation; verify the exact variant against current datasheets — payloads, reaches, and especially collaborative speeds vary by model revision and safety configuration.)

Step 4: integration checklist

• Mounting: floor, wall, ceiling, table, or cart. Confirm the arm supports the orientation and that the safety config accounts for gravity direction.
• Flange & EOAT: ISO 9409-1 flange; tool I/O (digital, IO-Link, fieldbus); cable routing through the wrist if available.
• Controller & fieldbus: the cell PLC integration (PROFINET/PROFISAFE, EtherCAT/FSoE, Ethernet/IP CIP Safety) for safe signals and process I/O.
• Safety devices: scanners/curtains for SRMS/SSM; the measurement plan for PFL validation.
• Ecosystem: is the gripper/vision/tool a certified plug-in (UR+, FANUC partner, etc.) or a custom integration?

Safety rule: Lock and document the safety configuration (speed/force/position limits) and treat any change as a re-validation trigger. The single most common audit failure is a cell whose installed safety limits no longer match the validated risk assessment because someone "just bumped the speed."

Frequently asked questions

Is a cobot inherently safe to work next to? No. A cobot is capable of safe collaborative operation under the right risk assessment, mode, speed, payload, and end effector. The arm out of the box is collaborative-capable, not safe-by-default. Speed, a hazardous tool, a sharp workpiece, or a pinch point against a fixture can each make a cobot cell unsafe. Safety is a property of the validated application, not the robot.

What's the difference between ISO 10218 and ISO/TS 15066? ISO 10218 (parts 1 and 2) is the normative safety standard for industrial robots and robot systems, including collaborative operation — it defines the four collaboration modes. ISO/TS 15066 is a technical specification that supplements it with the detailed guidance and, crucially, the biomechanical force/pressure limit tables for power & force limiting. The 2025 revision of ISO 10218 absorbed much of TS 15066's content into the main standards. In the US, ANSI/RIA R15.06 and RIA TR R15.806 are the harmonized equivalents.

What are the four collaboration modes again? Safety-rated monitored stop (robot stops when human enters), hand guiding (operator moves the arm via a safe guiding device), speed and separation monitoring (robot speed scaled to distance, full stop below a protective separation distance), and power & force limiting (contact forces kept below injury thresholds so a moving robot may touch a human). Only PFL permits contact with a moving robot.

Do cobots really need no fencing? Sometimes. A properly risk-assessed PFL application — low speed, blunt geometry, no pinch points, safe tool and workpiece — can run fence-free. But many cobot cells need some safeguarding (a scanner for SSM/SRMS, a guard around a hazardous tool), and many integrators deliberately fence and run fast. "No fencing" is an outcome you earn with a risk assessment, not a guarantee you buy.

How fast can a cobot move in collaborative mode? In PFL, typically 250–1,000 mm/s TCP, derated as payload and effective mass rise, because contact force scales with speed and the square root of effective mass. Run guarded (not in contact-permitted mode), the same arm can hit 1,000–2,000 mm/s. Heavier payloads force lower collaborative speeds — that's physics, not a marketing limitation.

Joint torque sensors vs motor-current sensing — which should I care about? For simple pick-and-place and machine tending, motor-current estimation (e.g. UR e-Series) is fine and cheaper. For delicate force-controlled assembly, polishing, or research, joint torque sensors (Franka, KUKA iiwa, FANUC CRX, Doosan) give far cleaner low-speed contact detection and true impedance control. Torque sensing costs more but unlocks applications current-estimation cobots struggle with.

What's the difference between transient and quasi-static contact limits? Quasi-static (clamping/trapping, force sustained against a fixed surface) limits are the strict ones — e.g. ~130 N at the skull. Transient (free impact, body free to recoil, brief contact) limits are roughly double. If a body part can be trapped, you must use the quasi-static limit. Designing out pinch points lets more of your trajectory qualify as transient and run faster.

How do I actually validate a PFL application? Physically measure it. Drive the robot into a calibrated biofidelic force/pressure measurement device (a load cell on a body-region-matched spring) at the worst-case point and configuration, read peak force, and verify it's under the ISO/TS 15066 limit. Separately, use pressure-indicating film (Fujifilm Prescale) to check local pressure over the contact patch — sharp edges blow the pressure limit even when total force is fine. Calculation is a design target; measurement is the proof.

Can I put any gripper on a cobot and stay collaborative? No. The end effector is part of the safety case. Pinch points between fingers, sharp jaws, or a gripper that doesn't force-limit its closing can each violate PFL even if the arm is compliant. Use collaborative-rated grippers (Robotiq, OnRobot, Schunk Co-act) with rounded geometry and force limits, and include the workpiece in the assessment — see the grippers guide.

Are higher-payload cobots (20–30 kg) real, or marketing? Real and useful — the UR20/UR30, FANUC CRX-25iA, and Doosan H-series genuinely opened palletizing and heavier machine tending to cobots. The honest caveat: at high payload they run collaborative work slowly (the effective-mass speed limit) and often run guarded at full speed for throughput. The value is still flexibility and easy deployment, not collaborative speed.

How are cobots related to humanoid robots? Closely. The humanoid joint is the cobot actuator — frameless BLDC + strain-wave (or planetary/cycloidal) gearbox + torque sensing + impedance control — just used in larger numbers and arranged for legs and dual arms with whole-body force control. The sensing and safety philosophy carry straight over. Understanding cobot joints is most of the way to understanding humanoid limbs; see the humanoid hardware guide.

What's the realistic ROI and payback on a cobot? For machine tending and palletizing displacing manual, injury-prone work, payback is commonly 6–18 months, driven by labor reallocation, machine uptime, and reduced injury claims — not headcount elimination. Cobots lose to fixed automation at high volume/low mix and win on flexibility, low integration cost, and redeployability at low-to-medium volume and high mix. Match the tool to the volume-mix profile.