SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

Are the OMS engines meshes really at the correct angles?

 

[DaveS]

Are the OMS engines meshes really at the correct angles?

They should be. Why? I did a couple of test burns using your DIR parameters with the corrected positions and they held nicely. No RCS wraparound activity whatsoever. Only thing was 2 fps radial residual at the end of each burn.

 

[GLS]

They should be. Why? I did a couple of test burns using your DIR parameters with the corrected positions and they held nicely. No RCS wraparound activity whatsoever. Only thing was 2 fps radial residual at the end of each burn.

I'm seeing a difference in pitch between the animated nozzle and the gimballed thrust vector (exhaust texture). But then this thing currently needs to gimbal the nozzles pretty much all the way down (~5.7º) to point to the c.g., which doesn't seem right. :facepalm:

 

[Urwumpe]

First question: How do you measure the angles?

 

[DaveS]

I'm seeing a difference in pitch between the animated nozzle and the gimballed thrust vector (exhaust texture). But then this thing currently needs to gimbal the nozzles pretty much all the way down (~5.7º) to point to the c.g., which doesn't seem right. :facepalm:

I just checked, 15.5° pitch and 6.7° yaw. That is the correct angles right?

---------- Post added at 12:52 PM ---------- Previous post was at 12:51 PM ----------

First question: How do you measure the angles?

That's a good question, I measure it along the nozzle centerline.

 

[Urwumpe]

If I see the diagram here in low quality correctly:

-15.8° pitch
+/- 6.5 yaw

 

[GLS]

I just checked, 15.5° pitch and 6.7° yaw. That is the correct angles right?

The diagram says pitch 15.82444º and yaw 6.5º.

---------- Post added at 12:16 PM ---------- Previous post was at 12:09 PM ----------

First question: How do you measure the angles?

The directions I'm using came from "forcing" the vector compoments to have the null angles (see above) between them. Doing 2 rotations makes a vector that only matches one of those angles. Here it is: (+/-0.105128, -0.370911, 0.922699).

The nozzle is animated in the standard way, and the thrust vector direction is rotated using 2 rotation matrixes (because the rotation axis are slightly tilted) that use the same parameters fed to the animations.

 

[DaveS]

The diagram says pitch 15.82444º and yaw 6.5º.

I have checked in an updated orbiter mesh that has the OMS nozzles at those angles. I measured the angle between the c.g location and the pitch angle of the OMEs, and it comes out as a difference of 0.2°.

 

[Urwumpe]

Remember, when you do the thrust vector rotations, that the yaw axis should not be rotated with the pitch axis. Simply multiplying two rotation matrices should be wrong.

 

[GLS]

How sure are we that the ORBITER_CG is correct? With it applied to the mesh c.g., the OMS engines end up at a ~30º angle instead of the expected ~15º. Could it be that the c.g. was calculated assumming the nose is Xo=0, instead of Xo=236?
BTW: the (0, 0, 0) point in the mesh is what exactly in (Xo, Yo, Zo)?

---------- Post added at 03:00 PM ---------- Previous post was at 02:57 PM ----------

Remember, when you do the thrust vector rotations, that the yaw axis should not be rotated with the pitch axis. Simply multiplying two rotation matrices should be wrong.

This is what I did:

	MATRIX3 mrot = rotm( axisP, pitch * RAD );
	dir = mul( mrot, dir );

	mrot = rotm( axisY, yaw * RAD );
	dir = mul( mrot, dir );

The animation has the yaw as the parent for the pitch, same rotation parameters.

 

[DaveS]

How sure are we that the ORBITER_CG is correct? With it applied to the mesh c.g., the OMS engines end up at a ~30º angle instead of the expected ~15º. Could it be that the c.g. was calculated assumming the nose is Xo=0, instead of Xo=236?
BTW: the (0, 0, 0) point in the mesh is what exactly in (Xo, Yo, Zo)?

The mesh 0 point works out to the following coordinates: Xo960.782677, Yo0, Zo410.70787.

I got the c.g data from this NTRS document: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19850010693.pdf

 

[GLS]

The mesh 0 point works out to the following coordinates: Xo960.782677, Yo0, Zo410.70787.

I got the c.g data from this NTRS document: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19850010693.pdf

I'm looking at that document, and the OV in there doesn't look like the one that flew... :shifty:

 

[DaveS]

I'm looking at that document, and the OV in there doesn't look like the one that flew... :shifty:

Don't mind the graphics. They probably used whatever they found. The station numbers are still accurate.

 

[GLS]

Made a simple "conversion tool" in excel, pluggled the OMS engines locations and got this:
(+/-2.2352, 2.064820102, -14.15332) and we have currently have this (+/-2.2352, 2.12384, -14.04200)...

 

[GLS]

This settles it for me:

The gimbal assembly provides control angles of plus or minus 6 degrees in pitch and plus or minus 7 degrees in yaw with clearance provided for an additional 1 degree for snubbing and tolerances. The engine null position is with the engine nozzles up 15 degrees 49 seconds (as projected in the orbiter XZ plane) and outboard 6 degrees 30 seconds (measured in the 15-degree 49-second plane).

https://spaceflight.nasa.gov/shuttle/reference/shutref/orbiter/oms/vector.html

They say arc seconds instead of arc minutes, but it was probably written by humans so... :shrug:

The engine installation vector should be (+/-0.108926, -0.27228, 0.956033).

---------- Post added 12-24-17 at 12:35 AM ---------- Previous post was 12-23-17 at 10:09 PM ----------

