Body, Brain and Structure

1The loop

RSIH, recursive self improvement for hardware, is a design engine intended to get better at design with every project it runs. This paper reports its first complete pass. The engine has three layers: a language model that frames the problem and writes the project¹⁷; a pipeline of stages that turns the project into a robot; and a library of verification checks, the gates, that decide whether each stage's output is credible before the next stage uses it.

Stages communicate only through files. Every intermediate result can therefore be audited and every stage re-run on its own, and every figure in this paper reads one of those files.

What a human writes, and what comes back

There is no target mass, length or height anywhere in the system. Those are outcomes.

2The body

The body is a parametric family. Sixteen continuous variables set every dimension, and three categorical genes choose an actuator for the abduction, hip pitch and knee joint groups from a catalogue of two quasi direct drive modules: the RobStride RS03 (0.88 kg, 60 N·m peak, $214) and the RS04 (1.42 kg, 120 N·m peak, $267).

Every bound follows one rule: a bound may encode a physical limit, never an expected answer. The minimum thigh length, for example, is the largest actuator's radius plus a pivot boss, so it moves if the catalogue changes. Because the optimiser is continuous, each actuator gene is a number between 0 and 1 mapped onto the catalogue (1).

The hip pitch and knee actuators share one axis at the top of the thigh, and the knee is driven by a pushrod, so the knee actuator's mass sits at the hip rather than on the swinging leg. The stack sits forward of the abduction actuator, on the roll axis, rather than to the side. On a reference body this reduced the abduction joint's inertia from 0.0923 to 0.0479 kg·m² and its worst gravity holding torque from 4.27 to 1.40 N·m.

3One policy for every body

Scoring a body requires a controller to walk it. Training one for each of 288 candidates would take weeks, so a single policy is trained across a distribution of bodies and then frozen^4,5. To drive a body it has not seen, the policy must know which body it is in, so its observation includes a description of its own morphology (2).

The features are the 16 normalised design variables, four ratios (reach over 0.6 m, shank over thigh, mass over 25 kg, thigh over trunk) and the three actuators' peak torques. The last group lets the policy distinguish a 60 N·m knee from a 120 N·m one.

Vectorised GPU physics varies only the dynamic fields of the model across environments, so the features cannot be stored as metadata. Each environment must recover its body's description from its own physics fields, which requires the compile step to be invertible (3).

Actuator identity is recovered from the actuator force range, the only dynamic field it affects. An early test of this condition passed for months without being able to fail, because it never varied the actuators; Section 8 returns to this.

The policy is trained with proximal policy optimisation⁶ across 4096 parallel simulated environments^7,8,9.

4Searching bodies

With the policy frozen, scoring a body is a rollout of about 25 seconds across all six scenarios. CMA-ES^10,11 searches the 19 dimensional space, 16 variables and 3 actuator genes, in 24 generations of 12. The objective is the weighted mean return less a steep penalty when the body demands more of its actuators than they can give (4).

Here u_rms is the worst joint's RMS torque over its continuous rating, which governs motor heating, and u_peak is its peak torque over the transient rating. This duty constraint replaces a target mass: a heavy body is penalised not for its mass, but because the motors it chose cannot carry it.

The search converged on the lighter actuator at every joint. Among feasible bodies, those with the RS03 throughout have a median mass of 16.0 kg against 21.9 kg for bodies with any RS04, at a slightly higher median score (1.80 against 1.77). Refitting the winning geometry with an RS03, RS04, RS04 set, a plausible human choice, adds 4.3 kg and $424. The optimiser declined to spend either.

5The task suite sets the scale

The search converged on a small robot: 17.9 kg for the best scorer, and 14.8 kg for the lightest feasible body, which stands 139 mm tall. This is not a failure of the optimiser but a consequence of what the task suite rewards.

A task suite must contain something the robot can only do by being big enough, or size becomes an artifact of how hard control is.

An obstacle height, a sensor height, a payload that cannot be carried otherwise. This is a specification problem rather than an optimisation one, and it does not show in the aggregate scores: nothing in Fig. 7 looks wrong. Later projects of the engine make it a required input, the capability floor.

6Loads measured from behaviour

