Jump to content

Incoherent positions calculated from true anomaly ?


Recommended Posts

Hello, I'm attempting to draw custom orbit lines and place objects in the Tracking Station view. I'm trying to retrieve the position on a orbit from a true anomaly. However, I'm coming accross weird position calculations when using the Orbit.getPosition functions and custom true anomalies values.

I saw a similar issue in this post, but it doesn't provide an explanation or solution to the problem:

 

I've setted up this bit of code to debug what's going on, which runs on the first frame when entering the Tracking Station. It first compares positions calculated using UT and an offsetted UT. Then it compares the positions by modifying the true anomaly angle with a small offset. I made a small analysis of the results below.

Logger.Log("MODIFYING UT:");

double ut = Planetarium.GetUniversalTime();
Logger.Log("UT: " + ut);

double trueAnom1 = kerbin.orbit.TrueAnomalyAtUT(ut);
double trueAnom2 = kerbin.orbit.TrueAnomalyAtUT(ut + 1); // +1 second

Logger.Log("True Anom 1: " + trueAnom1);
Logger.Log("True Anom 2: " + trueAnom2);

Vector3d localPos1 = kerbin.orbit.getPositionFromTrueAnomaly(trueAnom1);
Vector3d localPos2 = kerbin.orbit.getPositionFromTrueAnomaly(trueAnom2);
Logger.Log("Local Pos 1: " + localPos1);
Logger.Log("Local Pos 2: " + localPos2);

Vector3d scaledPos1 = ScaledSpace.LocalToScaledSpace(localPos1);
Vector3d scaledPos2 = ScaledSpace.LocalToScaledSpace(localPos2);
Logger.Log("Scaled Pos 1:  " + scaledPos1);
Logger.Log("Scaled Pos 2:  " + scaledPos2);

Logger.Log("Local Positions Distance: " + (localPos1 - localPos2).magnitude);
Logger.Log("Scaled Positions Distance: " + (scaledPos1 - scaledPos2).magnitude);




Logger.Log("MODIFYING TRUE ANOMALY:");

ut = Planetarium.GetUniversalTime();
Logger.Log("UT: " + ut);

trueAnom1 = kerbin.orbit.TrueAnomalyAtUT(ut);
trueAnom2 = trueAnom1 + 0.001; // 0.001 offset angle in radians (= 0.05729578°)

Logger.Log("True Anom 1: " + trueAnom1);
Logger.Log("True Anom 2: " + trueAnom2);

localPos1 = kerbin.orbit.getPositionFromTrueAnomaly(trueAnom1);
localPos2 = kerbin.orbit.getPositionFromTrueAnomaly(trueAnom2);
Logger.Log("Local Pos 1: " + localPos1);
Logger.Log("Local Pos 2: " + localPos2);

scaledPos1 = ScaledSpace.LocalToScaledSpace(localPos1);
scaledPos2 = ScaledSpace.LocalToScaledSpace(localPos2);
Logger.Log("Scaled Pos 1:  " + scaledPos1);
Logger.Log("Scaled Pos 2:  " + scaledPos2);

Logger.Log("Local Positions Distance: " + (localPos1 - localPos2).magnitude);
Logger.Log("Scaled Positions Distance: " + (scaledPos1 - scaledPos2).magnitude);

(Logger.Log is a custom wrapper around Debug.Log)
Here are the results:

MODIFYING UT:

UT: 135842917.592889
True Anom 1: 1.63107920616794
True Anom 2: 1.63107988885983
Local Pos 1: [493910.75, 1014.90991210938, -340737.9375]
Local Pos 2: [501845.514609337, 1014.90991210938, -335916.997343063]
Scaled Pos 1:  [82.3098468153844, 0.269453518842612, -56.9360563766938]
Scaled Pos 2:  [83.6323075694434, 0.269453518842612, -56.1325663591432]

Local Positions Distance: 9284.500708296
Scaled Positions Distance: 1.54741676814283


MODIFYING TRUE ANOMALY:

UT: 135842917.592889
True Anom 1: 1.63107920616794
True Anom 2: 1.63207920616794
Local Pos 1: [493910.75, 1014.90991210938, -340737.9375]
Local Pos 2: [12113141.2240677, 1014.90991210938, 6726731.39502716]
Scaled Pos 1:  [82.3098468153844, 0.269453518842612, -56.9360563766938]
Scaled Pos 2:  [2018.84823841927, 0.269453518842612, 1120.97548642882]

Local Positions Distance: 13599839.6893388
Scaled Positions Distance: 2266.63992394695

 

First test (modifying the UT) :

