Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 03-01-2017, 04:11 AM   #1
mstram
Orbinaut
Default Univ Ptg yaw - 89.4 270.6

When using OPS 201 / Univ PTG :

With body vect =5

If item 16 (Yaw) is set to > 89.4, or < 270.6 when Item 19 (TRK) is executed the pitch is being set to 270.0 / 90.0

Is this a "floating point " / " trig" limitation ?

Or some other unknown bug ?
mstram is offline   Reply With Quote
Old 03-01-2017, 07:05 AM   #2
Ilmars
Orbinaut
Default

Quote:
Originally Posted by mstram View Post
 When using OPS 201 / Univ PTG :

With body vect =5

If item 16 (Yaw) is set to > 89.4, or < 270.6 when Item 19 (TRK) is executed the pitch is being set to 270.0 / 90.0

Is this a "floating point " / " trig" limitation ?

Or some other unknown bug ?
Since MSTRAM and I have both been puzzling about the above, I would like to elaborate the description of the issue, in case it isn't clear.....

When a body vector of 5 is selected and item 19 is executed with P=0, Y=0, and OM=0, the orbiter's attitude is oriented with +X pointing to the center of the earth and -Z is pointing in the direction of VV (as would be expected).

If a value is then entered for Y (item 16) that is between 0 and 89.4, the orbiter will yaw so that the entered Y vector is pointing to earth and -Z axis is still pointing to VV, as I would expect.

However, if a value is entered for Y that is between 89.5 and 90, the orbiter orients the Y vector to earth as expected, but then pitches the +X axis so that it is pointing to VV, and the -Z axis is pointing to antinormal. The same behaviour occurs when entering a Y value within 1/2 degree of 270, except the -X axis then points to VV. I would not have expected the +X or -X axes to be oriented towards VV in these cases. (Note that the P and OM values are still set to 0 in all cases).

Is this behaviour correct, or is it an artifact of the trig at the boundaries? Does the same thing happen on the real shuttle?

Last edited by Ilmars; 03-01-2017 at 07:47 AM.
Ilmars is offline   Reply With Quote
Old 03-01-2017, 03:11 PM   #3
GLS
Addon Developer
 
GLS's Avatar
Default

Smells like math trouble somewhere... I'll try to take a deeper look at this.

---------- Post added at 03:11 PM ---------- Previous post was at 10:33 AM ----------

It appears to be the intention of the code to differentiate Y=90 or Y=270 from the rest of the values... why, I'm not really sure. It seems the Body Vector reference rotates -90 in those 2 cases, so one has to input omicron 270 or 90 to get to the desired attitude mentioned above.
There is a lack of precision in the value testing that causes values close to 90 and 270 to be "accepted" as 90 or 270 (which is easy to fix), but if the current behaviour is correct for 90 and 270 I don't know because I don't have enough info.

Right now the only thing I can do is a small change so that the Body Vector only rotates when Y=90.00 and Y=270.00.
GLS is online now   Reply With Quote
Old 03-01-2017, 10:59 PM   #4
Ilmars
Orbinaut
Default

Quote:
Originally Posted by GLS View Post
 Smells like math trouble somewhere... I'll try to take a deeper look at this.

---------- Post added at 03:11 PM ---------- Previous post was at 10:33 AM ----------

It appears to be the intention of the code to differentiate Y=90 or Y=270 from the rest of the values... why, I'm not really sure. It seems the Body Vector reference rotates -90 in those 2 cases, so one has to input omicron 270 or 90 to get to the desired attitude mentioned above.
There is a lack of precision in the value testing that causes values close to 90 and 270 to be "accepted" as 90 or 270 (which is easy to fix), but if the current behaviour is correct for 90 and 270 I don't know because I don't have enough info.

Right now the only thing I can do is a small change so that the Body Vector only rotates when Y=90.00 and Y=270.00.
I'm not really concerned about a behaviour fix for the values within the 1/2 degree of 90 or 270. What I am puzzled about is that the X axis is rotatated at all to VV for Y=90 or 270. I would have thought that the yaw behaviour at those limits would be the same around the Z axis, as with the other values, and leaving the -Z pointing to VV throughout. Would there have been a reason on the real shuttle for the current behaviour? I guess, as you said, you may not have the info to answer that.

Is there a document anywhere that details the attitude behaviour for the values used with the TRK mode? I've searched quite a bit of the NASA documents but haven't found anything other than vague references in the DPS and some checklists.
Ilmars is offline   Reply With Quote
Old 03-01-2017, 11:41 PM   #5
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Ilmars View Post
 I'm not really concerned about a behaviour fix for the values within the 1/2 degree of 90 or 270. What I am puzzled about is that the X axis is rotatated at all to VV for Y=90 or 270. I would have thought that the yaw behaviour at those limits would be the same around the Z axis, as with the other values, and leaving the -Z pointing to VV throughout. Would there have been a reason on the real shuttle for the current behaviour? I guess, as you said, you may not have the info to answer that.

Is there a document anywhere that details the attitude behaviour for the values used with the TRK mode? I've searched quite a bit of the NASA documents but haven't found anything other than vague references in the DPS and some checklists.
Tomorrow I'll look at the checklists and flight plans to see what is input in the display and what the expected attitude is, but I'm thinking the current behavior is intended. In the revision where this code was last (largely) modified, SiameseCat wrote: "Fixing bug in ConvertPYOMToBodyAngles so that angles are calculated correctly - see description in NASA Guidance and Control Workbook", so it seems the code was done with more info than what we have now.
GLS is online now   Reply With Quote
Old 03-02-2017, 10:14 AM   #6
Ilmars
Orbinaut
Default

Thanks for looking into this, GLS.

