Spacecraft Attitude Control Sim

Premise

A working scratchpad for the first question every attitude control trade study asks: how many reaction wheels do I really need, and which arrangement survives a failure? The classic answers — three orthogonal for nominal three-axis control, four in a pyramid or tetrahedron for one-fault tolerance — are well-trodden in heritage design, but they live as static charts in textbooks. This page lets you wiggle the parameters and watch the consequences.

The simulator runs entirely in your browser. There is no shared state; your edits and your sim are yours alone. Refresh to reset.

What it models

Rigid-body attitude dynamics with a body-frame quaternion, Euler rotational equations, and reaction wheel stored angular momentum. Wheel torque is allocated across the active set by a pseudo-inverse of the spin-axis matrix; failed wheels are pulled from the allocation and their stored momentum is either coasted, depowered, or dumped into the spacecraft body (bearing seize), depending on which failure mode you arm. Optional RCS torque assist is available when the wheel set runs out of authority.

The vehicle shape, mass, dimensions, and diagonal inertia are all editable. Wheel layout flips between three orthogonal, four-wheel pyramid, and four-wheel tetrahedral configurations. Disturbance injections — release impulse, docking contact, appendage snap — let you see how the controller recovers, or doesn't.

Shape presets

Cylinder, cube, flat-stack, hex prism, capsule, asymmetric

Wheel layouts

3-orthogonal · 4-pyramid · 4-tetrahedral

Failure modes

Coast · slow depower · bearing stop

Disturbances

Release · docking · array snap

Telemetry

Wheel speeds · body rate · attitude error · authority condition

Stack

Vite · React 19 · Three.js

What it's not (yet)

An engineering prototype, not a validated flight design tool. The dynamics are textbook rigid-body; flex modes, jitter, gyroscopic coupling between wheels, and sensor noise are not modeled. The control law is a simple PD with feed-forward, not a tuned mission controller. Treat numbers here as directional, not authoritative — the validation cases and source-backed model references that would elevate this to a design-evidence tool are on the queue.

Why this exists

The longer-term ambition is to use the same scaffolding to ask sharper questions that heritage charts don't answer cleanly: how does CG offset interact with wheel arrangement under a fault? When is a tetrahedron actually better than a pyramid for a given inertia ratio? What is the minimum RCS thruster set that retains controllability through any single thruster failure, as a function of spacecraft shape? Each of those becomes a parametric sweep on top of this engine; the interactive front end is the first usable surface for it.