Approximating the Position of Space Probes with Minimal Code

Information about the Parker Solar Probe or the Voyagers can be as interesting as info about the Moon or Saturn. However, generating that info is significantly harder, the libraries that can generate data about them are few and far between. And even when generating that data is possible, it’s difficult and cumbersome to actually do in a program. This is enough that Stellarium, XEphem, and KStars don’t generate data on interplanetary probes.

This is because generating this data involves either:

• Running an n-body gravitational simulation.
• Looking up the data in an extremely large interpolated table, generated by the previous method.

Neither of these are desirable for code that needs a small footprint and quick runtime. So tools that aren’t an n-body simulator like GMAT, ephemeris reader like CSPICE, both like JPL Horizons, or don’t want to prepackage megabytes of data for each probe, usually choose to omit space probes entirely

# The Difference Between Planets and Probes

There are fast, low footprint, accurate ways to generate the positions of planets. Extremely Large Interpolated Tables still exist and are used for exact accuracy. But for smaller utilities, Medium Sized Tables or Smaller can do the same nearly as well.

The orbits of planets are consistent and periodic, and since the main influence in their orbits is the Sun, they closely follow the laws of Keplerian Motion.

Keplerian motion, in this context, models a 2-body orbit of something around a fixed point, since the path the orbit traces is unchanging and inertial. It can be calculated to whatever precision is needed, at any epoch, with basic trig. Only 6 parameters are needed to describe an Keplerian orbit, although these 6 change based on what type of orbit is specified.

JPL Horizons, can be used to return 12 elements from any object (including space probes!) at any time, although in practice half of these are needed, and some can be derived from others:

Planets don’t follow Keplerian orbits exactly though, other objects influence their trajectories slightly. Jupiter and Saturn are large enough and exert enough force on each other for their positions to be several degrees off from what Keplerian orbits predict. This has to be accounted for explicitly.

As a rule:

The more external influence there is on an object, the more that objects trajectory will differ from a Keplerian orbit

For most planets, asteroids, comets, and even interstellar objects like Oumuamua, this is a small problem that can be corrected for. But a space probes trajectory is defined completely by other objects gravity. Through gravity assists, capturing into orbit around objects, correction maneuvers, etc. Which means the entire trajectory of a space probe can’t be modeled by one set of Keplerian elements.

# The Life of a Space Probe

Any object in interplanetary transfer (not on the surface, or in orbit of anything, except the sun) will spend almost all its time waiting. The closest approach to a planet could last days, part of a larger observation period, where data is collected and its future trajectory is fine-tuned. But these periods are separated from each other by years, where the probe is too far away from anything to take pictures or collect useful data, it hibernates and nothing happens.

The force gravity imparts on an object grows quadratically, inverse to distance. A space probe passing 1,000km from a planet will be affected by it 4 times more than it would at 2,000 km. This also means that a space probe 0.1 AU away from an object will be affected ~22,000x less than it would at 100,000km. Outside of gravity assists, a space probes trajectory is affected by other objects, but this affect is far, far smaller compared to being slingshot around a planet.

JPL Horizons confirms this:

Generating an “Osculating Elements” table for the Parker Solar Probe and graphing any orbital element that doesn’t normally change, Jolts in orbital parameters clearly indicate gravity assists with Venus.

Since these elements are unchanging, they accurately model the trajectory of the Probe until a gravity assist, external perturbations, or something else changes them.

Although the entire trajectory of a space probe is still not calculable, individual sections are:

Any section of a space probes trajectory subject to little external influence can be accurately modeled by Keplerian Motion.

We have as rules:

1. The more external influence there is on an object, the less accurate Keplerian Motion can model it.
2. Since space probes encounter extreme external influence, their full trajectory is not modelable using Keplerian Motion.
3. Space probes encounter external influence in extremely short bursts, between long, inertial sections of waiting without much external influence.
4. Any section of a space probes trajectory subject to little external influence can be accurately modeled by Keplerian Motion.

# Segmenting Sections

Instead of keeping a large table of XYZ positions, or a single set of Keplerian orbital elements. A small table of Keplerian Elements can be kept, each entry having a start time and being a different section of the probes trajectory. And the individual sections in it can be turned into coordinates using the same algorithms used to calculate the position of asteroids and comets. So that finding the position of a probe at a certain time is just searching through the table for the right section then calculating its position the same way as an asteroid.

As a test, I used this method to calculate the trajectory of Voyager 1. Since Voyager’s Jupiter/Saturn encounters are relatively close together, instead of cherry-picking sections, I chose to periodically generate them.

Using JPL Horizons (Osculating Elements, AU and days, CSV format), I generated 3 tables, then combined them:

• 1977 -> 1979: Orbital elements every 90 days
• 1979 -> 1981: Orbital elements every 30 days
• 1981 -> 2020: Orbital elements every 5 years

The final table is about 40 entries long, storing all 12 elements and the start time in double-precision floats¹, it’s about 4500 bytes of binary data, and 700 lines of code.

This method is also very fast, running a small script to generate a table of positions to compare against JPL Horizons, it only takes 200 milliseconds to generate 18,000 positions, this averages out to a single calculation only taking 10 microseconds.

Comparing the data against official data from JPL Horizons, we can tell that the maximum error is about 0.3 degrees, and that the average error is much lower, plotting error against time we get the following graph:

There’s an anomaly here in the days immediately after the Jupiter gravity assist, going out to around 20 arcminutes (2/3 of the moons diameter). This could be fixed by generating more sections immediately around the area of the encounter with Jupiter, and is a consequence of periodically generating sections instead of hand-picking them. Zooming past this:

Sudden jolts in accuracy can be seen starting immediately after 1981, the first 5-year long section being particularly wobbly. But slowly getting less severe with time.

I can’t confirm this, but the consistent wobble between 1986 and 2006 lines up with the 11 year orbit of Jupiter. Although far away, it might still have enough influence to change its course by several arcseconds.

# Even More Accurate?

Looking at the chart above, the long-term errors when compared against JPL Horizons usually slowly tend towards a certain direction. Interpolating² between sections would:

1. Make the trajectory continuous
2. Improve accuracy by anywhere between several arcseconds and several arcminutes

However, even though long term errors tend towards a certain direction over a long time. Short time errors (i.e. the anomaly in the first graph) very much don’t, they quickly jolt to a different set of orbital elements and stay that way afterwords. If every section were automatically interpolated, it would run the risk of large and sudden changes happening over months, causing large errors in those parts of the trajectory. To prevent this, sections where a small amount of change happens would have to be separated from sections where a large amount of change happens.

Regardless of exact accuracy, 1 arcminute is good enough for almost all non-scientific use, and provides fast, malleable code for use in other tools.

# See Also

• The code used in these tests