KSP Keostationary Orbits broken

[PrimoDev]

Hello !

I made a geostationary orbit in ksp with 3 satellite around kerbin, It was working well until I leave my save and come back on it :

The 3 satellites wasn't separated by 120 degree as before but the 1st one was like 20° from the 2nd and the 2nd was 35° away from the 3rd and last one..

I did not changed the gravity in debug panel or anything like that so I don't know why is this happening...

[PrimoDev]

Also, why do my content need to be approved by a moderator before posting ?

[luizopiloto]

31 minutes ago, PrimoDev said:

Also, why do my content need to be approved by a moderator before posting ?

For safety. You have no idea how many spambots tries to post here using new accounts...

[PrimoDev]

1 minute ago, luizopiloto said:

For safety. You have no idea how many spambots tries to post here using new accounts...

Okay, no problems it's good to know that people work here to keep a quality forum

[James Kerman]

Greetings and welcome to the forums, @PrimoDev.  It is difficult to maintain a satellite constellation in KEO.  Did you do any time warping after the last time you saw your network?

If you post the Apoapsis/Periapsis of each sat we should be able to see any problems.

[PrimoDev]

Thanks ! Yes, I did time warped 20days because of launching some other rockets.

1st sat :

Apo = 2863.345

Peri = 2863.341

2nd sat :

Apo = 2863.348

Peri = 2863.342

3rd sat :

Apo = 2863.344

Peri = 2863.340

Edited November 26, 2017 by PrimoDev

[Corona688]

But...  why?  Isn't KEO the kind of place - a giant orbit on rails - you'd expect to actually work right?

[PrimoDev]

I expected it to work properly  but seems like KSP failed to keep the right position of these satellite...

[Spricigo]

37 minutes ago, Corona688 said:

But...  why?  Isn't KEO the kind of place - a giant orbit on rails - you'd expect to actually work right?

I expect all the orbits to work right. Not only geostationary.

@PrimoDev seems like an error at the save file. I'd fix it with the [set orbit] functionality at the debug menu and pretend it never happened. 

 

[Corona688]

12 minutes ago, Spricigo said:

I expect all the orbits to work right. Not only geostationary.

@PrimoDev seems like an error at the save file. I'd fix it with the [set orbit] functionality at the debug menu and pretend it never happened. 

 

There are perfectly good reasons why some are computationally difficult.  These aren't.

[PrimoDev]

3 hours ago, Spricigo said:

I'd fix it with the [set orbit] functionality at the debug menu

How do you do that ? how to set a certain satellite at a certain angle of the orbit ?

[Spricigo]

1 hour ago, PrimoDev said:

How do you do that ? how to set a certain satellite at a certain angle of the orbit ?

It's one of the parameters you can set, MNA.

[Geschosskopf]

10 hours ago, PrimoDev said:

I made a geostationary orbit in ksp with 3 satellite around kerbin, It was working well until I leave my save and come back on it :

The 3 satellites wasn't separated by 120 degree as before but the 1st one was like 20° from the 2nd and the 2nd was 35° away from the 3rd and last one..

I did not changed the gravity in debug panel or anything like that so I don't know why is this happening...

There is 1 main and 1 secondary reason for this happening.  Both of which are game issues.

Main Reason:  Floating Point Errors.  Every time you load/save/reload the game, or go look at another ship, the positions of all ships in flight get shifted slightly due to rounding errors with floating point numbers.  This essentially means that it is impossible to have a constellation of satellites with stable spacing over the long term.  Which is why you should never try to make a kerbostationary constellation.  Which means you should NEVER disable the extra ground stations.  If those are turned on, there's no need for a kerbostationary network.

Secondary Reason:  KSP utterly lacks the necessary instrumentation for spaceflight.  That's because it's not a simulator, it's a game, intended to by played by eyeball and luck, for larfs.  The ONLY important variable to maintain even mid-term stability (as in a few months to a year or 2) for a kerbostatinary constellation is the satellites' orbital period.  You want this to be the same for all satellites.  Inclination can be off a bit, Pe and Ap can be off slightly---those don't matter for maintaining spacing.  If those are a bit off, the satellites will librate around their assigned spot in the sky just like Ike librates around the same place in Duna's sky.  Close enough for government work.  But orbital period is the be-all and end-all because THAT's what determines the stability of spacing.  However, there's no stock feature that shows you the orbital period in fine enough resolution to be useful.  You need all the satellites to be within 1 second of the same orbital period, which is only possible if you use a mod that displays your orbital period down to the second, and your satellites have RCS pointing forwards or back with the thrust turned way down, so you can very gently tweak your orbital period to match those of the other satellites.

