General Question I don't understand some orbital trajectory perturbations

manolollr

New member
Joined
Feb 16, 2023
Messages
1
Reaction score
0
Points
1
Location
Spain
Hi! This is my first post in this forum, but I'm using this good simulator several years ago, I remember from 2016. English is not my native language (it is Catalan and Spanish), but I hope you understand me.

Orbiter uses n-body calculations to propagate orbital trajectories, this make it very difficult, but very realistic, challenging and entertaining. But there are some orbital trajectory perturbations that I don't understand.

Suppose a trip from Earth to Jupiter. I use IMFD course program, it uses 2-body calculations, I know, so the initial trajectory need further corrections. If the ship passes near Mars the trajectory gets clearly perturbated and gets perturbated too by Jupiter itself when approaching. I understand these perturbations and I can do adequate corrections to solve them. But other times the ship is very far from Mars, Earth, Jupiter, Saturn... and there are perturbations too, I don't know why. I activate body vectors visual option to view forces actuating, the gravity is directed towards the Sun and is only 6 Newton, for an about 24,000 Kg ship, it's a very low force. Which force will be distant planets like Jupiter or Saturn? 0,001 N? Can this very very low force cause important perturbations? The perturbations are very strange, I zoom in the IMFD course program to view trajectory near Jupiter, one day it's to left of the planet and the other day it's to the right. This is an important perturbation in only one day. The perturbation is cyclic, it goes up and down, if I accelerate time it seems a sea wave. If the perturbation were caused by an alignment of planets (Mars, Earth, Venus), it should always be in the same way, and not one day in one way and other day the opposite. I suspect this is caused by integrator errors and correction. Well, the real life is very very complex, and even a very good simulator like Orbiter can only approximate to it. So AFAIK Orbiter integrators sometimes have errors and they are corrected, so probably this sea wave in the trajectory is caused by repeatedly errors and corrections. I've tried to set RK8 integrator for all time steps, in Configuration->Extra->Time propagation->Dynamic state propagators, but the result is nearly the same.

OK, IMFD course program is a 2-body tool only useful for initial burn, I need to use other tools. But I've tried TransX and IMFD Map program and doesn't work for long distances, trajectory prediction is changing every day. IMFD Map program works very well near a planet, even outside it's SOI (Sphere Of Influence), but I don't know if it can be configured correctly to work in long distances. I've tried different parameters, more accuracy, less accuracy, adaptative parameter... nothing works.

So, how do I travel to another planet? By trial and error. Because the perturbations are cyclic I try to guess the middle position, and then use IMFD Map to correct the trajectory. The prediction is changing every day, but the final trajectory generally is closer to the initial guess. But sometimes the cycle changes and need to make more corrections. I end up doing a lot of corrections. They are short corrections, using only RCS, but there are a lot.

Real space missions can go to planets with only few DSMs (Deep Space Maneuver), I do a lot. Yes, they can do better because they have more resources, more money, intelligent people, good software, the best computers. But I wish to do it better, in a more elegant manner other than trial and error.

Is there a good way to make precise trajectory predictions, needing only few corrections? Using native Orbiter tools? Or using external tools like NASA's GMAT software?

A little large first post. I'm starting strong. :-)
 
the ship is very far from Mars, Earth, Jupiter, Saturn... and there are perturbations too, I don't know why.
because of Planet 9 :)

more seriously, I have always wondered how the Sun proper motion is taken into consideration in Orbiter. As Orbiter uses mainly DExxx ephemerides that are one of the available models of ephemerides (actually a compilation of sources), the Sun should be seen as a moving source within a bubble of ca.500'000km if I remember correctly. At 5AU (say), it makes a direction change wrt. center of mass of the solar system up to 6E-4 rad = 2 arcmin (1/30th of a degree). Could this explain the deviation you see?
 
Is there a good way to make precise trajectory predictions, needing only few corrections? Using native Orbiter tools? Or using external tools like NASA's GMAT software?

GMAT is a good option. GMAT's internal propagator functions are comparable to Orbiter's.

