Ever wondered why satellite networks seem to drift so readily?

[MisterFister]

This is not intended as a how-to on setting up satellite networks (for example, comsat constellations for RemoteTech) as that is addressed in countless other threads. This is an explanation of why maintaining those multiple overlapping orbits can become such a headache on older career saves, with satellites falling out of phase with each other and multiple satellites / stations "bunching up" resulting in coverage gaps that might not have been there when you first set them up. Many people are surprised by this, and often, the discussions of how this happens to begin with ends up involving comparisons between GSO (Geostationary Orbit, which refers to real-world space technology [since "geo-" is a word prefix that specifically means Earth, as in the actual planet -- if it's not actually the planet Earth you're talking about, the prefix "geo-" isn't appropriate]) and KSO (KeoSationary Orbit, since "keo-" refers to Kerbin). *

First, it's true that real world GSO satellites drift and have to consume fuel for stationkeeping purposes to counteract this over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, real world orbit perturbations result from myriad underlying causes: including faintly off-kilter insertion calculations to begin with; fuel impurities (resulting in slightly-less-than-optimal thrust vectors, and burn times being minisculely off-mark;) and other n-body outside gravitational influences. Over extended periods for extremely accuracy-sensitive satellites, influences such as the moon's orbit, solar activity, and minute irregularities in Earth's own gravity well can interfere with orbit calculation (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle, and unequal distribution of mass means an unequal distribution of gravity, which means that the gravity well is not a perfect sphere to begin with.) Also, there is something called insterstellar and interplanetary drag, such as that from the cumulative slowdown you get from floating through faint dust clouds and debris stemming from Keppler Syndrome; as well as naturally occurring events such as the Leonid; or even the cumulative drag effect of the "solar wind," which is literally the result of being constantly bombarded with countless photons from the sun's light and radiation (photons and other subatomic particles are funny things, but they do have mass, even though that mass is very small -- if you keep getting slammed with them at the speed of light for long enough, they WILL eventually send you off course.)

Obviously, since KSP is a game, the Unity engine is not designed to (nor could it ever) faithfully model every single one of those conditions in an n-body-type system, though there have been mentions by people like Scott Manley that people are trying to make it happen anyway. Indeed, in KSO all SOIs (Spheres of [gravitational] Influence) are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a perfectly spherical and uniform featureless gravity well. For example, there is no such thing as Lagrange points in this game. Further, all fuel in this game is uniformly pure, as another example -- you don't have to worry in KSP about suboptimal burn times due to poor fuel mixtures unless you have a mod that specifically introduces that level of complexity. Despite all of these differences between real world orbital environments and KSP, however, there are three big items that can interfere with orbital maintenance (one is an obvious issue, and there are two others that are perhaps more subtle.)

The obvious issue is human input, just as with real world scenarios. In this game, even if you design and plan your maneuver nodes well (which even then is not entirely sufficient for the accuracy we would like, due to the two subtle reasons below) it's still necessary to aim and burn them well, too. Good form, good practice, and good fuel efficiency on maneuver nodes begins with good calculations when designing your craft in the VAB / SPH. Good practice continues beyond the design phase to then include the practice of dividing your total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00s BEFORE the designated time, and end exactly 30.00s AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never mathematically possible without leaving your throttle maxed and controlling them by toggling the engine on and off at the correct times) and accurately following the blue node indicator on your navball. The blue node indicator is another key item of good orbital planning in this game. especially since it's so impossible to be picture-perfect on the craft-design, maneuver-node design, and maneuver-burn elements -- when you are down to the last few m/s of burn, it's generally a good idea in this game to lower your throttle, puff those final m/s out, and actually follow the drifting node marker on your navball whenever possible, since the location of the marker DOES calculate your new trajectory live by applying any burn imperfections into the original node calculations (and it does so by pretty-accurately recalculating the actual m/s needed to get your final intended course change.) Generally, everything I've said so far makes an immediate sort of sense, when it's laid out clearly here or in other how-to posts on the forum.

The two other reasons why KSO** orbits (or any orbital arrangement, for that matter) drift into disarray the way they tend to do are much less obvious, however. First, we can agree that the actual math (advanced three-dimensional conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through real world space or through KSP space, is highly complex, with numbers that usually have unending decimal places out to 10^(-200) or even further. Simply put, in order to "work," the KSP game engine at some point is forced to say "meh, that's close enough" and stop calculating past the umpteenth decimal place and just fly with that. Those rounding errors, particularly when projected forward over simulated lapses of time acceleration, become significant -- ESPECIALLY in a situation like yours where you probably have multiple satellites involved, and one realizes that you can run the same calculation a hundred times, and round it the "same way" each of those hundred times, and little eensy-teensy math discrepancies become more and more noticeable between iterations of the same satellite, the same launch, the same orbital insertion, but with minute and subtle differences in burn accuracy and launch efficiency, etc.

As if all of that wasn't enough, there's also the third fact that when actually coming into and out of time compression, and when OTHER craft in your savefile change SOIs, all of those calculations are reset and recomputed and re-rounded anew, from scratch. As you play your game and progress in your save, whether you simply blast forward at 100,000x time compression for 5 real world days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways like Scott Manley, this repetitive rounding will compound and worsen all of the above factors that I've described, each time the engine calculates it, which can often be hundreds of times every real world second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow with poor framerates when it has to keep track of large and complex craft in close proximity to each other -- when physics load onto a craft or station, it calculates all of this orbital mechanics stuff for each individual part.)

So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem and prevent it from coming back. Savefile editing will, of course, come the "closest" to totally eliminating it, since doing so will eliminate all of the human-introduced elements of uncertainty and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately though, just as in real world satellite maintenance, you just have to in some way incorporate this inevitability into the design of your craft and your mission profiles (for example, by periodically re-editing your savefile, or by launching more satellites for your network for extra overlapping coverage, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot, and by launching those satellites with extra RCS for better fine-tuning over a longer operational life.)

I hope this explains a few things, and I invite discussion below. With new input and insight, I'd enjoy editing and maintaining this thread as an educational codpiece for the forums.

*Note that other proper-noun celestial bodies have their own prefixes that parallel this linguistic construction, we just don't hear them as often. For example, Mars is named after the mythical figure Ares (yes, like the zodiac sign) so Mars-stationary orbit would be "areostationary" orbit. Jupiter is named after "Jove," the Latin / Roman name for the god originally called Zeus by the Greeks, so Jupiter-stationary orbit would be "jovistationary" orbit, etc. This linguistic construction applies to other terminology, too; we refer to "geography," which literally translated to "Earth-recording," or "land-mapping," which is exactly what it is. On Mars, then, it would be properly referred to as "aerography." For the moon, called Luna, we'd have lunography.

**I'll briefly note here that actual synchronicity in any orbital arrangement is totally unnecessary in pretty much any scenario I can think of. Synchronous orbits have the managerial benefits of always being easy to visually identify on the mapview, and the ability to predict where and when coverage blackouts might form, this much is true. And also, of course, synchronous orbits in any case cater very well to the OCD that we all have to some degree large or small. Otherwise, however, the important element in setting up any orbital pattern of multiple satellites is coverage and overlap. The orbital period for KSO in the stock game [day length of 5h59m[XX]s] is an orbital period of the length of a Kerbin day. If you wanted to keep your satellite network at lower altitude, perhaps with an orbital period closer to thirty minutes, then obviously the satellites would not remain stationary with respect to the rotating surface of the planet, but you could still achieve continuously overlapping coverage by simply sending up more copies of the satellite and keeping them properly spaced (which admittedly brings us back to the original point of this post: maintaining the spacing between orbiting objects around the same celestial body.)

Edited July 31, 2014 by MisterFister

[Kuldaralagh]

I don't get it. I mean i do, the minute details of perfect orbits are impossible to get right, but my sats dont bunch up, specially the KSO. After I get the phase alignment i want, usually 120 degrees,  i match the orbital period to the thousandth of a second.

I am sure it will over a lot of time(a lot really, i have no idea how much) have a deviation,  but hey, just go there and align the phase again, and reset the orbital periods. 

 

[problemecium]

^ I have no idea how you manage to synchronize within a millisecond, but mad props for that.

Regarding bunching, I agree that concerns about bunching over short timescales, i.e. less than 20 years, are no big deal. Even then it can be solved with just a minimal bit of stationkeeping, but I've never even found it necessary due to my saves rarely lasting more than two years (if that) before my having to restart them due to a major game version change.

[DerekL1963]

9 hours ago, parameciumkid said:

^ I have no idea how you manage to synchronize within a millisecond, but mad props for that.

1] Use KER or MJ for a high precision readout of your orbital period and SMA (which is what you really want to match).  (And MJ's "Warp To" feature is very handy for zipping to a few seconds before your Ap/Pe.)
2] A craft with a ridiculously low T/W ratio.  (RCS based preferred because you can burn pro- and retro- grade w/o rotating the vessel.)
3] Practice, practice, practice.

Seriously, it's not that hard once you get in the habit of piloting "by the numbers" [displayed by MJ or KER].

[fourfa]

No one noticed this is a more than two years old necro?

[Val]

9 hours ago, fourfa said:

No one noticed this is a more than two years old necro?

It's only considered a necro if the topic is no longer relevant to current game state. I think, the topic of this one is still relevant.

 

Edited September 19, 2016 by Val
Edit fail

[Jarin]

Another problem that I've seen come up (and bit me repeatedly before I had the problem pointed out to me) is the difference between rotational period and sidereal rotational period. I got pretty darn good with minor orbit adjustments, but precision with the RCS engines doesn't help you one bit if you put up that primary KSO comsat - perfectly positioned over KSC - ... with an orbital period of exactly 6 hours. This worked fine, pre-1.0.5, but now that Kerbin has an actual synodic 6h day, its sidereal rotational period is down to 5h 59m 9.4s, so KSO satellites need to have this orbital period to stay put properly.

[John Cochran]

The OP is quite right about keeping things precise, but he missed one of the MAJOR issues that cause satellites to drift out of alignment. 1.2 just got out of open beta and I had heard that G and a few other constants changed and I wanted to update my orbit calculation spreadsheet with the new numbers, so I decided to figure them out empirically by using the cheat menu placing a satellite into orbit with a specified SMA and by monitoring KerbalEngineer, see if it's drifting east or west, then adjusting the SMA up or down until I simultaneously determined both the exact SMA for a stationary satellite and the sidereal rotational period for the body I was orbiting. The answer is "Yes, the mu values for the various bodies have changed a bit." For my final test, I inserted into orbit around the eight bodies who's synchronous orbit is within the SOI. I then took note of the longitude each satellite was above and finally did a time warp a year or two into the future. Then looked at the longitudes that the satellites were are and was rather dismayed that they had drifted several minutes of arc when they hadn't even drifted 1 second of arc while I was determining the original numbers.

So I looked closer at the figures and was rather unpleasantly surprised and extremely annoyed. The Satellite I left in a synchronous orbit of Eeloo with a semi-major axis of exactly 893589.151 meters and a period of exactly 5h 24m 20.000s had somehow changed to a semi-major axis of 893590.076 meters and a period of 5h 24m 20.030s. That little error of 0.030 seconds will cause quite a bit of drift over time. The SMA I set wouldn't even drift by a second of arc over a several game decades, but the new SMA drifts by 2 seconds of arc every orbit or a bit under 16 minutes of arc per Kerbin year.

Since the SMA I set and the SMA I saw when I came back to the satellite after switching to the tracking center only match to 6 digits of precision, I suspect that there's a conversion from double precision to single precision somewhere in the chain of calculations going between the Unity game engine and the persistent save file. And that loss of precision makes it absolutely impossible to setup a precise constellation of satellites. I also did some tests with save file editing and have noticed that the figures for an orbit of a satellite don't change in the save file unless you actually get within physics simulation distance of that satellite. When that happens, the figures lose their precision and things start drifting again. So it is possible to setup stable constellations by save file editing. Just never make those satellites the active craft or get within physics distance of those satellites.

For those who are interested, the stationary SMAfor a Kerbin satellite is 3462940.708 meters and Kerbin's sidereal rotational period is 5h 59m 9.434 seconds (figured correct for KSP version 1.2.0.1586).

To replicate my experiment, use the cheat menu to place a satellite into Eeloo orbit with a SMA of exactly 893589.151 meters. After doing that, while keeping that satellite the active vehicle, perform a time warp of a decade or two to see that it doesn't drift (Use KER to observe the latitude of the satellite). After confirming the lack of drift, go back to the tracking center at KSC and then switch back to the satellite orbiting Eeloo. You'll see that the SMA and period have changed and if you time warp, the satellite will now start drifting quite noticeably. 

[Serpens Solidus]

19 hours ago, John Cochran said:

I wanted to update my orbit calculation spreadsheet with the new numbers, so I decided to figure them out empirically

Instead of empirically determining the new values, let's calculate them. (I use MATLAB for convenience)

We have this
KSP now uses 9.80665 and 6.67408e-11 instead of 9.81 and 6.674e-11 for gravity equations.

and this

KSP calculates body mass by taking the gravity in gees at sea level (times g0) and the radius and back-calculating using G (big G). Since both g0 and G have changed, mass for all bodies will have changed slightly.

We first calculate the new Kerbin year using the in game values

g0 = 9.80665;

gKer = 1 * g0;
RKer = 600000;

gSun = 1.74625 * g0;
RSun = 261600000;

SMA = 13599840256;

year = 2 * pi * sqrt(SMA^3 / gSun / RSun^2)

year =

          9205116.55936357

Which is 30ish minutes (!) longer than the old year of 9 203 490 s. (according to the wiki)

Using the old sidereal day (also from the wiki), we get the length of a solar day

dsi = 21549.425;
dso = year * dsi / (year - dsi)

dso =

          21599.9911592099

Which is 8ish milliseconds shorter than the old value of 21 600 s, about 4e-7 of a day. So after a million days, the sun should be about 40% of a day ahead of the actual time. To test this, I started a new game and clicked "warp to next morning". The time was 4:33. Then I made a quicksave, and set the UT to 21 600 000 000. Loaded the quicksave again, warp to next morning. The time is 4:33 again, but the position of the sun in the sky hasn't changed at all. There isn't even a visible change in the shadows of the KSC. Apparently Kerbin's solar day is still exactly 21600 seconds. (gj Squad)

This gives the new sidereal day, which is also the period of a KEO

newdsi = year * 21600 / (year + 21600)

newdsi =

          21549.4337994455

Now we can calculate the SMA of a KEO

KEOSMA = (gKer * RKer^2 * newdsi^2 / 4 / pi^2)^(1/3)

KEOSMA =

          3462940.70836292

Both values match your empirically determined values, which suggests that my calculations are correct (which is always a good thing).

 

 

@NathanKell I have one question: Why does KSP use G in gravity calculations? When doing gravity calculations, you always use the standard gravitational parameter (G*Mass), which is equal to g_surface * radius². So you don't really need G (or body mass).

 

[NathanKell]

We don't use big G for orbital calcs, just for calculating mass (given a sea level gravity).

 

Err, KSP doesn't. Gonna take some getting used to, what words to use. :]

Edited October 14, 2016 by NathanKell

[John Cochran]

3 hours ago, Serpens Solidus said:

newdsi =

          21549.4337994455

Now we can calculate the SMA of a KEO

KEOSMA = (gKer * RKer^2 * newdsi^2 / 4 / pi^2)^(1/3)

KEOSMA =

          3462940.70836292

Both values match your empirically determined values, which suggests that my calculations are correct (which is always a good thing).

Nice Job. And I'll use those figures in updating mu for Kerbin in my spreadsheet. I determined the values empirically simply because I don't have what I would consider a reliable source of information for the actual parameters for G, g0, etc. The wiki has a lot of data, but doesn't bother to state what version of KSP the data is valid for, so I consider that source to be close, but unreliable if you're looking for precision. 

But, alas, because of that conversion to single precision floats somewhere in the chain between the persistent file and Unity, this level of precision is not going to actually be of any use. Just switching to a precisely positioned satellite is enough to cause it to be thrown into a new orbit that's several milliseconds off in its period. Although with the introduction of Commnet, I do hope that someone comes up with a new motor that's made for precise positioning. The Ant when thrust limited to 0.5 percent still packs quite a kick and it's tricky to get a period down to the millisecond unless you've deliberately made your satellite excessively heavy by using an absurdly large fuel tank. Would like to see something with a maximum thrust of about 1 to 20 newtons instead of the 2 kN that the Ant has. And of course, would like said very weak motor to be able to thrust limited down to 0.5 percent for when you're getting really nit picky. 

[MisterFister]

 

On ‎10‎/‎13‎/‎2016 at 5:58 PM, John Cochran said:

The OP is quite right about keeping things precise, but he missed one of the MAJOR issues that cause satellites to drift out of alignment.

-snip-

Since the SMA I set and the SMA I saw when I came back to the satellite after switching to the tracking center only match to 6 digits of precision, I suspect that there's a conversion from double precision to single precision somewhere in the chain of calculations going between the Unity game engine and the persistent save file. And that loss of precision makes it absolutely impossible to setup a precise constellation of satellites.

I devoted literally three very detailed paragraphs explicitly and exclusively discussing the very item that you suggest I forgot to mention.  Behold:

 

On ‎7‎/‎30‎/‎2014 at 11:29 PM, MisterFister said:

The two other reasons why KSO** orbits (or any orbital arrangement, for that matter) drift into disarray the way they tend to do are much less obvious, however. First, we can agree that the actual math (advanced three-dimensional conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through real world space or through KSP space, is highly complex, with numbers that usually have unending decimal places out to 10^(-200) or even further. Simply put, in order to "work," the KSP game engine at some point is forced to say "meh, that's close enough" and stop calculating past the umpteenth decimal place and just fly with that. Those rounding errors, particularly when projected forward over simulated lapses of time acceleration, become significant -- ESPECIALLY in a situation like yours where you probably have multiple satellites involved, and one realizes that you can run the same calculation a hundred times, and round it the "same way" each of those hundred times, and little eensy-teensy math discrepancies become more and more noticeable between iterations of the same satellite, the same launch, the same orbital insertion, but with minute and subtle differences in burn accuracy and launch efficiency, etc.

As if all of that wasn't enough, there's also the third fact that when actually coming into and out of time compression, and when OTHER craft in your savefile change SOIs, all of those calculations are reset and recomputed and re-rounded anew, from scratch. As you play your game and progress in your save, whether you simply blast forward at 100,000x time compression for 5 real world days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways like Scott Manley, this repetitive rounding will compound and worsen all of the above factors that I've described, each time the engine calculates it, which can often be hundreds of times every real world second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow with poor framerates when it has to keep track of large and complex craft in close proximity to each other -- when physics load onto a craft or station, it calculates all of this orbital mechanics stuff for each individual part.)

So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem and prevent it from coming back. Savefile editing will, of course, come the "closest" to totally eliminating it, since doing so will eliminate all of the human-introduced elements of uncertainty and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately though, just as in real world satellite maintenance, you just have to in some way incorporate this inevitability into the design of your craft and your mission profiles (for example, by periodically re-editing your savefile, or by launching more satellites for your network for extra overlapping coverage, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot, and by launching those satellites with extra RCS for better fine-tuning over a longer operational life.)