Design a robot, then prove it actually works

Ask a model to design a robot and you get a confident parts list, a plausible wiring diagram, and no way at all to tell whether any of it is true. Robotic Studio is built the other way round. The model chooses kinds of things and is never allowed to state a figure. Every number on the screen is computed from the parts you actually picked, and shows the formula it used. And a requirement counts as met only when trials say so — with the arithmetic to back it, which is usually less flattering than the ratio you were hoping to quote.

Say what it should do, then write requirements that can be settled

The brief is a sentence: what the robot does, where it works, how it is operated, what it carries and how hard it works. From there you write the requirements it will be judged on, and each one needs a metric and a threshold.

Anything without them is marked unmeasurable on the spot, and at the test bench it says plainly that no trial can settle it. That is not pedantry about wording. An unmeasurable requirement is one nobody can ever be held to, and the cheapest possible moment to find that out is the day it was written rather than at handover, when it turns into an argument between people who each remember agreeing to something different.

The model picks parts. It may never specify one.

Parts come from a catalog of archetypes with typical ranges — a gearmotor, a wheel, a battery pack — not from named products a model half-remembers. Add one and its class typicals fill in so the calculators have something to work with; that part is tagged estimate. Read the real figures off the datasheet in front of you and it becomes confirmed.

When the design needs something the catalog does not carry, the model does not invent it. It opens a gap: a named hole listing the specifications the design requires, which blocks the stage until you fill it from a real datasheet. A hallucinated 4.2 N·m is not a bad sentence. It is an arm that cannot lift itself, discovered after the parts arrive.

The rule that falls out of this runs through the whole app:

You may design on estimates. You may not build on them.

Class typicals are exactly right for sizing a chassis before anything is ordered. They are not right for switching a machine on, so bring-up refuses to start until every part is confirmed and carries a part number — a robot built from typical values is a robot nobody can order twice.

Every number shows its working

Mass budget, power budget, drive sizing against the real DC motor torque-speed line, battery runtime, centre of mass, tip-over margin, wire ampacity, voltage drop, fuse sizing, thermal headroom, first-order beam deflection. All of it is deterministic arithmetic over the parts you chose, unit-tested against worked textbook examples.

Open any card and it shows the formula and the assumptions: that fasteners are not in the bill of materials, that every rail is treated as loaded at once, that the reach is worst-case and static with a 1.5× safety factor. An unqualified number invites trust nobody earned; a number carrying its assumptions is an engineering claim you can argue with.

Cards are also allowed to disagree with you. The runtime card in the shot above reports 15 minutes against a 30-minute requirement and reports it as a fail, because a calculator that only ever agreed would be decoration. Others come back blocked — stability needs the parts placed on the chassis first, so it names the stage to go and do rather than inventing a centre of mass.

Geometry that comes off the datasheet

Chassis plates, brackets and motor mounts are generated from each component's own dimensions and bolt pattern, and export as STL. Change the motor and its mount is marked stale — which is the one thing a mesh you modelled by hand can never do for you.

There is an honest limitation, stated rather than worked around: a through-hole only runs along the extrusion axis, because this deployment has no boolean geometry and parts here are plates and bodies of revolution. An L-bracket with bolt holes in both legs is refused outright. That is two parts fastened together, or a job for the 3D Studio, whose meshes drop straight back in.

Wiring that refuses instead of warning

Nets, rails, a power tree, and wire gauges from published ampacity tables derated for a loom. Pin ratings come off each part's own spec sheet, so the check sharpens as parts get confirmed.

Behind it is a small circuit model rather than a table of nets, because the two most safety-relevant nets in a robot have no ratings of their own: voltage propagates forward from a source through the devices that pass a supply on, and current propagates backward from the loads. Checked net by net instead, switched motor power and a driver's outputs come out with no voltage and no current on them and are silently not checked at all — the exact opposite of where the attention belongs.

The verdicts are refusals, not advice: a supply rail on a logic pin, two supplies tied together, a shorted two-terminal load, an under-rated emergency stop, wire thinner than its current, a fuse that would let the wire become the fuse, an unterminated CAN bus, power without ground. The suggester holds exactly one topology opinion, and it is a safety one — the pack goes to the emergency stop and the stop goes to the drivers, in series, so the stop cuts motor power in hardware and still works when the software is the thing that failed.

It exports a KiCad netlist, and a placed, netted, DRC-able carrier board whose outline and mounting holes are cut from the chassis plate in the same document. The board fits the robot because the board and the robot are one design. Nothing is autorouted: generated routing always needs checking by somebody who could have routed it themselves.

The stack, and the guard that may not share a computer

