Tool for calculating asteroid close approaches *to each other*

[mikelepage]

I'm trying to determine if such a tool exists.  The problem I am trying to solve is as follows:

Imagine if - instead of designing $$ expensive asteroid probes like Dawn to visit specific asteroids (Vesta and Ceres) - you were sending numerous small probes as "mining prospectors" out into the solar system.  Rather than having a large team working on one probe (with extensive DSN communications to and from that probe), you instead had a small team managing a fleet of largely autonomous probes that periodically send back imagery/data on the millions of asteroids that are out there.

Because these probes have to be relatively cheap and small, they don't have much in the way of thrusting capability, but they are built to last.  Their aim is to "hop" from asteroid to asteroid, mapping each one for water/mineral resources as they go.  Perhaps there is a significant degree of onboard processing which generates a model of each object, so that the data transfer back to Earth is minimised as much as possible.  On those (presumably rare) occasions when two asteroids have a close approach, and the distance and velocity is within the capability of the probe to make the jump, it moves onto the next one.  And the next one, and so on.

What I want is a tool where I can type in database IDs for two or more asteroids, and find out time and date of the close approach as well as the approach velocity, exactly as is calculated for NEOs approaching Earth.  It doesn't have to be particularly accurate (simple orbital elements should suffice - I'm not wanting to make something too computationally expensive) - I just want to get a feeling for how frequent or rare these close approaches actually are.  Sure, space is huge, but there are also lots of asteroids (many of which are grouped into families with similar orbits), and I'm surprised I haven't been able to find such a tool.

Does anyone know of anything like this?

[eeergo]

Something like this could be derived from the "Accessible Near Earth Asteroid" NASA database: https://cneos.jpl.nasa.gov/nhats/

It indicates the minimum dV for a specified mission duration (or for a minimum mission duration) from Earth. While this is not particularly useful for what you're looking for, a script could be developed that looked at similar accessibility dates and a delta-delta-v (i.e. the difference in dV for a given mission duration as output by the tool) under a certain threshold. This should give you NEAs with low-impulse relative accessibility requirements, or a rough approximation to low relative velocity.

Of course, this doesn't take into account their relative *distance*, but it could be a start from where to weed some of them out. A second script could use the ephemeris database to gather their relative distance and discard those over a certain distance threshold, avoiding to have to finely determine in time all asteroids' orbits.

[launchwatcher]

Because these probes have to be relatively cheap and small, they don't have much in the way of thrusting capability, but they are built to last.  Their aim is to "hop" from asteroid to asteroid, mapping each one for water/mineral resources as they go.  Perhaps there is a significant degree of onboard processing which generates a model of each object, so that the data transfer back to Earth is minimised as much as possible.  On those (presumably rare) occasions when two asteroids have a close approach, and the distance and velocity is within the capability of the probe to make the jump, it moves onto the next one.  And the next one, and so on.

If the probe is limited in "thrusting capability", shouldn't you look at difference in velocity rather than distance in space?   (you're not wanting to "lithobrake", are you?) With a limited delta-V budget I'd think you should be looking for slow rendezvous trajectories that only require little nudges to set up; the closest approach of the asteroids to each other would be less important than the orbits being similar enough that a few nudges could set up a rendezvous over the course of some number of years of phasing.

[mikelepage]

Because these probes have to be relatively cheap and small, they don't have much in the way of thrusting capability, but they are built to last.  Their aim is to "hop" from asteroid to asteroid, mapping each one for water/mineral resources as they go.  Perhaps there is a significant degree of onboard processing which generates a model of each object, so that the data transfer back to Earth is minimised as much as possible.  On those (presumably rare) occasions when two asteroids have a close approach, and the distance and velocity is within the capability of the probe to make the jump, it moves onto the next one.  And the next one, and so on.

If the probe is limited in "thrusting capability", shouldn't you look at difference in velocity rather than distance in space?   (you're not wanting to "lithobrake", are you?) With a limited delta-V budget I'd think you should be looking for slow rendezvous trajectories that only require little nudges to set up; the closest approach of the asteroids to each other would be less important than the orbits being similar enough that a few nudges could set up a rendezvous over the course of some number of years of phasing.

Well you'd want to look at both - as with the table I screen-captured - it would be an optimisation between limiting propellent use and avoiding lost time where the probe is between asteroids not doing anything at all.

You still want to know about all close approaches - even if the delta-V to transit is too high - because you would still get some data from a flyby.

[speedevil]

