Prior art: the toolchain gyropup should build on

Research date: 2026-10-25. Stars, licences and "last push" dates come from the GitHub API on that date. PyPI versions and release dates come from pypi.org/pypi/<name>/json on that date. Where a capability could not be confirmed from a repo, its docs or a local test, the text says not documented or not verified. Some behaviour was checked locally against the gyropup venv (Python 3.12.3, MuJoCo 3.17.0, CadQuery 2.8.0, RTX 3080 12 GB, driver 580.178.04, Ubuntu 24.04). Those results are marked (tested locally).

The gyropup loop this survey serves: parametric design → CadQuery CAD → URDF + MJCF with CAD mass properties → scenarios (balance, push, drive, slope, curb, squat, hop) with a baseline controller → loads → FEA of printed parts → manufacturability and cost → optimiser or agent → repeat. Later: RL in Isaac Lab, deployed to a Jetson AGX Orin 32 GB.

Executive summary

1. Nobody has built a CadQuery/build123d → URDF/MJCF exporter worth adopting. GitHub searches for "cadquery urdf", "build123d urdf", "cadquery mujoco" and "build123d mujoco" turned up only one zero-star hobby repo. All the mature exporters are tied to a GUI CAD tool: onshape-to-robot (Onshape), fusion2urdf, solidworks_urdf_exporter, phobos (Blender) and freecad.cross. So keep our own small writer, but:
   • build the MJCF with MuJoCo's official mujoco.MjSpec API rather than XML strings;
   • copy onshape-to-robot's conventions: closing_* loop markers become MJCF <equality>, plus joint_properties, geom_properties, frames as sites, and a generated scene.xml;
   • gate every URDF with the vendored cadgen urdf validate;
   • hand the Isaac side to NVIDIA's own converters, urdf-usd-converter and mujoco-usd-converter. Isaac Sim 6's importers are built on them.
2. Closest existing robot: Upkie. Upkie (Apache-2.0) is an open wheeled biped with exactly gyropup's joints: hip, knee and wheel per leg. It comes with a PD/MPC balancer and an RL velocity task in mjlab (MarcDcls/mjlab_upkie, Apache-2.0). This is the nearest template for both the baseline controller and RL.
3. Fastest path to "load a generated robot and score it on a drive course": plain MuJoCo 3.17 on the CPU, which is already installed, plus our own scenario harness and an LQR/VMC baseline. Port the LQR from Upkie's examples, or from the RoboMaster "balance infantry" pattern (LQR gains fitted as a function of leg length, see RP_Balance, MIT). No simulator framework currently ships a wheel-legged scenario suite we could reuse.
4. Fastest path to RL: mjlab (Apache-2.0, pip, Python 3.10–3.13). It is Isaac Lab's manager-based API running on MuJoCo Warp, so it trains on the same MJCF the evaluation loop uses, with no USD conversion step. Isaac Lab 3.0 (released 2026-10-20) now has the same API on a Newton/MuJoCo-Warp backend, with Isaac Sim optional. That gives a clean upgrade path for rendering, sensors and the Isaac Sim tooling later. Note that Isaac Lab 3.0 targets Isaac Sim 6.2, while we have 6.0.
5. Actuators: model them at the MuJoCo layer, not in our own code.
   • MuJoCo now has a native <dcmotor> actuator (3.7.0), with electrical dynamics, cogging, LuGre friction and a winding-temperature state. That last one is exactly what the Diablo "15 min squat" limit needs.
   • MuJoCo also has actuator delays (3.5.0) and a system-identification toolbox (3.5.0). MuJoCo Warp supports dcmotor and the delay history.
   • mjlab and Isaac Lab both ship a linear torque–speed DcMotor model, delay models and learned actuator nets. Isaac Lab adds a BamActuator on the Newton backend only.
   • BAM, which Open Duck Mini uses, identifies extended friction models. Its model library covers only Dynamixel, Feetech and eRob, not CubeMars, Robstride or Damiao.
