News The Space Shuttle for Flightgear 3.6

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
We're proud to announce that the next release of Flightgear (3.6) will include a rather detailed simulation of the Space Shuttle. For those interested in multi-platform OpenSource spaceflight in a realistic sim, take a look at what we have:


The NASA Space Shuttle was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents. The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.


shuttle_feature01.jpg

Space Shuttle 'Atlantis' in Flightgear


The Space Shuttle model for Flightgear, released together with version 3.6, aims to re-create this experience by a detailed modeling of all aspects of the spacecraft's operations, ranging from sophisticated aerodynamical modeling to a comprehensive simulation of the Shuttle's systems and the effect of their failures.

The main platform for the aerodynamical, orbital motion and systems simulation is JSBSim, a sophisticated Open Source multi-platform flight dynamics engine which is also used in research and professional applications.

For the 3.6 release, the Shuttle is a beta version - the modeling of aerodynamics, flight controls and systems is in a fairly advanced state, but the visuals (both outside and in-cockpit) and the avionics displays are work in progress.

Download repositories:

Last stable version

Possibly unstable development version

Aerodynamics


Spanning the full range of a rarified atmosphere rushing by at Mach 27 to the dense low atmosphere through which the Shuttle glides at subsonic speeds on final approach, the orbiter probes a huge variety of conditions. Through this range, the aerodynamical properties change drastically. The entry into the atmosphere is flown at a high AoA of 40 degrees, creating a detached shockwave of hot plasma which limits the direct heat transfer to the fuselage, while at lower Mach numbers the AoA is gradually reduced, leading to a more aircraft-like behavior.

While the craft is yaw-stable at subsonic speeds, at supersonic and hypersonic speeds the high AoA places the vertical stabilizer essentially outside the airstream, making the craft dynamically unstable in the yaw axis. Yaw stability in this regime is then purely managed by the flight control systems. For a similar reason, the response of the craft to elevon deflections is non-linear and asymetric at high Mach numbers and high AoA and gradually becomes symmetric only at lower airspeeds.

Aerodynamics is where Flightgear and JSBSim excel - the platform offers the possibility to incorporate a huge amount of available data into the simulation. All aerodynamics used is based on NASA technical documents in public domain - for the nominal regime, in-flight data has been used, for off-nominal situations wind tunnel results both for the mated launch vehicle and the orbiter alone have been utilized.

shuttle_feature02.jpg

Atlantis on approach into Edwards Airforce Base (KEDW)

shuttle_feature07.jpg

During entry, the Shuttle drags a bright plasma trail.

Features of the aerodynamical modeling include:

* full Mach number dependence of all relevant force and moment coefficients
* double or triple differential dependence (Mach number, AoA and elevon deflection) for the major coefficients (e.g. pitch, yaw and roll stability)
* full accounting of the non-linearity of the pitch response to elevon deflection at high Mach numbers
* realistic cross-couplings between the pitch, yaw and roll control channel
* suction effects on the orbiter aft fuselage caused by elevon deflection at high Mach numbers
* Mach-dependent pitching moment caused by speedbrake opening
* realistic trim behaviour - if the weight distribution on entry is off nominal and the orbiter is tail-heavy, the elevons may no longer be sufficient to control the vehicle
* structural stress limit computation based on wing bending moment

Thrust for the Shuttle

From the huge solid rocket boosters (SRBs) used to get the spacecraft off the launch pad to the tiny Vernier thrusters used for attitude hold in orbit, the Shuttle utilizes more than 50 distinct engines, all with their unique characteristics.

The powerful SRBs and the main engines can be gimbaled to provide thrust vector control during ascent. After little more than two minutes, the SRBs are spent and separated, to fall back down to Earth, and the main engines continue for another six minutes to push the Shuttle into orbit, constantly re-adjusting for the change in the center of gravity as the external fuel tank gradually empties.

shuttle_feature03.jpg

A launch from Vandenberg (KVBG) with Southern California seen from about 150.000 ft altitude
shuttle_feature04.jpg

RCS and OMS firing seen from the rear cockpit window of Atlantis.

Once in space, the reaction control system (RCS) becomes the main mode of controlling the Shuttle and the orbital maneuvering system (OMS) engines execute the orbital insertion and de-orbit burns. Due to structural and thermal constraints, the arrangement of the RCS is somewhat awkward, with pronounced cross-coupling between both nominal rotational (yaw, pitch and roll) and translational (x, y, z) firings.