You still want to know about all close approaches - even if the delta-V to transit is too high - because you would still get some data from a flyby.

Flyby at perhaps as low as meters, and tiny impactors could yield interesting info, without the delta-v.
RADAR too, at very short ranges is not too hard. (sub 1km).

[spacester]

I developed software 12 years ago that ran on AutoLISP for AutoCAD and calculated solar system trajectories then plotted the orbits and the transfer path on the screen for any two bodies in solar orbit.

The math is not simple, but it is totally doable, I did it partly just to show that it is nothing more than algebra. What it amounts to is a trial and error solution where you specify the time of flight and eventually get the timing and delta v needed. Other inputs are the orbital parameters and position which you get from JPL's system, called Horizon back then.

What the software is largely about is doing the arithmetic of keeping track of the true anomaly of the destination, the spacecraft and the origin on their respective orbits.

The basic calculation is to find an elliptical path from the specified time of flight, then you check how much you missed the planet in space and time. Adjust and iterate the timing until you miss by less than the sphere of influence, or other specified accuracy.

I would love to send what I've got to someone to run with. It is not hard, you just need to get to know the math of elliptical paths.

Getting around between minor planets is all about time vs. delta v.

[mikelepage]

Well I guess it only took me 9 months to figure out that what I was asking for with this thread is possible using the NASA JPL Horizons web interface, and a bit of MS Excel-fu.

The trick is to set the output as a vector table (which gives positions and velocities in a Cartesian co-ordinate system), and set the origin as the solar system barycenter.  Download as comma-delimited and import into Excel.

Then, for any two objects you can calculate the distance between them and the relative velocity at that point.

My test example was the main belt asteroid 16 Psyche, and my hypothetical "stepping stone" asteroid 2008 EQ, which is an Apollo asteroid with the same inclination and argument of the ascending node. 

An interesting exercise.  I'm now planning to go back and explore the asteroids I identified in the "asteroid transit map" thread.

[glennfish]

I developed software 12 years ago that ran on AutoLISP for AutoCAD and calculated solar system trajectories then plotted the orbits and the transfer path on the screen for any two bodies in solar orbit.

The math is not simple, but it is totally doable, I did it partly just to show that it is nothing more than algebra. What it amounts to is a trial and error solution where you specify the time of flight and eventually get the timing and delta v needed. Other inputs are the orbital parameters and position which you get from JPL's system, called Horizon back then.

What the software is largely about is doing the arithmetic of keeping track of the true anomaly of the destination, the spacecraft and the origin on their respective orbits.

The basic calculation is to find an elliptical path from the specified time of flight, then you check how much you missed the planet in space and time. Adjust and iterate the timing until you miss by less than the sphere of influence, or other specified accuracy.

I would love to send what I've got to someone to run with. It is not hard, you just need to get to know the math of elliptical paths.

Getting around between minor planets is all about time vs. delta v.

Not sure I'm too happy with autolisp, but I'd like to see the code for the geometry stuff.

[mikelepage]

I developed software 12 years ago that ran on AutoLISP for AutoCAD and calculated solar system trajectories then plotted the orbits and the transfer path on the screen for any two bodies in solar orbit.

The math is not simple, but it is totally doable, I did it partly just to show that it is nothing more than algebra. What it amounts to is a trial and error solution where you specify the time of flight and eventually get the timing and delta v needed. Other inputs are the orbital parameters and position which you get from JPL's system, called Horizon back then.

What the software is largely about is doing the arithmetic of keeping track of the true anomaly of the destination, the spacecraft and the origin on their respective orbits.

The basic calculation is to find an elliptical path from the specified time of flight, then you check how much you missed the planet in space and time. Adjust and iterate the timing until you miss by less than the sphere of influence, or other specified accuracy.

I would love to send what I've got to someone to run with. It is not hard, you just need to get to know the math of elliptical paths.

Getting around between minor planets is all about time vs. delta v.

Not sure I'm too happy with autolisp, but I'd like to see the code for the geometry stuff.

Not sure how, but I totally missed both your posts. Must admit I’ve always found calculus very difficult, so downloading data from NASA horizons is definitely easier for me. I have now started a new thread in the advanced section using my progress there:

https://forum.nasaspaceflight.com/index.php?topic=46919.0

[mikelepage]

For reference: I've now started a new topic on my attempt to answer this question in the Spaceflight Entertainment and Hobbies section of the NSF forums here:

https://forum.nasaspaceflight.com/index.php?topic=61321.0