Eccentric Geosynchronous Orbit that skims the surface at Pa

[cyberKerb]

Just wondering if any maths / rocket surgery people out there that might be able to point me in the right direction for formula to work out the following for an airless body in KSP.

The question I'm trying to work out is for the bodies in the game that allow a Synchronous orbit, and given the limiting factor of SOI of the body, how close could I get to the surface with a vessel using an Eccentric Geosynchronous orbit?

ie something like a Molniya orbit that had the same sidereal duration as the body it was orbiting.

Edited August 4, 2017 by wile1411

[ThreePounds]

I am not sure if I understand your question correctly, so I'll just ramble a little bit and hope I'll answer your question accidentally along the way.

The orbital period T of any orbit depends soley on the semi major axis a and the standard gravitational parameter μ with μ = M * G (M = mass of central body [Kg], G= universal gravitational constant [km³*kg^-1*s^-2])

if you do the math you end up with something like this:

With that we can calculate the altitude of the apoapsis ap if our periapsis is pe kilometers above the surface of the body with radius r

ap = 2a - 2r - pe

does that answer your question?

EDIT:

and when that turns out to be greater than the SOI, you're basically trying to solve the reverse problem with is analogous.

pe = 2a - 2r - ap

 

Edited August 4, 2017 by Three_Pounds

[cyberKerb]

1 hour ago, Three_Pounds said:

I am not sure if I understand your question correctly, so I'll just ramble a little bit and hope I'll answer your question accidentally along the way.

EDIT:

and when that turns out to be greater than the SOI, you're basically trying to solve the reverse problem with is analogous.

pe = 2a - 2r - ap

 

