The Space Shuttle

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.

Space Shuttle Atlantis in Flightgear The 3d cockpit of Atlantis

The Space Shuttle model for Flightgear, first 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. It is by now one of the most advanced simulations in Flightgear and likely one of the most realistic representations of the Space Shuttle available.

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.


Last stable version      Possibly unstable development version

Flight Manual:

The official Flight Manual (Standard Edition) is available from the bookstore, a Deluxe Edition with more information is in preparation!

See also:

An informal development log


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.

Atlantis on approach into Edwards Airforce Base (KEDW). 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


The Shuttle flightdeck is densely packed with screens, controls and switches and allows to monitor hundreds of parameters. Many of these are animated and fully functional in the simulation such that practically all major tasks can be performed by utilizing 3d cockpit controls.

The cockpit also has a fairly detailed lighting model in which all available lights with their brightness controls are simulated, in addition to an ambient lighting model that takes into accound instrument backlighting and external light sources such as the glow of the plasma during entry to determine the residual light in the cockpit.

The forward panels of the Shuttle flightdeck. Details of the panels.

Features of the 3d cockpit include:

  • detailed 3d mesh of the forward panels
  • optional detailed 3d mesh of the complete flightdeck
  • 12 different direct lights rendered in raytracing quality
  • close to a hundred functional switches, buttons and other clickspots


The Space Shuttle has quite a complex avionics system, with an older layer, the data processing system (DPS) dating back to the time before a glass cockpit was installed, and a newer layer, the multi-function electronic display system (MEDS) having been installed later.

This structure, along with its quirks, error messages and pitfalls, has been faithfully implemented in the simulation, Over 40 pages allow to access systems ranging from basic flight control and attitude over RCS jet management to the details of the temperature distribution in the hydraulics systems. By using the cockpit keyboards, commands can be issued to both systems management and guidance and control systems, allowing to control the Shuttle just as it is in reality.

The simulation 'speaks Shuttle', i.e. you need to learn commands like ITEM 30 +1 EXEC to interact with the systems, and probably soon understand Commander John Young's frustration when he said: What we have in the Shuttle is a disaster. We are not making computers do what we want. (...) We end up working for the computer, rather than the computer working for us.

MEDS PFD and MEDS OMS/MPS display pages of the avionics. DPS SPEC 22 and SM OPS 201 pages of the avionics.

Features of the avionics include:

  • a near-complete simulation of the MEDS layer (only file-patching options are missing)
  • a 70% complete simulation of the DPS pages with extensive systems management supported
  • control via the screen edgekeys and the keyboards as in the real Shuttle
  • sophisticated software caution and warning system sensing off-nominal conditions and bringing warning messages on screen

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.

A launch from Vandenberg (KVBG) with Southern California seen from about 150.000 ft altitude 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.

Each of these thrusters comes with a detailed hardware model, checking free flow of propellant, availability of hydraulic or electrical power to operate valves and accounting for various damage modes, including e.g. RCS jets failing to extinguish. 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
  • detailed simulation of the propellant system with e.g. OMS to RCS cross feeding possible
  • sophisticated failure model for each thruster

The flight control system

Bringing a craft with the aerodynamics of a brick which in addition 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 attitude and 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.

The RCS can be controlled by many different digital autopilots (DAPs) 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:

  • user-selectable DAPs modeled according to their description in the Shuttle Crew Operations Manual
  • DAP gains and deadbands can all be fully configured in-sim or pre-loaded via a mission-specific file to the needs of a mission
  • 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!
  • off-nominal DAPs providing e.g. single-enging roll control (SERC) in the event of a two engine failure or mirror-imaging to provide RCS control during an OMS propellant dump via the RCS jets

Automated flight

While it was entirely possible to fly almost all parts of a Shuttle mission by hand, this was not normally done. Rather, the Shuttle was maneuvering under automatic control. An autopilot often manages tasks like achieving a precise inclination better than a human pilot, and especially highly dynamical situations such as the pullout after the plunge into the deep atmosphere during a contingency abort that stresses the Shuttle to its structural limits is better be handled by the flight computer.

There is extensive support in the simulation for automated flight both for nominal and off-nominal trajectories. The systems can be run to fully control the Shuttle as well as to provide 'fly-to' indicators for a human pilot to train manual control. On orbit, correction burns with the orbital maneuvering system can be planned and executed completely on autopilot, and to support a mission, multiple pointing and tracking routines are available which can be used e.g. to keep instruments in the payload bay pointed at a specific location on Earth's surface.

