Physical validation protocol
Test Protocol & Data Sheets
A repeatable bench-to-chamber protocol for generating evidence on perception, manipulation, verification and recovery. It deliberately separates software demonstration from physical validation.
| ID | Test | Setup | Procedure | Record | Pass condition |
|---|---|---|---|---|---|
| T01 | Endpoint acquisition | Known line on chamber surface | Run perception and identify endpoints repeatedly. | Confidence, location error, misses | Threshold defined before trial; no unmeasured success claim. |
| T02 | Single crossing | Two line segments crossing | Map topology and select a separation action. | State graph, selected action | Correct crossing relation and executable action. |
| T03 | Slack creation | Controlled crossing with limited slack | Acquire, reduce local tension, create separation opportunity. | Force/tension trace, motion, state IDs | No configured development limit exceeded and intended geometry change observed. |
| T04 | Verification gate | Successful manipulation | Compare predicted and observed geometry/physical response. | Expected vs observed, confidence | Commit occurs only after verification passes. |
| T05 | Failed manipulation | Inject controlled action mismatch | Execute action that should fail verification. | Failure reason, rollback state | System does not commit the failed state. |
| T06 | Rollback | Interrupted or failed action | Return to last physically safe verified state where feasible. | State before/after, motion trace | Verified state restored within defined tolerance. |
| T07 | Alternate action | Same fixture after T05 | Select a different manipulation primitive. | Action IDs, outcome | Alternate action completes without violating limits. |
| T08 | Sensor disagreement | Camera/tension data conflict | Inject or reproduce disagreement. | Sensor statuses, controller response | Uncertain transition is not committed. |
| T09 | Module fault | One module unavailable | Trigger actuator/current/watchdog fault. | Fault code, safe state | Motion authority is removed according to validated safety design. |
| T10 | Organization output | Recovered line + output path | Transfer line into straightening/loose-coil fixture. | Output geometry, jams, cycle time | Defined output condition achieved. |
| T11 | Repeatability | Standardized fixture/material | Repeat the same scenario over a predeclared trial count. | Per-trial success/failure + telemetry | Report measured rate; do not generalize beyond tested conditions. |
| T12 | Material expansion | Second material class | Repeat core tests after calibrated parameter changes. | Material, diameter/stiffness, results | Material-specific evidence established before claiming coverage. |
Per-trial data sheet
RUN ID · DATE/TIME · OPERATOR · MATERIAL · LENGTH · DIAMETER/SECTION · FIXTURE ID · INITIAL STATE ID · ACTION ID · MODULES · SENSOR CONFIDENCE · FORCE/TENSION TRACE · MOTOR CURRENT · EXPECTED CHANGE · OBSERVED CHANGE · VERIFICATION RESULT · STATE AFTER · FAULT CODE · ROLLBACK STATE · OPERATOR INTERVENTION · VIDEO/FRAME REFERENCES · NOTES
Evidence ladder
- Simulation: validates software flow and fault logic.
- Bench: validates individual sensing and module behaviors.
- Integrated chamber: validates perception-to-action loop.
- Repeatability: establishes measured performance under declared conditions.
- Material expansion: establishes which flexible-line classes are actually supported.
Research boundary: Cable manipulation and unweaving already have published robotics approaches, including graph-based state representations and recovery policies. citeturn0academia0turn0academia2turn0academia3 The purpose of this protocol is therefore to generate evidence for this proposed architecture and to expose exactly which elements remain engineering hypotheses.
Requirements & acceptanceValidation dashboardPrototype BOMControl package