Wow!  - that was both quick and amazingly confusing (just to me as I'm not a math guy) I'm still trying to search the wiki to find some of the parameters you've mentioned for the above formulas. I also got lost in wondering if some of the numbers from real world (eg Gravity 9.8m/s/s2 etc,,,) still translated fine into this calculations

Maybe I should refactor the question.. . Given a pe of 10m above the Minmus flats (which I'm guessing would be 0m alt or should I be calculating this from the center of Minmus and working out what the sea level "altitude" is relative to the middle of Minmus?), where would the Ap be so the same point was flown by each orbit. (ie  Geosynchronous - albeit highly eccentric)

EDIT:

Ok - tell me if I've got close - here's my workings:

Minmus Wiki says

a = orbit period is 1077311 seconds
r = Radius is 60,000
2a - 2r - 10meter Periapsis

= 2,154,622 - 120,000 - 10

Apoapsis = 2,034,612
 

Mimus SOI is 2,200k - so this would work I think..  (how'd I do?)

EDIT2:

Not good - I reread the maths and 'a' isn't orbital period - your post said a = Semi major axis and wiki says that's 47,000k

Redid the same equasion and ended up with 93,879k ap which would be WELL outside the SOI - so I'm guessing I'm SOL

 

Edited August 4, 2017 by wile1411

[ThreePounds]

57 minutes ago, wile1411 said:

Wow!  - that was both quick and amazingly confusing (just to me as I'm not a math guy) I'm still trying to search the wiki to find some of the parameters you've mentioned for the above formulas. I also got lost in wondering if some of the numbers from real world (eg Gravity 9.8m/s/s2 etc,,,) still translated fine into this calculations

9.8 m/s² has little to do with gravitation. It's the gravitational surface acceleration on Earth and incidentally, Kerbin. Maybe then I should have been a bit more clear in my explanations and maybe even provide an illustration. I can still do that - or simply just answer your question. Just ask. But of course, Kepler's laws hold true in the Kerbal Universe, too - which allows us to do all these calculations.

57 minutes ago, wile1411 said:

Maybe I should refactor the question.. . Given a pe of 10m above the Minmus flats (which I'm guessing would be 0m alt or should I be calculating this from the center of Minmus and working out what the sea level "altitude" is relative to the middle of Minmus?), where would the Ap be so the same point was flown by each orbit. (ie  Geosynchronous - albeit highly eccentric)

EDIT:

Ok - tell me if I've got close - here's my workings:

Minmus Wiki says

a = orbit period is 1077311 seconds
r = Radius is 60,000
2a - 2r - 10meter Periapsis

= 2,154,622 - 120,000 - 10

Apoapsis = 2,034,612
Mimus SOI is 2.2Mk - so this would work I think..  (how'd I do?)

The orbital period you've looked up is the orbital period of Minmus itself. That's not really useful to us when we are orbiting it. What you need to look up is the sidereal (in respect to the starts) rotational period, which is 40400s, and make that your orbital period. In other words: in the time it takes Minmus to rotate once about its own axis, we want to complete exactly one orbit - we'll end up in exactly the same place every time in respect to Minmus' surface.

So we note that

T = 40400s

which gives us a semi major axis

a = 417.94 km

Be mindful of the units here! I try to stay consistent with using km as my base unit. Make sure the value for G that you look up matches the unit from above - otherwise you'll end up with the wrong result. Obviously, if it contains m you need to calculate everything in meters.

So if you want your periapsis to be 10m or 0.01km, then you just have to plug that in:

ap = 2a - 2r - pe
ap = 2 * 417.94km - 2 * 60km - 0.01km
ap = 715.865km

Luckily for us that apoapsis is within Minmus SOI, which is 2,187.43km from Minmus surface.

Like I said above if you have questions about anything just ask.

EDIT:

If you see GM, that's the same as my μ. The idea behind this so called "Standard gravitational parameter" is that G is a very small number and M is a very large number, so it's a good idea to multiply them together to get something that you can easily work with. This turns out to be very smart since those two aren't really used separately in these kinds of calculations. Since you need to remember the mass of every body in the game, it's not a big deal to just remember GM instead. I just looked into the game files and in 1.3.0 the GM of minmus is:

GM_Minmus = 1.765800026 km^3*kg^-1*s^-2

Apparently, under the hood, the game also uses km as it's base unit.

Edited August 4, 2017 by Three_Pounds

[cyberKerb]

32 minutes ago, Three_Pounds said:

Like I said above, if you have questions about anything. Just ask.

Thanks again - quick question, what numbers were you using to get μ for Minmus?

Ah - nevermind - found a shortcut - this wiki page here gives the semimajor axis and I can get the rest of the formula from the body wiki page easy enough.

Ok - thanks for that I've now got all I need to plan a base set up...  I'm wanting to have the 'satellites' buzz through a repair facility at orbital speeds  Only catch is I can only do it on these locations. Everything else is excluded due to either atmospheric drag or SOI limitations:

	Ap	Pe
Gilly	84,270	10
Minmus	715,870	10
Dres	1,464,470	10
Eeloo	1,367,370	10

Should be a fun challenge to set these up while taking into account the terrain before and after the Pe point  

 

Edited August 4, 2017 by wile1411

[ThreePounds]

3 minutes ago, wile1411 said:

Thanks again - quick question, what numbers were you using to get μ for Minmus?

Ah - nevermind - found a shortcut - this wiki page here gives the semimajor axis and I can get the rest of the formula from the body wiki page easy enough.

Ok - thanks for that I've now got all I need to plan a base set up...  I'm wanting to have the 'satellites' buzz through a repair facility at orbital speeds  Only catch is I can only do it on these locations:

	Ap	Pe
Gilly	84,270	10
Minmus	715,870	10
Dres	1,464,470	10
Eeloo	1,367,370	10

Should be a fun challenge to set these up while taking into account the terrain before and after the Pe point  

 

Awesome! I'd love to see some screen shots if you get it working. I added a section about μ and GM in an edit to the post above.

EDIT: And make sure you calculate this extremely carefully since you'll need to be 100% accurate. A fraction of a second at orbital speed is a lot of distance when you're standing on the surface - so to speak.

The GM for the calculations in km for the bodies you listed is:

Gilly = 0.008289450 Minmus = 1.765800026 Dres = 21.484488600 Eeloo = 74.410814527

 

Edited August 4, 2017 by Three_Pounds

[cyberKerb]

10 minutes ago, Three_Pounds said:

Awesome! I'd love to see some screen shots if you get it working. I added a section about μ and GM in an edit to the post above.

Ahhh! Thanks for the expanded info. I found where I was getting the maths wrong - I was taking the GM and multiplying it by the mass of the body. (I was thinking G*M) No wonder my numbers were showing up huge.  Thanks for the correction

As for the idea, it's definatly not my idea as I remember someone here posting an awesome gif (here or reddit can't remember) where they perfectly timed a Kerbal on Minmus getting shot forward, to when a craft was speeding by REALLY quickly and ended up matching speeds in a few seconds while flying a few mtrs from the ground.

I figured this might be an interest way to recreate something like that.

If you know of the gif - please post a link as I've forgetton where it was. I think the title was something like - "oh, hai"

Edited August 4, 2017 by wile1411

[ThreePounds]

5 minutes ago, wile1411 said:

Ahhh! Thanks for the expanded info. I found where I was getting the maths wrong - I was taking the GM and multiplying it by the mass of the body. (I was thinking G*M) No wonder my numbers were showing up huge.  Thanks for the correction

As for the idea, I don't think it's original. I remember someone here posting an awesome gif (here or reddit can't remember) where they perfectly timed a Kerbal on Minmus getting shot forward, to when a craft was speeding by REALLY quickly. I figured this might be a way to recreate something like that.

If you know of the gif - please post a link as I've forgetton where it was. I think the title was something like - "oh, hai"

Yes. I remember seeing something like this on reddit. You were right in thinking that GM = G * M. But like I said, the value of G is irrelevant and I don't even know what the game uses. The game just stores GM for every single body and that's what you also find on the KSP wiki. Just just it.

I know the idea is not original but I'd love to see it anyhow. Sounds like an awesome project to me.

Edited August 4, 2017 by Three_Pounds

[cyberKerb]

Found the GIF as well as some other reddit posts of the subject: - Oh I could watch this gif all day AND laugh at it in amazement every damn time.

 

[Zhetaan]

I hate to be the one to rain on the parade, but if you try to set up these bases, you will lose them.  Unfortunately for you, there is a minimum altitude below which KSP automatically deletes low-flying craft under the assumption that they would crash anyway--even though this assumption is sometimes incorrect.  This has a lot to do with the fact that in the code, every planet surface is a thin shell and orbital speeds are fast enough that a craft can glitch through that shell between physics ticks.

To illustrate, let's assume that you have a very slow computer that can only calculate one frame per second.  In order to approximate continuous motion, what KSP does is figure out where your vessel will be each second and 'jumps' it to that location instantaneously.  If you're moving at .1 metres per second, then every frame has it jump .1 metres.  If you're moving at orbital velocity of several hundred metres per second, then each second, the vessel jumps several hundred metres.  In this illustration, the simulation would be slow enough for you to see it; if there is a rock or a different vessel or the surface of the planet in the way, there is no collision, because in the code, the vessel never contacts anything:  it instantaneously jumps from one point on the orbit to the next and never checks to see whether there was anything in the way.  Those who try to have a demolition derby in space also encounter this problem:  head-on collisions in KSP tend to glitch through.

In KSP, the physics simulation operates much faster than that, but often, the speeds involved are also much faster.  This is a problem because it can conceivably allow a vessel to glitch right through the surface of a planet and come out again without ever actually crashing.  To counter this, the game assumes that anything below a preset altitude (which varies by body) will or has crashed, and because of the nature of the physics simulation, that altitude has to be higher than a vessel travelling at orbital speed can traverse in a single tick.

Obviously, there are exceptions.  This only applies to vessels that are both in flight and on-rails.  In other words, your already-landed bases are safe.  Also, if you are off-rails (meaning you are either controlling the vessel or controlling one within the physics range of 2.5-ish km) then the simulation uses much finer calculations and you won't have to worry about it.  Also, auto-deleting your lander while you try to land it would be in bad form, so the game specifically avoids auto-deletion of a controlled vessel.  (Additionally, if you're controlling it and you do crash, you get to see explosions.  Auto-deletion just removes the icon from the map view; it's very boring.)

What this means is that the GIF linked above was not only a matter of fine orbital manoeuvring, but in fact required an additional effort of great technical complexity to surmount the limitations of the game as a simulator.  What happened there is that the rover with the loaded Kerbal was parked on the Minmus flats ahead of time, and then the satellite's orbit was adjusted.  When the satellite came in for its low-orbit pass, the player had to wait until it was within physics range of the rover, quickly switch to the rover, and launch the Kerbal, all in record time.  Note that when the GIF begins, the camera view is side-on, just as it usually is when you first switch to a vessel.  If the player had truly begun with the rover, then the satellite would have been auto-deleted.  Without raising the periapsis, the satellite will still be auto-deleted unless the player makes a point of returning to control it through the low-altitude portion of every single orbit.

[cyberKerb]

Awwwww... an here I was hoping to have some busy skies while I build a base.

Thanks for the info though @Zhetaan - regardless of the disappointment, it's probably better to know this upfront and learn from those who have gone before me.

Any idea on what the deletion altitudes would be for the bodies mentioned? Are we talking hundreds or thousands of meters? I'd hazard a guess at a thousand of so, but I guess some trial and error is in order to find out is no one knows the details.

Edited August 4, 2017 by wile1411

[Zhetaan]

I have guesses, but no concrete figures.  I was planning on working something up this weekend, actually; you're the second person I've seen recently who wanted to put together a mission like this.

[OhioBob]

7 hours ago, Three_Pounds said:

Yes. I remember seeing something like this on reddit. You were right in thinking that GM = G * M. But like I said, the value of G is irrelevant and I don't even know what the game uses. The game just stores GM for every single body and that's what you also find on the KSP wiki. Just just it.

As of version 1.2, KSP uses G = 6.67408E-11 m³/kg-s², and g_o = 9.80665 m/s².  Prior versions used G = 6.674E-11 m³/kg-s², and g_o = 9.81 m/s².

The above change is why Kerbin has the weird surface gravity of 1.00034160493135 g, rather than 1 g like it use to have.  Note that,

GM = g*r²

When v1.2 was released, Squad didn't want any of the bodies' GM to change, because that would have changed things like orbital periods, geosynchronous altitudes, spheres of influence, etc.  So they kept all the bodies' surface gravities the same, but measured them to a new "standard gravity".  That is, Kerbin's surface gravity remained 9.81 m/s² like it has always been, but in units of standard gravities it became,

9.81 / 9.80665 = 1.00034160493135 g

While GM didn't change, mass did (because the value of G changed).  But like you've explained, that really doesn't matter.  Mass isn't used in any of the calculations, GM is used.

Something else to note is that mods that use Kopernicus to create new planets or modify existing ones can provide the needed gravitational data in one of several different ways.  The mod creator can specify either the body's surface gravity (geeASL), its mass (mass), or its gravitational parameter (gravParameter).  Only one of those is needed to calculate the others.  If more then one is given, it's possible the mod creator could unwittingly provide conflicting values.  I'm not certain but I believe priority is given to gravParameter, then mass, and lastly geeASL.  That is, if all three are given, the last two are thrown out and recomputed from gravParameter.

Most mod creators specify geeASL.  So if you look in a body's configuration file and you see radius = 500000, and geeASL = 0.8, you can compute GM thus,

GM = (0.8 * 9.80665) * 500000^2 = 1.96133E+12 m³/s².

And although you don't need it for any calculations,

M = 1.96133E+12 / 6.67408E-11 = 2.938727135E+22 kg.
 

[ThreePounds]

27 minutes ago, OhioBob said:

As of version 1.2, KSP uses G = 6.67408E-11 m³/kg-s², and g_o = 9.80665 m/s².  Prior versions used G = 6.674E-11 m³/kg-s², and g_o = 9.81 m/s².

The above change is why Kerbin has the weird surface gravity of 1.00034160493135 g, rather than 1 g like it use to have.  Note that,

GM = g*r²

When v1.2 was released, Squad didn't want any of the bodies' GM to change, because that would have changed things like orbital periods, geosynchronous altitudes, spheres of influence, etc.  So they kept all the bodies' surface gravities the same, but measured them to a new "standard gravity".  That is, Kerbin's surface gravity remained 9.81 m/s² like it has always been, but in units of standard gravities it became,

9.81 / 9.80665 = 1.00034160493135 g

While GM didn't change, mass did (because the value of G changed).  But like you've explained, that really doesn't matter.  Mass isn't used in any of the calculations, GM is used.

Something else to note is that mods that use Kopernicus to create new planets or modify existing ones can provide the needed gravitational data in one of several different ways.  The mod creator can specify either the body's surface gravity (geeASL), its mass (mass), or its gravitational parameter (gravParameter).  Only one of those is needed to calculate the others.  If more then one is given, it's possible the mod creator could unwittingly provide conflicting values.  I'm not certain but I believe priority is given to gravParameter, then mass, and lastly geeASL.  That is, if all three are given, the last two are thrown out and recomputed from gravParameter.

Most mod creators specify geeASL.  So if you look in a body's configuration file and you see radius = 500000, and geeASL = 0.8, you can compute GM thus,

GM = (0.8 * 9.80665) * 500000^2 = 1.96133E+12 m³/s².

And although you don't need it for any calculations,

M = 1.96133E+12 / 6.67408E-11 = 2.938727135E+22 kg.
 

Wow. Thanks for the in-depth explanation. I do remember stuff getting messed up in the 1.2 release that was later fixed in a minor release. Honestly, there have been so many changes it's difficult to keep track of everything. Worst of all, if I come across anything in the wiki I immediately doubt it because it was probably written a long time ago and no one bothered to update it. These days, I load up KSPTOT and pull the entire celestial catalogue which contains all the data I need. This way I can be sure that all my calculations are based on the data that is in my save file.

Apart from that, I do remember that the ISP calculations for engines used 9.82m/s² for some strange reason when determining the exhaust velocity but I think that got fixed as well. It's quite hard to measure precisely since it's not trivial to come up with a decent enough experimental setup. I have several excel spread sheets full of data, formulas and annotations but It's hardly necessary with KER giving me read outs directly from within the game.

Edited August 4, 2017 by Three_Pounds

[OhioBob]

5 minutes ago, Three_Pounds said:

I do remember stuff getting messed up in the 1.2 release that was later fixed in a minor release.

Yeah, I was working on GPP at the time 1.2 was released.  I didn't want to do what Squad did and have a bunch of weird surface gravity numbers, so I instead just let the values of GM change.  That changed a bunch stuff, but GPP was in early development and didn't have that many users at the time, so it wasn't a big deal.
 

5 minutes ago, Three_Pounds said:

Apart from that, I do remember that the ISP calculations for engines used 9.82m/s² for some strange reason when calculation the exhaust velocity but I think that got fixed as well.

I've too read somewhere that that got fixed, but I can't swear to it.
 

[regex]

8 minutes ago, OhioBob said:

27 minutes ago, Three_Pounds said:

Apart from that, I do remember that the ISP calculations for engines used 9.82m/s² for some strange reason when determining the exhaust velocity but I think that got fixed as well.

I've too read somewhere that that got fixed, but I can't swear to it.

I can confirm it has been fixed although I have no immediate citation available. IIRC that was when ModuleEngineFX was added into the game or around the time that isp started acting like isp. It's been fixed for some time.

Edited August 4, 2017 by regex

[OhioBob]

1 minute ago, regex said:

... or around the time that isp started acting like isp.

Do you mean when they started varying thrust rather than fuel flow rate?  (I had forgotten all about that until you just now reminded me.)

[regex]

Just now, OhioBob said:

Do you mean when they started varying thrust rather than fuel flow rate?  (I had forgotten all about that until you just now reminded me.)

Yep, the day rockets started acting like rockets.