Any idea where a copy of the "NASA Guidance and Control Workbook" might be? I've scoured the web and NASA sites, but I can't seem to find anything.
Ilmars is offline   Reply With Quote
Old 03-02-2017, 10:33 AM   #7
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by Ilmars View Post
 Thanks for looking into this, GLS.

Any idea where a copy of the "NASA Guidance and Control Workbook" might be? I've scoured the web and NASA sites, but I can't seem to find anything.
Only a few workbooks are easily found on the NASA homepage, some require some more research.
Urwumpe is offline   Reply With Quote
Old 03-02-2017, 04:00 PM   #8
GLS
Addon Developer
 
GLS's Avatar
Default

Found this:

I was going to post that I was more confused with this, but I understand it now and we do have the correct implementation.
In simple terms: omicron is the angle we need to rotate the vehicle, around the defined body vector after it is pointed to the target, so the right wing is towards the "south* side" of the orbit. If Y=90 or Y=270, omicron becomes the angle we need to rotate the vehicle so that the payload bay is towards the "south side" of the orbit.

*) north for retrograde orbits

Later today I'll commit the fix for those 0.6, also the corrected numbers for body vector 4 (-Y ST), and a few more corrections there.
Attached Thumbnails
Click image for larger version

Name:	omicron.PNG
Views:	204
Size:	24.6 KB
ID:	15085  
GLS is online now   Reply With Quote
Thanked by:
Old 03-02-2017, 10:48 PM   #9
Ilmars
Orbinaut
Default

Thanks GLS, I'll put in some time to digest this.

Which document did you find the specification in, is it available anywhere?

Cheers,
Ilmars
Ilmars is offline   Reply With Quote
Old 03-02-2017, 11:24 PM   #10
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Ilmars View Post
 Thanks GLS, I'll put in some time to digest this.

Which document did you find the specification in, is it available anywhere?

Cheers,
Ilmars
That is in the Orbit Operations checklist, which should be available in the NASA website.
GLS is online now   Reply With Quote
Old 03-03-2017, 10:14 AM   #11
Ilmars
Orbinaut
Default

Quote:
Originally Posted by GLS View Post
 Found this:
{image}
I was going to post that I was more confused with this, but I understand it now and we do have the correct implementation.
In simple terms: omicron is the angle we need to rotate the vehicle, around the defined body vector after it is pointed to the target, so the right wing is towards the "south* side" of the orbit. If Y=90 or Y=270, omicron becomes the angle we need to rotate the vehicle so that the payload bay is towards the "south side" of the orbit.

*) north for retrograde orbits

Later today I'll commit the fix for those 0.6, also the corrected numbers for body vector 4 (-Y ST), and a few more corrections there.
I think you are right, the implementation is correct.

It took me a while to understand it. What threw me initially was why it rotated at all when the Y parameter was set to 90. But then I realized that for values of Y that are 0 to 89.99, the current omicron reference attitude was in effect, and since OM = 0, no omicron rotation occurs up to Y=89.99.

But when Y reaches 90 or 270, the latter part of the Omicron Specification takes effect and the -Z pointing to -H becomes the new Omicron 0 reference, and in the reached attitude the actual OM is now 90 relative to the new Omicron reference. But since the OM is still set to 0 in the MFD, the orbiter needs to rotate to resolve the current 90 OM attitude to the 0 OM set in the MFD.

Any chance this convoluted description is your understanding as well?

Last edited by Ilmars; 03-03-2017 at 10:38 AM.
Ilmars is offline   Reply With Quote
Old 03-03-2017, 10:41 AM   #12
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Ilmars View Post
 I think you are right, the implementation is correct.

It took me a while to understand it. What threw me initially was why it rotated at all when the Y parameter was set to 90. But then I realized that for values of Y that are 0 to 89.99, the current omicron reference attitude was in effect, and since OM = 0, no omicron rotation occurs up to Y=89.99.

But when Y reaches 90 or 270, the latter part of the Omicron Specification takes effect and the -Z pointing to -H becomes the Omicron 0 reference, and in the reached attitude the actual OM is now 90. But since the OM is still set to 0 in the MFD the orbiter needs to rotate to resolve the current 90 OM attitude to the 0 OM set in the MFD.

Any chance this convoluted description is your understanding as well?
Pretty much.
When Y=90 or 270, the body vector is "contained" in the Y body axis, so OM becomes redundant and we would loose a degree of freedom. So that's why in those cases the OM reference changes to another body axis.
GLS is online now   Reply With Quote
Old 03-03-2017, 11:18 AM   #13
Ilmars
Orbinaut
Default

Quote:
Originally Posted by GLS View Post
 Pretty much.
When Y=90 or 270, the body vector is "contained" in the Y body axis, so OM becomes redundant and we would loose a degree of freedom. So that's why in those cases the OM reference changes to another body axis.
I guess the loss of a degree of freedom is like a mathematical gimbal lock between 2 axes, you lose one axis.

BTW in the description above I should have said " in the reached attitude the OM is now 270", not 90 -- since the -Z would be pointing to VV and now needs to come down to -H to satisfy the OM 0 that is in the entry.

Whew!
Ilmars is offline   Reply With Quote
Old 05-24-2017, 09:23 AM   #14
Gingin
Orbinaut
 
Gingin's Avatar
Default

Very intersting discussion. I am diving into Universal Pointing, and it's not always easy to have a good picture of different BPV and Omicron rotation.

I found some interesting stuff about BPV/Omicron
Also, some good input when BPV is on +-Y axis ( as you said, orbiter -Z axis will have to point in the anti normal direction -H to no loose one degree of freedom)

A Visual example to sum up.
BPV is tracking center of Earth with different BPV and Omicron configuration:

Gingin is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 10:28 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.