Features of the thruster modeling include:

* realistic modeling of all Shuttle engines with appropriate sea level and vacuum thrust
* full time dependence of the SRB thrust curves
* detailed positioning and orientation of all thrusters, leading to the realistic moments and cross-couplings
* thrust vector control for solid rocket boosters, main engines and orbital maneuvering systems within real gimbal angle range

The flight control system

Bringing a craft with the aerodynamics of a brick which is yaw-unstable safely through the upper atmosphere where the trajectory has to be carefully controlled and managed is no mean feat. Neither is providing seamless control for the pilot from launch under full engine thrust via orbital maneuvering to the final landing. The flight control system (FCS) is the piece of software at the heart of all this.

The Shuttle is controlled by a number of selectable digital autopilots (DAPs), most of which are available in the simulation. These range from special-purpose in-orbit DAPs like the Vernier control which utilizes the weakest thrusters for attitude holding to highly adaptive pieces of software like the Aerojet DAP which is used for atmospheric entry till rollout, which has to cope with the transition from a purely-RCS controlled spacecraft at entry interface to a purely airfoil-controlled subsonic glider. DAPs utilize thrust vector control, RCS thrusters or airfoils to maintain the Shuttle's trajectory at all times. They have to cope with control cross-couplings, instabilities, shifting center of gravity - and yet they make controlling the Shuttle feel easy.

shuttle_feature12.jpg

The RCS can be controlled by many different digital autopilots (DAPs)

shuttle_feature14.jpg

The OMS engines have thrust vector control or can be operated with a wraparound DAP by using the RCS for attitude control.

Features of flight control modeling include:

*about twenty different user-selectable DAPs modeled according to their description in the Shuttle Crew Operations Manual
* a handful of educational DAPs in which the rate controllers are removed, allowing to directly control engine gimbal or airfoil movements - appreciate first-hand what the flight control software has to achieve.
* support for the more exotic DAPs like LOW-Z in which no upward thruster is fired to minimize plume impingement during a docking
* limited support for off-nominal DAPs dealing with gimbal or engine failures

Systems

The Space Shuttle is a complicated piece of hardware, with many different, mutually dependent systems aboard. For normal operations, power is generated by fuel cells which produce water for the environment systems as a by-product. To meet the higher power demands during launch and entry, three auxiliary power units (APUs) provide hydraulic pressure to actualize main engine valves and move airfoils and engine gimbal mounts. Several different cooling systems, among them water spray boilers, flash evaporators or the freon radiator loops, take care of the excess heat generated by the operation of these systems.

Crucial for orbital operations, the RCS and OMS use hypergolic propellants which are driven from the tanks by helium pressure. A complicated chain of valves allows to isolate parts of the system in case of leakage or to set up cross-feeding from one system to the other. In preparation for entry, part of this fuel may have to be dumped to move the center of gravity of the vehicle to a suitable value.

shuttle_feature08.jpg

Payload bay door opened after the orbital insertion burn is completed.

shuttle_feature09.jpg

Main propulsion system fuel dump after main engine cutoff.

The Shuttle does not simply drift after reaching orbit, there are many other procedures to be followed - for instance leftover fuel needs to be dumped after main engine cutoff, propellant feedlines need to be vacuum inerted, the radiator need to be deployed, heaters for the RCS and OMS thrusters need to be activated. Many of these are part of the systems modeling of the Flightgear Space Shuttle.

Features of systems modeling include:

* detailed modeling of the APUs and hydraulic pumps including their effects on airfoils, brakes or engines in case of failures - switch off two of the three hydraulics systems during atmospheric flight and watch the Shuttle use priority rate limiting to assign the remaining power as efficiently as possible to the airfoils.
* detailed modeling of the main engine, RCS and OMS propellant feed chains - create a helium leak and watch the tanks empty for a while by the remaining blowdown pressure before the contents become inaccessible, then use the crossfeed valves to restore functionality
* modeling of some mechanical systems - realistic procedures for closing external tank umbilical doors and for deploying the payload bay door
* simple model of electrical power generation and fuel cell operation

The physics environment of space

The low orbit environment the Space Shuttle moves in would by most people be characterized by the lack of gravity and an atmosphere. Yet this is not entirely correct - technically the orbiter is moving in a microgravity environment. The small tidal forces by the gravity difference between Earth-facing and sky-facing side still tug at the vessel, and so does the residual trace atmosphere.

