From Design to Print: An Open Platform for Designing and Validating Strandbeest Walkers

The parts#

• Designer (in the browser): drag the 13 linkage lengths and watch the foot path, with labelled joints; let a genetic algorithm evolve it in the browser.
• Fabrication: from one design file, printable STLs for bars, crank arms (a gripping bore at the shaft end, a loose hole at the crank pin), a phase jig, spacers, standoffs, a motor bracket and a shaft coupler, plus a bill of materials, assembly notes and printability checks. Bars are assigned to layers (parts sharing a pin, or sweeping through each other as the crank turns, must not share a layer); I verified with a finer angular step than the planner uses that no two bars in a layer collide over the whole crank cycle. The web UI has a moving 3D assembly preview and a single-part STL view.
• Simulation: a planar MuJoCo multibody simulator driven by a scenario file. Parameter sweeps, a persistent job queue (jobs survive restarts), stored and reproducible runs. Beside it sits an independent solver, K2 (planar rigid bodies, true Coulomb dry friction, sharing no contact code with MuJoCo): on slow flat-ground walking the two agree on stride per revolution to 0.58 % and on start wind to 4.4 %, which is E1 (two independent solvers agree).
• Lab: import raw test-rig data as a measurement with a quality report, overlay it on a simulation, and fit pad stiffness and friction.
• Test rig (hardware/): rig design, calibration procedures, five experiments (E0 to E4), ESP32 firmware, a notebook template; the ArUco video tracking lives in packages/rig.
• Community data intake (docs/HOW-TO-MEASURE.md): a bilingual “how to measure a walker” guide, a Measurement submission format and a validator, so a stranger can follow the guide and hand in a submission that passes validation.

What is real and what is not#

• Nothing has touched real hardware. The firmware’s logic core is unit-tested on the host, but the Arduino glue was never compiled; part recommendations are classes, not verified models; the exported parts contain assumptions (motor hole spacing, coupler, press-fit offset) and the first print will need adjusting.
• Calibration has only been checked on synthetic data. That shows the import, compare and fit chain is sound, not that real data will give physically meaningful values. One step further: on synthetic data contact stiffness and friction are not identifiable — the posterior intervals cover most of the prior, the point estimates must not be used, and the intervals themselves are the result.
• Torque level depends on how friction is treated numerically (previous post), so the UI reports a range, not a single number.
• The simple model’s start wind and peak torque are not validated. The model’s own start wind is now 0.489 m/s (bracket 0.479–0.500; criterion: one revolution from rest within 40 s), but the thing most likely to spoil that number is not a wrong model — it is pin friction: at just 0.5 mN·m per joint the required wind rises to 1.02–1.07 m/s (+110 % to +160 %). Pin friction is the biggest unknown here, and only a measurement can settle it.

Try it#

1
./scripts/setup-python.sh && source .venv/bin/activate
2
strandbeest-api                                   # backend
3
pnpm install && pnpm --filter @strandbeest/web-demo dev   # web UI
4
# or all at once: docker compose up --build

Issues and PRs welcome, and real measurements most of all: they are what is missing. The repository has a written guide, “How to measure a walker” (docs/HOW-TO-MEASURE.md, bilingual), so that a submission following it passes validation — what is missing now is not the channel but the data.