6. FEA in the loop: gmsh (pip) for meshing plus scikit-fem (pip, BSD-3, only numpy and scipy) for fast linear-elastic screening. Use CalculiX (apt install calculix-ccx, GPL-2.0) as the high-fidelity check. It supports orthotropic printed-part materials (*ELASTIC, TYPE=ENGINEERING CONSTANTS) and contact. Loads come from MuJoCo force/torque sensors placed on sites at each joint, or from efc_force for loop-closure constraints.
7. Optimiser: Optuna 5.0 (MIT, September 2026) is the orchestrator. It handles categorical and conditional component choices, multi-objective search (TPE is now the default there), a first-class trial.set_constraint(), a stable GPSampler with qLogEHVI, and shared storage for parallel workers. One catch: Optuna's pruning (its multi-fidelity mechanism) does not work for multi-objective studies. We run multi-fidelity as staged evaluation with early rejection, and keep BoTorch MOMF (multi-objective multi-fidelity) or SMAC3 as the upgrade. Use pymoo NSGA-II on the cheap analytic model and pycma for controller gains.
8. Web: a static three.js page.
   • urdf-loader draws the robot.
   • A JSON qpos trajectory replays the sim run. MuJoCo's official WASM bindings (@mujoco/mujoco on npm, Apache-2.0) can replay or re-simulate in the browser instead.
   • GLB meshes with baked vertex colours show stress.
   • Rerun .rrd files, embedded with @rerun-io/web-viewer, cover engineering debugging.
   • Avoid Foxglove: the open-source repo is archived and the product is now proprietary.

1. CAD → robot description

1.1 Comparison

1.2 MuJoCo URDF import quirks (checked in the docs and the parser source, and tested locally with MuJoCo 3.17.0)

• Compiler defaults differ for URDF: fusestatic and discardvisual are "true" for URDF and "false" for MJCF (XML reference). Since 3.7.0, strippath defaults to false for URDF and you set it yourself (changelog).
• URDF is not schema-checked: "mis-typed attribute names are silently ignored" (modeling guide). MuJoCo recommends converting to MJCF once and then working in MJCF.
• Local test with a three-link URDF:
  • The root link is fused into world, so there is no free joint. A floating-base robot needs one added.
  • Fixed-joint children are fused into their parent.
  • No actuators are created (nu = 0), and <transmission> is ignored.
  • <limit effort> becomes the joint actfrcrange, while <limit velocity> is dropped. The parser has the comment "no maxvel in MuJoCo" (xml_urdf.cc).
  • <dynamics damping/friction> becomes damping and frictionloss.
  • <mimic> becomes a joint equality constraint (eq_type = mjEQ_JOINT).
• Conclusion: generate MJCF directly, with free joint, actuators, sensors and equalities, and treat the URDF as a secondary output for ROS, Isaac and the browser.

1.3 Closed loops (four-bar knee transmission)

Recommendation: emit two models from one design.

• gyropup_closed.xml: the true linkage, with connect equalities. It drives the evaluation and load extraction, because four-bar link loads exist only here.
• gyropup_serial.xml / .urdf: the serial equivalent with reflected inertia. It drives RL, Isaac import and the browser.

A test checks that both models give the same foot trajectory and joint torques under quasi-static loads.

1.4 Install

pip install robot_descriptions yourdfpy urdf-usd-converter mujoco-usd-converter   # mujoco 3.17 already installed
uvx --from cadgen==0.7.26 cadgen urdf validate path/to/robot.urdf                 # vendored validator (version from text-to-cad skill)

2. Wheel-legged simulation and control baselines

2.1 Open-source wheel-legged projects

2.2 Simulator and RL frameworks

2.3 Recommendation

• Evaluation loop (now): plain MuJoCo on the CPU plus our own scenario harness.
  • Each scenario (balance, push, drive course, slope, curb, squat, hop) is a Python function: MJCF in, metrics out.
  • Baseline controller: a wheeled-inverted-pendulum LQR whose gains are scheduled on leg length (the RP_Balance pattern), with leg-length and roll handled by a PD/VMC layer.
  • Upkie's pd_balancing.py and mpc_balancing.py are the Python references (Apache-2.0, safe to adapt). The LQR is recomputed for every design from the MJCF's own linearisation (mujoco.mjd_transitionFD). Each new design then gets a fair, tuned controller rather than fixed gains.