The lack of an atmosphere also makes the thermal environment quite interesting - since convection can no longer carry heat away, all surfaces come into radiative thermal equilibrium, implying pronounced differences between sunward surfaces which may heat up to 350 K and dark surfaces which may cool down to 150 K. Both orbiter attitude and active thermal management systems, including the freon loop radiator and heating elements for thrusters and fuel lines are used to keep the vehicle functioning in this environment.

Features of physics modeling include:

* differential gravity simulation, leading to small attitude drifts of the Shuttle over time
* modeling of the orbiter heat balance, including radiative flux from Sun and Earth corrected for surface albedo, internal heat sources (avionics bays, APUs,..) and sinks (flash evaporator and radiator system, water spray boilers,...) and heat conduction between elements
* detailed model of the freon colling loop functionality - try a cold-soak maneuver by pointing the tail of the Shuttle sunward to reduce freon temperature to provide an extra 10 minutes of cooling time during entry, or watch the heat buildup caused by the APUs.
* thermal effects on equipment - payload bay door may jam due to thermal stresses, overheated APUs will die,...
* accounting for small residual forces, e.g. exhaust vents
* dedicated OpenGL shader effects accounting for the hard lighting in space and the transition to soft lighting in the atmosphere

Limits

While the sky is not the limit for the Space Shuttle, other things are. Have you ever wondered why the Space Shuttle is operated a certain way? For instance why the main engines need to be throttled back about 30 seconds after liftoff? Why a high AoA need to be maintained in the early, hot phase of atmospheric entry?

The simulation takes into account a large number of known structural and thermal limits of the Space Shuttle, from the wing bending moment upon ascent (which requires the craft to be flown into orbit in a heads-down attitude) to the vertical speed upon final touchdown. The violation of any limit can optionally be just called out, or can cause damage to the systems or aerodynamics of the vehicle.

shuttle_feature16.jpg

The result of a hard touchdown - gear strut broken, tire blown and the Shuttle off the runway due to the asymmetric braking forces.

Limit checks include:


* aerodynamical limits - dynamical pressure and wing bending moment
* structural limits - gear strut compression, g-forces during ascent and entry, tire rolling speed
* thermal limits on the heat shield and on equipment

Failure and redundancy modeling

Many of the procedures aboard the Space Shuttle are concerned with failure management and utilizing the redundancy of systems. The whole simulation of the Shuttle in Flightgear has been designed with that in mind - practically every single component in the model can be failed, with whole chains of failures generated throughout the rest of the systems.

For instance, watch a water spray boiler fail - this will lead to an overheating APU. Is this is not shut down in time, it will fail, causing a hydraulics system failure. This in turn will cause priority rate limiting for the airfoil movements as well as possibly reduce braking force on the runway and/or disable nose wheel steering. Lack of steering may lead the orbiter off the runway, causing a burst tire.

shuttle_feature13.jpg

Single engine failure during ascent.

The simulation contains several such failure scenarios to train the appropriate response. You may have to fly a Transatlantic Abort Landing in response to an engine failure, you may have to perform a manual engine shutdown in case of engine lockup or gimbal failure, you may have to de-orbit before running out of cooling water if you can't get any of the two freon radiator loops to work or you may have to set up a crossfeed for a leaky RCS tank - any of these is supported.

Features of failure modeling include:

* a number of pre-defined optional failure scenarios
* ability to fail 'by hand' almost any component (e.g. from an instructor station)
* realistic simulation of the Shuttle's redundancy management
* support for failure management procedures like cross-feeding or alternative cooling systems

The Flightgear environment

While Flightgear is not by nature a spaceflight simulation and has to be supplemented by a different rendering engine for orbital visuals, as a simulation platform it offers a number of distinct advantages in the lower atmosphere.

There are literally hundreds of well modeled airports which might be utilized as an alternative or emergency landing site for the Shuttle across the world. Elevation data for the world in the default FG engine is very precise, providing stunning visuals of mountain chains from up to 100 kilometers altitude.

In addition, Flightgear comes with a complete weather engine, capable of producing a large range of weather situations from fine weather to multiple overcast layers of rain clouds and fully interacting with the scene lighting and rendering model - clouds change to dramatic sunset colors, cloud shadows fall across the terrain, rain changes terrain reflectivity, wind changes ocean wave patterns. All this leads to rather compelling visuals during the first launch minutes and the final approach.

And, of course, Flightgear is OpenSource and GPL compatible - you can freely use anything for your own projects, and it's a piece of code made to tinker with: Customizations and modifications are easy, many changes to not even require coding skills but can be done by modifying xml files.

