News The Space Shuttle for Flightgear 3.6

[Thorsten]

Some nice weather during bailout-tests. The Shuttle has now the AP channel to hold her steady and slow during crew bailout if no runway can be reached - which is why we're just heading down into the sea here.

 

[Thorsten]

Looking a bit into rendering night launches, I realized I had the solution to a cool effect right at my fingertips - here's the SRB flame lighting up the cloud layer in a radius of a few miles:

 

[Thorsten]

I suspect the following is really for fans of the Space Shuttle avionics and all its intricacies. I've now as good as completed the MEDS layer (as much as this is possible - you can't patch files or command memory dumps, because it doesn't run internally on the historical MEDS code, so these operations make no sense in the context of the sim, but you can do pretty much everything else).

The MEDS menu shows now primary, secondary and selected port for every MDU, as well as flight-critical bus and port reconfiguration mode. In addition, the self-diagnostics checks for MEDS failures and fills the MEDS fault line with them if it detects any.

That means there can now be two faults flashing on one screen, one to be acknowledged by keyboard, the other via edgekey. MEDS faults are always a property of one IDP, so there's four lists of them being maintained, and the message gets bumped to a DPS screen under the command of the current IDP.

The maintenance display shows the current configuration for the active IDP

all items under the command of the IDP shown in blue, all items the IDP can listen to (because it's connected via the non-active port) show data, all else is blanked. Failed self-tests or equipment that doesn't communicate is shown in red. Using the config option allows to change ports on the current MDU or to change reconfiguration mode.

Finally, it's possible to access the fault summary page where all the faults the current IDP has detected are displayed.

I haven't come across any place that has a comprehensive list of faults/warnings which are detected and announced, so right now it knows just two categories (I/O ERROR and PORT CHANGE) for a specific device. If anyone knows where to find that info, please let me know.

It's clearly not something the casual user will ever need... but it's nice to have in the simulation for those who are interested i dealing with more exotic failures (broken ADC, problem on a flight-critical data bus,...)

 

[Thorsten]

More avionics fine-print - the system now responds correctly to failures of data transmission.

If the IDP can't get in touch with a GPC running the required software, it crosses out the DPS part of the screen and throws a poll error. It's possible to intentionally isolate an IDP by assigning GPC 0 via the keypads.

If the commanding IDP of an MDU goes non-operational, the MDU proudly proclaims its independence:

If no automatic reconfiguration is set, you can then change ports manually and get back to a working IDP, if this is set to AUTO, it happens on its own but leaves a MEDS message about the port change in the system.

(If an MDU fails or the main power bus it connectes with goes below operating voltage, it simply blanks)

 

[Thorsten]

Getting the interior lights installed...

Wayne has been busy putting the 3d model into a raytracer to render the direct and indirect illumination from every cockpit light into lightmaps which we're now bringing into the cockpit rendering scheme. Using a raytracer for the job just gives an accuracy that no real-time technique can hope to match.

 

[Thorsten]

Hey Thorsten,are you able to see the reentry plasma from the cockpit windows?

Well, now you do... Some first tests rendering the plasma sheath from within - this is a night scene for better contrast.

Onset of plasma builtup:

Max heating phase:

There's movement and structure to this which looks quite compelling (it runs via a dedicated GLSL shader), the light has a pulsating quality to it (and the alert observer might have spotted that the cockpit ambient light is influenced by the plasma glow).

 

[Donamy]

You should be able to see the interior with a orange glow. IMO

 

[Interceptor]

Here you go Thorsten,you have probably seen this video already,but if not check it out it should give you an idea about the colors of the reentry plasma from the cockpit windows of the shuttle.

 

[Thorsten]

You should be able to see the interior with a orange glow.

I suspect you may be overestimating the intensity of the light emission - the plasma isn't all that bright (the illumination is there when compared with a pure night shot, but not all that prominent).

The section 'sensory cues' of the crew manual has:

During the night portion of an entry, the glowing plasma sheath around the vehicle can
be observed through the orbiter windows. The pulsing light has not interfered with tasks
inside the vehicle. The plasma glow is less visible during daylight portions of entry and
may not be noticeable.

(emphasis by myself).

You can go through the physical intensity numbers of daylight sky at high altitude and ambient lit surfaces in daylight (Wikipedia has a few numbers, I've done my own tables with a series of controlled photographs to get my rendering framework onto solid grounds), you can ask what emission intensity is barely/not visible under these conditions, you translate that from physical intensity into perception space for rendering, and you get brightness value approximations from that statement.

Also, I've worked some time in plasma physics labs (MPI Garching and JET Culham) when I was a bit younger, and I've seen plasma discharges live, so I think I have a reasonable idea of how they look like.

Here you go Thorsten,you have probably seen this video already,but if not check it out it should give you an idea about the colors of the reentry plasma from the cockpit windows of the shuttle.

I'm afraid as far as color references are concerned, the video is unusable. You can easily see that it's overexposed to capture the rather dark cockpit visuals (you can already see the glow sticks de-saturate).

I frequently seem to get into these discussion, but in low light the perception of eye and camera is completely different and even high-quality still photographs often do not convey the right impression. One has to take care to select reference material where the exposure time is known/can be inferred, one has to translate the visuals into what the eye would see under the current lighting conditions,...

The current colors/intensities are based on a) my own experience seeing the glow of various plasmas b) a handfull of still photographs from the Shuttle cockpit where the exposure time can be inferred c) some images from the NASA mission simulator