• RL (next): mjlab, starting from mjlab_upkie's velocity task. Borrow reward and curriculum ideas from Wheel-Legged-Lab (jump, clearance, obstacle) and TRON1 (privileged critic, velocity estimator, ONNX export). One MJCF serves evaluation and training, so there is no USD drift.
• Isaac Lab 3.0 later, when we need Isaac Sim rendering, sensors or ROS. The task code ports, because the manager API is the same.
• Avoid porting Isaac Gym projects (legged_gym, Wheel-Legged-Gym, tita_rl): Isaac Gym is deprecated and stuck on Python 3.8. Read them for reward terms only.

# mjlab (needs uv); our venv is Python 3.12, within mjlab's 3.10–3.13
git clone https://github.com/mujocolab/mjlab.git && cd mjlab && uv run demo
git clone https://github.com/MarcDcls/mjlab_upkie.git && cd mjlab_upkie && uv sync
uv run play Mjlab-Velocity-Upkie --checkpoint-file logs/rsl_rl/upkie_velocity/bests/default.pt
pip install upkie          # Gymnasium envs + PyBullet balancers for reference
# Isaac Lab 3.0, kit-less Newton/MuJoCo-Warp path
git clone --branch v3.0.0 --depth 1 https://github.com/isaac-sim/IsaacLab.git
cd IsaacLab && uv run isaaclab train --rl_library rsl_rl --task Isaac-Cartpole --viz newton_gl physics=newton_mjwarp

3. Actuator models for simulation

Recommendation. Use one actuator description in the catalog and the design, rendered three ways:

1. Level 0 (every evaluation): a linear four-quadrant torque–speed clip, plus reflected rotor inertia (armature = rotor inertia × gear²), frictionloss, damping and a command delay. The formula is identical to mjlab's and Isaac Lab's DcMotor, so evaluation and RL agree.
2. Level 1 (squat, endurance and hop scenarios): MuJoCo <dcmotor> with thermal and saturation, built from datasheet R, Kt and thermal resistance. It answers "how long can it hold a crouch", which the Diablo spec sheet shows matters.
3. Level 2 (after hardware arrives): a bench log, then the mujoco.sysid fit (and BAM if the joint is geared and friction-dominated). An actuator net is a last resort.

4. Structural analysis (FEA) in the loop

4.1 Comparison

CadQuery/build123d + FEA integration projects: none of note. Searches for "cadquery fea", "cadquery gmsh", "build123d fea" and "cadquery calculix" found only 0–1-star templates (mechanical-model, LLM-FEA-Bench). The pattern is well established in the literature, for example FeaGPT: gmsh's Python API, physical groups for fixed and loaded faces, CalculiX .inp, first-order tets for complex geometry. We write the ~300-line glue ourselves.

4.2 Getting loads out of the simulation

• MuJoCo <sensor><force site=…/> and <torque> give "the interaction force between a child and a parent body, expressed in the site frame". The sensor "takes into account all forces acting on the system, including contacts as well as external perturbations" (XML ref). Put a site at every joint and every bolt interface, log the 6-axis wrench in every scenario, and keep the per-part worst cases (max |F|, max |M|, and the combined case at peak von Mises from a unit-load superposition).
• Whole-body alternative: mjData.cfrc_int (computed by mj_rnePostConstraint).
• Loop-closure (four-bar) pin loads: the equality-constraint rows of mjData.efc_force in the closed-loop model.
• Isaac Lab's PhysX backend exposes body_incoming_joint_wrench_b (found in the Isaac Lab repo); availability on the Newton backend is not verified.
• Turning a load into an FEA case: apply each wrench as a distributed traction (RBE3-style) on the bolt-hole faces of the part, with the opposite interface fixed. Use superposition of six unit cases per interface, so one solve per part covers every logged time step. That makes FEA cost independent of scenario length.

4.3 Printed-material modelling

FDM parts are weakest across layers (Z). Practical tiers, cheapest first:

1. Isotropic with a knock-down: E and allowable stress from the Z-direction (worst-case) datasheet value of the filament, safety factor ≥ 2–3. Works in scikit-fem today.
2. Transversely isotropic or orthotropic stiffness, oriented by the part's print orientation, with a Tsai-Hill or max-stress check per direction. Use SfePy's general D matrix, a custom scikit-fem form, or CalculiX TYPE=ENGINEERING CONSTANTS.
3. Infill homogenisation: not needed while we print structural parts at high infill.

The constants must come from filament datasheets or coupon tests. None of these tools supplies FDM material data.

4.4 Recommendation and install

• In the loop: CadQuery STEP → gmsh (OCC import, size field, physical groups) → scikit-fem linear elastic, P2 tets, isotropic knock-down. Output: max von Mises, safety factor and max deflection per part, plus a per-vertex stress field for the web viewer.
• Verification (top-N designs or flagged parts): the same mesh → CalculiX with orthotropic material (and contact at bolted joints if needed) → ccx2paraview → pyvista.

pip install gmsh "scikit-fem[all]" meshio pyvista ccx2paraview
sudo apt install calculix-ccx

5. Design optimisation

Recommendation.

• Outer loop: Optuna 5 multi-objective study. Objectives: cost, mass, a performance score aggregated over scenarios, and worst-part safety factor (or keep the safety factor as a constraint). Categoricals cover motors, wheel, battery, material and leg topology. Constraints use trial.set_constraint().

• Multi-fidelity, implemented by hand. Optuna cannot prune multi-objective studies, so staging happens inside the objective:

  1. analytic budget model (ms), rejecting via constraint;
  2. CAD + mass properties + a short balance sim (seconds);
  3. the full scenario suite (minutes);
  4. FEA on parts that survive.

  A failed gate returns penalised values plus a violated constraint.

• pymoo NSGA-II pre-screens on stage 1 alone, which seeds Optuna with good regions.

• pycma tunes controller weights inside stage 3, so each design is compared with a tuned controller.

• Switch to BoTorch MOMF (or SMAC3) only if stage-3 cost becomes the bottleneck. That would be RL-in-the-loop.

pip install optuna pymoo cma            # core
pip install botorch ax-platform smac    # only if/when needed

6. Web visualisation (designer)

Recommendation. The designer stays a static page.

• three.js + urdf-loader draw the serial model. The robot is animated from a compact run.json: time, qpos and a few metrics per frame.
• Each printed part has a part_stress.glb with a von Mises colour ramp baked into vertex colours, toggled per part.
• @mujoco/mujoco is added when we want "press play and push the robot" in the browser, using the same MJCF as the evaluation loop.
• Rerun .rrd files are linked from each evaluation report for deep inspection.

npm i three urdf-loader @mujoco/mujoco @rerun-io/web-viewer
pip install rerun-sdk viser

7. Recommended stack for gyropup

Licence notes

• Everything recommended for the code we ship is permissive: MIT, BSD, Apache-2.0 or MPL-2.0.
• GPL (gmsh, CalculiX, ccx2paraview, pygccx) is fine for internal tools invoked as libraries or subprocesses. Keep these as optional extras in the public MIT cad-agent repo.
• AGPL TetGen: avoid.
• No-licence repos (DDT Diablo RL, MuShibo, Open_Duck_Playground, L-SY): read for ideas, do not copy code.
• GPL-3 Skythinker616: read for ideas, do not copy code.

Open questions and risks

1. Isaac version mismatch. Isaac Lab 3.0 targets Isaac Sim 6.2 and CUDA 13.0. Our vp-isaac-sim is 6.0 dev. The kit-less Newton path avoids the mismatch for training.
2. Isaac closed loops. PhysX loop handling ("Exclude From Articulation") is manual, and whether the importers do it is not documented. This is why RL uses the serial model.
3. Converter maturity. urdf-usd-converter and mujoco-usd-converter are alpha, and contype/conaffinity collision filtering is not converted. Expect to check self-collision settings after every import.
4. Motor data. CubeMars, Robstride and Damiao have no identified sim models anywhere we looked. Budget a bench rig: one leg actuator, a load arm, a CAN logger, then mujoco.sysid.
5. Printed-material constants. These come from datasheets or coupons, not from any tool. Treat early safety factors as screening numbers.