ASCENT

There is a real flight computer running in this browser tab.

Ascent is the public demo of OpenBMP (Open Body Motion Platform), an open-source, academic, simulation-only research platform for launch-vehicle-class flight dynamics written in Rust. The entire simulation stack — six-degree-of-freedom rigid-body kernel, EGM2008 gravity, US Standard 1976 atmosphere, synthetic sensors, and the in-loop flight software — is compiled to WebAssembly and steps inside a Web Worker on your machine. Nothing is pre-rendered, there is no server, and no trajectory is keyframed: every frame you see is the state of a live numerical simulation.

What is real here

• Navigation. An extended Kalman filter fuses a synthetic tactical-grade IMU, a GNSS receiver, and a star tracker — with innovation gating, bias estimation, and dead-reckoning fallback. The flight computer never reads simulation truth; it flies on what its sensors tell it. The ENGINEERING overlay plots the difference live.
• Control. A three-loop autopilot commands engine gimbals (thrust-vector control) with per-phase gain schedules, plus a closed-loop max-Q load-relief law that throttles to hold dynamic pressure at the structural limit — watch the q strip-chart flatten at 26 kPa.
• Guidance. A closed-loop insertion law flies the booster phase; Powered Explicit Guidance (PEG) steers the upper stage and commands engine cutoff from its own time-to-go estimate.
• Sequencing. Mission phase transitions are owned by the flight computer's commander, and the SECO event fires on the guidance solution — not on a script reading the true state.
• Staging. The jettisoned booster is propagated as an independent six-degree-of-freedom body; in the boostback scenario its own controller flips it retrograde and fires the recovery burn.

What is synthetic

The vehicle — we call it Phalcon-9 — is a wholly synthetic two-stage kerolox launcher with rounded, order-of-magnitude class figures. It is not a model of any fielded vehicle, it contains no SpaceX data, and this project is not affiliated with or endorsed by SpaceX (the resemblance is the homage every two-stage kerolox rocket pays to physics). The aero model in this scenario is an axial drag deck; the scenario carries the validated-toy label, which in OpenBMP's verification vocabulary means: validated against first-principles orbital-mechanics invariants (vis-viva, angular-momentum and energy conservation on the coast) — and nothing stronger.

OpenBMP is not validated for operational flight, not suitable for hardware deployment, and not a substitute for any qualified flight-software stack. Outputs are for engineering education, simulation research, and controller prototyping. See the project's non-suitability disclaimer and scope boundaries.

The sandbox: disturb and observe — never steer

The SANDBOX panel exposes the simulator's fault-injection seams: terminal engine shutdown, thrust loss, gimbal lock, sensor outage windows, and a wind override. These are the same simulated-malfunction paths OpenBMP scenarios declare for FDIR studies. There is deliberately no command that steers the vehicle: guidance, navigation, and control stay onboard, and the host can only perturb the world and watch the flight software cope — the same forward-only observation boundary the project's software-in-the-loop bench enforces.

Every stimulus is logged against the simulation step clock. The simulation is bit-deterministic, so SHARE RUN produces a link that replays your exact flight — faults, gusts, and all — on anyone else's machine.

How it works

The Rust workspace compiles unchanged to wasm32-unknown-unknown (the kernel and flight-computer crates are no_std-portable and deterministic by construction). A stepping Session API drives the same code path as the native one-shot runner — the two are byte-identical by construction and pinned by test. The scenario files and every data file they reference are embedded at compile time and verified against their SHA-256 pins exactly as on disk. The renderer is three.js; the simulation posts a flat telemetry snapshot ~30 times a second from a Web Worker. The wasm payload is ~1.6 MB gzipped and runs hundreds of times faster than realtime, which is what the time-warp buttons spend.

Credits & licences

• Simulation, flight software, and this demo: OpenBMP, dual-licensed Apache-2.0 / MIT.
• Earth texture: NASA Earth Observatory “Blue Marble” (NASA imagery is not copyrighted; NASA does not endorse this project).
• three.js, MIT licence (vendored).
• Stars, vehicle, and plumes: procedural, generated from the scenario definition.