shuttle_feature05.jpg

SRB separation seen from high over southern California.

shuttle_feature06.jpg

An early morning launch through broken cloud cover.

Features of Flightgear as simulation platform include:

* full weather model - you can set up complicated windshear and crosswind scenarios for the final approach, try to launch in rain or explore how the Shuttle interacts with turbulences in a thunderstorm
* hundreds of well-modeled airports - watch a busy airport as the Space Shuttle does an emergency landing e.g. in Hawaii
* multiple rendering engines - use the default terrain for low altitude visuals and EarthView for orbital visuals, or use the OSGEarth version of Flightgear which renders photoscenery using aerial image databases
* multi-platform (Windows, Linux, MacOS,....) and OpenSource code made to be accessible for modifications at all levels

The future


The Flightgear Shuttle is very much a work in development. The plan for the near future is to make the 3d cockpit fully functional and include a fair share of the original avionics and to do some additional work on the exterior of the craft. At the same time, additions to the Flightgear core code should allow the simulation of the interaction with other orbiting objects so that the Shuttle can perform docking operations or capture satellites.

A somewhat more ambitious plan is to add an optional simulation of real navigation errors - in order to get a good state vector for the vehicle, procedures such as star tracking to calibrate the inertial measurement units would then need to be executed.

In any case, FG development is going to stay in low orbit!

shuttle_feature15.jpg

Edwards AFB (KEDW) seen from the Shuttle cockpit

shuttle_feature17.jpg

Touchdown in Vandenberg, deploying the drag chute.
 
Last edited:

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
Seems like an interesting and ambitious project.

I can see where Flightgear has big advantages in modeling the atmospheric/aerodynamic side of things.

However, I seem to recall that the earth does not actually rotate in Flightgear. Is this going to be fixed? What are Flightgear's limitations regarding spaceflight?

Also, will the Flightgear shuttle be able to carry payload? Will it be able to release satellites into orbit?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
However, I seem to recall that the earth does not actually rotate in Flightgear.

I can't say whether that's always been the case, but it sure does now. As far as I understand, JSBSim internally computes in an internal Earth-centered inertial system before transforming into a co-rotating system - you get the expected penalties for a westward launch for instance, and the groundtracks of orbiting objects are as expected.

What are Flightgear's limitations regarding spaceflight?

I think the honest answer is that we don't quite know. JSBSim has been benchmark-tested against commercial orbital-simulation tools and gets the expected decay of orbits over several days, so we're reasonable certain LEO is fine.

Using an Earth-centered coordinate system may be less optimal for going to the Moon or even further - I'm not sure if double precision coordinate accuracy is sufficient and when long double precision would be needed. Also, it's not clear how accurate the numerics deals with very accelerated fast-forward, compressing e.g. months of flight time into minutes.

I'm not sure that's where the community wants to go - the Shuttle is particularly interesting from a piloting perspective, other spacecraft are less so.

Also, will the Flightgear shuttle be able to carry payload? Will it be able to release satellites into orbit?

In a way, we have the proof of concept of that with the ET - which co-orbits with the Shuttle after separation under the control of a simple equation of motion solver. Right now a payload can be added only as additional weight influencing CoG and mass - but the plan is definitely to make the RMS arm work and use it to release a satellite.
 

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
Let me see if I have this right.

It is the flight model (JSBSim), that transforms into a rotating system. The rotation is not a property of the Flightgear environment itself per se.

Do all craft in Flightgear use JSBSim?

If not, would that mean that placing other aircraft in orbit would not get the same rotational behavior?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
We're getting into architectural questions here, but:

The actual Flightgear code is something like a container that calls a flight dynamics model module (FDM) for the state changes of the simulated craft and calls the Simgear module for an environment simulation and the rendering backend. It's a fairly modularized design - you can view FG scenery without an airplane using the FGViewer backend, you can feed the flight dynamics via network from your own simulation environment (matlab is most popular - many researchers use it that way) and use FG to visualize your results, you can run flight dynamics outside the FG main loop to create standardized test and benchmark environments, you can use Simgear for any environment sim (someone has used it to provide a dynamical skybox for a roleplaying game, someone else to visualize giant 3d molecules,...)

In particular, the FDMs currently supported are JSBSim, YaSim and UIUC, with some legacy code for things like LARCSim.