Nodes, topics and rates with real ROS 2 message types, and sensor rates taken from the datasheets of the parts you chose. One button seeds a Grafy Code project with the whole stack — drivers as skeletons, the watchdog and failsafe written out in full and failing closed.

The refusal that matters here: a watchdog or comms failsafe running on the same computer as the stack it guards is reported as a failure. Whatever stops one stops the other, so on a single-computer robot that guard is decoration. Two publishers on a command topic is refused too, and deliberately not tidied away by namespacing them apart.

The test bench is the point

Protocols say what you will subject the machine to; runs say what happened. Trials arrive typed by hand, imported from a CSV with units in the cells, or posted by the robot itself to a one-way telemetry endpoint. Then the acceptance arithmetic, which is where most tools quietly round in your favour:

Nineteen passes out of twenty is not 95%. The Wilson interval on it runs 76–99%, so a requirement is met only when the lower bound clears the target its priority sets.

An acceptance row can read 19 of 20 met and still say unverified — and it also says how many more consecutive passes would settle it, because a refusal with no route through it is one people learn to route around.

Three more rules keep the evidence worth having. A simulation never closes a requirement: it tests the model, and the model came out of the same design as the robot, so mission-level metrics need field evidence. An excluded trial has to say why — invalid is the only outcome that leaves the denominator, and one with an empty note is stored as a failure. And there is no way to delete a trial at all.

The envelope you tested, not the one you designed

The last stage composes what ships with the machine: a datasheet, an operating envelope, a safety case, a maintenance schedule, a spares list and a written residual-risk section. It holds one opinion above all others — the operating envelope is the envelope you tested. It reads the stimulus levels that actually appear in runs with counted trials and names every level of the vocabulary that does not, so a robot whose drive calculator says it climbs 20° but whose every trial ran on level ground is qualified for level ground, in writing.

Two rules follow. A capability reaches the datasheet only if a requirement covering it is verified, because a calculator sizes a machine and never qualifies one. And a declared interlock with no bring-up trial that fired it is listed as a hole in the safety case rather than quietly left out.

One thing it will never do

It will not command hardware. Telemetry is inbound only: there is no actuation endpoint, no teleop, no button that runs a trajectory, and there will not be one. A web app over the public internet cannot offer the latency guarantees, interlocks and dead-man behaviour that moving a machine requires, and pretending otherwise is how somebody gets hurt.

What you take away

A .robot bundle carrying the design and its evidence, including the design revisions each run cites, so an imported result is never stale by accident — the same provenance discipline as reproducible workflows. Printable parts as STL. A KiCad netlist and carrier board project. A URDF/SDF/MJCF simulation with inertias from the real printed meshes at their real mass. And a share link that shows the validation packet and nothing else, because sending somebody proof that a machine works should not hand them your bill of materials.

Frequently asked questions

Does it design the robot for me?

It does the parts of the job that are arithmetic, and refuses the parts that are assertion. The model selects kinds of components and justifies the choice; every figure attached to them comes from the catalog or from a datasheet you confirmed. That split is the product: a design you can check is worth more than a design that sounds finished.

What actually changes when I confirm a part?

Confirming records that these figures were read off the part in your hand rather than estimated for its class, and it is what unlocks bring-up, trials and validation. Estimates still run every calculator, so you can size a whole machine before ordering anything — you simply cannot switch one on from them, or ask anyone else to build the same robot twice.

Nineteen of my twenty trials passed. Why does it still say unverified?

Because 19/20 is a point estimate and the confidence interval around it runs from 76% to 99%. If the requirement asks for 90%, the evidence has not reached it yet. The row tells you how many more consecutive passes would, so the refusal comes with a route through it rather than a shrug.

Can it drive my robot?

No, by design. Telemetry is one-way and inbound; there is no actuation path anywhere in the app. Commanding a moving machine needs latency guarantees and interlocks a browser cannot give, so that is a different product with its own safety case, not another endpoint on this one.

Do I need KiCad, a printer or a robot to try it?

Not to design one. Everything up to bring-up runs here, and the emitted files are checked structurally on the way out. The first real validation happens on hardware you own — which is precisely why the test bench, and not the generator, is the centre of this app.

What happens to my test results when I change the design?

Every trial cites the immutable design revision it ran against. Swap the drive motors and every drive-performance trial goes stale, saying which change did it, while the perception trials are untouched. Without that, the app would become a machine for showing last month's passing grade on this month's robot.

How is this different from planning a game or a film here?

The pipeline shape is the same one Game Studio uses — staged, gated, with the model writing validated data rather than artifacts. What differs is what a gate means. There, a manual gate exists because the next stage spends money. Here, three stages wait because they move a physical object, and the "run everything automatically" switch deliberately does not reach them.

Open Robotic Studio, or walk through it first in the Robotic Studio tutorial.