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.

​
AMR — ISO 3691-4

This pattern is for Autonomous Mobile Robot vendors pursuing ISO 3691-4 conformity. For vendors selling into the US market, the pattern extends to dual-claim with ANSI/RIA 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-platformWhy
Risk assessment per ISO 12100 with detection-zone analysisDrives the scenario grid
Certified safety scanners (IEC 61496-3) from supplierTheir certs reference; you integrate
Detection-zone geometry definitionPinned 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 / fixtureSpot-validation anchor

​
Project setup

1

Pin the standards stack

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:
rbtk standard pin ansi-ria-r15-08-1-2023 --project acme-amr/firmware
2

Declare detection zones

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

Build the scenario grid

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:
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.
4

Author the requirements

Requirements are coarse-grained — one per (speed band, payload band, scenario category). See ISO 3691-4 derivation example.

​
Test patterns

The dominant test is a parameterised stopping-distance assertion: 
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:
ScenarioWhat it tests
step_out_from_rackOperator emerges from behind a static obstacle
low_contrast_palletBlack pallet on dark floor
partial_sensor_occlusionScanner partially blocked by dust simulation
pinch_point_corridorNarrow corridor, operator in path with no escape
mixed_traffic_amr_amrTwo AMRs approaching, both must yield
manual_mode_safetySafety functions remain active in manual mode
recovery_no_restartVerifies 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

EventAction
ISO 3691-4 amendmentRe-conformity workflow
New AMR variant in the product lineNew project (or new repository in the same project); apply the same pattern
New scanner / lidar modelRe-verify the requirements that derive from the sensor’s IEC 61496-3 characteristics
Field incident reportAd-hoc pack scoped to the field-build’s commit; investigate; add new scenarios; re-verify
New customer site with different environmental constraintsSite-acceptance testing is off-platform; reference the site-specific tests in the evidence pack

​
Next steps

ISO 3691-4 standard page

Standard reference.

ANSI/RIA R15.08

Dual-claim for US market.

IEC 61496

The scanner standard your sensors are certified to.

EU MR conformity

Full technical-file assembly.