Astronomic frames of reference (Orbiter vs. SPICE)

[evilfer]

Hi,

I apologize in advance for the mistakes that might appear in the following sentences .

I've noticed that the frame of reference that Orbiter uses (ecliptic and mean equator at J2000 epoch) is different to that of Naif's SPICE (eclipj2000): in Orbiter, the X and Z axes are in the plane of the ecliptic, while in SPICE it's the X and Y axes which lie in that plane.

As these reference frames are still kind of a mistery for me, I wonder whether there is no convenction for naming the axis of the reference frames, and whether there's any reason for these two frames to be different.

Or is that the axis names don't matter that much?

 

[Wishbone]

The names (and their sequence) matter. SPICE uses right-handed frames (as pretty much everybody else) while Orbiter uses a left-handed one. Being geometry-challenged, I have been evading this very problematic issue by frantically swapping axes until the results were "acceptable".

 

[evilfer]

The names (and their sequence) matter. SPICE uses right-handed frames (as pretty much everybody else) while Orbiter uses a left-handed one. Being geometry-challenged, I have been evading this very problematic issue by frantically swapping axes until the results were "acceptable".

. I've been looking in puzzlement for a while at a DG in an orbit unexpectedly perpendicular to the ecliptic (set in a scenario created with SPICE data), and then another while considering in anger how much code I'd have to fix in case I had mistaken the axes, and then realized that I should RTFM.

I think swapping Y and Z will do the trick .

 

[evilfer]

. I've been looking in puzzlement for a while at a DG in an orbit unexpectedly perpendicular to the ecliptic (set in a scenario created with SPICE data), and then another while considering in anger how much code I'd have to fix in case I had mistaken the axes, and then realized that I should RTFM.

I think swapping Y and Z will do the trick .

Not meant as a thread bump, but my previous thought was partially wrong. Swapping Z and Y did work for vectors representing vessel's position and velocity relative to Earth:

cspice vector (X, Y, Z) -> orbiter vector (X, Z, Y)

However, it did not work with a normalized vector representing a direction (the direction for the thrust vector for a burn). In this case, I had to do the following conversion:

cspice vector (X, Y, Z) -> orbiter vector (-X, -Z, Y)

I have no idea why. I prefer to think the reason is a bug somewhere in my code rather than some unfathomable math rules though.

 

[mjessick]

I suggest using standard coordinate frames and converting on input and output to the Orbiter API. Life is too short otherwise...

 

[evilfer]

I suggest using standard coordinate frames and converting on input and output to the Orbiter API. Life is too short otherwise...

Hi, I'm working with the CSPICE eclipj2000 frame as "my standard", and I convert only from this frame to the Orbiter frame (I don't need to convert vectors the other way around). Should I use a different standard frame? What I meant by my post is that it doesn't make sense to me that I need to use a different conversion depending on the meaning of the vector; my best guess is that I must be doing something wrong somewhere. Or is there any explanation for this two conversion methods?

 

[kwan3217]

Not meant as a thread bump, but my previous thought was partially wrong. Swapping Z and Y did work for vectors representing vessel's position and velocity relative to Earth:

cspice vector (X, Y, Z) -> orbiter vector (X, Z, Y)

However, it did not work with a normalized vector representing a direction (the direction for the thrust vector for a burn). In this case, I had to do the following conversion:

cspice vector (X, Y, Z) -> orbiter vector (-X, -Z, Y)

I have no idea why. I prefer to think the reason is a bug somewhere in my code rather than some unfathomable math rules though.

A vector is a vector. Normalized vectors should work just like position and velocity vectors, so x,z,y should work. Are you perhaps confusing the direction of thrust with the direction the exhaust is going? Or are you using the spice->orbiter conversion when you should be doing orbiter->spice?

Every time you flip a sign, you go from left to right handed or back, and every time you flip the order of two components, you also switch left and right. You flipped Z and Y, and added two - signs, so you should have gone from right to left three times, ending up left-handed. So at least this is right.

 

[evilfer]

A vector is a vector. Normalized vectors should work just like position and velocity vectors, so x,z,y should work. Are you perhaps confusing the direction of thrust with the direction the exhaust is going? Or are you using the spice->orbiter conversion when you should be doing orbiter->spice?

Every time you flip a sign, you go from left to right handed or back, and every time you flip the order of two components, you also switch left and right. You flipped Z and Y, and added two - signs, so you should have gone from right to left three times, ending up left-handed. So at least this is right.

I think you're right about the thrust and exhaust directions, that's a very good point!! The cspice vector (x y z) represents the direction the ship should accelerate. After some time fighting with dimensions and space, I see that converting it to an orbiter vector (-x -z y) means that this new vector points to the oposite direction (exhaust direction).

But then, when I compare this (-x -z y) vector with a second vector direction, calculated with the angles obtained from GetGlobalOrientation(), the angle difference is ~0º when the ship is pointing in the direction I need!! This is what I didn't understand.

However, the documentation of GetGlobalOrientation() indicates that "The components of the returned vector arot are the angles of rotation [rad] around the x,y,z axes in the global (ecliptic) frame to produce the rotation matrix R for mapping from the vessel's local frame of reference to the global frame of reference".

In other words, GetGlobalOrientation does not really represent the vessel's orientation angles in the local frame of reference (as I had assumed), but rather the angles you'd have to rotate the ship in order to have it pointing to +z (that is, the opposite angles).

Does this make sense?

EDIT:

No, it doesn't, the exhaust direction vector should be:
cspice_forward = (x, y, z) -> orbiter_exhaust = (-x, -z ,-y) :S