> ## 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

> End-to-end workflow for a cobot integrator demonstrating ISO/TS 15066 contact-force limits. Derive thresholds, instrument sim runs, capture MCAPs, structure the audit pack.

# 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](/standards/iso-ts-15066). Applicable both to the cobot-arm vendor and to the cell integrator who builds the PFL application around the arm.

<Warning>
  **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.
</Warning>

## 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-platform                                                      | Why                                          |
| ----------------------------------------------------------------- | -------------------------------------------- |
| Risk assessment per ISO 12100 with explicit contact analysis      | Drives the contact-scenario set              |
| Licensed copy of ISO/TS 15066 with Annex A                        | Source 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

<Steps>
  <Step title="Pin the standards stack">
    ```bash theme={null}
    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.
  </Step>

  <Step title="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).

    ```yaml theme={null}
    # 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.
  </Step>

  <Step title="Author the requirements">
    One requirement per (body region, contact mode) tuple. See the [ISO/TS 15066 derivation example](/standards/iso-ts-15066#example-derived-requirement).
  </Step>
</Steps>

## Test patterns

The dominant test is parameterised across the contact-scenario set, asserting peak force / pressure under the Annex A threshold:

```python theme={null}
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:

```yaml theme={null}
- 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](/evidence/customer-handoff).

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

| Event                                           | Action                                                                                           |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| ISO/TS 15066 amendment (rare; the TS is stable) | [Re-conformity workflow](/compliance/re-conformity-on-amendment)                                 |
| ISO 10218 amendment (more common)               | Re-conformity; many cobot requirements cross-derive                                              |
| New end-effector / new payload                  | Add scenarios; re-verify the affected body-region requirements                                   |
| Customer field-report of unexpected contact     | Generate ad-hoc pack scoped to the field-build; investigate; add scenarios to prevent regression |

## Next steps

<CardGroup cols={2}>
  <Card title="ISO/TS 15066 standard page" icon="handshake" href="/standards/iso-ts-15066">
    The threshold reference.
  </Card>

  <Card title="ISO 10218 pattern" icon="industry" href="/compliance/industrial-robot-iso-10218">
    The broader industrial-robot pattern.
  </Card>

  <Card title="EU MR conformity" icon="flag" href="/compliance/eu-mr-2023-1230-conformity">
    For the full conformity assessment under EU MR 2023/1230.
  </Card>
</CardGroup>