Automated flight features include:

  • automatic launch, entry and TAEM phase
  • on-orbit automatic pointing and tracking programs
  • programmable OMS maneuvers
  • targeting systems for orbit corrections or de-orbit maneuvering
  • autopilot capable of handling any launch abort up to and including two engine out contingency aborts


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.

The environment system utilizes cryogenic storages to supply water and breathable air to the cabin. The atmosphere is constantly cycled through air scrubbers to remove the CO2, and a system of fans uses it to provide cooling for the avionics. In preparation for a spacewalk, the atmosphere pressure and composition may have to be changed.

Payload bay door opened after the orbital insertion burn is completed. 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, fuel cells may need to be purged regularly. There are navigational needs as well - the star tracker need to be activated, and sometimes a manual procedure to fix attitude errors may be needed in addition. All 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 several mechanical systems - realistic procedures for closing external tank umbilical doors and for deploying the payload bay door and the Ku-band antenna
  • detailed electrical system - you can see bus voltages change with every single power-consuming system switched on
  • environment controls allowing to manage cabin air pressure and composition
  • simulation of star tracker operations and COAS procedure

Orbital encounters

Often a Space Shuttle mission does not simply go into orbit and back, rather it serves a purpose there - be it the release of a satellite or another payload, or a service flight to a space station. While there is not yet an extensive choice of missions, some of these at least can be explored. It is for instance possible to carry a satellite in the payload bay and release it into space - or catch it again and fly it back to Earth. Also visits to the International Space Station can be done.

Docked to ISS The SPARTAN satellite deployed.

Supported features include:

  • selectable payloads
  • fully working RMS arm, including manual and automatic modes, to handle payloads
  • RMS arm control software - the simulation can run a pre-loaded movement pattern for the RMS
  • realistic rendezvous navigation using the ranging radar
  • ISS docking and undocking

Night operations

Launch windows don't wait for the sun to rise - the Shuttle needs to be able to launch any time. The simulation fully supports nighttime operations. On orbit, this basically is a must since half of each orbit is in darkness, but also launches and landings during the night are possible. Unlike in other simulations, nights in FG tend to be realistically dark, so you are going to need light sources to see anything!

The glare of the SRBs illuminates the darkness during a night launch. For nighttime landings, floodlights on the ground are used to illuminate the touchdown zone.

Night-operation features include:

  • full cockpit lighting - instrument backlighting, glareshield lights, overhead lights
  • all screens can be brightness-adjusted individually
  • payload bay floodlights
  • illumination of the cloud layer by the SRB flame during night launch
  • external floodlights for illuminating the touchdown zone for night landings

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.
  • modeling of various heater elements throughout the Shuttle
  • thermal effects on equipment - payload bay door may jam due to thermal stresses, overheated APUs will die, fuel lines may freeze...
  • 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


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.

Tumbling helplessly through the atmosphere after a wing has been ripped off during a contingency atmosphere entry. 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.

Or imagine one of the electric buses is shorted. Operating voltage will drop, and all equipment on the bus will cease to work. Over time, this may affect fuel line heaters which can't perform their function without power. Thus, if parts of the Shuttle are not heated by the sun, hydrazine may freeze up there once temperature gets low enough --- preventing the OMS thrusters from igniting.

Single engine failure during ascent. At this stage, the thermal protection system integrity should better be good.

The simulation contains multiple 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
  • definition of probabilistic failure points beforehand to set up training 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, alternative cooling systems
  • realistic response of flight dynamics to failed thrusters

    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.

    SRB separation seen from high over southern California. 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 and OpenSource code made to be accessible for modifications at all levels
    Enjoy one of the most realistic simulations of the Space Shuttle available outside NASA's training centers! Learning how to operate the Shuttle may not be easy, but it will be worth the effort once you understand how spaceflight is really done.


    'Atlantis' on the Kennedy Space Center launchpad. The lights of the eastern Mediterranean. Supersonic flight phase in the higher atmosphere.
    Nightfall over the ocean. In the thin upper atmosphere, the plume widens at the shocks disappear. The bright SRB separation motor exhaust flames are deflected by the airstream.
    Plasma glow illuminates the flightdeck during a night atmospheric entry. The MEDS SPI page and the DPS SM SPEC 67 page of the avionics. Aurora Borealis seen from the Commander window.
    Aurora Borealis display over Finland. High over the Caspian Sea. Crossing over northern Canada.

  • Back to main index

    Created by Thorsten Renk 2015-2016 - see the disclaimer and contact information.