APEX-1 — flight software for a rocket I'm about to build
The inspiration
Ever since I was a child, I’ve been fascinated by space. I believe one of the most meaningful things we can do is push civilization forward on the Kardashev scale and help humanity reach the stars.
In 2020, watching the SpaceX Crew Dragon launch from my home in Argentina marked a turning point for me. I decided that I wanted to build an aerospace company in Europe—helping ensure the region remains a leader in deep-tech innovation rather than falling behind global powerhouses. Every day, step by step, I work to move the needle toward that vision.
APEX-1 is the foundational step of that journey: building the flight and ground software to track an amateur model rocket. While the physical flight hardware is en route, the software layer is already fully functional.
The Engineering Focus Before launching hardware, the most valuable asset isn't the physical frame—it's the flight software that transforms raw, noisy sensor data into a live telemetry stream you can visualize in real time.
APEX-1 is that software pipeline. Currently running on a Software-in-the-Loop (SIL) simulator, it is architected so that plugging in a physical ESP32 flight computer requires zero changes to the ground station. For instant demonstration, the deployed web dashboard features an automatic client-side flight fallback, allowing anyone to view a simulated mission live from anywhere.
How I built it
Four layers share a single wire contract — one JSON frame per sample at 50 Hz — defined in protocol.py and implemented by the simulator, the ground station, and even the browser's demo mode:
- Firmware (ESP32, C++) — BMP280 barometer + MPU6050 IMU over I2C, a six-phase flight state machine (PRE-LAUNCH → BOOST → ASCENT → DESCENT → PARACHUTE → LANDED), barometric altitude referenced to a pad captured at launch, and 0.3 s debounced touchdown detection to ride out pressure noise.
- Simulator (Python) — 1-D flight model with quadratic drag, semi-implicit Euler at 50 Hz. Critically, the wire carries only noisy sensor readings — never ground truth — so the ground side cannot tell it apart from a real flight.
- Ground control (FastAPI) — receives UDP JSON, validates every frame, keeps a 24 s rolling buffer, relays to the browser over WebSocket, and replays the last 400 frames on connect.
- Dashboard (vanilla JS, zero dependencies) — an "Iron Man HUD": hand-built SVG gauges, canvas time-series charts, link-stale detection, and flight event markers (BOOST END, CHUTE, LANDED), deployed to GitHub Pages.
The sensor model uses the international barometric formula, with 1 hPa of Gaussian noise added:
$$P(h) = 1013.25 \left(1 - \frac{0.0065\,h}{288.15}\right)^{5.2558}$$
That equation taught me the most: 1 hPa of pressure noise is ~8 m of altitude noise — good enough to display, not enough to land on.
What I learned
- A single source of truth for the protocol. The C++ firmware mirrors the Python schema field-by-field, and every sync point is explicitly commented.
- Robustness belongs at the edges. Instead of inventing binary framing, I layered per-frame validation, history replay, auto-reconnect, and flight-reset detection (mission-time rewind) on top of plain UDP/WebSocket.
- Honest sensor modeling is a feature. Ground truth is logged to CSV separately, feeding a planned Phase 3: ML landing prediction.
Challenges I faced
- IMU velocity drift — integrating raw acceleration diverges; documented and solved next with sensor fusion.
- Keeping three implementations in sync — Python, C++, and the browser demo all speak the same contract.
- Testing without hardware — the simulator's
--selftestruns a full flight and checks seven numeric invariants (peak altitude within 190–230 m, specific force ≈ +g at rest, correct phase sequence, mean baro error < 12 m) with a non-zero exit code on failure.
The README is honest about what's approximate and why — and what the fix will be (touchdown switch, sensor fusion, landing prediction).
The next steps
Once the physical components arrive, I will assemble the rocket airframe, integrate the ESP32 flight computer, and flash the embedded firmware. From there, I will conduct full hardware-and-software validation tests and document the bench testing process on video.
Beyond this initial build, I have co-founded Litoral Systems—an initiative dedicated to building, scaling, and documenting increasingly ambitious aerospace and deep-tech projects in the future.
Log in or sign up for Devpost to join the conversation.