Solar system simulation coordinates

[george7378]

Hi!

I have a quick question about relative coordinates in a simulation of the solar system. Let's say I am simulating a spacecraft using an RK4 propagator in an environment containing the Sun, the Earth and Mars (with the Sun at the centre). The two planets are on simple circular orbits around the Sun to make calculating their positions easy.

My problem is this: If the spacecraft is initially orbiting Earth, it seems like specifying its position/velocity relative to the Sun is not a very elegant idea due to the large numbers involved and the fact that the Earth is moving relative to the Sun at about 30km/s. Do you think it's a good idea to implement a system which, for every timestep, determines which body is imparting the largest acceleration on the spacecraft and do all the propagations in coordinates relative to that body?

Is there another method for solving this issue? Does Orbiter have a system for determining which frame the propagations are done in? I would try doing some research but I can't really think of what I should be searching!

Thanks a lot

 

[Thunder Chicken]

I think some keywords that may interest you are "patched conic approximation" and "sphere of influence". This is how orbits are often calculated in multiple body systems. Numerical methods could include the gravitational influence of as many bodies as desired, but at some point the increase in accuracy is not worth the increased computational cost.

I do not recall if Orbiter uses this in the engine or not. I believe that in the Orbiter solar system the planets and moons move with essentially fixed elements. I do not know how many bodies are considered for the gravitational acceleration of a vessel in that system.

 

[BruceJohnJennerLawso]

I do not recall if Orbiter uses this in the engine or not. I believe that in the Orbiter solar system the planets and moons move with essentially fixed elements. I do not know how many bodies are considered for the gravitational acceleration of a vessel in that system.

I think it does do some selection of gravitating bodies due to distance and mass. If you check the vessel state window, it lists the propagator type along with the current gravitational influences (IIRC a typical list for LEO is Sun, Earth, Moon, Jupiter (Jupiter is a maybe depending on the exact date)) This will change depending on the location of the vessel. My personal guess is that Orbiter uses some kind of arbitrary precision data type for positions and velocities, and selection like this is very important to keep the number of digits of precision low (ie adding 200.0000000 + 0.000000000067 might force the data type to extend the number of digits it carries)

My personal suspicion is that Orbiter uses some sort of SOI coordinate system, since vessel definitions in each scenario file specify their major body. That would seem to be useless if their coordinates were actually global, since the major SOI of each body could just be obtained during runtime anyways. I would be interested to know if the coordinates are cartesian or spherical polars though.

If you want to talk about this ad-nauseum george7378, drop me a PM . Im working on a project that deals with this sort of thing, so its of great interest to me as well.

 

[george7378]

Thanks for the help!

I have solved it by using local coordinates depending on each planet's SOI. If I'm not inside any SOI then I use the Sun as the origin. At the moment I'm using all the bodies for every gravitational calculation but may end up using the patched conic approximation too. Speed isn't currently an issue though.

This was particularly annoying because in my current program I am calculating all the trajectories at startup and then displaying them as a bunch of connected points, so each location I record has a reference frame attached to it which then needs to be transformed back into whichever frame I am using to display the results. It's working quite nicely though

 

[HarvesteR]

Relativity is the name of the game when writing a solar system simulation. Every coordinate, be it position, velocity, rotation or whatever else you can think of, must be relative to something.

This was something I struggled with as well in the early days of building KSP's simulation. Back then, the game was a very simple thing, and most coordinates were simply in worldspace. As we added moving (and later rotating) celestial bodies, the concept of worldspace got more and more meaningless, up to a point where now it's only useful to compare distances or tell how close you are to the scene origin. In themselves, the absolute XYZ axes of the engine mean very little to the simulation.

In KSP, the problem is simplified by our decision to use a 2-body simulation all the time, but any simulation should be able to work just fine, be it an n-body RK4 integrated solution or a deterministic propagator, by expressing orbital state vectors in a coordinate frame relative to the current dominant body in the system.

In fact, the 'other' solution (all coords relative to some inertial frame that encompasses everything) would probably be much harder to work with in practice. Most equations and solutions you'll find out there for orbit maths are already based on coordinates that are local to the central body, so you'd find yourself constantly having to transform them again and again. As you said it, inelegant indeed.

The solar system inertial frame is useful to transform coords though. It's much easier to compute the relative velocity of a spacecraft switching SOIs by transforming its state vectors to solar-system inertial first, along with the state vectors of the new reference body, than to try to always stay on top of whether you are going in or out of a child or parent frame to add/subtract vectors. It works very well as a 'transition' reference frame, where all coordinates are equal.

Cheers

 

[BruceJohnJennerLawso]

Relativity is the name of the game when writing a solar system simulation. Every coordinate, be it position, velocity, rotation or whatever else you can think of, must be relative to something.

This was something I struggled with as well in the early days of building KSP's simulation. Back then, the game was a very simple thing, and most coordinates were simply in worldspace. As we added moving (and later rotating) celestial bodies, the concept of worldspace got more and more meaningless, up to a point where now it's only useful to compare distances or tell how close you are to the scene origin. In themselves, the absolute XYZ axes of the engine mean very little to the simulation.

In KSP, the problem is simplified by the our decision to use a 2-body simulation all the time, but any simulation should be able to work just fine, be it an n-body RK4 integrated solution or a deterministic propagator, by expressing orbital state vectors in a coordinate frame relative to the current dominant body in the system.

In fact, the 'other' solution (all coords relative to some inertial frame that encompasses everything) would probably be much harder to work with in practice. Most equations and solutions you'll find out there for orbit maths are already based on coordinates that are local to the central body, so you'd find yourself constantly having to transform them again and again. As you said it, inelegant indeed.

The solar system inertial frame is useful to transform coords though. It's much easier to compute the relative velocity of a spacecraft switching SOIs by transforming its state vectors to solar-system inertial first, along with the state vectors of the new reference body, than to try to always stay on top of whether you are going in or out of a child or parent frame to add/subtract vectors. It works very well as a 'transition' reference frame, where all coordinates are equal.

Cheers

How did You deal with the issue of Numerical Precision? My simulation breaks down at something like 277 thousand km from the origin ( the function that compares where vessel images should be drawn onscreen gets messed up and the vessel image jumps around from frame to frame). My setup is cartesian coordinates with the components as long doubles.

 

[HarvesteR]

How did You deal with the issue of Numerical Precision? My simulation breaks down at something like 277 thousand km from the origin ( the function that compares where vessel images should be drawn onscreen gets messed up and the vessel image jumps around from frame to frame). My setup is cartesian coordinates with the components as long doubles.

You're on the right track using doubles already to hold precision. The problem is, the underlying graphics API is still 32-bit based (not sure what you're using, but unless you're rolling your own starting at DirectX level, chances are you're stuck with 32 bit).

There were a number of solutions we implemented over time to solve FP issues in KSP as the game progressed, and those issues became greater and greater bars to gameplay.

First to be implemented was the Floating Origin solution. Even if you store coords at double precision, when the time comes to place the actual game objects, that double precision is cast down to 32 bit values again, and issues like visual (and physics) jitter ensue. This meant that before FO was implemented, any object going farther than about 15km from the scene origin (the location of the launchpad) woudl start showing signs of jitter, and eventually become so unmanageable parts would detach themselves on their own, meshes would jitter as vertices lost placement precision (due to transform matrices degrading), in general, madness. Floating Origin consists of keeping the 'player' (ship, camera, disembodied soul) constantly near the origin, and shifting the rest of the universe in the opposite direction whenever the player leaves the allowed range in which he's permitted to roam. Doing this ensures nearby (relative to the player) objects will always be close to the origin as well, and thus be resolved at maximum resolution.

The second thing to be implemented was the concept of scaled space. This was done so objects seen in the map, or very far from you (such as a moon as seen from the surface of Kerbin) would be modelled in a 'subscene' (a layer with its own cameras and lighting which is invisible to cameras and objects in other layers), where objects are scaled down at a 1:6000 ratio relative to the true-space subscene, called localspace.

That solved the problem of visualizing the map, and the moon, up to a point. eventually, even the scaled space subscene had to be given its own floating origin system, because astronomical scales, even in a scaled-down version of a scaled-down fictional solar system, are still quite astronomical.

Last of all but certainly not least, was the solution we called Krakensbane. KB works very much like floating origin, but instead of solving FP issues for position, it does so for velocity. In space, you're free to accelerate continuously until your velocity vector itself becomes so large a value, it starts to break down in precision. In KSP, this was a serious problem because each part of the ship is its own rigidbody, and having rigidbodies which are supposed to be linked together not share exactly the same velocity, down to the micrometer range, caused phantom forces to randomly act on the vessel, eventually becoming so large as to tear the ship apart. This became known as the Deep-Space Kraken, and Krakensbane was the solution that finally killed it.

KB consists of putting the vessel in a motionless reference frame (relative to the scene), where its imprecise physical velocity is close to zero, and a double-precision vector accumulates the velocity 'absorbed' by this reference frame, and on each new tick, moves the universe (much like FO does) velocity*deltatime units in the opposite direction. This again ensures the 32-bit values you can't escape are kept close to their high-resolution range (close to zero).

This was the product of nearly 3 years of development though, so it's quite a bit to digest, let alone explain, in a few forum posts. We did a presentation last year at Unite where I talked about these solutions in more detail, hopefully it will be of help:

https://www.youtube.com/watch?v=mXTxQko-JH0

Cheers

 

[BruceJohnJennerLawso]

You're on the right track using doubles already to hold precision. The problem is, the underlying graphics API is still 32-bit based (not sure what you're using, but unless you're rolling your own starting at DirectX level, chances are you're stuck with 32 bit).