Do this and it will last a while, but not for years due to the floating point errors of the Main Reason.  Which basically means, constructing a kerbostationary network is a fool's errand.  Which means, you should never turn off the extra ground stations because that's what makes having a kerbostationary constellation necessary.

Edited November 27, 2017 by Geschosskopf

[PrimoDev]

15 hours ago, Spricigo said:

It's one of the parameters you can set, MNA

Thanks ! I didn't knew that

@Geschosskopf

That's explain a lot ! Thanks you very much !

15 hours ago, Geschosskopf said:

Which means you should NEVER disable the extra ground stations.

I checked and it was disabled but never touched to these but I think I will leave them because it add a challenge and some more difficulty to the game, like in reality .

By the way, Do you have to edit the topic name and add [Solved] before the title, as you guys answered my question ?

[Eric S]

18 hours ago, Geschosskopf said:

Main Reason:  Floating Point Errors.  Every time you load/save/reload the game, or go look at another ship, the positions of all ships in flight get shifted slightly due to rounding errors with floating point numbers.  This essentially means that it is impossible to have a constellation of satellites with stable spacing over the long term.  Which is why you should never try to make a kerbostationary constellation.  Which means you should NEVER disable the extra ground stations.  If those are turned on, there's no need for a kerbostationary network.

In addition to that, if you switch to the craft, the orbital parameters get translated to a velocity.  Then, when you switch away from the craft, the velocity gets converted back to orbital parameters.  Which really just means more opportunity for rounding errors.

[Spricigo]

12 hours ago, PrimoDev said:

By the way, Do you have to edit the topic name and add [Solved] before the title, as you guys answered my question ?

Clicking one of the check marks(only available for the OP) will select the post as correct/best answer and mark the question as answered.

You don't have too, but it may help people seeking and offering help.

Similarly the little triangles are to upvote answers, those appear to all users. By default this subforum displays post by votes.

[Starman4308]

On 11/26/2017 at 6:56 PM, Geschosskopf said:

Main Reason:  Floating Point Errors.  Every time you load/save/reload the game, or go look at another ship, the positions of all ships in flight get shifted slightly due to rounding errors with floating point numbers.

To the best of my knowledge, no floating point rounding errors occur for on-rails vessels beyond what occurred when they last went on-rails.

I'm testing things right now (just got 3 vessels Hyperedited to have the same SMA, now timewarping), but my understanding is that, for an on-rails vessel, its current position is calculated from 6 stored orbital parameters and the current game clock. The only reason those stored orbital parameters would change is if the vessel encountered a new SOI, or impacted a celestial body.

If you have a stable orbit in KSP, it remains in that stable orbit forever; with the Keplerian 2-body approximation, there are closed-form solutions for position given 6 orbital parameters and a time.

So, if you have 3 vessels in orbits with identical semi-major axes, plus or minus a bit of wobbling if they're not perfectly circular, they will stay in phase forever.

The trouble is that, sans Hyperedit and similar, you're never going to get absolutely identical SMAs, because you do get floating-point errors in position when in physics, and unless you have absurd luck, you're not going to click "return to space center" exactly when you have the correct SMA.

In the real world, constellations like that do go out of phase for a million reasons. However, real-world satellites have paid control crews who do maintenance burns every so often to keep satellites where the're supposed to be; there's no such luck in KSP, where the control crew is one dude who may or may not have a good understanding of orbital mechanics.

EDIT: Ran the clock forward almost seven years. First, the testing is a success: while the satellite I jumped back to developed a minute error because of a moment of off-rails physics, the error is consistent when I look at either of the two untouched satellites. MechJeb is reporting the synodic period to both of the others to be exactly equal: 67014 years, 189 days, 16 hours, 38 minutes, and 11 seconds (Earth time). When I use MechJeb to reposition the satellite back into a perfect orbit, that synodic period is reported as infinity.

To clarify why this can occur: for on-rails vessels in a stable orbit, KSP does not calculate position at timestep n based on its position in timestep n-1. It calculates position based on 6 orbital parameters and the current game clock. The only reason you need Hyperedit or save-file editing to ensure absolutely perfect stationkeeping is because it's generally impossible to get exactly the correct SMA while in physics; micro-jitter induced by floating-point errors ensures you have to be incredibly lucky to get that.