I'm not claiming I'm doing it correctly 'as is', but there's a lot of experience in light and perception modeling behind these visuals as well as a decent amount of research, so if you believe they're off, I'd like to see a solid case.

 

[Interceptor]

No,you seem to be misunderstanding me,I am not questioning your judgement,I was just trying to help.

 

[Thorsten]

That's appreciated of course

In any case, I feel it can't hurt to explain why I do something a certain way, just as it can't hurt to challenge that. How else do we learn anything?

 

[Interceptor]

Looking foward to future updates,great job.:thumbup:

 

[Thorsten]

PDRS control joins the SM DPS pages:

The operator commanded AUTO mode is actually functional, you can simply enter a target and the RMS arm will move there (or run into software stop on the way if it's not inhibited). There's also a simple reach limit test available.

The complete automatic modes are not done yet, but a fairly trivial extension - just need a script to push one point after the next (admittedly I don't have any use case yet...).

In case I never mentioned it before - I really really hate the trigonometry underlying the RMS arm movement control - it's so easy to make a mistake which screws everything...

 

[Thorsten]

Wayne has done it - the rear flight deck mesh is in.

Lots of work ahead with texturing and making it functional, but one big step is taken.

 

[Thorsten]

I've spent some time with the cabin environment simulation, and I would like to pose a question to the community.

So far, the system simulates the valves of the oxygen and nitrogen system and uses O2 and N2 partial pressure data to decide upon oxygen/nitrogen flow if the O2/N2 manifold valves are in auto, otherwise just feed oxygen or nitrogen to hold the pressure.

If the sim is confronted with a leak, the controllers first up the flow rates to hold pressure. If there's more than ~6 lb/h loss, the increased flows trigger the CWS. The controllers up the flow to as much as 75 lb/h to keep pressure, then it drops from 14.7 psi, at 8 psi the emergency oxygen feed opens and adds another 75 lb/h (at which point overall reserves deplete pretty quickly). For a loss of more than 150 lb/h, the cabin will eventually depressurize (which also happens if you're dumb enough to open the vent valves in space).

My question is - what then?

What would you expect from a sim if the cabin de-pressurizes beyond alarms going off all over the place and the ambient sounds gradually fading out? I guess in theory the crew could slip into space suits and continue to operate for a while - but the urgency of the real situation wouldn't really be felt in the sim.

Does any Orbiter craft simulate that situation?

 

[Urwumpe]

My question is - what then?

What would you expect from a sim if the cabin de-pressurizes beyond alarms going off all over the place and the ambient sounds gradually fading out? I guess in theory the crew could slip into space suits and continue to operate for a while - but the urgency of the real situation wouldn't really be felt in the sim.

If the crew has the time for that and can get suited up and connected to the Orbiters oxygen system in that time, the backup oxygen of the ACES suits is limited to only 10 Minutes. AFAIR, there is an emergency procedure in the FDF that describes exactly that scenario and how to behave if there is enough time. If you are fast enough, you can let the cabin depressurize and limit the Orbiters oxygen to the ACES.

See here for some details about the ACES and proposed modifications for Orion:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20140010572.pdf

Does any Orbiter craft simulate that situation?

Not that I know. Some simulate life-support in a "alive or dead" style, but not as a gradual degradation of performance and health.

 

[Ripley]

...Not that I know. Some simulate life-support in a "alive or dead" style, but not as a gradual degradation of performance and health.

IIRC, Dansteph's DGIV has some sort of health degradation.
My poor XR Fleet astronauts have died several time of hypoxia too.

 

[Thorsten]

See here for some details about the ACES and proposed modifications for Orion:

Made for some interesting read, thanks...

Essentially that'd mean adding a simple suit simulation... perhaps add a 'helmet from inside' frame to the rendering camera, change the sound environment to hear your own breathing... Something like that.

 

[Thorsten]

Environment system is now hooked up to the avionics - most importantly DISP 66.

For those who enjoy the technicalities - the display as posted shows the effect of vent isolation and vent valve opened in orbit - large negative pressure change, cabin pressure dropped to 11.6 psi already, oxygen partial pressures dropping in sync.

N2/O2 valve is set to full oxygen to get partial pressure up, the system is injecting 75 lb/h into the cabin to stabilize partial pressure (but the vent valve is much faster of course). Keeping this up, one could stabilize cabin pressure at 10.2 psi in preparation for a scheduled EVA (I was surprised to read that this can't be done automatically - the atmosphere really needs to be managed manually for this - though in reality the airlock valves would be used to decrease pressure rather than the vent valves.

Incidentially - that's now screen number 40 of the avionics that's implemented (MEDS and DPS pages taken together that is).

 

[Thorsten]

Managed to beat the PDRS automatic sequences int submission. Now you can i-load any set of points and have the RMS arm go through them automatically.

If I were to nominate any subsystem of the Space Shuttle for most annoying to code, I think the whole RMS arm code would score pretty high...