We're open-sourcing Prospector.

Today we're releasing Prospector, the tool we use internally to decide where to go as well as what spacecraft to design, under an Apache-2.0 licence. It's on GitHub at github.com/Karmanplus/prospector, and you can use it for anything.

This post explains what it does, why we built it, and why we decided to make it available.

The cost of a question

There are roughly forty thousand known near-Earth asteroids and that number climbs every month. For any given launch date and spacecraft design, a small fraction is reachable. A smaller fraction of that is worth reaching. Figuring out which is the first real decision in a mission, and every decision after it inherits the answer.

The conventional way to answer it is slow. Trajectory analysis is specialist work, and a single serious question — can this vehicle reach that target, on what dates, at what cost — can take days of analysis. That pace drives the shape of the whole program. When each question is expensive in time and effort, you probably ask few of them. You commit to an architecture on limited evidence and you find out whether it was right somewhere around PDR, when changing it is no longer cheap.

Every other part of aerospace engineering has some way out of this. You breadboard before you build a flight unit. You run CAD before you cut metal. You make a lot of bad versions quickly so the good one arrives early enough to matter. The whole discipline is organized around making iteration cheap, because cheap iteration is how you find out you were wrong while being wrong is still affordable.

Mission design mostly skipped that. Prospector is our internal work to fix that for the class of missions we care about.

What it does

Give it a mission and a vehicle outline. It screens the entire small-body catalogue against that vehicle's delta-v budget in seconds, working from orbital elements alone with no dates and no positions. It narrows the survivors by what a target is made of, how big it is and how well it holds together. Then it hands the best candidates to progressively more accurate solvers, ending at a trajectory you could actually fly. Every step is visible in a desktop app.

The architecture is a ladder, and the point of the ladder is that each rung only runs on what the rung below it kept. Edelbaum screens forty thousand bodies in NumPy. Lambert gives two-body transfers between real dates. Sims-Flanagan, through PyKEP 3, does the real low-thrust solve in seconds per run. A transfer grid samples that solve across departure date and flight time, with every cell a real trajectory rather than an interpolation. A spiral solver flies the Earth escape properly, which prices the departure speed the cruise would otherwise treat as free.

An afternoon on Prospector covers more ground than a week of the old loop.

The part we care most about

A fast tool that is quietly wrong is worse than a slow tool. We spent the most effort on knowing which direction each estimate errs.

The screening estimates undercharge delta-v deliberately. When you are choosing targets, the expensive mistake is not including a marginal one. It's discarding one that was actually reachable, because you never find out. So none of the screening estimates is permitted to reject a target on its own, and all of them are biased toward optimism by design.

Past the screen, that bias reverses. Escape flies worst-case radiation. Thrust is derated by duty cycle. The grid and the solve are ordinary optimizations with no thumb on the scale. A screening number is a floor. A converged number is an estimate. Which is which is written down in docs/physics.md, along with what each solver is and is not allowed to decide.

We also ship four flown missions in the example config library — Dawn, Psyche, Hayabusa2 and DART — with their real engines and masses from public sources. Run them, compare the tool's answer to what actually happened, and decide for yourself whether to trust it. We would rather you check than take our word for it.

Reachable is not the same as worth reaching

A screening tool that only answers reachability answers half the question. Prospector's second axis characterizes each reachable target against public catalogues: size, composition, spin state, structural cohesion, and the mission tier that follows from them, with the reasoning attached.

This matters for us specifically because we are in the business of going to asteroids and doing something with them, and a body you can reach but cannot work with is not a target. It matters more generally because the reachability answer alone tends to produce massive lists of low utility.

So, why are we not keeping it?

Three reasons:

The code is not the advantage. What makes Prospector useful to us is the config library it reads: our engine models, our vehicle definitions, our corrections to published measurements. That library lives in a directory the tool reads at run time and never ships with the code, by deliberate design. Someone who clones the repository gets a solver ladder and no calibrated inputs. The physics was never the moat.

The field needs shared tooling more than we need a private copy. Planetary defense, asteroid science, and commercial small-body work all keep re-deriving the same reachability analysis in private, with no common reference to argue against. Publishing a tool with its error characteristics written down gives people something concrete to disagree with. We expect to be told we're wrong about some things and that is most of the value.

And it is how you find out whether you're actually right. A tool used only by the people who wrote it accumulates assumptions nobody has ever questioned. We would rather have the assumptions found now.

What we'd like from you

If you work on low-thrust trajectory design, small-body characterization, or planetary defense mission analysis, we would particularly like you to try to break it. The validation cases are the place to start, and docs/physics.md is where we've stated what we think our errors are. Tell us where that's wrong.

Issues and pull requests are open. If you build something with it, we'd like to hear.

github.com/Karmanplus/prospector

Prospector is Apache-2.0 licensed. It builds on PyKEP and PyGMO from ESA's Advanced Concepts Team, JPL's Small-Body Database and Horizons system, and a number of published small-body surveys, all credited in the repository's NOTICE file.