Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.roboticks.io/llms.txt

Use this file to discover all available pages before exploring further.

Cobot — ISO/TS 15066

This pattern is for cobot integrators and cobot-platform manufacturers demonstrating Power and Force Limiting (PFL) collaborative operation under ISO 10218 — specifically the contact-force limits of ISO/TS 15066. Applicable both to the cobot-arm vendor and to the cell integrator who builds the PFL application around the arm.
Roboticks is audit-readiness tooling, not a certified toolchain. We assemble the evidence your notified body, certification body, or QA process ingests. We do not replace tool qualification (DO-178C, ISO 26262-8 TCL) and we do not issue conformity assessments. Verify the regulatory interpretations on this page against the standard text and your accredited assessor.

Scenario

You ship a cobot, or a cobot application, intended to operate in PFL mode — direct unguarded interaction with a human operator. Your obligations:
  • For every foreseeable contact between cobot and operator, demonstrate the resulting force and pressure stay below the ISO/TS 15066 Annex A biomechanical limits for the relevant body region.
  • Document the contact scenarios analysed.
  • Provide verification evidence — sim runs, hardware-in-the-loop measurements, or a hybrid.

Prerequisites

Off-platformWhy
Risk assessment per ISO 12100 with explicit contact analysisDrives the contact-scenario set
Licensed copy of ISO/TS 15066 with Annex ASource of the threshold numbers
Validated contact model in sim (if sim is your evidence vehicle)Anchors the sim-vs-reality equivalence claim
Hardware contact-force rig (if hardware is your evidence vehicle)Direct measurement

Project setup

1

Pin the standards stack

rbtk standard template apply cobot-eu --project acme-cobot/firmware
Pins: ISO 10218-1:2025, ISO 10218-2:2025, ISO/TS 15066, ISO 12100, EN ISO 13849-1, IEC 62061, EU MR 2023/1230.
2

Author the contact-scenario set

Create scenarios/contact_*.yaml files, one per body region. Each lists the scenarios — initial pose, trajectory, contact geometry, expected contact-mode (transient or quasi-static).
# scenarios/contact_upper_arm.yaml
- id: UA-001
  world: worlds/assembly_station.world
  contact_mode: quasi_static
  trajectory: trajectories/pick_from_left.json
  operator_pose: poses/operator_standing_close.yaml
- id: UA-002
  world: worlds/assembly_station.world
  contact_mode: transient
  trajectory: trajectories/fast_return.json
  operator_pose: poses/operator_reaching.yaml
# …
A typical project ends up with 50–300 contact scenarios across all body regions.
3

Author the requirements

One requirement per (body region, contact mode) tuple. See the ISO/TS 15066 derivation example.

Test patterns

The dominant test is parameterised across the contact-scenario set, asserting peak force / pressure under the Annex A threshold:
import pytest
from roboticks import confirms
from roboticks.gazebo import contact_force

CONTACT_SCENARIOS = load_scenarios("scenarios/contact_upper_arm.yaml")
QS_LIMIT_N = 150  # placeholder; consult ISO/TS 15066 Annex A

@pytest.mark.parametrize("s", CONTACT_SCENARIOS, ids=lambda s: s.id)
@confirms("REQ-PFL-007")
def test_upper_arm_quasi_static(robot, s):
    if s.contact_mode != "quasi_static":
        pytest.skip("scenario covers transient")
    robot.load_world(s.world)
    robot.set_operator_pose(s.operator_pose)
    robot.execute(s.trajectory)
    peak = contact_force(robot, body_region="upper_arm",
                        duration_threshold_s=0.5).peak()
    assert peak < QS_LIMIT_N, f"{s.id}: peak {peak} N exceeds limit"
The contact-force helper:
  • In Gazebo: pulls wrench data from the contact-sensor plugin.
  • In Webots: pulls touch-sensor data.
  • For hardware: reads from your force / torque sensor stream over ROS2.
Every scenario captures an MCAP of wrench, TF, joint states, and the operator-pose mock. The evidence pack references every MCAP for assessor inspection.

Sim-vs-reality anchoring

For sim-evidenced projects, run a smaller hardware-in-the-loop spot-test set (typically 10–20 scenarios chosen to span the contact-mode × body-region grid) and prove the sim contact-force model agrees with hardware measurement within an acceptance band. The spot-test results are themselves requirements:
- id: REQ-SIM-VALIDATION-001
  title: Sim contact force model matches hardware within 15% across spot-test set
  type: validation
  text: |
    Across the 18 hardware spot-test scenarios in `scenarios/hil_spot.yaml`,
    the sim-predicted peak contact force shall match the hardware-measured
    peak force within 15% (absolute, both directions), per body region.
  acceptance:
    - test: tests/validation/test_sim_vs_hil.py
Without this anchor, an assessor may discount sim-only evidence. With it, the sim-broad-coverage strategy becomes defensible.

Release and handoff

Cut releases on every firmware version that ships, generate the evidence pack, hand to the notified body per the customer-handoff procedure. Expect the assessor to:
  • Drill into the contact-scenario set — coverage of foreseeable contact, completeness across body regions.
  • Question the sim-vs-reality equivalence — your REQ-SIM-VALIDATION-001 evidence answers this.
  • Restore specific contact-scenario MCAPs from Glacier.
  • Re-verify a subset of scenarios on demand (cobot demos with a sample fixture are common during the assessment).

Maintenance

EventAction
ISO/TS 15066 amendment (rare; the TS is stable)Re-conformity workflow
ISO 10218 amendment (more common)Re-conformity; many cobot requirements cross-derive
New end-effector / new payloadAdd scenarios; re-verify the affected body-region requirements
Customer field-report of unexpected contactGenerate ad-hoc pack scoped to the field-build; investigate; add scenarios to prevent regression

Next steps

ISO/TS 15066 standard page

The threshold reference.

ISO 10218 pattern

The broader industrial-robot pattern.

EU MR conformity

For the full conformity assessment under EU MR 2023/1230.