ARES-6 — Disaster Rescue Spider Robot

An interactive 3D hexapod robotics simulation that runs in the browser. Dark cinematic field-test console: a procedurally built six-legged rescue robot in a collapsed-structure test site, with real inverse kinematics, simulated sensors, telemetry, mission scripts and a fault-injection scenario.

Everything is generated in code. No downloaded models, no textures, no external assets.

---

Running it

Three.js is vendored locally (vendor/three.module.js), so the app works fully offline. ES modules need an HTTP origin, so opening index.html from the filesystem will not work — serve the folder instead:

node server.mjs

Then open http://localhost:8080. Any static server works equally well:

python -m http.server 8080

No build step, no npm install, no dependencies. Node is used only to serve files.

---

The five demo moments

Every one of these is a single button in the left panel. Nothing important is buried.

#	What	How to trigger	What to watch
1	Six-legged walking	03 LOCOMOTION → START WALK CYCLE	Alternating tripod gait: FL·MR·RL swing while FR·ML·RR support. The camera follows. Push WALK SPEED to 100% to see it stride.
2	Lidar + thermal scan	06 SENSORS → LIDAR toggle, then SURVIVOR SCAN	Spinning lidar head, 48-ray sweep fan, expanding ground pulse rings, then a scan progress bar and a survivor beacon punching up through the rubble.
3	Claw picks up debris	05 MANIPULATOR → GRAB DEBRIS DEMO	8-phase scripted sequence: approach, descend, grip, lift, traverse, place, release, stow. The slab is really re-parented into the gripper and really ends up in the drop zone.
4	Scout drone	07 SCOUT DRONE → LAUNCH DRONE	Rotors spin up, vertical climb to 2.6 m, banked orbit around the robot. Turn on DRONE CAMERA FEED for a live picture-in-picture downlink rendered from the drone's own camera. RECALL DRONE flies it home and docks it.
5	Failure + recovery	08 MISSION PRESETS → M-05 SYSTEM FAILURE TEST	Mid-right actuator faults: motor temp climbs 40 → 96 °C, hydraulics sag to 143 bar, damage hits 34%, the chassis develops a visible tremor, the leg row blinks red, warning lights strobe. Then hit ⚡ AUTO-STABILIZE to watch it fully recover.

Keyboard shortcuts: W walk · L lidar · T thermal · K searchlight · G grab demo · D drone launch/recall · S survivor scan · X failure test · Z auto-stabilize · R reset · 1–5 missions · F frame the robot.

Camera: left-drag orbit · wheel zoom · right-drag (or shift+drag) pan · double-click re-centre. The camera follows the robot until you pan; F re-locks it.

---

Architecture

index.html          layout shell + mount points
styles.css          the entire console design system
vendor/             three.js r160, vendored for offline use
src/
  main.js           boot order, frame loop, drone-cam picture-in-picture
  core/
    state.js        THE single source of truth: store + event bus + command registry + log
    utils.js        math, easing, NaN-safe damping, Sequencer, ring buffers
    context.js      shared runtime refs (keeps the module graph acyclic)
  robot/
    config.js       physical dimensions, leg mounts, joint limits, named poses
    leg.js          closed-form 2-link IK, hydraulic struts, per-leg status LEDs
    robotBuilder.js chassis hull + the full articulated hierarchy
    arm.js          shoulder/elbow/wrist + two-finger claw, attach/detach payloads
    sensors.js      sensor turret, lidar sweep, searchlight, telescopic mast
    drone.js        scout drone state machine + its downlink camera
  scene/
    sceneSetup.js   renderer, camera, lighting rig, fog, dust
    materials.js    shared material/geometry cache + wireframe registry
    environment.js  procedural disaster site
  systems/
    gait.js         tripod / ripple / rotate / climb gaits — owns every foot target
    controls.js     orbit camera (we do not vendor OrbitControls)
    telemetry.js    coupled simulated telemetry
    missions.js     5 mission scripts, grab sequence, scan, fault injection + recovery
  ui/
    ui.js           builds every panel, two-way state binding, HUD, log, timeline
    minimap.js      top-down tactical map