In real life, as stated above, there's all sorts of things causing errors in your trajectory (solar wind, etc), and they just use small stationkeeping burns every so often, something most KSP players don't have the patience for; thus, why I'll often get an almost exact communication constellation, and then Hyperedit them into a perfect constellation.

Edited November 29, 2017 by Starman4308

[Spricigo]

Btw if someone want some help with stationkeeping

(Reported to work with newer versions of KSP)

 

[Geschosskopf]

4 hours ago, Starman4308 said:

The trouble is that, sans Hyperedit and similar, you're never going to get absolutely identical SMAs, because you do get floating-point errors in position when in physics, and unless you have absurd luck, you're not going to click "return to space center" exactly when you have the correct SMA.

Right.  The game's stock information systems and flight controls are not precise enough to position the constellation to achieve long-term stability.  Even with better information provided by mods, you still have the flight control issue, so it's only possible to get a truly stable constellation by cheating.  Which is sort of a paradox, given that the only reason to make a kerbostationary network anyway is due to one's perception of realism  

This right here is the main reason I quit using RemoteTech, and that was back before the stock system came along.  At least at that point in time, RT required you frequently to take your relays off rails to aim their various antennae at new targets.  Say you wanted to put up 3 kerbostationary satellites.  So you put up the 1st and it's on rails.  Then you put up the 2nd and aim 1 of its antennae at the 1st.  Then you had to go to the 1st and aim one of its antennae at the 2nd.  When you put up the 3rd, you had to go to each of the other 2 and aim one of their antennae at the 3rd.  And so on every time you expanded your network.  Thus, you were always putting in more error into your spacing, which wasn't precise to begin with, so networks really had no long-term stability.  Before too long, you were spending all your time doing station-keeping instead of exploring the solar system.

It's better with the stock system now as the relays are fire-and-forget, but you still can't get the spacing even so over time you still get drift.  But even better is the fact that you don't need to bother with this at all if you leave the extra ground stations enabled.

[Starman4308]

9 hours ago, Geschosskopf said:

Right.  The game's stock information systems and flight controls are not precise enough to position the constellation to achieve long-term stability.  Even with better information provided by mods, you still have the flight control issue, so it's only possible to get a truly stable constellation by cheating.  Which is sort of a paradox, given that the only reason to make a kerbostationary network anyway is due to one's perception of realism  

Right: I'm not arguing that. Except maybe the "cheating" thing; I'd hardly call it cheating to use Hyperedit to move an almost-perfect constellation with a synodic period measured in decades to a perfect constellation.

Your original post, however:

On 11/26/2017 at 6:56 PM, Geschosskopf said:

Main Reason:  Floating Point Errors.  Every time you load/save/reload the game, or go look at another ship, the positions of all ships in flight get shifted slightly due to rounding errors with floating point numbers.

What I had an issue with was the assertion that you get compounding floating-point errors* for on-rails vessels any time you do anything. The only sources of floating-point error relevant to maintaining a keosynchronous communications network come from using on-physics flight to set up the network in the first place. Once you stop flying the communications satellites, loading, saving, reloading the game, switching to other ships, etc, has no effect on your constellation.

*Technically, there's a small error in calculating its position each timestep; it's just an independent, random error that doesn't affect its calculated position in the next timestep.

[Geschosskopf]

1 minute ago, Starman4308 said:

What I had an issue with was the assertion that you get compounding floating-point errors* for on-rails vessels any time you do anything. The only sources of floating-point error relevant to maintaining a keosynchronous communications network come from using on-physics flight to set up the network in the first place. Once you stop flying the communications satellites, loading, saving, reloading the game, switching to other ships, etc, has no effect on your constellation.

*Technically, there's a small error in calculating its position each timestep; it's just an independent, random error that doesn't affect its calculated position in the next timestep.

Well, OK, maybe what's happening is not "floating point error" but it's definitely error that has sort of the same symptoms.  Stuff on rails (or on the ground) does not stay precisely where you left it over time.  Especially if you warp through days/weeks/months at high rate while you have another ship or nothing at all in focus.

