SDK Question Get Attitude/Angles of Orbitsystem

[huddi]

Hi,

I just can't find any function to get the angles between my vessel
and the Orbitsystem (or another vessel or the planetsurface).

All I find are the angles to the ecpliptic, but only of my own vessel.

can anybody help me?
thanks

 

[tofitouf]

That's because it is not that simple....
I'm a develloper too and I had the same troubles.
I found some answers in the attitude mfd source code
first of all you can get any vessel attitude :
get the VESSELSTATUS Structure and its arot value

I've made a pilot based on the attitude mfd source code
It can orient your vessel in any direction or point to any object
you can use it if you want to.
my source is exposed in source forge (control mfd)
search the attitude pilot

good luck

 

[huddi]

thanks for the information so far. but i am just not able to
see how it works that you get the attitude of another vessel.
must be in the autopilot class from which attitude pilot inherits?

do you have another hint for me how it works?

 

[tblaxland]

I found some answers in the attitude mfd source code

I'm glad you could use it because I find it a bit of a mess myself and I'm sure I've looked at it for longer than you have (that's what happens when the code has been through the developers ).

thanks for the information so far. but i am just not able to
see how it works that you get the attitude of another vessel.
must be in the autopilot class from which attitude pilot inherits?

do you have another hint for me how it works?

I'm not quite sure what you are after. The function VESSEL::GetGlobalOrientation will return your vessel's orientation with respect to the ecliptic reference frame. This function can also be used to find the orientation of any other vessel in the scenario, once you have its handle. Note though that these are Euler angles which represent rotations around the primary axes of the ecliptic frame and if you want to know your attitude in the more standard Tait-Bryan rotations you will need to do a conversion.

For finding your attitude relative to another target, simply use oapiGetGlobalPos (on the target) and VESSEL::Global2Local (on your vessel) to transform the target location into a vector in local vessel coordinates. Then calculate the Tait-Bryan rotations to (or from) the principle vessel axes.

 

[huddi]

The function VESSEL::GetGlobalOrientation will return your vessel's orientation with respect to the ecliptic reference frame. This function can also be used to find the orientation of any other vessel in the scenario, once you have its handle.