In the first comparison, I'm calculating the true anomalies using the built in TrueAnomalyAtUT function at two different dates : the current UT and that same time but 1 second in the future. As you can see, the positions seem close enough both in local space and scaled space. Morover, the distance of about 9284 meters between the two position matches the distance Kerbin would travel in 1 second, based on its orbital velocity which is 9285 m/s (according to the wiki: https://wiki.kerbalspaceprogram.com/wiki/Kerbin).
Note also that the scaled position calculated at the current UT matches the coordinates of kerbin.scaledBody.transform.position (not shown here, but tested).

However, the magnitude of the position vector (in local space) is about 60000 m, which doesn't seem to match Kerbin's orbit semi major axis of 13 599 840 256 m (according to the wiki). I thought intuitively that the origin of the world (= local space ?) coordinates would be where the Sun is, but it can't be according to these values. Where is the origin of the world ? Am I missing something in how the local space works ?
I also find a bit curious that the distance traveled in the scaled space is about 1 unit. The magnitude of the position vector in scaled space (according to these logs) is about 100 units. So that means that Kerbin would have moved of 1/10th of its "position magnitude" in one second in the Tracking Station view... which clearly isn't the case. We don't see any bodies moving that much in just 1 second (they look pretty still).

 

Second test (modifying the true anomaly) :

Now the second comparison. I first compute the true anomaly at the current UT, and the position at this true anomaly using getPositionFromTrueAnomaly. Then I compute another position but with a true anomaly offsetted of only 0.001 radians, which corresponds to about 0.06 degrees. I expect to have very close coordinates, but as you can see, it's complete nonsense.
The position calculated from the true anomaly at the current UT looks correct (same as in first test). But the positions calculated at the offseted anomaly makes no sense. Except the y-coordinate, the xz-coordinates are different from the first position by several orders of magnitude (not mentioning the sign change on the z-component). The scaled coordinates doesn't make sense either.
The distance between the two positions is about 13 600 km for a 0.06 degrees difference in the true anomaly, and in scaled space it's about 2300 units.

 

