Exodus Pathfinder Project

[mikelepage]

Hi all, I'm hoping to enlist some of you as play-testers on a free game/webapp I have developed - largely as a response to three threads I've created on to NSF forums over the last six and a half years. Those threads are summarised in the most recent of them: the Asteroid Transit Map thread.

TLDR: I wanted to make an attempt at a different user-interface (hopefully one that's far more simple & intuitive) to navigate a ship around the solar system. It's part 90's computer game, part citizen-science project, and all based on real data sourced from NASA JPL's small bodies database (with Keplerian, 2-body orbit determination only).

https://exodusspacesystems.com/exodus-pathfinder-project/

Suffice to say, during the past year - thanks to ChatGPT - I've been able to go from a long-time frustrated programmer to learning enough Python/JS/WASM to build this. Be aware that it's still quite buggy, and currently only works on Mac/PC in Google Chrome, but I think (fingers crossed) it works well enough now that I can start to ask for feedback from real players. And with the high score system now implemented, it will hopefully be a lot more fun to play. 

Today I've published a YouTube video tutorial to give an intro to how it works:



And on the website landing page you'll find further explanation as to some of the assumptions built into the core of the game, and the citizen-science aspects of what I'm trying to achieve with it. Hopefully obviously, the game is pretty big in its scope, and I'm a self-taught programmer, so please be kind

[mikelepage]

I wrote a bit more about this for my LinkedIn just now, and thought I would share here:

As we head into the weekend, I'm glad to give an update on our work on the Exodus Pathfinder Project, a webapp which grew out of our 2022 Space Commerce Hackathon. An early version of this webapp is now on the Exodus Space Systems website, and we're inviting all interested space enthusiasts to take it for a spin, even as we continue to work on the bugs. On our site you’ll find a link to a 14-minute video tutorial on the controls, as well as more specific discussion of the assumptions embedded in the app.

So why make a space webapp? Aren’t there a million space games out there?

Let’s start with the obvious: It’s fun! We know the idea of space travel is inspiring to kids and adults alike - it features strongly in STEM initiatives, and has inspired countless science-fiction stories. But it’s only fun if the user interface is both easy to understand and intuitive to use, and that’s what the Exodus Pathfinder Project aims to do for both orbital mechanics and radiation in space, two key factors which are critical to the success of every space mission.

In doing so, I believe we’ll also expand the paradigm of how we imagine astronaut crews travelling through interplanetary space. Current rocket tech and orbital mechanics tell us that once you leave the Earth-Moon system, you’re not coming back for multiple years, and realistic mission timeframes could even last decades, as long as we can feed the crew and keep them healthy for that long. The major problem is that lifetime limits for radiation doses could be exceeded in little more than a year (or maybe two) beyond Earth’s magnetic field.

Substantial radiation shielding for the highest energy particles (HZEs) is too heavy to build into spacecraft. There is however, passive shielding moving around the solar system already in the form of the hundreds of thousands of large asteroids. We think that the asteroids will become important to humanity, not just as potential hazards to the Earth, or as sites for scientific study, or even as sites for space mining, but as locations for sheltering astronaut crews from this high-energy radiation.

What’s missing is a map, or more specifically, a *pathfinding tool*, for hopping between the asteroids in a fuel-efficient manner, all while keeping crew radiation exposure to a minimum.

So, the idea is to 1) take an indie-game-like interface for travelling through space, 2) ground it in real orbital mechanics, and 3) incorporate real data for over 10,000 of the largest asteroids in our own solar system (so far). 4) Players compete for high scores, 5) log their solar system journeys to an online database, and 6) Exodus uses this data to build a useful map of the most efficient paths across the solar system.

I hope you (or your most persuadable teenager), will take a minute to go to the site and bookmark it for later. I may be biased, but I think it’s quite a lot of fun.

[Twark_Main]

From the video, I notice your paths are going "up and over" the Sun's poles. From this I gather you don't do broken plane transfers, only ballistic transfers.

Check out these resources:

https://hopsblog-hop.blogspot.com/2013/01/deboning-porkchop-plot.html

https://physics.stackexchange.com/questions/123029/why-is-there-a-gap-in-porkchop-plots

http://www.braeunig.us/space/ (section "Non-coplanar Trajectories")

There's an implementation of the latter...  for KSP.  Selecting "Optimal" will perform both ballistic and broken plane calculations and return the cheapest option.

https://alexmoon.github.io/ksp/

https://github.com/alexmoon/ksp

Even that algorithm isn't quite optimal. It's actually better to do a hybrid strategy, with part of your plane change at departure and part of it during the mid-course burn. See:

https://orbital-mechanics.space/orbital-maneuvers/plane-change-example.html

https://space.stackexchange.com/questions/12997/saving-delta-v-by-splitting-plane-changing-manoeuvre

It's not perfectly optimal, but it's close. To find the exact optimal solution would require a 4-D binary hill climb for the mid-course burn X/Y/Z/time variables. At first I worried this would be too simplistic an approach, but further research reveals that's exactly how NASA solved the problem. 

https://ntrs.nasa.gov/api/citations/19940010378/downloads/19940010378.pdf (see "Optimizer" on page 16 / PDF page 28)