So Flightgear as such (i.e. without an FDM) doesn't know what an airplane is or how it flies or in fact any physics - it gets coordinate updates from the FDM module and just manages them - by providing the interfaces to the controls for instance, or by handing the eye point to the rendering backend.

You can as well do a fictional FDM using your own physics - we have Santa and his Reindeer as a Christmas Egg in the repository.

Do all craft in Flightgear use JSBSim?

No, but the more serious ones usually do.

If not, would that mean that placing other aircraft in orbit would not get the same rotational behavior?

Not in general, no. You get what the FDM provides - JSBSim is the tool for realistic physics simulations and serious applications, YaSim is for quick successes in airplane modeling if you're fine with something plausible, fictional FDMs are for things like Santa, Ufos or Colonial Vipers,... It's not a monolithic design with unique properties, it's rather a collection of modules.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Also, will the Flightgear shuttle be able to carry payload? Will it be able to release satellites into orbit?

Since you asked - that's today's state:

shuttle_TDRS02.jpg



The RMS arm deployment sequence and single joint driving is modeled and one can attach a 3d model to the end effector and move it around. Releasing it into orbit is just a matter of handing it to the orbit equation of motion solver. The solver could also take accelerations into account, i.e. the payload could be commanded to ignite a thruster. I guess you see the picture...
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
The devel repos are on SourceForge - and that has been down all week. As of today, SVN services still seem to be unavailable (stable version), but the GIT repo for the devel version seems accessible again, although the direct tarball seems still messed up.

Sorry about that, but SourceForge's hardware problems are beyond my capability to fix.
 

garyw

O-F Administrator
Administrator
Moderator
Addon Developer
Tutorial Publisher
Joined
May 14, 2008
Messages
10,485
Reaction score
209
Points
138
Location
Kent
Website
blog.gdwnet.com
Single engine failure during ascent is an option?
Interesting to try out a TAL or even a RTLS in that :)
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Single engine failure during ascent is an option?
Interesting to try out a TAL or even a RTLS in that

I've done one half-hearted two-engine TAL test, aiming for Zaragoza. Back then the guidance (especially ballistic impact point prediction) wasn't done yet, so I found myself guesstimating the correct azimuth to site, which didn't work exceedingly well - I got the range management okay, but missed laterally by a thousand kilometers. Needless to say, this prompted me to improve the guidance.