The best body is walked by its policy through all six scenarios for 10 seconds each at 250 Hz, giving 60,000 samples per channel. At each step, inverse dynamics gives the wrench each body part applies to its parent. The wrench is transferred to the joint and resolved along the member's axis into the four loads a beam is sized by (5), and each design load is a safety factor applied to its 99.9th percentile (6).

Before any load reaches a part, the extraction must reproduce statics on the same body. Standing still, the four ground reactions must sum to the body's weight, and the force at each knee must equal its foot reaction less the weight below the knee. On this run both hold exactly: 176.8 N = 176.8 N and 45.4 N = 45.4 N¹⁶.

7Generating the structure

Each member is generated by three dimensional topology optimisation on a 6 mm voxel grid, using the SIMP formulation^12,13,14. The solver keeps material where it carries load and removes it elsewhere, minimising compliance within a volume budget (7).

Interfaces where actuators bolt on are forced solid, actuator envelopes and access channels are forced empty, and the volume budget applies to the remainder. The solver runs matrix free on the GPU in double precision and stops with an error if its residual does not converge. Its result is a density field between 0 and 1, and a part is obtained by choosing where to cut it.

Two stresses are reported because they answer different questions. The field value evaluates grey elements with solid stiffness, so it overstates stress and never understates it. The binarised value re-solves the part as exported. Every part passes the 30 MPa allowable of PA12-CF. The stress fields in Fig. 12 were recovered by rebuilding each part's finite element problem from the run's own loads and interfaces and re-solving the binarised part; all five peaks reproduce the reported binarised values to within 0.05 MPa. With the pushrod, the generated structure totals 4.84 kg, against the 5.09 kg the search assumed.

Volume fraction is not a monotone knob

Below a certain volume fraction the cut must drop to keep the load path connected, which brings grey material into the part and makes it heavier and weaker at once. The shank in aluminium weighs 0.230 kg and peaks at 358 MPa at a volume fraction of 0.05, against 0.190 kg and 69.5 MPa¹⁶ at 0.08. Each part is therefore taken to its own governing point, which is why the table shows five different values. The thigh needs 0.38 in PA12-CF where every other part needs between 0.08 and 0.15: it carries 20.3 N·m of torsion, sixteen times the shank's, and the solver builds it as two booms with no web. For this part the printed material is the wrong choice, and the pipeline shows it with numbers.

8Designing for silent failure

The most useful finding of this run is not that the pipeline works but how it failed. Almost every defect produced a complete run, plausible numbers and a valid mesh. Optimisation pipelines coupled to physics rarely crash; they answer a different question from the one asked, confidently and in the same format as a correct answer.

Each gate below was written after a specific silent failure, and each has since caught a real one. Every gate is mutation tested¹⁵: the code it guards is deliberately broken to confirm that the gate fires. Break any of them to see what it guards against.

A gate you cannot make fail is not a gate.

One gate is incomplete. The statics check compares force magnitudes, and |f|² = F_ax² + F_sh² about any axis, so a wrench resolved about the wrong axis passes while reporting axial load as shear, which is exactly the error that mis-sizes a member. The fix, a third identity projected onto the member's own axis, has not yet been written.

9What makes it recursive

A pipeline that designs a robot is a generator. What makes the engine recursive is the path back into the tool. In the companion paper¹⁷, a language model frames the problem, writes the robot's project against a fixed interface, runs the stages in order at the right cost and reads the results back. The model performs none of the numerics, and the pipeline makes none of the decisions. When a diagnosis cannot be settled from the results, the model writes a new gate into the shared library, and every later project inherits it.

The gates in Section 8 are the record of that loop, run by hand. Whether each project measurably improves the next has not yet been tested; that requires a fixed benchmark of design tasks.

10Conclusion

A legged robot can be designed from a task description to printable structure by one pipeline, in about 2.5 hours on one GPU, with every number traceable to the files the run wrote. Its results follow from what it was given: the duty constraint, not a target mass, chose the lighter actuator, and a task suite with no reason to be large produced a small robot. Its most useful lesson is how such a pipeline fails: silently, with complete and plausible output. Verification gates written for each such failure, and inherited by every later project, are how a design engine of this kind improves with use.