Hux

3D sandbox

Drive the working model around a course with real rigid-body physics. Same geometry and lump masses as the drawings; the actuators and the MCU are drawn from the vendors' STEP files when the page is served (envelope boxes otherwise). Every motor is a torque with a limit. The LQR balance loop uses delayed ideal state and simulator contact loads; a physical estimator remains unimplemented. First pass: a place to play and to find where the design breaks, not the digital twin.

Model 2026-09-27
6" × 1.25" wheel
7.5" + 7.5" tubes
24" tall · 14" wide
Loading physics…

Drive W A S D or arrows (Shift for more) · Ride height Q / E, the slider, or Low / Medium / High · Hip roll Z / X · Modes 1 Parked, 2 Two wheel, 3 Left only, 4 Right only · Space shove · R reset · K kill motors · C camera · P pause · Mouse wheel zoom. A gamepad works: left stick drives, right stick sets height and hip roll, A shoves, B resets.

Wheel torque, last 10 s

Knee and hip roll torque, last 10 s

Lean of the mass over the axle, last 10 s

What the robot depends on

Working assumptions, not decisions. Torque limits apply live. Mass, CoM and the skid rebuild the robot where it started.

What this is and is not

  • Physics. Rapier rigid bodies at 2 kHz: body, two hip yokes, four carbon tubes, two wheels, Coulomb friction, real contacts with the stair, sills and crates.
  • Motors. Every joint has torque-speed limits and a first-order response, updated at 2 kHz. Joint stops and nonadjacent self-collisions are enabled. The in-wheel motors lose torque linearly to the assumed no-load speed. Parking requires the support skid; without it the request stops motion while keeping balance active. Emergency motor-off remains separate.
  • Suspension. Each leg is a virtual spring-damper along the hip-to-axle line (3.5 Hz, 0.6 damping by default) with the leg angle held stiff. A real Hux can only do this with torque-controlled, backdrivable joints (FOC / QDD class) or real springs. A position servo or a stepper cannot.
  • Reflexes. A leg that is hit hard at speed hops its wheel up for about a tenth of a second. A wheel stopped dead by an edge at walking pace hops too. When the mass runs away, the legs swing and the hip rolls step the wheels under it. The current implementation uses ideal simulated state.
  • One wheel. Left/right buttons request a planned sequence: stand tall, stiffen, shift the mass over the planted wheel until the other carries about 15%, hold, then centre. The HUD reports actual support, requiring both low free-wheel load and ground clearance before reporting single support. With a hop time set, the free wheel comes up for that long with the hip rolls held stiff (no one-wheel balance), the robot tips toward the free side, and the wheel goes back down: dynamic single support, what a stair step needs. The balanced one-wheel stand is an acrobot with a few millimetres of capture region on this geometry and stays experimental — docs/research/one-leg-stance.md.
  • Balance. LQR on the lean of the mass over the axle, rebuilt as the legs change height, at 500 Hz. Roll levelling by leg length and leg force. It uses delayed ideal state and contact samples. A physical state and load estimator remains to be implemented.
  • Tire. One shared profile (tire.js): a 6″ × 1.25″ tread with a full-round crown, the shape a scooter pneumatic takes on a narrow rim. The collision hull, the mesh and the 2D projection all come from it, so the contact point walks around the crown as the wheel cambers instead of catching an edge. Each tire is a tread ring on a carcass spring (stiffness and damping are knobs; 40 kN/m is a guess for a high-pressure 6×1.25, not a measurement), so the wheel squishes and shifts sideways on the hub and the HUD reports the pad that deflection implies. Rapier still resolves the contact at points; the pad is an estimate, not a resolved patch. The ring's rolling error is measured separately.
  • Not modelled. Motor inertia through the gearbox, backlash, belt stretch, tube flex, battery sag, current limits, temperature and sensor noise. Delay and drive response are adjustable assumptions, not measured hardware. No stair-climb controller yet: the stair is there to drive up to.

Findings and how to rerun them: docs/research/sim-sandbox.md. Headless check: node tools/living-drawings/sim-test.js.