The basic issue is that a ship's orbit is not it's only motion.  The planet it's orbiting is also moving, so not only does the ship have to circle the planet, but that circle has to be dragged along with the planet as it moves.  When you warp, this combined motion goes from smooth at 1:1 to jerky because warping essentially means the game is performing fewer positional update in a given amount of elapsed realtime.  So the higher you warp, the further both the planet and the ship teleport to their next positions, and the less agreement there is between those new positions and where they would have ended up after the same amount of elapsed gametime had you not warped.  In addition, the higher the warp level, the greater the effective temporal distance relative to the game clock between when the planet moves and the ship moves.

The result is that the relative position of the ship to the planet changes when you're warping.  The higher you warp, and the longer you warp, the greater this difference becomes.  As the ship's position to the planet changes, so does the force of gravity acting on it, and this affects even ships on rails.  Thus, the next time it's the ship's turn to move, it will move differently than before due to the different gravity acting on it at present.  In extreme cases, this can result in on-rails ships being ejected from orbit or even the solar system during long periods of high warp level.  But in your average, everyday situation, the result is simply relatively small orbital perturbations.

Applying this to a satellite constellation, each relay is affected differently.  If it happens that the planet moves before any of the relays, then the relays that happen to be on the leading side of the planet when its their turn to move are now closer to the planet than before, so speed up.  OTOH, those on the trailing side are further away so slow down.  As the warp goes on, all the relays have both of these things happen to them multiple times but with a somewhat random-ish distribution depending on warp level.  But the result is that the orbital periods of each relay change by different amounts during the warp, so that spacing quickly becomes irregular.  And the amount of change in the amount of elapsed gametime is usually rather greater than expected just from the known difference in orbital parameters before you started warping, so you're left to wonder how it happened.

This all isn't much of a problem as long as your space program is staying relatively close to home.  Then you don't need to warp at extreme levels nor for very long stretches of realtime.  But as you go further from home, this changes.  Then maintaining the kerbostationary network becomes extremely problematic.  If you don't warp a lot for a long time, you'll never get to the distant planet in a reasonable amount of real time.  But if you do that, then your network falls apart and you can't talk to those ships as you'd like to when they arrive.

 

[Corona688]

1 hour ago, Geschosskopf said:

Well, OK, maybe what's happening is not "floating point error" but it's definitely error that has sort of the same symptoms.  Stuff on rails (or on the ground) does not stay precisely where you left it over time.  Especially if you warp through days/weeks/months at high rate while you have another ship or nothing at all in focus.

Stuff on the ground has to deal with hitboxes and landscape colliders.

It's difficult to align stuff in space precisely enough.  Your instruments can't tell you when an orbit is correct -- they have floating point errors too.  And even if you get it perfect, the orbit will probably stop being perfect a few game ticks later.

Quote

The basic issue is that a ship's orbit is not it's only motion.  The planet it's orbiting is also moving, so not only does the ship have to circle the planet, but that circle has to be dragged along with the planet as it moves.

Physics and rails are always computed relative to the local sphere-of-influence, to make that dragging irrelevant.  Squad did that quite intentionally, as 32-bit floats just aren't precise enough to model a mun landing with Kerbin as the center of the universe.

In pre-Mun versions of KSP, you could tear your ship apart by flying far enough away that floating point errors nudged different bits of your ship different directions.  That was the original Kraken, which they "slayed" by adding references of different scales.

Quote

When you warp, this combined motion goes from smooth at 1:1 to jerky because warping essentially means the game is performing fewer positional update in a given amount of elapsed realtime.

Timewarp doesn't have incremental errors, it puts your ship on rails.  (Physwarp does, though.)  The jumpiness can be many other things, but often means other things switching SOI.

Edited November 29, 2017 by Corona688

[Geschosskopf]

2 minutes ago, Corona688 said:

Physics and rails are always computed relative to the local sphere-of-influence, to make that dragging irrelevant.

BUT, the motion of the ship and the SOI don't happen simultaneously.  The game can only crunch a limited amount of numbers at a time.  So the planet moves, then the ship moves, or vice versa, it doesn't matter.  What matters is that this sequential motion of the 2 objects results in different distances between them when it's the turn of the ship.  So when the ship's motion is computed relative to the local SOI, that computation is now different than it was last time, because the effect of gravity on the ship is different.

