§ Recipe

SO-ARM101 on Raspberry Pi 5.

Wire a 6-DOF arm to Claude. Feetech driver on /dev/ttyACM0; named poses; one signed run-bundle to verify. About 30 minutes.

Time · ≈ 30 min Hardware · SO-ARM101 + Raspberry Pi 5 Driver · feetech Difficulty · cookbook+

Step 01 — Bill of materials

What you need.

Step 02 — Install

robot-md + the SO-ARM101 actuator.

The cookbook covers the Claude Code plugin install path. For this recipe we install via pipx directly so you can wire the actuator package alongside.

$ pipx install robot-md
$ pip install so-arm101-actuator   # published as part of the actuator catalog

Verify the actuator advertises itself:

$ robot-md actuators list | grep so-arm101

Step 03 — Author

Generate a ROBOT.md for this hardware.

robot-md init auto-detects USB devices on /dev/ttyACM* and proposes a starter manifest. Accept the SO-ARM101 preset:

$ robot-md init --preset so-arm101

The generated ROBOT.md binds the feetech driver to /dev/ttyACM0 and seeds a ready named pose that holds the arm extended forward (wrist_flex centered so the STS3215 servo can hold indefinitely against gravity).

Step 04 — Register

Mint an RRN.

Same as the cookbook — register with RRF to get a Robot Registration Number. The registration generates the keypair the run-bundle cryptographically binds to.

$ robot-md register

You'll get back an RRN of the form RRN-000000000XXX. Save it; the audit bundle (Step 06) verifies against this identifier.

Step 05 — Talk to Claude

Run a skill from the agent surface.

In the same directory as your ROBOT.md, open Claude Code (or your chosen MCP-aware agent) and ask:

"What can this robot do?"

Claude will read ROBOT.md and report the declared capabilities. Then ask it to move the arm to the ready pose:

"Pose the arm at ready."

The gateway runs a dry-run first; the named-pose move requires no HITL gate, so it'll execute on confirmation.

Step 06 — Verify

Inspect the signed run-bundle.

Every action goes into a RCAN-signed run-bundle. List recent bundles:

$ robot-md bundles list --limit 5

Pick the most recent runbundle_* ID and verify it end-to-end:

$ robot-md bundles verify runbundle_<ID>

You'll see each action signed, the pose decomposition, and the RRF countersignature. The bundle is curl-verifiable from https://rrf.robotmd.dev/v2/run-bundles/runbundle_<ID>.

Where safety is meant to be enforced.
Physical limits are meant to be enforced at Layer 3 (robot-md-gateway and the actuator driver it calls), and only for commands that pass through it. OpenCastor (Layer 4) does not embed the gateway yet, so actuators it drives directly are not covered. Declaration alone (Layer 1) does not enforce safety. Agent host alone (Layer 2) is not the safety boundary. If a deployment lacks Layer 3, no safety claim attaches to it. Layer 3 is not a certified safety function, and hostile-input testing in simulation (October 2026) found motions it does not yet bound.