Space Shuttle Ultra development thread

[SiameseCat]

GLS: I can connect the discsignals, but I'd prefer to get the next release out soon, then work on converting all the old panels (including PanelR2) to use the new framework. Do you need this done now or can it wait?

 

[GLS]

GLS: I can connect the discsignals, but I'd prefer to get the next release out soon, then work on converting all the old panels (including PanelR2) to use the new framework. Do you need this done now or can it wait?

It can wait... thanks SiameseCat!

 

[SiameseCat]

I've added the FSS GH2 Vent Arm animation code. The arm falls straight down at T0.

 

[DaveS]

Seems like the second stage(MM103) ascent AP has died again. Just getting jibberish data and no action from the AP once the SRBs have separated.

Verified this behaviour twice, so it isn't intermittent. It's a solid appearance.

 

[SiameseCat]

Just tested the autopilot (using the STS-120 T-9 scenario) and it worked fine.

 

[DaveS]

Just tested the autopilot (using the STS-120 T-9 scenario) and it worked fine.

Weired. Worked this time. Must have been a glitch or something. Something that do needs work on is attitude control during OMS burns. The usage of RCS thrusters during the burns nominally is not correct. Nominal attitude control is by gimballing the OMS engines.

The RCS thrusters only come into play if the OMS engines can't null the rates on their own and this is called "RCS Wraparound".

And something else needed is a way to calculate OMS burn targets(TIGs and DV targets).

 

[Orbinaut Pete]

MERRY CHRISTMAS SSU TEAM, great work & good luck for 2009

 

[SiameseCat]

DaveS: I'll work on the OMS gimballing. One question: what is the purpose of the TRIM LOAD Items on the MNVR display? Is it just the initial gimbal position of the engines at the start of the burn, or does it represent the position at which the engines will not produce any torque?

 

[DaveS]

DaveS: I'll work on the OMS gimballing. One question: what is the purpose of the TRIM LOAD Items on the MNVR display? Is it just the initial gimbal position of the engines at the start of the burn, or does it represent the position at which the engines will not produce any torque?

Hmmm, not sure. But I believe it's the DAP-computed settings at which the OMS gimbal angles goes through the c.g at burn time. Throughout the burn the OMS engines will gimbal to null the attitude rates as the position of the c.g changes.

 

[Donamy]

I was thinking of changing the RMS elbow camera, to match the newer ones done by Daves, but the animations would have to be updated. I believe this would be for SiameseCat to play with, if you are willing. If not, no big deal.

 

[Urwumpe]

Hmmm, not sure. But I believe it's the DAP-computed settings at which the OMS gimbal angles goes through the c.g at burn time. Throughout the burn the OMS engines will gimbal to null the attitude rates as the position of the c.g changes.

Just for dropping my understanding of the trim values into the thread: They seem to be the initialization values for the control loops. If these values are not correct, you will get a number of control problems. one of them being the risk of overloading control loops and possibly emergency cut-offs. Your spacecraft will not be under complete control.

 

[Donamy]

Seems there is a problem with the RMS elbow camera anyway. When it is in the stowed position, the rotation points are not carried with it.

 

[SiameseCat]

Another odd thing about the trim values is that, for a two-engine burn, the standard yaw trim values are +/- 5.7 for each engine. However, the engine's null position is offset about 6.75 degrees in the yaw axis. This means that some thrust is wasted.

 

[C3PO]

Another odd thing about the trim values is that, for a two-engine burn, the standard yaw trim values are +/- 5.7 for each engine. However, the engine's null position is offset about 6.75 degrees in the yaw axis. This means that some thrust is wasted.

That makes sense. That means that the standard offset is 1.05°, which translates to 0.0168% 'wasted' thrust.

 

[SiameseCat]

The OMS engines can gimbal up to 7 degrees in yaw, so I'm not sure what the point is in wasting even a small amount of the thrust. As far as I can tell, the offset shouldn't improve control in any way.

 

[Urwumpe]

The OMS engines can gimbal up to 7 degrees in yaw, so I'm not sure what the point is in wasting even a small amount of the thrust. As far as I can tell, the offset shouldn't improve control in any way.

Not when the two engines are intact. But when one of them cuts off or you need to shut it down, these trim angles ensure only little torques to be compensated by the remaining OMS engine

 

[DaveS]

Checked in a new SSUBay.dds texture with the following alterations made:

-New bay liner texture with new and accurate bay vent positions
-New radiator panel textures, based on a photo of the rad panels during PLBD closure for STS-90 in the OPF and some photos over the aft rad panels from ISS Destiny Lab.
-New forward and aft bulkhead textures with the aft bulkhead having a new fresher US Flag swiped and enhanced from a STS-125 OPF PLB processing photo.

 

[kwan3217]

Checked in some changes to RSLS. Most visible is the hardstand mesh is now used by the LC39A vessel and there is a visible "twang" (bending of the stack) just before launch.

The twang is implemented by moving the attachment point on the MLP, therefore the twang is only visible when the shuttle is attached to an MLP.

I have included a new scenario with everything set up at about T-31 seconds to test this, called "RSLS test".

I made some changes to my copy of Canaveral.cfg because my graphics card isn't big enough to support all the textures for the TAL sites. I may have also cleared off pad 39A so that there is room for the vessel version of it. I haven't checked in my copy of the config files.

Let me know what you all think, or if I missed something.

 

[Donamy]

Nice, I'll try it when I can get the .dlls from DaveS.

 

[DaveS]

Checked in some changes to RSLS. Most visible is the hardstand mesh is now used by the LC39A vessel and there is a visible "twang" (bending of the stack) just before launch.

The twang is implemented by moving the attachment point on the MLP, therefore the twang is only visible when the shuttle is attached to an MLP.

Looks very nice! Is there any way you could stabilize the MLP while the SSMEs are thrusting? Currently the MLP+stack begins to move northward when the SSMEs are thrusting.

Also, you might want to add in the water tower mesh to module.


-----Post Added-----


And a better way to demonstrate the "twang" is to implement a proper T-10 to T0 behaviour of the RSLS(which is Redundant Set Launch Sequencer, not Redundant Sequencer Launch Sequencer) and GLS which is to cut-off the main engines if something is not right and is violating preset criteria.

This leads to alot of "twangs", rocking back and forth for a while until the motion has subsided. Just a tree-second long firing of the SSMEs produces a "twang" motion that lasts for over 5 minutes.

Also started in the event of an RSLS abort is a set of water deluge nozzles used to cool down the aft and disperse any free hydrogen to avoid what they saw following the first RSLS abort in the program, STS-41D where they experienced small hydrogen fires between the ET/Orbiter umbilical disconnects damaging several tiles that had to be swapped out on the pad before a new attempt could be tried.

For the STS-41D RSLS abort they managed to use some of the sound suppression water to extinguish the fires before it got out of hand.