IMFD is the most accurate tool that we currently have...but I don't believe it accounts for every perturbation source. (radiation pressure, n-body). It also calculates trajectories with large step sizes, compared with the time-steps that will be used by Orbiter to actually fly the trajectory. Orbiter, by default uses VSOP87, not DE440/441 for its ephemerides; there is this: https://github.com/Ajaja/spice_orbiter, some assembly required though, and unless you need centimeter-accuracy you're probably fine using the defaults.

For NASSP we (not me, other, smarter people) had to develop better tools than the Orbiter defaults and even IMFD in order to precisely fly the Apollo missions. I am very comfortable saying that Orbiter is very accurate. The navigation tools are very good, but not quite as accurate.

Here's a comparison of position residuals between GMAT and Orbiter in a low lunar orbit flying through the LP165 gravity field:

1734969442128.png

The error is probably due to round-off from both Orbiter and GMAT.

I did recently read a paper about a fast implementation of RKN10/12 though...future projects :)
 
Just to add a little to the above discussion: Orbiter 2016 uses the VSOP87 ephemeris, which is a planetary theory developed by the Bureau des Longitudes in Paris. It was used for computing the positions of the planets (Mercury through Neptune) with high accuracy. As you might guess, it was developed in 1987, so that makes it about 37 years old. Orbiter does not use JPL's DEXXX ephemerides series, which would generally be regarded as the more modern and even more accurate ephemeris. The differences between the two ephemerides, however, are not material in the context of the anomaly presented in this post. In fact, the differences between the two are not really relevant for any trajectory planning that one is ever likely to do in Orbiter.

As a point of interest, Orbiter 2016 uses an internal Cartesian coordinate system for computing Newtonian gravitational forces acting on a spacecraft. This reference frame is assumed to be an inertial, non-rotating reference frame. This reference frame is the barycentric (solar system centre of mass) reference frame of the VSOP87 ephemeris. And this is all fine, and unless you are picking nits, it is the correct frame of reference to use. Because it uses the barycentric reference frame, the position of the Sun is not located at the centre of the coordinate system because of the influence of Jupiter and Saturn in the main. As pointed out above, the deviation of the Sun can vary significantly - by around half a million km from the solar-system barycentre. There is also a velocity offset for the Sun, where the Sun is, in effect, in orbit around the barycentre.

Of more material concern is IMFD itself. Here, there are two relevant programmes: the Course program; and the Map program. The Course program uses two-body physics, which is to say, it assumes that the gravitating body (e.g., the Sun) is at the centre of the coordinate system. The Map program uses a more sophisticated n-body integrator - but its integration method is not (as far as I know) open source and I have not been able to review its underlying integration algorithm. Suffice to say, however, it is not 'state-of-the-art' when it comes to numerical n-body integration techniques.

It is possible to build a better n-body integrator and successfully use this to compute trajectories and integrate these with Orbiter. I've done this for myself in the past, and the results are satisfyingly accurate - of the order of 1-2 km in a transfer from Earth to Mars, for example. However, these tools are bespoke and there isn't an existing, publicly available tool/MFD that can be used to carry out these integrations. In broad terms, I think one either accepts the limitations of tools such as IMFD/TransX, or one builds one's own tools for mission planning. There is the GMAT option, but I think GMAT uses a DEXXX ephemeris, which inevitably differs from the VSOP87 ephemeris used by Orbiter.

As an aside, I see that there is an active thread on this site re Orbiter 2024 development. I might suggest that a review of Orbiter's physics engine and update of its underlying
ephemeris system might be useful to bring it into line with third-party tools such as GMAT.
 
Last edited:
It is possible to build a better n-body integrator and successfully use this to compute trajectories and integrate these with Orbiter. I've done this for myself in the past, and the results are satisfyingly accurate - of the order of 1-2 km in a transfer from Earth to Mars, for example. However, these tools are bespoke and there isn't an existing, publicly available tool/MFD that can be used to carry out these integrations. In broad terms, I think one either accepts the limitations of tools such as IMFD/TransX, or one builds one's own tools for mission planning. There is the GMAT option, but I think GMAT uses a DEXXX ephemeris, which inevitably differs from the VSOP87 ephemeris used by Orbiter.