This is my problem... probably my programming skills are too low yet (I'm still learning c++).
How do I get this Handle?

 

[tblaxland]

This is my problem... probably my programming skills are too low yet (I'm still learning c++).
How do I get this Handle?

The oapiGetVesselByIndex function will allow you to step through all the vessels in a scenario. It is just a matter of searching until you find the vessel you want (you need to set the criteria by which you know when you have you found what you want, eg, is it a vessel with a particular name or class, or any vessel within a certain distance, etc, etc). The focus vessel can be found with oapiGetFocusVessel (although I'm not sure you want that, by the sound of it you are working within the context of a VESSEL or VESSEL2 derived class anyway?).

 

[huddi]

Maybe I just explain what I'm trying to do ...

Yes I'm working on a VESSEL2 ship.
I wanted to create my own head-up-display (which is now functionable
but i cant get anymore angles than to the ecliptic system)

So I am looking for some Angles as they already exist in
the standard HUD-- orbit and surface angles
plus the angles to a reference ship.

this compiles fine, but does not work... how do i do it right?

oapiGetGlobalPos(oapiGetVesselByIndex(0), &Angle1);
Global2Local(Angle1,Angle2);

 

[tblaxland]

this compiles fine, but does not work... how do i do it right?

In what way does it not work? There is every chance that oapiGetVesselByIndex(0) is returning the handle to your vessel and, if it is, I would expect the value in Angle2 to be exactly zero, ie, the position of your vessel in local vessel coordinates is {0,0,0}. Also, naming those vectors AngleX is somewhat poor naming since they do not contain angles at all - it won't stop your code working but it will make it hard to read.

 

[huddi]

I thought that it changes the position vector in to angles ...
thats why it didn't work.

by the way... do i see it right that yaw and pitch angle are somehow
swapped?

and do you maybe know how i can get reference to the surface and
the orbit system?

thanks so far!

 

[tblaxland]

I thought that it changes the position vector in to angles ...
thats why it didn't work.

No it gives you a vector to the target in local vessel coordinates. You need to use trigonometry to convert that into Tait-Bryan rotations (normalise the vector first, it makes it easier).

by the way... do i see it right that yaw and pitch angle are somehow
swapped?

You may be thinking in a right handed coordinate system. Orbiter uses a left handed system. Thinking of a Delta-Glider type vessel, by convention, the +z axis is aligned with the longitudinal axis, the +y axis is the heads up direction and the +x axis points to starboard. So pitch is a rotation about the x axis, yaw is a rotation about the y axis and roll is a rotation about the z axis. Those rotations are measured by right hand convention so, for example, rolling right is a positive rotation.

and do you maybe know how i can get reference to the surface and
the orbit system?

Surface: use functions VESSEL::GetPitch, GetBank and GetSideSlip.
Orbit: use rpos and rvel vectors from the VESSELSTATUS structure

 

[tofitouf]

Hi,

I just can't find any function to get the angles between my vessel
and the Orbitsystem (or another vessel or the planetsurface).

All I find are the angles to the ecpliptic, but only of my own vessel.

can anybody help me?
thanks

Vessel::GetRotationMatrix gives the orientation of the vessel and not only current one. you need to get a Vessel pointer on this using oapi Accesors.

for planet you can use
oapiGetPlanetObliquityMatrix(m_HProjectionReference, m_MReferenceOrientation.p());

 

[huddi]

You may be thinking in a right handed coordinate system. Orbiter uses a left handed system. Thinking of a Delta-Glider type vessel, by convention, the +z axis is aligned with the longitudinal axis, the +y axis is the heads up direction and the +x axis points to starboard. So pitch is a rotation about the x axis, yaw is a rotation about the y axis and roll is a rotation about the z axis. Those rotations are measured by right hand convention so, for example, rolling right is a positive rotation.

yeah the left handed system was a problem too ..

the actual confusion is that the GetGlobalOrientation function returns
yaw angles from only -90° to 90° and pitch angles from -180° to 180°

for example i position my vessel in a way that the bank angle is 0°
now i pull up and can get those big angles even though the pitch angle usually does not.

is there an advantage of these new conventions?
if i get the angles respective to the surface, everything is as expected

 

[tblaxland]

the actual confusion is that the GetGlobalOrientation function returns yaw angles from only -90° to 90° and pitch angles from -180° to 180°

I'm not quite sure what you are referring to here since GetGlobalOrientation returns Euler angles (ie, rotations around the principle axes of the Orbiter's ecliptic frame) not Tait-Bryan rotations (pitch, yaw and roll are Tait-Bryan rotations, ie, rotations around the principle axes of the local vessel frame). It is an important distinction because the axis around which the second and third rotations (beta/gamma and yaw/roll) are conducted are fixed in direction for Euler angles but not fixed for Tait-Byran rotations.

With regard to Tait-Bryan rotations, pitch and roll have a range of 360° (0 to 360 or -180 to +180) and yaw a range of only 180° (usually +/-90). This is because yaw angles >90° are redundant, like latitudes of >90° are.

for example i position my vessel in a way that the bank angle is 0°
now i pull up and can get those big angles even though the pitch angle usually does not.

Perhaps the above explains why?

is there an advantage of these new conventions?
if i get the angles respective to the surface, everything is as expected

I'm not sure what "new conventions" you are referring to?

 

[huddi]

It is an important distinction because the axis around which the second and third rotations (beta/gamma and yaw/roll) are conducted are fixed in direction for Euler angles but not fixed for Tait-Byran rotations.

Are those not the the same angles with a different rotation sequence?

eg Euler: first bank, then pitch, then yaw
tait-bryan: first yaw, then pitch, then bank

i thought you get the same attitude... but corrections are welcome .

With regard to Tait-Bryan rotations, pitch and roll have a range of 360° (0 to 360 or -180 to +180) and yaw a range of only 180° (usually +/-90). This is because yaw angles >90° are redundant, like latitudes of >90° are.

I'm not sure what "new conventions" you are referring to?

this is the convention I'm referring to.
I'm used to aircraft conventions where the yaw angle equals the heading. the heading is displayed by a compass which is known to
have 360° range .
sky is 90°pitch and ground is -90°pitch

 

[tblaxland]

Are those not the the same angles with a different rotation sequence?

eg Euler: first bank, then pitch, then yaw
tait-bryan: first yaw, then pitch, then bank

i thought you get the same attitude... but corrections are welcome .

Incorrect. Tait-Bryan rotations are always conducted around the local vessel axis. For example, the roll axis changes direction w.r.t. an inertial observer. In Euler rotations, the gamma axis remains fixed w.r.t. an inertial observer. This is an important distinction in aerospace applications because your control surfaces/RCS thrusters for one axis always change direction (again w.r.t. to an inertial observer) when one or more of the other axes change. Euler rotations do not account for this. Also, Tait-Bryn rotations do not explicitly state the order. You are correct that yaw/pitch/roll is the conventional order for aircraft (perhaps because of the nav reasons you mentioned). Spacecraft, at least in my limited experience, use the order pitch/yaw/roll. AttitudeMFD works this way (not my design BTW, I inherited the code that way) and the Apollo program used this convention, as evidenced by the design of the FDAI (see how the lines of constant pitch converge at yaw +/- 90 deg?).

 

[huddi]

Do you know how I can transform those Angles to Tait-Bryan Angles?

 

[tblaxland]

Do you know how I can transform those Angles to Tait-Bryan Angles?

Hehe, I knew that question was coming. Yes I do, but not that I have time to write right now. I'll come back later.

 

[tblaxland]

There is not much sense in trying convert between the two directly since the only thing you really should care about is what your target attitude is with respect to your local vessel frame. The Euler angles you get from Orbiter only tell you your rotation relative to the global ecliptic frame.

Here is a bit of a description of how I am doing it in the new Attitude MFD. It is in pseudo-code ATM, so I've written this in better language. I've also drawn a picture to go with the words (see attached). The attitude errors (difference between current attitude and target attitude) will be presented such that they are the angles required to rotate from the current attitude to the target attitude (some conventions may present them the other way around). Here goes:

1. Determine the target attitude frame (in target relative relative mode, this is defined such that the target frame's +Z vector points towards the target and the +X vector lies in the local horizontal plane, in inertial mode the target frame is aligned with the global ecliptic frame, in velocity mode the +Z vector is parallel to the velocity vector and the +X vector lies in the local horizontal plane). I express that frame as at least two vectors (I often use three for convenience) in local vessel coordinates. All vectors should be normalised. The target axes vectors are labelled +Xt, +Yt and +Zt in the drawing.

2. You want to pitch up so that the vessel's +Z axis intersects a plane such that when the pitch is complete, a yaw rotation will bring the +Z axes of the vessel and the target frames into alignment. We will call that intersection point +Z'. The plane passes through the vessel frame's +X axis and the target frame's +Zt axis and is defined by its normal which is the cross product of these two:
+Y' = +Zt X +X
The pitch error can be found from the dot product of +Y and +Y':
pitch error = acos(+Y.+Y')
You will need to be aware of the case where +Zt and +X are either parallel or anti-parallel because the plane becomes undefined. To handle that case, I just disable the pitch steering law because no pitching is required, pure yaw will do the trick.

3. The yaw error can be found from the dot product of +Z' and +Zt:
yaw error = acos(+Z'.+Zt)

4. And the roll error:
roll error = acos(+X'.+Xt)

Hope that makes sense.

 

[tofitouf]

Here is a bit of a description of how I am doing it in the new Attitude MFD.

New attitude MFD ? That's excellent !!!!

Is it yet released or just in preparation ?

 

[tblaxland]

Is it yet released or just in preparation ?

Currently in work. It is a complete rewrite so it is taking a while. User interface and manager classes are complete, guidance class is about 50% and RCS control module is about 10%. The attitude control will be via pluggable modules as I plan to also write a control moment gyro attitude control module.