Something is obviously wrong and I can't figure out what. I want to draw custom orbit lines and I've looked through the source code of other mods (the DrawTools class in Kopernicus: https://github.com/Kopernicus/Kopernicus/blob/755ab1e3a5cf73e44e033be12906693f9564ceaa/src/Kopernicus/Components/DrawTools.cs) and they don't seem to do anything different from me except using the eccentric anomaly (I tried it, and I get the same problems).

What am I missing ? Am I misunderstanding how local space / scaled space work ? (another post I made related to Tracking Station positioning problems :

 

Thank you very much in advance for any help ! :D

Edited by Krafpy
Link to comment
Share on other sites

  • 5 weeks later...
On 7/24/2022 at 2:59 PM, Krafpy said:

I thought intuitively that the origin of the world (= local space ?) coordinates would be where the Sun is, but it can't be according to these values. Where is the origin of the world ? Am I missing something in how the local space works ?

The origin (both in local and scaled space) can be anywhere, because it's a floating origin. To mitigate floating point precision issues, KSP occasionally move the origin so the active vessel stays near the origin. However, this isn't done on every frame and there are various exceptions.
The main consequence is that you can only compare relative positions at a specific point in the execution flow. Even within the same frame, there is no guarantee that the origin won't move between two separate calls.

Link to comment
Share on other sites

Thank you for the information !

After playing around a bit I eventually noticed that the scaledSpace coordinates indeed change every frame and depend on camera position.

9 hours ago, Gotmachine said:

The origin (both in local and scaled space) can be anywhere, because it's a floating origin.

So if I need to compute the positions of several bodies for physics purpose (i.e. with origin centered at the Sun or at the planet for moons), ignoring floating point precision issues for now, is it feasible with getPositionFromTrueAnomaly or a similar functions ? Or do I need to reimplement the maths myself ?
If the origin can be anywhere, how does KSP compute the bodies' positions since the maths involve positions vectors with defined origins ?

Sorry if I'm not clear.

 

Link to comment
Share on other sites

9 hours ago, Krafpy said:

is it feasible with getPositionFromTrueAnomaly or a similar functions

I think so, but there are various shenanigans, the KSP methods don't always do what you expect them to do from their name.

10 hours ago, Krafpy said:

If the origin can be anywhere, how does KSP compute the bodies' positions since the maths involve positions vectors with defined origins ?

The origin is irrelevant, everything's position is relative to another. All positions are consistent relatively to the current origin at any point of execution, that's what matter.

Link to comment
Share on other sites

Alright, I guess it will be simpler to reimplement the functions I need.

7 minutes ago, Gotmachine said:

The origin is irrelevant, everything's position is relative to another. All positions are consistent relatively to the current origin at any point of execution, that's what matter.

For placing and rendering objects I agree. But KSP needs at some point to compute, for example, the position of a planet at a given date, and for that, to my knowledge, it needs to do some maths involving quantities and vectors (computing mean anomaly then true anomaly, and then rotating some vector) that are defined in a coordinate system where the origin is the Sun.
Or am I missing something ?

Link to comment
Share on other sites

44 minutes ago, Krafpy said:

defined in a coordinate system where the origin is the Sun

No. If you use one of the "AtUT" method, the body position is computed recursively relatively to it's parent body using keplerian orbit parameters and equations. There is no need for a known absolute point of reference.

Edited by Gotmachine
Link to comment
Share on other sites

1 hour ago, Gotmachine said:

the body position is computed recursively relatively to it's parent body using keplerian orbit parameters and equations.

That's exactly what I meant, with the example of a planet orbiting the sun. Sorry if my phrasing was poor. So indeed for a planet, their coordinates would be calculated and expressed relatively to the sun (sun as origin), and for a satellite relatively to the planet its orbiting around.
So the "AtUT" methods actually return the correct coordinates relative to the attractor body ? and not relative to some floating unkwon origin in space (that's what I understood from your earlier answer) ?

Link to comment
Share on other sites

I think we are lost in semantics.
To me, "origin" is the 0,0,0 point, anything else is a reference point, not an origin.
If your question is "are the positions returned by the various orbit methods consistent relative to each other and to a common reference point ?" the answer is yes.

3 hours ago, Krafpy said:

their coordinates would be calculated and expressed relatively to the sun (sun as origin), and for a satellite relatively to the planet its orbiting around.

There are two different set of methods in the orbit class.
Those prefixed with "Relative" return a vector expressing the position offset from the parent body position, but that vector is usually in a coordinate system where the y and z axis are swapped compared to world space.
The non-prefixed ones return an absolute position in world space, where the origin / (0,0,0) point can be anywhere.

3 hours ago, Krafpy said:

So the "AtUT" methods actually return the correct coordinates relative to the attractor body ?

No, for the methods that don't have "Relative" in their name, they return an absolute point in world space where the origin (0,0,0) point can be anywhere.
If you want a vector from the parent body, you need to look at the "Relative" methods.

Link to comment
Share on other sites

On 7/24/2022 at 2:59 PM, Krafpy said:

The position calculated from the true anomaly at the current UT looks correct (same as in first test). But the positions calculated at the offseted anomaly makes no sense.

To get back to your original post (because I actually didn't really took the time to read it before) : the results you are getting make perfect sense to me.
A +0.001 offset in true anomaly is absolutely not equal to 1s of orbital period, it's far, far more (something like 1400s), so of course you're getting a much larger movement.
Also, if you followed what I said before, comparing the absolute position magnitude like you do doesn't make much sense because you don't know where the origin is.

Edited by Gotmachine
Link to comment
Share on other sites

2 hours ago, Gotmachine said:

Those prefixed with "Relative" return a vector expressing the position offset from the parent body position, but that vector is usually in a coordinate system where the y and z axis are swapped compared to world space.

2 hours ago, Gotmachine said:

If you want a vector from the parent body, you need to look at the "Relative" methods.

Alright thank you very much for the clarification !

 

1 hour ago, Gotmachine said:

A +0.001 offset in true anomaly is absolutely not equal to 1s of orbital period, it's far, far more (something like 1400s), so of course you're getting a much larger movement.

I know that a true anomly offset isn't directly linked to time. But if you look at the values, what looked like nonsense to me was these lines :

Local Pos 1: [493910.75, 1014.90991210938, -340737.9375]
Local Pos 2: [12113141.2240677, 1014.90991210938, 6726731.39502716]

`Local Pos 2` is the position after adding +0.001 to the true anomaly of `Local Pos 1`. The sign of the z coordinate is changed, meaning that the object would have traveled to the opposite side of the xy plane by such a small change in angle...
But now that you precised that the origin in local space can be anywhere, I guess they make more sense, the origin for these coordinates can be very close to the camera for example, thus the change of sign in the z coordinate.

 

2 hours ago, Gotmachine said:

Also, if you followed what I said before, comparing the absolute position magnitude like you do doesn't make much sense because you don't know where the origin is

Even though the origin can be anywhere and can change, the scale should stay consistent. So just to verify that, the distance between `Local Pos 1` and `Local Pos 2` is 13599 km (if the units used are indeed meters). Knowing the velocity of Kerbin, in 1400s Kerbin would travel about 13000 km. So the coordinates make sense indeed, and confirms the units are meters.

I hope I didn't mess up again in undertsanding what you write...

 

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...