I agree. I think the challenge with any navigation tool is that we typically want the "best" solution, which for the average Orbiter user is probably something along the lines of "fast and accurate enough to do with a vessel that has 50km/sec of DV", for an NASSP user that may be: "rendezvous in 10 revs", "minimize a potential abort DV", "some tradeoff between dv and time", for a "JPL" user that would be some hyper-specific mission profile

As an aside, I see that there is an active thread on this site re Orbiter 2024 development. I might suggest that a review of Orbiter's physics engine and update of its underlying
ephemeris system might be useful to bring it into line with third-party tools such as GMAT.

There has been some good effort toward this and a solution exists as an add-on. The challenge preventing this from being a drop-in replacement for VSOP87 is the size of the SPICE kernels. This is a practical concern with GitHub releases, and how big we want the base download to be.

 
Orbiter does not use JPL's DEXXX ephemerides series, which would generally be regarded as the more modern and even more accurate ephemeris. The differences between the two ephemerides, however, are not material in the context of the anomaly presented in this post.
Good to know!
Also thx for the detailed answer about Sun's location.

Then, regarding @manolollr's questions: (6N,24000kg) -> acc.2.5E-4m/s². If only due to the Sun, your vessel is at 4.86AU from the Sun. Jupiter is 1000 times lighter than the Sun, i.e. its gravitation is less by the same factor at same distance. But at 0.1UA from Jupiter (15E6Km = 15G as shown by Orbiter), the contribution of Jupiter on your vessel is a force of ca.14N (vs.6N!!), at 0.2UA it is 3.5N... at 1UA it is still 0.14N, and so on... which is a great contribution when integrating. 2-Body problem are not enough.

As an aside, I see that there is an active thread on this site re Orbiter 2024 development. I might suggest that a review of Orbiter's physics engine and update of its underlying
ephemeris system might be useful to bring it into line with third-party tools such as GMAT.
I can only second that.
 
I did recently read a paper about a fast implementation of RKN10/12 though...future projects :)
There is also an IAS15 engine with variable time-step, which is key for integration in deep-space. I have an implementation in python that goes relatively quick, so I can imagine that a re-code in C++ would be efficient for a mission planning tool.

By the way, you don't need to import all SPICE kernels, or to "load" all of them. For instance, Jupiter's moons take a lot of memory... do we need them? not outside of Jupiter's system, where only the Center of mass of the Jovian system is needed... etc... Dedicated combination of useful kernels for Orbiter could be considered and rebuilt (i.e. "fair" accuracy and periods of times). Indeed, next time.
 
There is also an IAS15 engine with variable time-step, which is key for integration in deep-space. I have an implementation in python that goes relatively quick, so I can imagine that a re-code in C++ would be efficient for a mission planning tool.

By the way, you don't need to import all SPICE kernels, or to "load" all of them. For instance, Jupiter's moons take a lot of memory... do we need them? not outside of Jupiter's system, where only the Center of mass of the Jovian system is needed... etc... Dedicated combination of useful kernels for Orbiter could be considered and rebuilt (i.e. "fair" accuracy and periods of times). Indeed, next time.

It should be pretty easy to add new integrators here: https://github.com/orbitersim/orbit...85c3458fc4b2a9/Src/Orbiter/BodyIntegrator.cpp if we want to. It would be very cool; I think the necessity is probably vanishingly small. I fully support adding it to future releases.

The problem with the SPICE kernels has nothing to do with the technical challenge of loading them into memory. It's a practical challenge of: downloading 5GB of kernels from NAIF/JPL, merging them with a desired date range, packaging them with the Orbiter build process, and having a solution for scenarios outside of the kernel date range.

Rolling your own kernel is relatively easy once you know how to do it, and the system is very modular and flexible for adding data/bodies. I just think it's one of those "features that should be an addon" things. Maybe I just need to think of a better way to implement it though.
 
Back
Top