"Lagrange" point woes

[impyre]

--I know that Lagrange points don't exist in KSP... that's why I wrote "Lagrange" instead--

Now that that's out of the way. Here's what I've been trying to do. I want to eventually build a station just outside Kerbin's SoI. Since KSP uses two-body orbital mechanics, I thought this should be possible.... so I started trying to launch communication satellites up there (RT2). I establish escape trajectory, wait until I'm outside the SoI (quite a bit outside it in some cases), and then attempt to match kerbin's orbital velocity. I've tried matching the orbital periods, but it doesn't seem to make much sense... it seems like in order to get an orbital period that matches kerbin's, I have to raise my apoapsis well above kerbin's (and thus I drift off). If I try to match kerbin's orbital velocity, I end up falling back to kerbin (though I shouldn't if I understand the two-body system correctly). What am I doing wrong? Is this even possible? I've done it with the Mun with no issues... but I can't seem to replicate my success with Kerbin.

The only theory that I've been able to come up with is that Kerbin is "on rails" in an orbit that makes no sense given its velocity. Is this true?

EDIT: Unless they manually calculated gravity in the kerbin-kerbol system accounting for both masses, and treated the mun as massless in the kerbin-mun system..... but why would they do that?

Edited April 13, 2015 by impyre

[Deutherius]

It's not very clear from your post which Lagrange point you are trying to simulate. I think you're trying to simulate L4/L5, which should be possible (well... they won't be automatically stable like the real ones would, you'd have to get the trajectory absolutely perfect for it to work - but you probably know that), but it should be stated somewhere in your post. "Just outside SOI" is pretty general and might get interpreted like you are trying to simulate L1 or L2, which will, of course, never work in a 2-body system.

As for the reason why it does work with the Mun but doesn't work with Kerbin... No idea. It most definitely should.

Edited April 13, 2015 by Deutherius
corrected quotes

[Taki117]

If you ate just outside kerbins soi it is entirely possible that the rounding errors are putting you back inside kerbins soi. What you should do is get a significant portion of an orbit behind kerbon, then put one opposite kerbin in its orbit. You want to match kerbins orbital period, which might be difficult.

[impyre]

It's not very clear from your post which Lagrange point you are trying to simulate. I think you're trying to simulate L4/L5, which should be possible (well... they won't be automatically stable like the real ones would, you'd have to get the trajectory absolutely perfect for it to work - but you probably know that), but it should be stated somewhere in your post. "Just outside SOI" is pretty general and might get interpreted like you are trying to simulate L1 or L2, which will, of course, never work in a 2-body system.

As for the reason why it does work with the Mun but doesn't work with Kerbin... No idea. It most definitely should.

You're right, L1/L2 couldn't work. As is, I wasn't trying to simulate an actual lagrange point... just a point on kerbin's orbit a little ahead of it in such a way that I don't drift off or "fall" back in.

As for distance from kerbin being the issue, I've been pretty far... I can try for further though.

[Yakky]

I just did some calculations based on the listed Kerbal Wiki orbit data, and it looks like the "on rails" Kerbin orbital velocity may indeed be wrong. Either that or some part of the Wiki data is wrong.

Note that for a circular orbit, the orbital speed s = sqrt(mu/r) where r is the orbital radius and mu is a gravitational parameter. More importantly for our purposes, given two different orbital radii r1 and r2, and one corresponding s1, we can quickly calculate s2 as s1*sqrt(r1/r2). We don't even need to mess with mu because it conveniently cancels out.

I plugged the following Kerbal Wiki data into that equation:

Kerbol radius: 261,600 km

Kerbol surface rotation speed: 3.8048 km/s

Kerbol synchronous orbit altitude ("r1"): 1,508,045.29 km

Kerbol synchronous orbit speed ("s1"): 25.6548 km/s (calculated from the three numbers above)

Kerbin orbit altitude above Kerbol ("r2"): 13,599,840.26 km and perfectly circular (Edit: see my note below)

Now, plugging r1, s1, and r2 into our equation, we get s2 = 9.16884 km/s. But Kerbin's orbital speed is listed in the wiki as 9.2845 km/s, which doesn't match. So if the Kerbal Wiki data is to be believed, that right there tells us something is inconsistent.

So while I haven't fired up KSP to verify what you said, from this math it looks like your suspicion is correct and staying in a Kerbin-following or Kerbin-leading orbit is impossible. But it also seems to me that someone would have stumbled across this already. Am I missing something obvious here?

Edit: It turns out that if Kerbin's listed orbital radius is taken as being from the center of Kerbol while the kerbosynchronous altitude is interpreted as being from the surface of Kerbol, then the calculated speed is 9.28446 km/s which pretty much matches the listed speed. But I don't know if the orbital radius is defined that way or not. Seems like one or the other value should be updated in the wiki so they are defined consistently.

And since your in-game altitude display is shown relative to the surface of the celestial body you're orbiting, you might be off from the correct altitude by 261,600 km if you're basing your satellite's altitude on some reference that is relative to Kerbol's center (such as the wiki).

(I have not launched KSP to look at what altitude Kerbin is shown to be orbiting in the game. Is it above Kerbol's surface or relative to Kerbol's center?)

