A ground-up experimental rocketry project and the local-first AI workstation built to operate it: internal-ballistics simulation, airframe optimization, instrumentation, flight analysis, agent orchestration and a shared MCP tool layer.
Author: Sebastián Velandia · Electronic Engineering Status: ongoing · Focus: agentic systems, instrumentation, simulation, flight dynamics
AI engineering entry point: Rocketry Console · agent workstation architecture · technical plan
This repository contains two connected engineering layers:
- Rocketry engineering: simulation, data acquisition, flight analysis and open-source contributions to OpenRocket.
- Rocketry Console: a local agent workstation that lets Codex and Claude operate the same bounded engineering services through a shared MCP server.
The second layer is the most relevant part of this repository for an AI Engineering review.
| Capability | Evidence in this repository |
|---|---|
| Agent orchestration | A Starlette gateway manages durable Codex and Claude sessions, streaming events over WebSockets, approvals, interruption, recovery and provider adapters. |
| MCP integrations | A shared stdio MCP server exposes bounded engineering tools with explicit read-only/local-write annotations, progress reporting and structured errors. |
| Stateful systems | SQLite persists sessions, events and approvals; per-session locks and scoped workspace validation protect concurrent operations. |
| Safe execution | Sessions can use isolated Git worktrees; review/merge is explicit, and the MCP surface does not expose ignition or arbitrary shell execution. |
| Full-stack delivery | Python services, a Tauri/Rust desktop shell and a TypeScript/React interface share the same domain contracts. |
| Verification | Python unit checks, desktop tests, browser E2E tests, visual baselines and Rust compilation checks are documented in the console README. |
This is a concrete example of building an agent around tools, state,
permissions and recovery—not only calling an LLM from an HTTP endpoint. Start
with the console architecture, then inspect
console/gateway/ and console/rocketry_mcp.py.
Amateur experimental rocketry is one of the few disciplines where a single person touches the whole engineering chain — thermochemistry, internal ballistics, compressible flow, aerodynamics, structures, and avionics. This repository documents that chain end to end, including the parts that failed and what they taught, because honest failure analysis is where the engineering actually happens.
Everything here was driven by one discipline: measure before you trust, and change one variable at a time.
| Motor | 25.4 mm minimum-diameter KNSB (potassium nitrate / sorbitol) BATES-grain motor, F-class, designed from a headless internal-ballistics sweep |
| Key safety finding | A Kn in the "safe" 200–280 range is not sufficient — 120 Kn-valid configurations all violated port/throat or mass-flux limits. All four limits must hold simultaneously |
| Airframe | The aluminium motor tube is the airframe (true minimum diameter). Optimized in OpenRocket: +64 % apogee from fin-profile and finish alone — the nose shape was irrelevant at Mach 0.77 |
| Avionics | Custom ESP32 data-acquisition system: live Nyquist/aliasing demonstration, frequency-domain (FFT) analysis, and interrupt-driven sampling (0 µs jitter vs. 233 µs), ADC calibration (159→38 mV), and a full pipeline dry-run recovering a known 72.7 N·s impulse to within 3.7 % |
| Open source | The simulation seed never reached OpenRocket's wind models, so every turbulent run was irreproducible — diagnosed, fixed, and merged upstream (#3188). A second fix, for a stable rocket aborting as if tumbling, is under review (#3183 → PR #3190) |
| Section | What's inside |
|---|---|
| 01 · Internal Ballistics | Motor design, the Kn-isn't-enough finding, burn-rate sensitivity, nozzle retention |
| 02 · Flight Simulation | OpenRocket airframe study, the +64 % optimization, stability, wind |
| 03 · Propellant & Static Test | Characterization methodology and the static-test post-mortem (engineering-level) |
| 04 · Avionics DAQ | ESP32 sampling system, Nyquist/aliasing demonstration, results |
| 05 · Open-Source Contribution | Two OpenRocket bugs: the spurious tumble abort and the unseeded wind model — diagnosis → fix → deterministic validation |
| 06 · BIRST 2026 | International OpenRocket simulation tournament: rules, timeline, scoring, and where this project's upstream work bears on it |
simulation/internal-ballistics/ # Python sweeps over openMotor's motorlib
simulation/flight/ # OpenRocket driven headless via JPype
avionics/daq-fase1/ # ESP32 firmware + Python capture/plot
images/ # result figures
docs/ # engineering write-ups
MEASURE ESTIMATE CONTROL
(DAQ, done) → (sensor fusion) → (active TVC)
This project is at the measure stage. The data-acquisition system is the instrument that turns the next static test into real numbers (the measured burn-rate coefficient), which in turn unlocks a data-grounded flight design.
This is a documentation and engineering-analysis repository. It deliberately does not include propellant synthesis procedures or quantities. All physical testing described followed a static-test-first methodology and standard amateur safety practice (remote ignition, stand-off distance, physical barrier). Nothing here should be treated as instructions to manufacture energetic materials.
Python · openMotor (internal ballistics) · OpenRocket (flight, driven via JPype) · PlatformIO / ESP32 (Arduino framework) · matplotlib
MIT — see LICENSE.