ReEntrySim

Don't just plan a launch — simulate whether the booster can come back.

Comment

Inspiration

Most launch planning tools answer one question: can we reach orbit?

For reusable rockets, that is only half the mission. I must also decide whether a booster can safely and economically return under changing upper-level winds, sea state, booster health, fuel margin, and customer deadlines.

I was inspired by real mission-control workflows: compare multiple futures, explain trade-offs, keep a human in the loop, and leave an auditable record. That led me to ReEntrySim Lite — a mission-planning sandbox where an Agent doesn't just chat about launches; it simulates recovery outcomes and recommends a plan humans can approve or reject.

Don't just plan a launch. Simulate whether the booster can come back.

What it does

ReEntrySim Lite is a single-page world-model Agent for reusable rocket launch and booster recovery planning.

A mission planner can:

  1. Choose a scenario (e.g. LEO cargo with droneship recovery, fresh booster, heavy payload)
  2. Run simulation on three candidate plans (Plan A / B / C) with different launch times and recovery modes
  3. Watch the Agent work through a 5-step MongoDB MCP pipeline (load → simulate → persist → aggregate → recommend)
  4. Explore trajectories on a 3D Earth globe (real launch sites, ascent arc, reentry descent to recovery zone)
  5. Trigger anomalies (e.g. early sea-state deterioration) and see the Agent replan
  6. Approve or reject the recommendation and export a Mission Readiness Report

The executable world model scores each plan on payload success, recovery success, and risk. A simple stochastic layer adds mission-day variance so repeated runs feel closer to operational uncertainty.

Example score intuition (simplified):

$$ S_{\text{payload}} = \mathrm{clamp}\bigl(S_0 + \sum_i \Delta p_i + \varepsilon_p,\ 0,\ 99\bigr) $$

$$ S_{\text{recovery}} = \mathrm{clamp}\bigl(R_0 + \sum_j \Delta r_j + \varepsilon_r,\ 0,\ 99\bigr) $$

where \(\varepsilon_p, \varepsilon_r\) are sampled per run from a seeded distribution that widens under worse weather and booster constraints.

Important: ReEntrySim is a simulated planning demo, not flight software.

How I built it

Architecture

Next.js UI  →  Agent runtime router  →  Gemini reasoning
                    ↓
              MongoDB MCP (find / insert-many / aggregate)
                    ↓
              MongoDB Atlas (scenarios, runs, reports)

Tech stack

Layer Technology
Frontend Next.js 16, React 19, TypeScript, Tailwind CSS 4
Agent reasoning Google Gemini (gemini-2.5-flash)
Agent orchestration Google Cloud ADK sidecar (FastAPI + Python)
Database tools MongoDB MCP Server (find, insert-many, aggregate)
Persistence MongoDB Atlas
Visualization react-globe.gl + Three.js (NASA Blue Marble)
World model Rule-based simulatePlan() with stochastic variance

Agent workflow (MongoDB MCP)

  1. find — load mission scenario from MongoDB
  2. World model — score Plan A / B / C locally
  3. insert-many — persist simulation run
  4. aggregate — analyze historical recovery stats
  5. Gemini — generate recommendation with MCP context
  6. insert-many — save Mission Readiness Report

Runtime modes

  • Local Agent — Next.js missionAgent.ts + Gemini + MCP (development)
  • ADK Sidecar — Cloud Run FastAPI service for Hackathon ADK compliance
  • Demo Mode — pre-recorded Agent snapshots for zero-cost public demos (DEMO_MODE=true)

UX choices

I styled the console like a mission control room: high-contrast telemetry, risk badges (Nominal / Caution / Critical), streaming Agent steps, and a looping ascent→recovery trajectory animation on real coordinates (Cape Canaveral, Vandenberg, Atlantic/Pacific recovery zones).

Challenges I ran into

1. MongoDB MCP on serverless hosting
The MongoDB MCP Server relies on stdio subprocess semantics. That is awkward on pure serverless frontends (e.g. Vercel). I solved this with a multi-runtime design: local/Cloud Run for live MCP, plus Demo Mode with pre-recorded snapshots for judges.

2. Making the Agent feel real, not like a chatbot
I exposed every MCP step in an Agent Activity panel so users see find → simulate → persist → aggregate → recommend as a structured workflow, not a black-box answer.

3. 3D trajectory visualization
Early arc-dash animations looked like broken ground-to-ground segments. I rebuilt the path with proper start/end altitudes (MECO high, recovery zone at sea level), phased draw animation, and camera controls that respect user interaction.

4. Balancing determinism vs. realism
Fully fixed scores felt artificial; fully random scores broke trust. I added seeded stochastic variance tied to environmental uncertainty — repeatable within a run, different across reruns.

5. Hackathon demo reliability
Live Gemini + MCP calls can fail or burn quota during judging. Demo Mode bundles 6 scenario snapshots, seeded report history, and session-local exports so the full story still works offline from Atlas.

Accomplishments that I'm proud of

  • Built an end-to-end Agent pipeline that uses MongoDB as a true mission world state, not just a chat memory
  • Implemented human-in-the-loop approval (Approve / Reject) before exporting readiness reports
  • Shipped a 3D Earth trajectory sandbox tied to Agent plan selection and anomaly replanning
  • Supported three mission scenarios × normal + anomaly paths with coherent demo data
  • Delivered three production-grade runtimes (Local / ADK / Demo) behind one UI toggle
  • Kept the world model explainable — every score maps to launch window, weather, booster health, and recovery mode

What I learned

  • MCP is a strong fit for Agents that need memory and audit trails. Persistence and aggregation are first-class tools, not afterthoughts.
  • A world model does not have to be a neural network. A transparent rules engine plus light stochastic noise can support credible mission trade-off discussions.
  • Visualization changes how people trust recommendations. When planners see ascent and recovery arcs on Earth, abstract risk scores become intuitive.
  • Demo reliability is part of the product. For hackathons, a replay mode is as important as the live Agent path.
  • Human approval matters in high-stakes domains — even in a simulation, the workflow should end with an explicit decision, not an auto-executed plan.

What's next for ReEntrySim

ReEntrySim Lite proves that recovery is a first-class planning problem, not an afterthought to launch. The next phase is to evolve it from a hackathon sandbox into a mission-grade decision intelligence layer for reusable launch operations.

Near term — make the world model real I plan to replace rule-based approximations with a Monte Carlo mission engine: thousands of sampled runs per plan, sensitivity charts for wind/sea-state/booster health, and confidence intervals instead of single-point scores. Trajectories would move from illustrative arcs to physics-informed paths (simplified orbital mechanics + reentry corridor modeling), still fast enough for interactive planning.

Mid term — close the loop with live data The Agent should ingest live weather, space weather, and range safety constraints, then trigger autonomous replanning when thresholds are breached — similar to how I demo sea-state anomalies today, but driven by real feeds. MongoDB would become a mission memory graph: every simulation run, anomaly, human override, and post-flight outcome linked for longitudinal learning.

Long term — fleet-scale reusable operations I envision ReEntrySim supporting multi-booster fleet scheduling: which vehicle to fly, which recovery asset to position, and whether to trade booster life for schedule assurance. Specialized ADK agents could divide labor — one for environmental risk, one for booster health, one for customer schedule — orchestrated through MCP tools over a shared Atlas world state.

Ultimate vision A human-in-the-loop digital twin for launch-and-recovery: planners see not only “can we launch?” but “what is the distribution of outcomes if we launch now, wait 90 minutes, or go expendable?” — with auditable Agent reasoning and exportable readiness artifacts for mission directors.

ReEntrySim will remain a decision-support system, not flight software — but the goal is to make reusable rocket operations as simulation-driven as they are data-driven.

Built With

Share this project:

Updates