Edited April 13, 2015 by Yakky

[LethalDose]

While I understand that you aren't trying to simulate any particular Lagrangian point, it may be helpful to try to roughly simulate L4 or L5, which are 60 degrees before or behind Kerbin's orbit.

This will provide a very wide margin for error in the positioning of the satellite so libration (back and forth oscillation of a body when viewed from an other point) doesn't cause the satellite to encounter Kerbin's SoI. Libration occurs when a synchronous orbit has a non zero eccentricity (horizontal libration) or non-zero inclination (vertical inclination). When simulating a Lagrange point, you are essentially placing the satellite in an orbit that has the same orbital period as the sibling body (In this case, Kerbin, as the the sun is the parent).

Your target orbit should have AP + PE = 2 * Kerbin's orbital radius, which will give cause your satellite's orbit's semi-major axis to match the length of Kerbin's semi-major axis, and hence, have similar orbital periods (this is a simplification of the math, but it should work). NOTE: The orbital radius given in the wiki is not the orbital radius displayed in the map view. The wiki includes the radius of the parent body (again, the sun, in this case) in the radius, while the map display in the game does not. Just be consistent between the two and you'll be fine.

If the AP doesn't equal the PE (hence e != 0), the satellite will appear to librate back and forth in reference to Kerbin, but if it's far enough away, the movement should lead to encounters with Kerbin's SoI.

Proactive Addendum: Yes, I know this may not be the exact definition of "librate" but it works well enough in this situation.

- - - Updated - - -

Kerbin orbit altitude above Kerbol ("r2"): 13,599,840.26 km

Now, plugging r1, s1, and r2 into our equation, we get s2 = 9.16884 km/s. But Kerbin's orbital speed is listed in the wiki as 9.2845 km/s, which doesn't match. So if the Kerbal Wiki data is to be believed, that right there tells us something is inconsistent.

As I noted in the previous post, make sure you're aware that the wiki reports orbital altitude from the parent's center while the map view reports orbital altitude from the parent's surface at sea level. This is consistent across the wiki entries (typically the first footnote).

Basically, just make sure you know what numbers you're using. Since you listed Kerbin's orbital altitude as it appears in the wiki and labeled it "orbital altitude above Kerbol", I fear you may have fallen victim to one of the classic blunders.

Update: Using the orbital radius provided by the wiki as the footnote indicates it should be used, Kerbin's orbital velocity is calculated to be 9284.5 m/s using eq 4.6 here. This value is consistent with wiki entry.

Edited April 13, 2015 by LethalDose

[Yakky]

Basically, just make sure you know what numbers you're using. Since you listed Kerbin's orbital altitude as it appears in the wiki and labeled it "orbital altitude above Kerbol", I fear you may have fallen victim to one of the classic blunders.

Yup, just realized the numbers are not presented the same way... but thanks for pointing it out. It does raise the possibility that impyre is basing his target orbital altitude off an incorrectly calibrated reference.

[Red Iron Crown]

Your target orbit should have AP + PE = 2 * Kerbin's orbital radius, which will give cause your satellite's orbit's semi-major axis to match the length of Kerbin's semi-major axis, and hence, have similar orbital periods (this is a simplification of the math, but it should work).

This is the key. Matching orbital periods is critical to avoiding drift, and it is the semi-major axis that determines period. It is better to have Ap 1000 km too high and Pe 1000km too low than to have both too high by 100km.

[impyre]

Thanks guys, I'll have another look and pay a bit more attention to exactly what's going on. I'll update once I know for sure what I'm doing wrong.

UPDATE: My issue was a combination of floating point error and very slight orbital period mismatch.... so I kept falling back into kerbin's soi. Setting up just outside the soi and *behind* kerbin was much easier (and I was able to stay relatively close without fear of being "caught"). Another thing that was confusing me (but not causing problems really) was that KER was showing orbital periods in 24-hour days rather than 6 hour days. I also managed to set up a much more interesting "pseudo orbit" by burning radial-out once out of the soi, this eliminated accidental encounters and made it seem as if I were still orbiting kerbin (was kinda cool).

Edited April 14, 2015 by impyre

[kerbiloid]

Btw. There are two well-known problems: near-Langrange orbit stability and synchronous orbit stability.

Both problems are the same: some virtual point in space moves along a fixed trajectory, and we want all crafts in its proximity to float around this point without an engine burn.

Maybe the best solution would be if anybody skilled in the KSP modding would create a mod for such purposes, smth like "Attractive Points".

I.e. a player manually puts/defines in cfg a virtual non-visual object - where some Lagrange or synchronous position would be.

The he/she launches any craft to its proximity range.

And then this object just cyclically searches all crafts in some radius and corrects their position with a brute mathematical force - to keep the craft in proximity unless craft's engines are on.

I.e. then we have not a N-bodies problem, but just an orbit patching.

upd: Maybe Kopernicus mod would be a quick-and-dirty solution for Lagrange points. Defining invisible and untouchable pseudo-"celestial bodies" in desired points.

With some little mass, weak gravity and small SOI: enough to keep the craft aside, insignificant to effect something another, invisible (or with weak particle effect).

Edited April 14, 2015 by kerbiloid