But it all works in principle - the PID control logic needs a few seconds to realize it needs to adjust to the loss of an engine (especially if you lose left or right, that's awkward for roll control) and the stabilizes again, and there's good control over the vehicle again. I've also tested that the ascent DAP can hold one engine out, one in lockup.

Two engines down would be tougher, but is in the making - this needs a wraparound DAP in which the roll control is provided by RCS (probably gives you really poor turning rates, trying to yank the ET around...)

Theoretically there should even be limits for the ET heat load implemented if you have poor trajectory control and get too low during RTLS - I haven't flown this in practice though.

Unfortunately, I've come to realize that time spent developing is not time spent flying - there's much I still would like to try. Eventually... :-/

---------- Post added at 06:01 PM ---------- Previous post was at 02:54 PM ----------

Some eight hours coding on the RMS in total, and it basically performs as hoped for (demo rigged together while the collaborators work on proper satellite foldup and animations):

payload_ops02.jpg


payload_ops03.jpg


payload_ops04.jpg


payload_ops05.jpg


payload_ops06.jpg


payload_ops07.jpg


payload_ops08.jpg


payload_ops09.jpg


Upon reflection, I should have used the LOW-Z DAP to push away from the satellite, it's probably not very good to fry it with my RCS exhaust plumes...

The devil is in the nitty-gritty stuff to come - computing the CoG shifts as the payload dangles on the arm might be interesting.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Since garyw mentioned the TAL, this is now doable with the instrumentation provided in the devel version (= will then be shipped with FG 3.8 rather than 3.6).

Single-engine failure 210 seconds into the flight, decision to abort to Banjul, a few minutes of trajectory management necessary to reach the desired course and vertical speed without dropping below 270.000 ft:

shuttle_TAL01.jpg


Hectic three minutes of freefall disconnecting the ET, closing umbilical doors, then dumping the fuel from the propellant lines, dumping OMS fuel, configuring software for entry, bringing the Shuttle to entry attitude and getting ready for g-load:

shuttle_TAL02.jpg


Nearly captured the target entry trajectory (that's the rough version of the actual ENTRY TRAJ 4 display - it currently lacks the visuals and extra alphanumerics, but functions like the real thing).

shuttle_TAL04.jpg


Reaching the coast of Africa, slightly high on energy at TAEM interface, nothing some liberally applied speedbrake can't fix in this regime.

shuttle_TAL05.jpg


I have to say, it's pretty instructive, and after having tried it, several remarks in the Shuttle crew manual make a lot more sense.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Thanks for the pointer. Judging from how the notion of converting free airplanes from e.g. FSX has worked out, it's unfortunately probably not really useful.

The detailed implementations of flight dynamics and systems are very different - in FG, an airplane definition never contains any compiled/compilable code, while I understand Orbiter ships dlls (?) for spacecraft if needed. So things can't ever ported 1:1, they'd need to be ported on algorithmical level and brought into a very different format.

Also, the platforms are rather different. I spend lots of time coding spatiotemporal helpers which I imagine are trivially supported in Orbiter ('compute the intersection point of this orbit with the surface of Earth' for instance) - on the other hand, I can trivially call up very sophisticated navigation helpers (we have a neat radio propagation model for TACAN for instance).

What is generally most useful is basic data (aerodynamics, systems descriptions) - but in this particular case NASA is very generous and there's no shortage of photographs of the Shuttle cockpit, systems descriptions or wind-tunnel / in-situ data - there's literally thousands of pages available.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Also, the platforms are rather different. I spend lots of time coding spatiotemporal helpers which I imagine are trivially supported in Orbiter ('compute the intersection point of this orbit with the surface of Earth' for instance) - on the other hand, I can trivially call up very sophisticated navigation helpers (we have a neat radio propagation model for TACAN for instance).

The problem is pretty much the same for Orbiter. Most of the navigation has to be implemented by the add-on, including radio propagation models. But we have more functions for accessing orbital parameters.
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Work on the avionics has started in earnest - reference for the layout and functionality of the screens is the Data Processing System Dictionary. The screens show the original combination of the edgekey-controlled MEDS display frame and the keyboard-controlled DPS screen layout characteristic for the late Shuttle fleet.

The simulation includes the interaction with the DPS by typing multi-key command strings on the keyboard, i.e. the parser 'speaks Shuttle'.

Automatic maneuver and pointing routines are also being added (personally I think all the joy is in writing them - using them is rather boring and takes away the joy of piloting, but then I come from a flightsim community...).

Here's and example of a PEG-7 target specified in Major Mode 104 and calculated to a 33 second two engine burn (all items which are currently not supported are marked with an X):

shuttle_DPS_MNVR01.jpg


And here's the resulting burn under automatic guidance using OMS thrust vector control to hold attitude:

shuttle_OMSburn.jpg
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
785
Reaction score
56
Points
43
Dear Orbiter Shuttle pilots - are you up for a challenge? I got the idea while testing various failure modes and how they're visible on the avionics displays and I think it's worth posting (all you need is some familiarity with the GNC SYS SUMM 2 display of the Space Shuttle and the sections 2.18 (OMS) and 2.22 (RCS) of the crew manual (or equivalent knowledge).

The following five screens show each an off-nominal condition. The relevant fault message has been cleared already from the fault line (otherwise it'd be easy). Can you spot what's wrong (first series of hints after the screenshots)?



shuttle_gnc_failure01.jpg


shuttle_gnc_failure02.jpg


shuttle_gnc_failure03.jpg


shuttle_gnc_failure04.jpg


shuttle_gnc_failure05.jpg






Hint: The failure conditions are (not in order shown)

a) a nitrogen leak in the OMS
b) both He-valves closed for an RCS pod
c) an OMS engine burning inefficient (subtle one)
d) an RCS thruster failure with manifold closed off (easy)
e) a helium leak in the RCS with thrusters running on blowdown pressure
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
hint/picture number:
a/4
b/2
c/1
d/5
e/3
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
hint/picture number:
a/4
b/2
c/1
d/5
e/3

He should have written: "SSU developers are required to answer by PM. Give the others a chance." :rofl:
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
He should have written: "SSU developers are required to answer by PM. Give the others a chance." :rofl:

You're right. My fail :facepalm: sorry
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
You're right. My fail :facepalm: sorry

Well, I am not sure if c is really that subtle - such a high pressure drop between injector and tank pressure for both fuel and oxidizer rather suggests a catastrophic failure of the injector milliseconds away from LOCV or at least one the combined fuel/oxidizer valves not opening correctly, despite the 100% indication.

Just an inefficient burn would mean diverging FU/OX IN values.
 
Top