Prospector is an open-source tool for low-thrust mission design. Give it a mission target and a vehicle outline, and it tells you which asteroids that vehicle can reach, which of those are worth going to, and what the trajectory looks like when you fly it.
It is what we use at Karman+ to decide where to send spacecraft. It is now Apache-2.0 licensed and free for anyone to use, including commercially.
The problem it solves
Deep space mission design runs on a slow loop. A single question — does this mission close — is a specialist task measured in days or weeks. That pace sets how many options a program can afford to consider, which is usually far fewer than it should. Architectures get locked in early, on thin analysis, and the consequences surface years later in mass margin and schedule.
Hardware engineering solved this problem decades ago with cheap iteration: breadboards before flight units, CAD before metal, many bad versions before one good one. Mission design never got the same treatment. Prospector is our internal effort to give it one.
It screens the entire small-body catalogue (as well as the major planets) against a vehicle's delta-v budget in seconds, from orbital elements alone. It then narrows what survives by what the target is actually made of and how large it is. Only the candidates that pass both filters reach the expensive solvers. The result is that a question which used to take a week takes an afternoon, and you get to ask a hundred of them instead of three.
How it works
A ladder of solvers, cheapest first. Each rung runs only on what the rung below it kept. An Edelbaum estimate in NumPy screens the whole catalogue with no dates and no positions. Lambert gives two-body transfers between real dates. Sims-Flanagan, through PyKEP 3, does the real low-thrust solve in seconds. A transfer grid samples that solve across departure date and flight time, every cell a real trajectory. A spiral solver flies the Earth escape properly and prices the departure speed the cruise treats as free.
Errors that point in a known direction. The screening estimates undercharge delta-v on purpose. When you are choosing targets, the expensive mistake is discarding one that was reachable, so no screening estimate is permitted to reject a target on its own. Past the screen the bias reverses: escape flies worst-case radiation, thrust is derated by duty cycle, and the grid and solve are ordinary optimizations. Read a screening number as a floor and a converged one as an estimate. Which direction each model errs is documented, not implied.
Two axes, not one. Reachability is necessary and not sufficient. Prospector characterizes reachable targets against public catalogues — size, composition, spin, how well the body holds together — and assigns a mission tier with the reasoning behind it. A target you can reach and cannot use is not a target.
Escape and cruise solved together. They trade against each other, so solving them separately gives you an answer that is wrong in a way that is hard to see. A mission can swing past a planet on the way, with both legs solved as one problem.
Configuration is data. Engines, propellants, launch types, vehicles, missions and sizing coefficients live in YAML, read at run time. Nothing is hardcoded. Your config library is a directory the tool reads and never a thing the tool ships, so your vehicle model stays yours even when the code does not.
Everything visible. Four workspaces: set up the project, find targets, compare vehicles, plan the trajectory. Vehicle sweeps run across dry mass, propellant load, engine count and working gas, with each design flown to the target. A study exports as a standalone PDF or as a trajectory bundle for a 3D viewer.
Checking it against history
The example config library ships four flown missions — Dawn, Psyche, Hayabusa2 and DART — with their real engines and masses from public sources. You can run them and compare the tool's answer against what actually happened before you trust it with anything of your own. The comparisons are written up in docs/validation.md.
Who it is for
Mission designers, planetary defense researchers, university groups, and anyone else who needs to answer a reachability question before a trajectory optimization team becomes involved.
Licence
Apache-2.0. Use it in a commercial or closed-source product and publish nothing back. Carry the LICENSE and NOTICE files, note which files you changed, and do not use the project's name to promote your own build. It also grants a patent licence from contributors.
Get started
git clone https://github.com/karmanplus/prospector.git
cd prospector
pixi install
cp -r examples/configs configs
pixi run app
Runs on Linux, macOS and Windows from one lockfile. Full install notes, architecture and the modeling reference are in the repository.
github.com/Karmanplus/prospector →
Issues and pull requests are welcome. If you use it for something interesting, we would like to hear about it!