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.
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.
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
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.
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.
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:
*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.
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. 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.
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.
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.
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 (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!
Edwards AFB (KEDW) seen from the Shuttle cockpit
Touchdown in Vandenberg, deploying the drag chute.
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 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.
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
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.
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.
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:
*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.
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. 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.
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.
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.
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 (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!
Edwards AFB (KEDW) seen from the Shuttle cockpit
Touchdown in Vandenberg, deploying the drag chute.
Last edited:
