Orbit Mission Simulator
Redesigning a legacy tool for space mission designChallenge:
Designing a spacecraft mission means juggling a lot of interlocking constraints at once: how much the spacecraft weighs, how much fuel that leaves room for, when it's actually possible to launch (the timing has to line up with where the Moon or target will be), and how many precisely-timed engine burns it takes to get there and back. All while keeping track of things like whether the spacecraft can currently talk to a ground station, or whether it's in sunlight or in the Earth's shadow.
None of these live in isolation, changing one (say, adding more fuel) changes the weight, which changes the burn timing, which changes when you need to talk to which ground station. And there's no room for a mistake to be quietly wrong. A bad number here doesn't just produce a bug, it can mean a mission that fails.
That's the real challenge in redesigning a tool like this. It would be easy to make something that looks simpler, hide the technical detail, round the numbers, streamline the screens, but if that simplicity strips out information an engineer actually needs to trust the result, you've made something easier to look at and worse to rely on.
"The goal isn't "simple." It's "no wasted effort for the person using it, without leaving anything important out."
Why an orbit simulator?Widely used: It's used at every stage of space mission design, from initial trajectory planning through to execution.
Industry standard: Universities, aerospace companies, and agencies all rely on the same handful of tools to do this work. There isn't a fragmented landscape of alternatives to compare against.
Outdated existing tools: The tools people actually use (GMAT, and similar) are functionally powerful but visually and interactionally dated. The overall experience hasn't kept pace with how interface design has evolved elsewhere.
Rich problem space: The domain covers enough range, such as propagation, targeting, optimization, constraints, multiple burn types, to be a genuine design problem, not a surface-level one.
Design approach:
It's used at every stage of space mission design, from initial trajectory planning through to execution.
Treated everything as a node:
Mission-planning tools like this can grow features exponentially, more burn types, more constraint types, more spacecraft, so I took inspiration from Photoshop and other node/layer-based creative tools to make every piece (spacecraft, burns, propagators, constraints) independently addressable, organizable, and reusable, rather than hard-coded into one fixed hierarchy.
Mission-planning tools like this can grow features exponentially, more burn types, more constraint types, more spacecraft, so I took inspiration from Photoshop and other node/layer-based creative tools to make every piece (spacecraft, burns, propagators, constraints) independently addressable, organizable, and reusable, rather than hard-coded into one fixed hierarchy.
Kept things layered, Figma-style:
The tools people actually use (GMAT, and similar) are functionally powerful but visually and interactionally dated. The overall experience hasn't kept pace with how interface design has evolved elsewhere.
The tools people actually use (GMAT, and similar) are functionally powerful but visually and interactionally dated. The overall experience hasn't kept pace with how interface design has evolved elsewhere.
Features:
Cloud-based projects, with import/export at the component level
The actual reported problem is people losing or overwriting each other's work on shared lab computers, and rebuilding the same spacecraft or thruster setup from scratch across missions. This targets lost work and repeated effort, specifically.
A persistent, mission-wide right panel
For Delta-v budget and the full mission script because an engineer checking their propellant budget needs to see every burn at once, not one at a time. So the Delta-v panel is a flat, always-visible list in mission order (TLI → MCC1 → LOI, and so on), with a running total against the mission's total budget.
The script panel works the same way: a single combined script (resource declarations plus mission sequence, matching how GMAT itself structures a script) that engineers can copy out to run standalone, diff, or hand off, rather than something reconstructed only inside this tool.
For Delta-v budget and the full mission script because an engineer checking their propellant budget needs to see every burn at once, not one at a time. So the Delta-v panel is a flat, always-visible list in mission order (TLI → MCC1 → LOI, and so on), with a running total against the mission's total budget.
The script panel works the same way: a single combined script (resource declarations plus mission sequence, matching how GMAT itself structures a script) that engineers can copy out to run standalone, diff, or hand off, rather than something reconstructed only inside this tool.
A descriptive sequence view
The view can be toggled independently of the config panel. A high-level view keeps the mission scannable at a glance while switching on "Show details" surfaces key parameters (target values, durations, delta-v amounts) directly in the tree.
So an engineer can fine-tune or sanity-check a sequence without opening a full config panel for every single step.
The view can be toggled independently of the config panel. A high-level view keeps the mission scannable at a glance while switching on "Show details" surfaces key parameters (target values, durations, delta-v amounts) directly in the tree.
So an engineer can fine-tune or sanity-check a sequence without opening a full config panel for every single step.
Warnings and validation, tied to their actual source (not just their symptom)
If a burn is configured in a way that won't work (say, a target delta-v the spacecraft doesn't have the propellant to achieve), the warning shows up in three synced places at once.
A gutter icon on the specific script line responsible, a badge on the matching sequence-tree row, and a flag on the specific config field that's actually the root cause (thrust, Isp, propellant tank), not just wherever the failure happens to surface.
The goal was to make sure an engineer can always trace a warning back to the thing they'd actually need to change, from whichever view they're currently working in.
If a burn is configured in a way that won't work (say, a target delta-v the spacecraft doesn't have the propellant to achieve), the warning shows up in three synced places at once.
A gutter icon on the specific script line responsible, a badge on the matching sequence-tree row, and a flag on the specific config field that's actually the root cause (thrust, Isp, propellant tank), not just wherever the failure happens to surface.
The goal was to make sure an engineer can always trace a warning back to the thing they'd actually need to change, from whichever view they're currently working in.
Camera controls built for precision, not just exploration.
A dedicated Camera / Target & Frame / Overlays panel exposes exact position (X/Y/Z), orientation (azimuth, elevation, roll), field of view, and clipping planes, letting an engineer reproduce or communicate an exact viewing angle, not just "somewhere near the Moon."
Multiple, independently configurable viewports
Views can be split freely, and each one can be a different camera type, such as a free-orbit 3D view, a spacecraft-relative chase camera, or a 2D ground-track map for Earth-relative phases (station coverage, day/night, sub-satellite point) where a 3D globe stops being useful.
All viewports share one mission clock, so pressing play advances every open view together, only the camera framing in each stays independent.
Views can be split freely, and each one can be a different camera type, such as a free-orbit 3D view, a spacecraft-relative chase camera, or a 2D ground-track map for Earth-relative phases (station coverage, day/night, sub-satellite point) where a 3D globe stops being useful.
All viewports share one mission clock, so pressing play advances every open view together, only the camera framing in each stays independent.
A sequence timeline view
The timeline node lays the whole mission out as parallel tracks. Sequence steps alongside environmental state (orbit regime, spacecraft mass, sunlight/eclipse periods, DSN ground-station handoffs), so an engineer can see how a burn, a mass drop, and a station handoff line up in time, not just read them as separate disconnected facts.
The timeline node lays the whole mission out as parallel tracks. Sequence steps alongside environmental state (orbit regime, spacecraft mass, sunlight/eclipse periods, DSN ground-station handoffs), so an engineer can see how a burn, a mass drop, and a station handoff line up in time, not just read them as separate disconnected facts.
Future opportunities:
These are the smaller refinements sitting on top of the high-level functions above, polish and convenience, not new categories of feature:
Live Delta-v depletion during playback
Instead of the current static per-burn totals, the number would visibly drain as you scrub through an active burn.
Hover-to-reveal on the uncorrected trajectory line
Instead of a permanent label, so the main view stays less cluttered until someone actually wants that detail.
Camera position presets/bookmarks
Save a specific angle you've dialed in, instead of resetting to default and re-tuning every time you switch context.
Keyboard shortcuts
For switching Sequence/Resources and toggling Script/List view, since these are actions an engineer would do dozens of times per session.
Key takeaways:Grounded in real data:
Without deep firsthand expertise in this domain, I anchored decisions in something concrete rather than guesswork. I used the actual Apollo 11 mission (real burn timings, delta-v figures, spacecraft masses) as the working example throughout, instead of invented placeholder numbers.
Without deep firsthand expertise in this domain, I anchored decisions in something concrete rather than guesswork. I used the actual Apollo 11 mission (real burn timings, delta-v figures, spacecraft masses) as the working example throughout, instead of invented placeholder numbers.
AI as a research and sanity-check tool :
Used throughout the process to surface what real mission-design tools already do well, and to catch places where my own assumptions about the physics or the workflow didn't hold up.
Used throughout the process to surface what real mission-design tools already do well, and to catch places where my own assumptions about the physics or the workflow didn't hold up.
Open question :
Whether these changes would actually make the tool easier for a working aerospace engineer to use, or whether some of what reads as "improvement" to a designer's eye would feel like unnecessary overhead to someone already fluent in GMAT's plainer, denser interface. That's the real test this project hasn't had yet.
Whether these changes would actually make the tool easier for a working aerospace engineer to use, or whether some of what reads as "improvement" to a designer's eye would feel like unnecessary overhead to someone already fluent in GMAT's plainer, denser interface. That's the real test this project hasn't had yet.