KontrolSystem2 icon indicating copy to clipboard operation
KontrolSystem2 copied to clipboard

True anomaly

Open PhilouDS opened this issue 1 year ago • 7 comments

I tested true_anomaly for a vessel around the Mun.

let t0 = current_time() + 50000
while (current_time() < t0) {
    alt = vessel.altitude_sealevel + vessel.main_body.radius
    CONSOLE.print_at(0,0,$"True anomaly radian: {vessel.orbit.true_anomaly_at_radius(alt):N2}     ")
    CONSOLE.print_at(1,0,$"True anomaly degree: {RAD_TO_DEG * vessel.orbit.true_anomaly_at_radius(alt):N2}     ")
    yield()
  }

image

I should have 0 when the vessel is at the periapsis and 180° (or 3.14 rad) at the apoapsis. But It's not the case.

So I changed the alt variable to ship.orbit.radius(current_time()) and it's ok... From where does this difference come from?

ALSO: the true anomaly is increasing from 0° to 180° from periapsis to apoapsis. But from apoapsis to periapsis, the value decreases from 180° to 0° instead of continuing to increase to 360°... Or, at least, the value should be negative. Any explanation for that? (my vessel is flying counterclockwise around the mun)

PhilouDS avatar Mar 28 '24 21:03 PhilouDS

vessel.altitude_sealevel + vessel.main_body.radius should be the same as vessel.orbit.radius(current_time()) ... but the data is taken from different places of the game, so I have to investigate if there is something strange going on.

As for the 0° - 180°: Every orbit is symmetric, so true_anomaly_at_radius usually has two solutions.

I guess the API is missing some helpers to get the true anomaly for a position/time ... so far I only had use-cases the other way round.

untoldwind avatar Mar 28 '24 23:03 untoldwind

vessel.altitude_sealevel + vessel.main_body.radius should be the same as vessel.orbit.radius(current_time()) ... but the data is taken from different places of the game, so I have to investigate if there is something strange going on.

Something is definitively going strange. The difference between the 2 values goes from -2m to 2 m... but, with time warping, the value can raise to 20m !

Finally, I need some help to find the argument of my craft. I would like this angle measured from the LAN with a result between 0 and 360°... using argument_of_periapsis and true_anomaly led me nowhere.

I'm just thinking of this (just before going to bed)... Should I use vectors and find the angle. Maybe i just have to compute the angle betwwen relative_ascending_node and ship.position)? Is it that simple?

PhilouDS avatar Mar 28 '24 23:03 PhilouDS

If it may help, you are searching The argument of latitude. And with vectors, don't know if it's correct, but all computing I made on this base gives me result I expected. (body.geo_coordinates(0.0, vessel.orbit.LAN).altitude_position(0.0) - vessel.main_body.position).angle_to(vessel.position - vessel.main_body.position)

lefouvert avatar Mar 29 '24 03:03 lefouvert

Thanks. I tried the following this morning for the true anomaly and it works: RAD_TO_DEG * vessel.orbit.true_anomaly_from_vector(vessel.orbit.relative_position(current_time()))

PhilouDS avatar Mar 29 '24 07:03 PhilouDS

I mark this is enhancement, because there should be some reliable helpers on orbit to get/calculate the true-anomaly of a position/time.

As for the drift in the distance ... this is a rabbit-hole of wonders. Here is what I figured out so far:

  • vessel.altitude_sealevel is based on the internal Telemetry component, which in turn calculates its value from the current position of the vessel
  • ... so at the very least vessel.altitude_sealevel + vessel.main_body.radius should be equal to (vessel.global_position - body.global_position).magnitude
  • ... but the position of the vessel is actually take from the internal transformation frame, that can be the very special PhysicsSpace, which is its own frame of reference (essentially an inertial frame where the physics engine can run in).
  • I have not fully worked out how the PhysicsSpace is synced with the orbit (I am not even sure which one is "in charge"), but there is certainly a delay ... so I guess that is where the difference is coming from.

So in short: I do not think this could be fixed, it is just how the game works internally (at the moment?).

untoldwind avatar Mar 29 '24 08:03 untoldwind

I'm sorry, but I don't understand what's missing. Did the purpose was to get current true anomaly ?

As found by Philou, const vesselTrueAno = vessel.orbit.true_anomaly_from_vector(vessel.position) * RAD_TO_DEG does a great job. (I didn't understood the question was to found the current true anomaly)

Maybe a shortener for time related true anomaly may be usefull since the true anomaly -> eccentric anomaly -> mean anomaly tools are given (and orbit provide epoch, mean_anomaly_at epoch and period), but not the other way, and yes, computing thoses is a bit tedious (especialy mean anomaly to eccentric anomaly)

Edit : (great video about this subject (6 minutes): OrbitNerd with some algo shared, sourced form some great famous books on the topics, even if the mean anomaly -> eccentric anomaly algo is 'Meh' to my taste. But it's because i'm a grumpy man, everything is 'Meh' at best :D)

lefouvert avatar Mar 29 '24 10:03 lefouvert

In the 0.5.7.5 pre-release (https://github.com/untoldwind/KontrolSystem2/releases/tag/v0.5.7.5) I added an orbit.true_anomaly_at_ut(ut: float) function.

I also ensured that both true_anomaly_.. functions always return 0 - 2π

untoldwind avatar Mar 29 '24 15:03 untoldwind

This issue is stale because it has been open for 60 days with no activity.

github-actions[bot] avatar May 29 '24 02:05 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Jun 12 '24 02:06 github-actions[bot]