Double pendulum · mimo-v2.5

Let me build the simulation. I'll write index.html with a double pendulum using RK4 integration, canvas rendering, fading trail with hue cycling.

Key details:
- Equal masses m1=m2, equal lengths L1=L2 (say 1 unit each, e.g., 150 px scale).
- Gravity 9.81.
- Initial angles 120° and -10° from downward vertical, zero angular velocities.
- RK4 with small dt (e.g., 1/240 or 1/600), fixed substeps per frame.
- Trail: store points of lower bob, fade based on age, draw with hue gradient, bounded length (e.g., 600 points).
- Pause/Resume, Reset buttons.

Equations for double pendulum (standard):

θ1'' = (-g(2m1+m2)sinθ1 - m2 g sin(θ1-2θ2) - 2 sin(θ1-θ2) m2 (ω2²L2 + ω1²L1 cos(θ1-θ2))) / (L1(2m1+m2-m2 cos(2θ1-2θ2)))

θ2'' = (2 sin(θ1-θ2)(ω1² L1 (m1+m2) + g(m1+m2)cosθ1 + ω2² L2 m2 cos(θ1-θ2))) / (L2(2m1+m2-m2cos(2θ1-2θ2)))

Or use the matrix form solved directly. I'll use the standard form.

Let me write it, then run browser checks.

Then verify: sample at several moments, pause/resume, reset. I can use the browser tool with motion/screenshot and also expose some state to check (e.g., window.__sim state). Let me implement with a debug hook: window.doublePendulum with getState(), pause(), resume(), reset().

Let me write the file.

Design: dark background, canvas 900x700 or responsive. Controls bar with buttons and readouts (time, energy maybe). Energy check is a good stability indicator — display total energy to confirm stable integration.

I'll make canvas fit within viewport with devicePixelRatio scaling.

Let me write code carefully.

Physics code:

const G = 9.81, M1 = 1, M2 = 1, L1 = 1, L2 = 1 (simulation units), scale px per unit.

deriv(state): returns [ω1, ω2, α1, α2].

α1 numerator: -G*(2*M1+M2)*sin(t1) - M2*G*sin(t1-2*t2) - 2*sin(t1-t2)*M2*(w2*w2*L2 + w1*w1*L1*cos(t1-t2))
denom: L1*(2*M1+M2-M2*cos(2*t1-2*t2))

α2 numerator: 2*sin(t1-t2)*(w1*w1*L1*(M1+M2) + G*(M1+M2)*cos(t1) + w2*w2*L2*M2*cos(t1-t2))
denom: L2*(2*M1+M2-M2*cos(2*t1-2*t2))

RK4 standard.

Fixed timestep accumulator: dt = 1/600 s sim time per step, accumulate real elapsed, cap steps per frame (e.g., max 40 steps) to avoid spiral of death. Speed multiplier 1x.

Trail: array of {x,y,age} in simulation coordinates or pixel? Use world coords (unit coords), convert at draw. Fade: each point has life; alpha = (1 - age/maxAge). Store trail points each render frame (or each integration step downsampled). Cap at e.g. 900 points, maxAge ~ 2.2 s. Also draw as segments with hue based on time.

Better: draw trail as polyline segments with per-segment color and alpha, using lineWidth tapering. Use 'lighter' composite maybe.