Two supporting files that are not part of the app: CONTRACT.md (the module interface spec the code was written against) and check.mjs (node check.mjs — verifies every module parses as ESM and that every import path and named import actually resolves).

How the robot is put together

robotRoot                    world position + heading
 └ chassis                   ride height + yaw/pitch/roll
    ├ bodyGroup              hull, hazard stripes, status LEDs, rescue beacon
    ├ leg_FL … leg_RR        hip → femur → knee → tibia → ankle → foot
    ├ armRoot                shoulder → elbow → wrist → claw
    ├ sensorHead             yaw → pitch → lidar / camera / thermal / lamps
    ├ mast                   3 telescoping tubes → camera pod
    └ droneDock              anchor the scout drone snaps to

The key design decision: foot targets live in the ground frame, not the body frame. The gait engine decides where each foot should be in world space; the legs then solve to reach it. That is why the legs visibly compensate when you change body height, pitch, roll or yaw while the feet stay planted — and it is what makes the walk cycle read as real.

The IK

Each leg is a closed-form 2-link solve: hip yaw from atan2 to put the target in the leg plane, then the law of cosines for femur and knee, then an ankle rotation that keeps the foot pad level. It was verified numerically before anything was built on top of it — zero forward-kinematics error, the pad stays level in every configuration, and the stance was retuned after the first check showed the legs running 98% extended at maximum ride height with no headroom for step lift. Worst-case reach saturation across the whole operating envelope (0.25–1.10 m ride height × full stride × full step height) is now 0.10.

---

What is real and what is faked

Worth being straight about, since it is a simulation and not a physics engine.

Real:

• The inverse kinematics. Genuine closed-form solve, verified against forward kinematics.
• The gait timing. Body velocity is derived from stride ÷ stance duration, which is why planted feet stay locked to the ground (measured drift: ~3 mm per stance at 30% speed, ~8 mm at 60%, against a 170 mm foot pad).
• State coupling. Power drain, CPU load, motor temperature, hydraulic pressure and signal strength all respond to what you actually switch on. Walking, lidar, the searchlight and an airborne drone each cost power; hydraulic pressure dips on every leg lift.
• The debris grab. The slab is genuinely re-parented into the gripper with its world transform preserved, carried, and released at the drop zone.
• The mission log. Timestamped off the simulation clock, not wall time.

Simplified:

• No collision detection and no terrain following. Feet are placed on the y=0 plane and the robot walks through rubble rather than over it. The obstacle-climb demo is a scripted pose sequence, not a solved climb. This is the single biggest simplification.
• No rigid-body physics — no mass, no contact forces, no tipping. Stability margin, torque and load are plausible simulated numbers, not computed ones.
• Sensors do not raycast against the scene. Survivor probability is derived from true 3D distance to the target, but the lidar rays are a visualisation rather than a range scan.
• The drone camera is a real second render pass, but it runs at half rate (30 Hz) because it re-renders the whole scene.
• The robot is confined to an 8.6 m operating radius; the gait halts at the perimeter rather than letting the feet skate in place.

---

Performance

~750 draw calls, ~35k triangles, 13 shader programs, and roughly 3 ms of simulation work per frame. Measured on integrated graphics (AMD Radeon 660M) it holds up with everything switched on at once — walking, lidar, thermal, searchlight, mast extended, drone airborne and the downlink PiP running.

If you need more headroom: turn off the drone camera feed (it is a second full scene pass), or drop renderer.shadowMap.enabled in src/scene/sceneSetup.js.

Scene layout is deterministic — it is driven by a seeded PRNG, so the site is identical on every reload and looks the same in every take.

---

Debug console

The app exposes a live handle for driving it from devtools:

ARES.run('mission.survivor')   // fire any command
ARES.commands()                // list all 30
ARES.S.gait.speed = 100        // poke state directly
ARES.step(1/60, 120)           // advance 120 frames deterministically
ARES.Ctx.robot                 // the scene graph

ARES.step() runs the simulation without waiting for requestAnimationFrame, which is how the behaviour above was verified.