There were a number of solutions we implemented over time to solve FP issues in KSP as the game progressed, and those issues became greater and greater bars to gameplay.

First to be implemented was the Floating Origin solution. Even if you store coords at double precision, when the time comes to place the actual game objects, that double precision is cast down to 32 bit values again, and issues like visual (and physics) jitter ensue. This meant that before FO was implemented, any object going farther than about 15km from the scene origin (the location of the launchpad) woudl start showing signs of jitter, and eventually become so unmanageable parts would detach themselves on their own, meshes would jitter as vertices lost placement precision (due to transform matrices degrading), in general, madness. Floating Origin consists of keeping the 'player' (ship, camera, disembodied soul) constantly near the origin, and shifting the rest of the universe in the opposite direction whenever the player leaves the allowed range in which he's permitted to roam. Doing this ensures nearby (relative to the player) objects will always be close to the origin as well, and thus be resolved at maximum resolution.

The second thing to be implemented was the concept of scaled space. This was done so objects seen in the map, or very far from you (such as a moon as seen from the surface of Kerbin) would be modelled in a 'subscene' (a layer with its own cameras and lighting which is invisible to cameras and objects in other layers), where objects are scaled down at a 1:6000 ratio relative to the true-space subscene, called localspace.

Hmmm

A lot of this wouldnt directly apply for me here, since the engine I am writing is strictly 2d (think Lunar Lander, but expanded to the scale of Orbiter). If I follow correctly, the basic idea is to set up all of the code that deals with rendering in terms of a coordinate system centered at wherever the camera is? That should at least make the code easier to follow.

Im not sure I follow the part about subscenes. Why would you want to scale down objects at all?

Last of all but certainly not least, was the solution we called Krakensbane. KB works very much like floating origin, but instead of solving FP issues for position, it does so for velocity. In space, you're free to accelerate continuously until your velocity vector itself becomes so large a value, it starts to break down in precision. In KSP, this was a serious problem because each part of the ship is its own rigidbody, and having rigidbodies which are supposed to be linked together not share exactly the same velocity, down to the micrometer range, caused phantom forces to randomly act on the vessel, eventually becoming so large as to tear the ship apart. This became known as the Deep-Space Kraken, and Krakensbane was the solution that finally killed it.

KB consists of putting the vessel in a motionless reference frame (relative to the scene), where its imprecise physical velocity is close to zero, and a double-precision vector accumulates the velocity 'absorbed' by this reference frame, and on each new tick, moves the universe (much like FO does) velocity*deltatime units in the opposite direction. This again ensures the 32-bit values you can't escape are kept close to their high-resolution range (close to zero).
Cheers

So the Kraken was basically an issue with integration errors piling up? Those kind of "Phantom forces" should in fact be present in reality right? (different gravity at different position, centrifugal forces, etc) The kraken was just an issue with high time accelerations making them much larger than they should have been? (Man I just love saying the Kraken :lol

Im having a really hard time following why your reference frame is moved like this (seems like it would be easier to just describe an objects position in the universe than describe where everything is relative to it) What happens to the coordinate system when the player changes vessels? And how does this affect stability of faraway vessels (say a ship landed on the mun, when the current focus is near Jool)

The actual project itself on Github:

https://github.com/BruceJohnJennerLawso/Ignition_Engine

*One other thing, what is FO?*

 

[orb]

*One other thing, what is FO?*

FO = Floating Origin
http://wiki.unity3d.com/index.php?title=Floating_Origin


To further increase precision in calculations (but not really rendering) when you have large scales and small changes in values, you can for example use double-double arithmetic, where you use pairs of doubles, which will increase precision to 106 bits, but with the exponent still at 11-bits: http://en.wikipedia.org/wiki/Quadruple_precision#Double-double_arithmetic. It slows down calculations only a little when compared to arbitrary precision solutions.

 

[Urwumpe]

Also, the precision depends a lot on how you calculate. What seems to be an effective algorithm on the paper can be extremely unprecise in floating point calculus.

Another good solution there is too keep track of the calculation errors in the position and velocity. While those are initially too small to notice, they get pretty annoying after a few time steps - by just tracking the accumulative errors, you have a correction factor at a smaller exponent, that can be included in the calculations.

 

[Keithth G]

Numerical accuracy notwithstanding, one thing you should note is that modelling the physics is simplest in an inertial reference frame. A straightforward approach to modelling Newtonian gravity is to identify the Solar System barycentre (the Centre of Mass, in effect) and use that as the origin of one's reference frame. If one uses the centre of the Sun, say, as the origin of one's coordinate system, this co-ordinate system is not inertial because the Sun is, in fact, in orbit around the Solar System barycentre. To get the physics right, you will need to take care to include all of the additional apparent forces (e.g. centrifugal force) that arise because you have moved to a non-inertial reference frame. It is, of course, possible to do this, but you need to take considerable care in doing so.