> ## 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.
# AMR - ISO 3691-4
> End-to-end workflow for an AMR vendor pursuing ISO 3691-4 conformity. Detection-zone requirements, hardware-in-the-loop sim, edge cases, the evidence pack a notified body wants.
# AMR — ISO 3691-4
This pattern is for **Autonomous Mobile Robot vendors** pursuing [ISO 3691-4](/standards/iso-3691-4) conformity. For vendors selling into the US market, the pattern extends to dual-claim with [ANSI/RIA R15.08](/standards/ansi-r15-08); the structural workflow is identical with both standards pinned.
**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 manufacture an AMR — autonomous mobile robot for industrial material handling. Conformance target: ISO 3691-4:2023 under EU MR 2023/1230 (and R15.08-1:2023 for US sales).
Your obligations:
* Demonstrate the AMR's personnel detection system (PDS) detects operators in time to stop before contact, across the operational design domain.
* Document detection-zone geometry per truck speed and payload.
* Demonstrate safe behaviour in edge cases — operator step-out, low-contrast obstacles, mixed-traffic scenarios.
* Document fault behaviour — sensor occlusion, communication loss, charging-station interactions.
* Provide verification evidence — primarily sim, anchored by hardware spot tests.
## Prerequisites
| Off-platform | Why |
| --------------------------------------------------------------- | --------------------------------------------------------- |
| Risk assessment per ISO 12100 with detection-zone analysis | Drives the scenario grid |
| Certified safety scanners (IEC 61496-3) from supplier | Their certs reference; you integrate |
| Detection-zone geometry definition | Pinned per-release in Roboticks |
| Validated sim environment (Gazebo or Webots with sensor models) | Sim-based evidence is the dominant strategy for AMR scale |
| Hardware test track / fixture | Spot-validation anchor |
## Project setup
```bash theme={null}
rbtk standard template apply amr-eu --project acme-amr/firmware
```
Pins: ISO 3691-4:2023, ISO 12100, EN ISO 13849-1, IEC 62061, EU MR 2023/1230, IEC 61496-1, IEC 61496-3. For US dual-claim, additionally:
```bash theme={null}
rbtk standard pin ansi-ria-r15-08-1-2023 --project acme-amr/firmware
```
```yaml theme={null}
# roboticks/zones.yaml
zones:
- name: forward_warning
geometry: polygon
speed_band: [0.5, 2.0] # m/s
payload_band: [0, 1500] # kg
# …
- name: forward_protective
# …
```
The platform pins this configuration per-release; the evidence pack documents the geometry in force when each scenario ran.
Scenarios are parameterised across `speed × payload × obstacle-type × obstacle-position`. A typical AMR project has 500–5,000 scenarios. The grid is auto-generated from `scenarios/grid.yaml`:
```yaml theme={null}
grid:
speeds_ms: [0.5, 1.0, 1.5, 2.0]
payloads_kg: [0, 500, 1000, 1500]
obstacles:
- kg-box-30x40
- operator-mannequin-standing
- operator-mannequin-crouching
- pallet-empty
obstacle_positions:
# forward straight, forward-left, forward-right, pinch-point
- [3.0, 0.0]
- [2.5, 0.5]
- [2.5, -0.5]
# …
```
The grid expands at test-time.
Requirements are coarse-grained — one per (speed band, payload band, scenario category). See [ISO 3691-4 derivation example](/standards/iso-3691-4#example-detection-zone-requirement).
## Test patterns
The dominant test is a parameterised stopping-distance assertion:
```python theme={null}
import pytest
from roboticks import confirms
from roboticks.gazebo import distance_to_obstacle
SCENARIOS = expand_grid("scenarios/grid.yaml")
@pytest.mark.parametrize("s", SCENARIOS, ids=lambda s: s.id)
@confirms("REQ-AMR-014")
def test_stopping_distance(amr, s):
amr.load_world(s.world)
amr.set_payload_kg(s.payload_kg)
amr.command_velocity(s.speed_ms)
amr.spawn_obstacle(s.obstacle, s.position)
amr.wait_until_stopped()
distance = distance_to_obstacle(amr, s.obstacle)
assert distance > 0.0, f"{s.id}: contact occurred"
```
Each run captures an MCAP of TF, scanner topics, motion commands, and stop-confirm topics. The evidence pack references every MCAP.
### Edge-case scenarios
Beyond the grid, build explicit scenarios for the corner cases assessors scrutinise:
| Scenario | What it tests |
| -------------------------- | -------------------------------------------------------- |
| `step_out_from_rack` | Operator emerges from behind a static obstacle |
| `low_contrast_pallet` | Black pallet on dark floor |
| `partial_sensor_occlusion` | Scanner partially blocked by dust simulation |
| `pinch_point_corridor` | Narrow corridor, operator in path with no escape |
| `mixed_traffic_amr_amr` | Two AMRs approaching, both must yield |
| `manual_mode_safety` | Safety functions remain active in manual mode |
| `recovery_no_restart` | Verifies AMR does not auto-restart with obstacle present |
These scenarios are typically derived from individual requirements (e.g., `REQ-AMR-EDGE-step-out`), so the requirement is explicitly tested.
### Hardware spot-validation
Run a subset of the scenario grid on the hardware test track — typically 30–80 scenarios anchoring the speed × payload corners and the edge cases. The hardware results enter the evidence pack as JUnit XML the same way sim results do.
Author a sim-vs-hardware-equivalence requirement (similar to the cobot pattern) to defend sim-broad-coverage to the assessor.
## Release and handoff
Cut releases on every firmware version, generate the evidence pack, hand to the notified body.
Expect the assessor to:
* Scrutinise scenario-grid coverage — what speed × payload × obstacle combinations did you skip and why.
* Drill into edge-case scenarios — particularly pinch-point and step-out cases.
* Restore MCAPs for representative failures (if any acknowledged gaps) and representative passes from Glacier.
* Question communication-loss and sensor-occlusion fault handling — these are common conformity-assessment focus areas.
* Request a live hardware demo of a few scenarios, with the evidence pack PDF as the script.
## Maintenance
| Event | Action |
| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| ISO 3691-4 amendment | [Re-conformity workflow](/compliance/re-conformity-on-amendment) |
| New AMR variant in the product line | New project (or new repository in the same project); apply the same pattern |
| New scanner / lidar model | Re-verify the requirements that derive from the sensor's IEC 61496-3 characteristics |
| Field incident report | Ad-hoc pack scoped to the field-build's commit; investigate; add new scenarios; re-verify |
| New customer site with different environmental constraints | Site-acceptance testing is off-platform; reference the site-specific tests in the evidence pack |
## Next steps
Standard reference.
Dual-claim for US market.
The scanner standard your sensors are certified to.
Full technical-file assembly.