At up to about 1000:1 warp, the difference in gravity isn't enough to worry about because the change in the strength and direction of gravity on the ship isn't significant, although it does happen.  Also, you don't generally use 1000x warp for long stretches.  Usually, it's for moving to the next maneuver node or SOI change only a few hours in the future.  Thus, not only is the effect not significant, it doesn't have the chance to build up into a problem.  10,000:1 warp, OTOH, is somewhat borderline, and anything above that is really asking for trouble, especially if continued to warp through the months, years, or even decades required by a long interplanetary trip.

[Corona688]

2 hours ago, Geschosskopf said:

BUT, the motion of the ship and the SOI don't happen simultaneously.  The game can only crunch a limited amount of numbers at a time.

1. Orbits aren't done iteratively, not unless  you're actively flying the craft.  When an orbit is "on rails", its defined by a fixed equation which should stay as accurate as it started for 24 million game ticks or so.
2. Even when you are flying a craft, the motion of the SOI is not considered at all.

Quote

So the planet moves, then the ship moves, or vice versa, it doesn't matter.

No.

There's a third way to calculate these things.  You can calculate orbits around each SOI independently, as if each body were motionless at the center of the universe.  Then it no longer matters which order you calculate them in.

So, when you're landing on the mun, Kerbin's motion is not factored into your own.  Your own SOI couldn't care less where Kerbin is.  That's not even the real Kerbin in the sky, just a miniature placeholder fudged and downscaled to fit your own SOI.

 

Quote

At up to about 1000:1 warp, the difference in gravity isn't enough to worry about because the change in the strength and direction of gravity on the ship isn't significant, although it does happen.  Also, you don't generally use 1000x warp for long stretches.  Usually, it's for moving to the next maneuver node or SOI change only a few hours in the future.  Thus, not only is the effect not significant, it doesn't have the chance to build up into a problem.

Timewarp is not iterative.

Just to make that clear.  Ahem.

Some inaccuracy is caused from going into and out of timewarp, from translating between iterative motion and fixed equations and back.

Some inaccuracy also happens when switching SOI's.  It has to rescale your motion into a new reference, and when one reference is big and the other is small, accuracy is lost.

And even a fixed equation is not perfect.  It doesn't accumulate error in the same sense as iterative calculation, but an orbit that's off 10m per day will be off 3km in a year.

And a fixed equation is only as accurate as the place it started from.  You will never get an orbit quite perfect during iterative physics, therefore it will never bet quite perfect on rails either - not unless you edit it into perfection with alt-F12 or save-file meddling and leave it untouched thereafter.

Edited November 29, 2017 by Corona688

[Geschosskopf]

3 hours ago, Corona688 said:

Timewarp is not iterative.

I KNOW what you say is SUPPOSED to be true.  But the problem is, it doesn't work out that way in practice.  And AFAIK, there is no cure for this.  Every game that purports to have even semi-realistic orbital mechanics going on has the same problem.  Crank time warp "up to 11" and the universe falls apart sooner rather than later.  That's the inevitable result of trying to replicate what is in reality an n-body "analog"* system with what is, by the nature of the underlying hardware and software, a discrete X-body system.  In stock KSP, X=2.  If you have some mod that does "n-body" (however that math is defined), you still can't escape the bottom limit of the positional coordinate system, which is orders of magnitude greater than the Planck Length.

And then you have to consider how the game engine handles relative velocity, even when limited to the SOI of the primary of the 2-body system.  When you're skipping computations, how do you deal with some objects moving faster than others?  The usual answer is, the faster objects get to move more often than the slower objects.  And each time those objects move, they have their relevant forces applied to them, based on the position of the central body.  But that central body is itself moving, and its motion is out of sync with the ships orbiting it.  Thus, things get funky.

*The real Universe is, of course, actually digital and discrete as opposed to being analog and continuous,  In real life, the smallest unit of time is the Planck Time and the smallest unit of distance is the Planck Length.  Anything less than those values is "floating point error".  As a result of these constants, Zeno's Paradox of Achilles vs. the tortoise isn't really a paradox.  At some point, Achilles will be 1 Planck Length behind the tortoise,.  Because that is the minimum distance behind the tortoise it is possible to be, Achilles can't ever get less than that far behind the tortoise.  But Achilles is way faster than the tortoise, so in the next timestep (which can't be less than Planck Time), he will be at least tied with the tortoise if not out in front.  And from there on, the tortoise is eating Achilles' dust.  But because reality doesn't have moons ripped from their orbits barring extreme external stimuli, either the real Universe has no time warp > 10, or is capable of running (in Sagan's voice) "billions and billions" of threads simultaneously.,