Sorry for the number of links, but hopefully you find something useful in it.

[mikelepage]

From the video, I notice your paths are going "up and over" the Sun's poles. From this I gather you don't do broken plane transfers, only ballistic transfers.

Check out these resources:

…
Sorry for the number of links, but hopefully you find something useful in it.

No cheers, This is great. I’ve seen some of these before, but still going through them.

The point of this of course is to determine if we can significantly reduce lifetime GCR doses on crewed flights by spending as much time as possible in close proximity to passive shielding by asteroid regolith. It’s more like the Mars-cycler rendezvous problem. If your trajectory is long enough for non-ballistic / plane-changes to make a difference, then it’s hard to see how it’s worth it.

The key fact is that beyond Earth’s magnetic field, the top 1% of high energy HZEs account for a third of accumulated dose. Ergo even shielding 99% of everything else only increases career lifetimes by 3x from the current 1-2 years.

But these are particles that are impractical to shield with anything that is part of the ship, therefore -> “asteroid hopping” as a paradigm for getting around the solar system. The question is if conjunctions are frequently low deltaV-enough for this to make sense.

[Twark_Main]

If your trajectory is long enough for non-ballistic / plane-changes to make a difference, then it’s hard to see how it’s worth it.

While this may be true in some cases, it seems unlikely that it's true in all cases (especially when you consider the transfer to/from Earth/Mars). I fear that you may be prematurely pruning promising paths.

If I did discover a useful broken plane trajectory, does the game even have a way for me to input it, even manually?

What's the formula for calculating the final score?

[mikelepage]

While this may be true in some cases, it seems unlikely that it's true in all cases (especially when you consider the transfer to/from Earth/Mars). I fear that you may be prematurely pruning promising paths.

If I did discover a useful broken plane trajectory, does the game even have a way for me to input it, even manually?

Not currently. I really was aiming to simplify the interface/calculations as much as possible to make it more approachable for users and also keep it within my coding capabilities. But although feedback has been good so far, I've had to be realistic about how little take-up there has been and where my next efforts will be best focussed. I'm now looking into if I can automate this whole process and keep the game just for fun. I think I can take the code I've developed for the game and create a script which will systematically go through the asteroids' orbital elements to highlight low-duration, low-deltaV hops between asteroids.

This post in response to LMT was one of many I've made over the years, where I advocate my concept of "asteroid hopping" between "stepping-stone asteroids" as reasonable, but I think I might be able to prove it now.

What's the formula for calculating the final score?

Thanks for asking This is quite complex (and yet still simplistic), which is why I haven't tried to explain it in game. Others will no doubt have their own opinions on whether this is a good formula, but my game, my rules 

Remembering that it is assumed that a radiation shelter is created at each asteroid that the user spacecraft visits.

1) The shelter scores at each asteroid is calculated upon leaving each asteroid, then summed at the end.

The way shelter score is calculated is that it is assumed a hole big enough for the spacecraft is being dug at a constant rate whilst landed on the asteroid, and the shelter score is proportional to the depth of the hole multiplied by the visible_angle of the sky from which GCR is being received. So as the hole gets deeper and the visible sky angle gets relatively smaller, each meter of depth counts for relatively less.

Also, I think having built radiation shelters at big asteroids should have some intrinsic extra value, so asteroid diameter figures into the calc: for asteroids over 10km diameter, shelter score is multiplied by the square root of (asteroid diameter in km / 10). Therefore, Ceres gives the biggest multiplier bonus to shelter score of 9.7x

Lastly the shelter score is then multiplied by the crew survival percentage at the time of departure, according to the crew-survival model. Note that the more protection from shielding the crew receives, the better survival will be, but crew-survival will never be perfect because the crew survival model starts with 50-55 yo's and takes natural attrition into account.

2) A second element -  delta-V excess - is also calculated upon leaving each asteroid, and these are also summed at the end of the game.

When landed at an asteroid ISRU propellant is assumed to be generated from material taken out of the hole being created.  The ship's propellant tanks have a certain capacity, so the available deltaV goes up linearly while landed, in proportion to the depth of the hole, up to a certain maximum level. The listed figure assumes a certain mass and isp of thruster tech (1100 ton, 380 isp), but of course I don't know what the actual config might be.

So when in trajectory mode, each trajectory dV is calculated, and this is often more than calculated available delta-V, sometimes much more, but rather than blocking this (based on my mass/isp assumptions), the game records this ratio between trajectory dV vs dV available as a delta-V excess. Or as 1.0 if dV used is less than available dV.

Final Score therefore is the sum of shelter scores is divided by the sum of dV excess scores, and then multiplied by the crew survival at the end of the mission.

[mikelepage]

I've made an update to the app, now that I've fixed the main bug that was left in the trajectory calculation code. But in troubleshooting it I made myself a little mini-app which I find surprisingly fun to play with, so thought it was worth sharing with you all.

https://exodusspacesystems.itch.io/trajectory-code-demo

Co-ordinates are in astronomical units. Time is in years.
The sun is at the origin. XYZ axes are 1 AU long.