alt:apoapsis returns seemingly random numbers when on escape tragectory.

[Dunbaratu]

I was trying to find a way to detect: I am on an escape trajectory and will leave my SOI.

And thought that maybe since there is no real apoapsis this might help detect it.

But alt:apoapsis returns seemingly random different numbers when you are on an escape trajectory. Sometimes negative, sometimes positive. But always big, and never quite the same. You can keep re-entering "print alt:apoapsis" with pressing up-arrrow,return and keep getting drastically different numbers out.

Which brings to mind the question, what should your apoapsis be reported as when on an escape trajectory?

[baloan]

"Infinity" would make sense in physics terms but for the purpose of kOS "None" would be appropriate.

[Dunbaratu]

Returning "None" would have the same problems that returning "None" for ENCOUNTER has had. You'd have to write code that can simultaneously handle the case of expecting a number AND a string in the same expression. If you're testing whether Apoapsis is None, you can't tell if that's a string check or a number check until after you made the check.

Returning ''Inf'' like some math operations do would be fine by me if KOS supported the ability to test for it like so: if apoapsis = Inf { print "on escape vel.". }. But for a return of ''Inf'' to be useful KOS would first have to be given the ability to let scripts test against infinity.

[Dunbaratu]

This will be a nice fix. At the moment what I have to do is detect if my velocity exceeds escape velocity, but this does not yield exactly the same answer as "Does [b]KSP think[/b] I'll escape?" The difference is because the KSP's idea of escaping is "is your apoapsis altitude larger than the finite SOI radius the game has defined for this body." while the actual physics equation is calculating "do you even have an apoapsis at all, or is it above infnity?" The true escape velocity is a bit higher, and a LOT higher in some cases.

[fibonatic]

You can also calculate other parameters, such as your eccentricity and semi-major axis, which allow you to calculate this more accurate. For this you would need to know the gravitational parameter and mean radius of the body you are orbiting. However you can get the mass and therefore

[Dunbaratu]

@fibonatic The point is that this is a case where being more accurate to the actual laws of physics is actually a detriment because what is needed is KSP's behavior, not real-world behavior. Real-world physics can claim I'm not on an escape trajectory in cases where KSP claims I am. The reason for the difference is that in real world calculations, I have to raise my apoapsis above infinity to be on an escape path, whereas in KSP I only have to raise it above the body's sphere of influence.

[fibonatic]

@Dunbaratu But if you are able to calculate your orbital parameters, it would allow you to check how high your apoapsis would be when still in an elliptical orbit: r_a = a(1+e). And if this is higher than the SOI you know that you will escape (assuming you will not get an encounter with a moon).

[Dunbaratu]

And I query a body's SOI radius exactly how?

[baloan]

The apoapsis values returned - albeit negative seemingly random numbers - make sense progamatically - and maybe physically and mathematically. Apoapsis is not broken for hyperbolic orbits. Using my perinode script

run perinode(100000)

I could successfully perform a Mun injection (new periapsis after maneuver: 99918m) while on a hyperbolic trajectory in Mun's SOI! I thus request to leave apoapsis as is. To check for escape orbit checking for a negative number should do - or add some other means. Please roll back any changes already done. Note: apoapsis = 0 breaks my script and creates a nonsense maneuver node.

[Dunbaratu]

Boloan, if the apoapsis values returned were reliably negative, I wouldn't have complained because then I could just check for apoapsis < 0 to discover that I'm on an escape path.

But they emphatically are NOT reliably negative. Sometimes they look like perfectly valid positive numbers that could be real apoapsis numbers. I've had apoapsis return the following sequence on subsequent executions of "print apoapsis." at the terminal while drifting on an escape path and not thrusting:

1445.61641 5050101.4121 -565.351 -691.45166 54340.45124

etc.

It's a pain to write a script that's looking for escape conditions when it's random luck whether or not you happen to hit one of the moments where it gives you a negative number at the moment you checked.

I do agree that returning a negative number as the clue that apoapsis is invalid works a lot better than returning zero. But that isn't a good reason to roll back to what it was before where it was utterly random. It's a good reason to change it to return something like -1.

[baloan]

I have had a closer look at the issue. For orbits the following equations hold true:

soe = - mu / 2 a        // specific orbital energy
soe = v^2/2 - mu/r      // also specific orbital energy
a = (rper + rapo) / 2

Let's look at each case:

1. elliptical, soe < 0, a > 0
2. elliptical, apoapsis > SOI (KSP escape), soe < 0, a > 0
3. parabolic, soe = 0, a = oo
4. hyperbolic, soe > 0, a < 0

Checking it out:

1. we know it works
2. Kerbin's SOI is at 86.000km. Let's change orbit to an apoapsis of 120.000km

run perinode(120000000).  //dv 935
print nextnode:apoapsis.
120001289.052
// so KSP dutifully reports the correct apoapsis
run exenode.
print apoapsis.
128701821.108708
// periapsis was 80km
// I don't know where the initial difference comes from, but once settleed it varies in the 0.01% range.
// my trajectory entered Mun's SOI
print apoapsis.
-1347872.257
print periapsis.
757714.898
// which is stable; here apoapsis indicates an escape orbit, a positive specific orbital energy
// let's compare the specific orbital energy from the semi major axis (based on apoapsis and periapsis):
// Mun: - mu/(rper+rapo) =  6.5138E+10/(-1347872+757714+2*200000) = +342820
// with the specific energy from velocity an radius
// r = 2284452, v = 861, v^2 / 2 - mu /r = 861^2 /2 - 6.5138E+10 / 2284452 = +342146
// which match.
// after leaving Mun's SOI
print apoapsis.
-68767867.747
// which indicates a real escape orbit now, the Mun encounter acted as a slingshot adding extra speed
// and again the value is stable
// key point is that specific orbital energy for a hyperbolic orbit matches when calculated apoapsis
// -> apoapsis is not a random number but follows physics and math laws!
-> makes sense