Energy: E = KE + PE. KE = 0.5*m1*v1² + 0.5*m2*v2², withv1² = L1²ω1²
x2 = L1 sinθ1 + L2 sinθ2, y2 = -L1cosθ1 - L2cosθ2 (downward positive? Let's define y down positive in screen coords: y = L*cosθ measured downward). I'll compute positions:
x1 = L1 sinθ1, y1 = L1 cosθ1 (down positive)
x2 = x1 + L2 sinθ2, y2 = y1 + L2 cosθ2
vx2 = L1ω1cosθ1 + L2ω2cosθ2
vy2 = -L1ω1sinθ1 - L2ω2sinθ2
PE (relative to pivot, down positive → height = -y): U = -m1 g y1 - m2 g y2.

Energy drift check displayed.

Controls: Pause/Resume toggle button, Reset button. Also maybe speed slider — not required, skip or add small. Keep minimal but nice: showθ readouts, energy drift.

Trail should be cleared on reset.

Also "Keep pendulum visible": scale so that total length 2 units maps to fit; pivot near top-center with margin. Canvas 900x760; pivot at (450, 340)? Max reach 2L downward = 2*scale. With scale 150, reach 300 px → pivot y340 gives bottom 640, canvas 760 fine. Angles can go anywhere, radius 2L = 300px around pivot; ensure pivot centered horizontally with ≥ 300 px margin: canvas width 900 → 450 margin. Height: need300 above pivot too? Pivot y340, top reach 40. OK.

Use fixed canvas size 900x720 with CSS scaling to fit viewport (max-width 100%, aspect ratio). DPR handling: set canvas.width = 900*dpr etc. Simpler: fixed internal resolution 900x720, CSS scales. Slight blur acceptable but let's do DPR-aware: internal size = cssSize*dpr, draw in world→screen transform. I'll do a straightforward: compute layout in CSS pixels with scale factor derived from min(width, height) mapping. Let's keep it manageable: canvas CSS size responsive via container; on resize, recompute. World-to-screen: scale = Math.min(w, h - 60) / (2*TOTAL_LEN * 1.15)? Simpler: scale = (Math.min(w,h) * 0.42) / L_total where L_total = 2. pivot at (w/2, h*0.44).

Trail in world coords → converted at draw, so resize-safe.

Let me write it now. Also add pause overlay maybe. Keyboard space toggles pause, R resets.

Then browser verification: reload, screenshot, use inspect to evaluate state at several moments. The browser tool has "inspect" action which likely returns DOM/console; can I evaluate JS? Not sure. I could add a status readout in DOM showing θ1, θ2, time, energy drift which I can read via inspect/screenshot. That gives me sampling at several moments.

Let's write the file.

Trail rendering details:
- points pushed each frame (with world coords), each has t (sim time).
- maxTrail = 800 points, but frame-rate dependent; better push points at fixed sim-time intervals (every 1/60 s of sim time) inside the integration loop, so trail density consistent. Do that: while accumulating, if simTime >= nextTrailTime, push point.
- Fade by age: alpha = clamp(1 - age/TRAIL_LIFE). Remove points older than life (shift from front).
- Color: hue = (baseHue + age*-30) % 360 or based on speed.

Drawing: iterate segments, strokeStyle hsl with alpha, lineWidth from thick to thin. Use ctx.globalCompositeOperation='lighter' for glow on dark bg.

Now the frame loop:

let last = performance.now(); accumulator.
frame(now): real dt = min((now-last)/1000, 0.1); last=now. if !paused: acc += dt*speed; while(acc >= DT && steps < MAXSTEPS){ integrate(DT); acc -= DT; steps++ }. Draw.

Energy drift display updated each frame.

Write the HTML.

Also verify coupled motion: sample θ values at various times, ensure chaotic-ish, rods connected (positions computed from angles — always connected by construction, but verify visually), trail follows lower bob.

Let me write.

Now run it in the browser and verify. Let me reload and inspect.

Rendering looks good. The pendulum starts at 120° and -10°. Energy drift is tiny (1e-10), indicating stable RK4. Now let me sample the state at several moments using the inspection hook to verify coupled motion, rod lengths, and trail.

The trail is showing, colorful fading. Energy drift is small (3e-7 after ~9s). Now let me check the getState values via JS. The inspect tool returned DOM, not JS evaluation result — the `text` param maybe types text? Let me try browser inspect without text, or maybe there's a way to evaluate. The inspect action description: "inspect DOM/console". The text param might have typed into something. Hmm, I passed text as JS code; unclear if evaluated. The DOM readout shows values anyway.

I need to sample rod lengths from getState. Maybe I can display that info in the DOM by temporarily... Actually a simpler approach: add rod length check into readout? That'd clutter UI. Alternative: use browser "type"/"click" tools. There may not be an evaluate tool. 

Option: temporarily modify the page to write getState JSON into document.title or a hidden element, then inspect. Or I can just do the numeric verification in Node (no browser needed) by extracting physics functions — but the requirement is verifying in browser behavior.

Let me just have the page expose rod-length info in the DOM readout subtly: e.g., add a hidden div updated each frame with rod lengths. Actually simplest: I can add rod length to the readout line only if there's drift... Better: add a `#roDebug` div with `display:none`? Inspect output might not include hidden text.

Alternative: I can verify rod lengths by computing positions: bobPositions is derived from angles with fixed L1=L2=1, so rod lengths are constant by construction. The screen drawing uses those. Math.hypot checks confirm.

Practical approach: temporarily add a visible debug element, inspect, then remove it. Or permanently add a small "rod check" indicator — actually a subtle readout "rods: 1.000/1.000" could be a nice stability indicator. Let me add it to readout — it's informative and lets me verify. Hmm, keep UI clean; I'll add it temporarily then remove.

Actually, a cleaner approach: put debug info in document.title and check via inspect? The inspect output doesn't show title. Let me add a temporarily-visible debug span, inspect, then remove it.

Let me do that: edit index.html to add `<span id="dbg">` in readout, updated in updateReadouts with JSON of getState. Then reload, sample a few times, click pause/resume/reset, verify, then remove the debug span.

Let me do it.

Wait — updateReadouts is called before window.pendulum is defined during boot (reset() calls updateReadouts before window.pendulum assignment). window.pendulum is assigned at the end of the IIFE, but reset() runs in boot section after... Let me check order: Controls section defines reset; Boot calls resize(); reset(); ... then window.pendulum is defined AFTER boot. reset() calls updateReadouts() → window.pendulum is undefined → crash. I need a guard or move pendulum definition before boot. Let me add a guard: `if (window.pendulum) {...}`. Simpler and safe.

window.pendulum is defined at the bottom, before boot. Boot runs at the very end. updateReadouts is called in reset() during boot... Actually window.pendulum is assigned before boot runs? Let me check order: the code defines window.pendulum then boot section? Let me look at the file order.

In my file: Controls, Main loop, Boot, then window.pendulum assignment is inside... actually window.pendulum is at the very end after boot. reset() is called in boot which calls updateReadouts which references window.pendulum — which is not yet assigned. The guard handles it. Good.

Now reload and check.

Rod lengths stay exactly 1.0000, trail grows. Now test pause: click the Pause button, check state freezes (t stops advancing, angles constant), then resume, then reset.

Paused. Now verify time doesn't advance while paused — inspect again after a moment.

Time frozen at 5.63 s, angles unchanged, trail unchanged at 133. Pause works. Now resume and check motion continues.

Resume works — time advanced past 5.63 and angles changing. Now test Reset: should restore θ1=120°, θ2=-10°, ω=0, t=0, trail cleared.

Reset worked: back to θ1≈120°, θ2≈-10°, trail cleared (3-4 points, the old long trail is gone visually), energy drift back to ~1e-12. The starting pose matches the initial screenshot.

Everything verified. Now remove the temporary debug span to keep the UI clean. Actually, the debug readout (L1/L2/trail) is arguably useful, but it was meant as temporary. I'll remove it to keep the UI as designed... Actually it's a nice stability indicator. Hmm — "Provide Pause/Resume and Reset" — extra readouts are fine. But the rod length/trail debug line feels dev-ish. I'll keep the energy readout and remove the debug span for a cleaner final UI.

Let me remove the dbg code and re-verify quickly.

The debug readout was actually somewhat informative, but the requirement says keep it simple. Actually the L1/L2/trail info is a nice stability indicator... but I removed it for cleanliness. Fine. Reload and check for errors, let it run a while.

Clean, no errors, no debug readout. Let it run ~20s and take a final screenshot to check long-run stability and trail.

After 48 seconds of chaotic motion, energy drift is still only 1.5e-6, the pendulum stays on screen, the rods remain connected, and the trail is bounded and fading nicely (older segments faded to dim teal, newest bright pink). Everything works.

Done. Final file is index.html. Let me confirm the file exists.