Found a bug where ITEM entries in a DISP display are accepted by the underlying OPS display. The fix is not hard to do, but I'm wondering exactly what to do: should an ITEM entry in a DISP be classified "ILLEGAL ENTRY" right at the IDP level, or should the DISP number be passed to the "display generators" same as the SPEC number (and because none of them will take the ITEM we still get the error message)?

 

[GLS]

Late Christmas gift: the OMS TVC should be much better now!
For some reason, yaw control is a royal PITA, but as the 2 other axis are now very good IMO (and I used up all my allocation of OMS burns this year :lol, I'm happy enough to commit it. Dual-engine burns seem pretty good in all axis, but single-engine burns suffer in the yaw axis (and in the dvY component).

The precision of the burn depends on the trim angles, as they factor into the initial vehicle attitude. But as one is unlikely to come up with the EXACT angles that make the OMS point to the c.g., during the burn the engines will produce a torque, requiring them to null the rates and point to the c.g., requiring a slightly different vehicle attitude so the thrust vector points in the desired direction. With "perfect" trim angles, this attitude correction would not be needed, thus residuals would be very small. But with real-life trims, thrust is wasted nulling rates and repointing the vehicle, leading to a less efficient (but now not that bad) burn. Long story short: the trim angles are desirable, but not needed, especially now that they gimbal angles are saved for the next burn.

Still no manual OMS TVC control... I could add more code in the wrong places to have that but IMO it's better to wait.

 

[DaveS]

Late Christmas gift: the OMS TVC should be much better now!
For some reason, yaw control is a royal PITA, but as the 2 other axis are now very good IMO (and I used up all my allocation of OMS burns this year :lol, I'm happy enough to commit it. Dual-engine burns seem pretty good in all axis, but single-engine burns suffer in the yaw axis (and in the dvY component).

The precision of the burn depends on the trim angles, as they factor into the initial vehicle attitude. But as one is unlikely to come up with the EXACT angles that make the OMS point to the c.g., during the burn the engines will produce a torque, requiring them to null the rates and point to the c.g., requiring a slightly different vehicle attitude so the thrust vector points in the desired direction. With "perfect" trim angles, this attitude correction would not be needed, thus residuals would be very small. But with real-life trims, thrust is wasted nulling rates and repointing the vehicle, leading to a less efficient (but now not that bad) burn. Long story short: the trim angles are desirable, but not needed, especially now that they gimbal angles are saved for the next burn.

Still no manual OMS TVC control... I could add more code in the wrong places to have that but IMO it's better to wait.

I just tried the new OMS TVC with STS-109 (long 477 fps dVTOT OMS-2 burn) and it worked very well. No issues at all.

 

[Urwumpe]

Found a bug where ITEM entries in a DISP display are accepted by the underlying OPS display. The fix is not hard to do, but I'm wondering exactly what to do: should an ITEM entry in a DISP be classified "ILLEGAL ENTRY" right at the IDP level, or should the DISP number be passed to the "display generators" same as the SPEC number (and because none of them will take the ITEM we still get the error message)?

A DISP should have by definition no ITEMs to enter. You might mean a SPEC there. DISPs are for display only.

A SPEC or an OPS has a "view controller" (to use modern programming lingo) called "control segment" in the STS context that interacts with the FCOS by grammar macros in HAL/S. All entries go to the only active control segment if I remember the event handling in FCOS correctly. If you press resume to return to the OPS display, the control segment/handler of the OPS display will get called instead of the control segment of the SPEC. I am not sure right now, what a control segment actually is from a GPC perspective. Some semantics I remember look like a single function parsing the event data from the FCOS, but I can not exclude, that some special macros might even result in multiple different functions being active.

Also, this does not happen inside the IDP. The IDP does not know if it is displaying an OPS, SPEC or DISP. It can only react to bad syntax, but not bad semantics.

Sorry if I am a bit more vague than usual, I only have my brain right now, my external HDD with the STS documents is still somewhere deep in my backpack.

 

[GLS]

A DISP should have by definition no ITEMs to enter. You might mean a SPEC there. DISPs are for display only.

No, I really meant what I wrote. Yes a DISP does not have inputs, but you can still type "ITEM 1 EXEC". And if you do, what happens?

A SPEC or an OPS has a "view controller" (to use modern programming lingo) called "control segment" in the STS context that interacts with the FCOS by grammar macros in HAL/S. All entries go to the only active control segment if I remember the event handling in FCOS correctly. If you press resume to return to the OPS display, the control segment/handler of the OPS display will get called instead of the control segment of the SPEC. I am not sure right now, what a control segment actually is from a GPC perspective. Some semantics I remember look like a single function parsing the event data from the FCOS, but I can not exclude, that some special macros might even result in multiple different functions being active.

Also, this does not happen inside the IDP. The IDP does not know if it is displaying an OPS, SPEC or DISP. It can only react to bad syntax, but not bad semantics.

Sorry if I am a bit more vague than usual, I only have my brain right now, my external HDD with the STS documents is still somewhere deep in my backpack.

So "Illegal Entry", triggered from the GPCs, it is (even though we currently have the SPEC and DISP numbers defined in the IDP...)

 

[Urwumpe]

So "Illegal Entry", triggered from the GPCs, it is (even though we currently have the SPEC and DISP numbers defined in the IDP...)

Yes. I suspect this illegal entry comes straight from FCOS and not a single piece of application code has a chance to react. The table of the item entries is loaded from magnetic tape AFAIR.