Mission and requirements
This step has run. Its results are below — read them, then move on.
Mission
Requirements
Every requirement needs a measurement, or no trial can ever settle it.
Architecture
Every subsystem this form factor needs.Bill of materials
Suggested for this form factor
Click one to add it. Every row is a class estimate — confirm each against a real datasheet.
Confirming means these figures were read off the part in your hand — not estimated for its class. Bring-up will not start until every part is confirmed.
Mechanical design
Still outstanding
Link chain
Each link is a joint and the arm past it. Lengths and masses are what the joint torques are worked out from.
Ground contacts
Where it touches the floor. Three or more, or tipping cannot be checked.
Part geometry
A mount is cut from the component's own dimensions, so its bolt circle is the one on the datasheet. Generated meshes are for shells and covers.
Electrical design
Every pin carries what it can survive. Nothing here is advice — a rail on a logic pin is refused, not warned about.
Nets
Power tree
What feeds what, and how much goes down each branch.
Add a net
Carrier board
The outline and the mounting holes come from the chassis plate in this same design, so the board fits the robot. Placed and netted, never routed — generated routing always needs checking by somebody who could have routed it themselves.
What this board check assumes
Software stack
Nodes, topics and rates. A guard that shares a computer with the thing it exists to catch is refused, because whatever stops the one stops the other.
Safety interlocks
Nodes
Topics
Add a node
Timing
A timeout is a distance once you multiply it by the speed this robot promises. Both numbers are below.
Simulation
Composed from the design — every figure here came off the bill of materials or a datasheet. Nothing in the export was generated to fill a hole.
Kinematic preview
Joint angles in, link positions out. No contact, no friction, no motor dynamics — a clean sweep here is a reach and self-collision check, and not a passed physics test. That is what the exported scene is for.
Scenarios
One per measurable requirement, so a simulation run is always a test of something somebody promised.
Bring-up
The checklist before the first switch-on, built from this design's own numbers. The four marked safety have to be recorded before any campaign run can be opened — everything else is good practice.
Test bench
Protocols say what you will subject it to; runs say what happened. A requirement is met when the lower bound of the interval clears its target — nineteen passes out of twenty is 76–99%, not 95%.
Acceptance
Protocols
Add a protocol
Runs
Run
Log a trial
Trials
Import a campaign
A CSV with a header row, or a JSON list. Cells may carry their own unit
— 0.62 m/s. Columns nobody can read are named back,
never dropped quietly.
Telemetry
One-way, inbound. There is no endpoint here that commands anything, and there must never be one: a web app cannot offer the latency guarantees a moving machine needs. Post with a scoped API key for this app.
Validation
What ships with the machine. A capability appears here only if a trial demonstrated it — a calculator sizes a robot, it never qualifies one — and the operating envelope is the one you tested, not the one you designed.
What it does
Operating envelope
Anything in the right-hand column was never tried, and is outside what this packet supports.
Safety case
Maintenance and spares
Residual risk
Written down rather than left out. Every line is a true statement about the limits of the evidence above.
Share the packet
A link that shows this packet and nothing else. Sending somebody proof that a machine works does not hand them the bill of materials, the wiring or the brief it was built from.
Print packet
Safety declaration
Yours to declare, never ours to assume. Each of these is a statement about hardware that exists.