Computing the UT at which an altitude is reached

[Meithan]

Hi. I'm trying to compute the next UT at which a vessel with a given Orbit will be at some altitude (specifically, I want to find the UT for the next atmospheric contact, assuming the periapsis is within the atmosphere of the primary).

I've been using several methods of the KSP Orbit class but I get unreliable results: sometimes the UT is spot on, sometimes it's nonsensical, not even close to the actual atmospheric contact.

This is an example of what I've tried:

atmoTopR = vessel.mainBody.Radius + vessel.mainBody.maxAtmosphereAltitude;
contactUT = orbit.GetUTforTrueAnomaly(orbit.TrueAnomalyAtRadius(atmoTopR),0.0);

I don't really understand what the second parameter of the GetUTforTrueAnomaly() method of the orbit class is for. It's a double called "wrapAfterSeconds". It sounds like it's used to clamp the resulting UT to a certain maximum value so as to get a result in the current orbital cycle and not far off into the future. However, the UTs I've been getting are always within the current orbital cycle, so I've simply left its value at zero.

I've checked manually the results of the TrueAnomalyAtRadius() method, and even when the resulting UT is incorrect, the calculated true anomaly is correct. So it seems it's a problem in the GetUTforTrueAnomaly() method. I understand there is some ambiguity in these matters since orbits are cyclic and have certain symmetries.

I guess I could compute the UT myself by computing the eccentric and mean anomalies, obtaining a time, and then adjusting that into the smallest value in the future.

Thoughts, anyone?

[sarbian]

The second parameter is the time from which you start your search. Most of the time it will be the current time.

You can have a look at how MJ does it too :

https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/OrbitExtensions.cs#L463-L473

[Meithan]

The second parameter is the time from which you start your search. Most of the time it will be the current time.

You can have a look at how MJ does it too :

https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/OrbitExtensions.cs#L463-L473

Thanks for answering. Ah yes, I was concocting a "manual" solution very similar to what MechJeb does. I see that MJ doesn't use the GetUTforTrueAnomaly() method from the KSP API, but does the computation using its own functions involving the eccentric anomaly as intermediate step.

I guess the GetUTforTrueAnomaly() method is bugged somewhat? I'll try playing around with the wrapAfterSeconds parameter, and see if that fixes it. If not. I think I'll just do the following, which is similar to what MJ is doing:

[Pseudocode]
[given a radius r and a minimum UT min_UT, as well as an Orbit instance to extract orbital elements]

E = acos(1/e*(1-r/a))
MA1 = E - e*sin(E)
MA2 = 2*pi - MA1  (or MA2 = -MA1, should be equivalent)
n = sqrt(G*M/a^3)
t1 = (MA1-M0)/n + t0
t2 = (MA2-M0)/n + t0
while (t1 < min_UT) {
  t1 += P;
}
while (t2 < min_UT) {
  t2 += P;
}
return min(t1,t2)

I haven't had chance to test it out, but I think it should work. That's for elliptic orbits, but the computation for hyperbolic ones is similar.

Edit: yup, the above definitely works . Thanks for the tip in the right direction, though. MJ is an impressive piece of software.

Edited January 31, 2014 by Meithan