Univ Ptg yaw - 89.4 270.6

[mstram]

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 ?

 

[Ilmars]

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?

 

[GLS]

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. :shrug:

 

[Ilmars]

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. :shrug:

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.

 

[GLS]

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. :shrug:

 

[Ilmars]

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.

 

[Urwumpe]

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.

 

[GLS]

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.

 

[Ilmars]

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

 

[GLS]

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.

 

[Ilmars]

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.

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?

 

[GLS]

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.

 

[Ilmars]

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!

 

[Gingin]

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: