Hardware Readiness¶
Use this checklist before running DAM against physical robot hardware. It is intentionally practical: confirm the environment, validate the Stackfile, then move from monitor-style learning to enforce-style operation only when the signals make sense.
Before Connecting Hardware¶
- You completed Quick Start without hardware.
make validatepasses for the example Stackfiles.- You can explain the task name and active boundaries in your hardware Stackfile.
- You know how to stop the robot outside DAM.
- The robot workspace is clear and the physical stop procedure has been tested.
Check The Hardware Stackfile¶
For the SO-ARM101 example:
Confirm:
| Field | What to verify |
|---|---|
hardware.sources.arm.port |
Matches the connected serial device |
| Camera sources | index_or_path values match local cameras |
policy.device |
Uses a device supported by your machine |
safety.enforcement_mode |
Starts from the mode you intend |
tasks.soarm101.boundaries |
Contains only boundaries you want active |
Run In Small Steps¶
- Validate:
.venv/bin/dam validate examples/stackfiles/so101.yaml - Inspect:
.venv/bin/dam inspect examples/stackfiles/so101.yaml - Start with a short controlled run:
- Watch the console for guard decisions and latency.
- Stop and review any reject, fault, repeated clamp, or latency warning.
What To Watch In The Console¶
| Signal | Why it matters |
|---|---|
| Guard status | Shows which layer is making decisions |
| Event log | Shows recent clamp, reject, fault, and control events |
| Risk gauge | Summarizes current risk state |
| Cycle latency | Shows whether the loop is staying inside budget |
| MCAP Sessions | Lets you inspect safety events after the run |
Do Not Continue If¶
- The Stackfile does not validate.
- The selected task name is wrong.
- Hardware health boundaries reject immediately and you do not know why.
- Console latency is repeatedly over budget.
- You cannot stop the robot independently of DAM.
Return to Troubleshooting or Console Walkthrough before continuing.