Orbital Period drift calculation.

[bandi94]

Hy. ATM i started to add some satellites on kerbin orbit ( second attempt , first one ended up with a big de-sync only after 3 day's) . I want to keep them sync. with each other ( i have 4 ) , they are almost on the same orbit.

Two of them have a 0.15s orbital period difference one of them 1s difference and the last one has a + 10s difference.

Now is this close enought to keep them almost on the same formation for a time , well maybe the last one with +10s will be a problem? And is there any approximative value to keep them in place , i think under one secound is fine ( it will take very much time to drift a significant distance ) , but what about 10s ?

Also i tried to search some formula to calculate the drift distance in time but with no luck , i mean i know that the orbital period is X , i have a Y difference and the current distance between them is 2Mm so let's say i want to know the drift distance after 5 day's ? As an example it will give me 2.01Mm so i know that in 5 day's i will have a 0.01Mm drift distance.

Thx.

Edited September 19, 2014 by bandi94

[Jimbimbibble]

You ought to be able to get the orbital periods to about 0.1s difference. Kerbal Engineer can tell you what your orbital period is with that resolution so I'd suggest tweaking it until it's as good as it can be, unless you're out of RCS fuel or something. At 0.1s you'll hardly notice drift.

[cantab]

Consider the period difference as a percentage of the period. Let's say there's a 1% difference. Then if they start next to each other it will take 50 orbits for them to end up opposite each other.

[bandi94]

Thx. I will tweak it around 0.1s it's not a problem with the fuel, satellites have ion-engines ( with one tank ,so they can work almost 30 min at full throttle).

And thx for the percentage calculation methode it is indeed a good way to calculate the drift.

I calculated it and with a 0.1s it will take somewhere around 450 day's to drift out of the antena range. Almos perfect so i will try to tweak them as much as i can.

Edited September 19, 2014 by bandi94

[MisterFister]

Everything described here is true and useful, but I think the OP implies that it would be helpful to know "why" this happens.

First, it's true that realworld GSO satellites drift and have to consume fuel for stationkeeping purposes over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, realworld orbit perturbations result of myriad underlying causes, including faintly off-kilter calculations to begin with, along with fuel impurities (resulting in slightly-less-than-optimal thrust vectors, resulting in burn times being minisculely off-mark) and 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 (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle). Also, there is something called interstellar and interplanetary drag, such as 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 leonids.

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. Indeed, in KSO all SOIs are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a featureless gravity well. For example, there is no such thing as lagrange points in this game. All fuel is uniformly pure, as another example. There is one obvious issue with maintaining accurate KSO paths and two subtle issues.

The obvious issue is human input, just as with realworld. If you design 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 and fuel efficiency on maneuver nodes begins with good calculations in the VAB / SPH, and continue to include dividing the total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00 seconds BEFORE the designated time, and end exactly 30.00 AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never exactly possible) and accurately following the node indicator on your navball -- when you are down to the last few m/s of burn, it's generally a good idea 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. Generally, everything I've said so far makes an immediate sort of sense, when it's laid out.

The two other reasons why KSO orbits drift the way they do are much less obvious, however. First, we can agree that the actual math (advanced conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through realworld space or through KSP space, is highly complex, with numbers that have unending decimal places. Simply put, in order to "work," the game engine at some point is forced to say "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 time lapses, become significant -- ESPECIALLY in a situation like yours where you 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 discrepancies become more and more noticeable.

As if all of that wasn't enough, there's also the fact that when 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. As you play your game, whether you simply blast forward at 100,000x time compression for 5 realworld days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways, 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 realworld second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow when it has to keep track of large and complex craft in close proximity to each other, even without dark NRE strings.)

So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem. Savefile editing will, of course, come the closest to totally eliminating it, since doing so will eliminate all of the human-introduced and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately, just as in realworld 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, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot in your coverage, and by launching those satellites with extra RCS for better finetuning over a longer operational life.)

[bandi94]

@MisterFister big thx for your nice explanation. At one point i will expend my network but for now i will try to make it work with those 4 ( i am playing in career mode and i need to get some funds for expansion ) anyway they have ion-engines they have a big working period (30min at full throttle) , i will be able to fin-tune the orbits with a very small velocity to compensate the drift , one satellite have a +/- 8% of his orbital period as marge after that it will drift out of range with the other satellites.

I will try to keep them in place manually rather editing savefile , this way it will give a bit more challenge.