\3. Let's try a parabolic orbit. We'd expect apoapsis to be infinite; soe = 0, a -> oo

run escnode(0)            // which creates a maneuver node for parabolic escape speed
run exenode.
print apoapsis.
-2.3E+10
// indicating a hyperbolic orbit (stable)
// I now orientate the ship prograde and use thrusters to decelerate just a little bit.
// interestingly enough apoapsis flips to 
print apoapsis.
+4.9E+8 
// indicating I'm back in an elliptical orbit again.
-> makes sense

For neither case I could reproduce your random apoapsis numbers. All cases show consistent behaviour and physical integrity. From above observations your trajectory looks like it entered a moon's soi temporarily. Can you reproduce your apoapsis observations? Maybe it was a KSP bug - or due to time warp effects?

For querying whether your orbit leaves the bodies' KSP SOI you need to check two conditions:

1. apoapsis > soi, or
2. apoapsis < 0 or check "status" for "ESCAPING"

I still request rolling back the change. There are two simple workarounds. There is nothing wrong with apoapsis in KSP 0.22/kOS 0.9.2.

[Dunbaratu]

If I lived in the alternate universe where those workarounds worked, I'd be fine with rolling it back. But what you're observing is NOT what happens when I do it. I do NOT consistently get numbers that are always negative for apoapsis when on an escape path.

[erendrake]

I think that using the Apoapsis for detecting when you have escaped is incorrect. you should be checking your orbital eccentricity. if its greater or equal to 1 then you have escaped.

[baloan]

You are right about the eccentricity check. But checking for eccentricity, apoapis or semi-major axis is basically the same thing. All three are linearly related.

Eccentricity depends on apoapsis and periapsis (see https://en.wikipedia.org/wiki/Ellipse under Planetary Orbits) with ra is apoapsis rp is periapsis a is semi major axis

You can see:

1. elliptical, 0 < e < 1 for apoapsis > 0, apoapsis > periapsis
2. parabolic, e = 1 for apoapsis -> oo (infinity)
3. hyperbolic, e > 1 for apoasis < 0, -apoapsis > perapsis

Why do you think it's incorrect to check for apoapsis?

[baloan]

@Dunbaratu: have you considered looking at status = "ESCAPING"? It is not a workaround. As it switches from ORBITING to ESCAPING exactly when apoapis changes from large positive to large negative numbers I presume it will be broken in your installation as well... From your last response, though, I have the impression that you are not willing to look deeper into the issue. Nothing more I can do here.

[Dunbaratu]

@baloan I did not know about status="ESCAPING". If it works, it will help deal with the fact that KSP has a different idea about what causes a body to escape than physics does. (For physics you have to raise your apoapsis past infinity, for KSP you just have to raise it past the SOI of the body. For the sake of the game, the definition based on SOI is more useful, especially when trying to calculate whether or not you've burned retro enough to get captured from a flyby - the laws of physics will claim you're now on a captured elliptical orbit in scenarios where the KSP simulation will still let you flyby because you'll leave the body's SOI before you'd have gotten to the apoapsis.. So thanks for that heads-up about that status value. It may help.

@erendrake: You calculate eccentricity using apoapsis, except in hyperbolic orbits where there is no such thing as an apoapsis. When the apoapsis being returned is bogus, you can't calculate your eccentricity correctly.

[Dunbaratu]

Well after testing it, STATUS="ESCAPING" still doesn't fix the problem. It does the same thing the apoapsis numbers do - it doesn't report ESCAPING unless the apoapsis is also being reported as negative. In scenarios where you are escaping according to KSP's map view, but you aren't escaping by a large margin, it still reports as "ORBITING".

[erendrake]

@baloan and @Dunbaratu You are right that in release KOS you determine e with Ap and Pe but on my fork i made a new expression that gets e directly out of the vessel's orbit object and expose it into OBT:ECCENTRICITY and i have never seen the problem that @Dunbaratu is dealing with.

[baloan]

@Dunbaratu:

1. the request for commit now relies on status = ESCAPING as well. It won't indicate leaving SOI but whether an orbit is hyperbolic. see here: https://github.com/Nivekk/KOS/pull/253/files.

cpu.Vessel.situation.ToString() == "ESCAPING" is the same as status = "ESCAPING" in kOS.

Btw @erendrake: eccentricity won't help Dunbaratu as e > 1 for physical escape trajectories (hyperbolas); and 0 < e < 1 for orbits which leave the bodies soi. See 2.

2. The correct check is: (apoapsis + Kerbin:radius) > Kerbin:soi
3. There is the (admittedly somewhat pathological) boundary case where apoapsis will become 0 or negative as well, that is when your vessel is submerged in an ocean. That is no longer an issue once you look at (apoapsis + Kerbin:radius). To be unique and consistent you want to choose a negative number for apoapsis which is less than minus the bodies' radius when you want to indicate an escape orbit.
4. And finally: I still think apoapsis should be left alone - and another solution be found to indicate that a vessel leaves into parent bodies' soi (the Sun for Kerbin).

Edit: Just noted according to the change diff that periapsis information becomes unavailable in kOS as well when status = "ESCAPING".

[Dunbaratu]

You don't NEED to check status to find out if an orbit is hyperbolic. Escape velocity calculations already tell you that. It's redundant to have status just echo back what the laws of physics say (which can be calculated) instead of what the KSP simulation says (which can't).