The Space Shuttle - a (loose) development log

Sunrise during entry

Impressions from performance testing.

On the pad, ready to go.
Pushing throught the first cloud layer.
It's nice up here!
Looking at the ET over Scotland.
Nightside of Earth.
Entry plasma.
Early dawn just after the high heat phase is over.
Sunrise during the late entry phase.
Scattered morning clouds during TAEM.
Light through the top windows playing across the pilot console.
Aimed for the Vandenberg runway with HUD de-cluttered early.
Safe touchdown in Vandenberg.

Let there be light!

With the help of Wayne Bragg, the cockpit now gets the GLSL magic taking care of lights. The tool of choice are lightmaps rendered using a raytracer operating on the cockpit 3d mesh. The results are nothing less than spectacular - a raytracer allows to capture fine shadows (look at the switch guards!) as well as diffuse reflection of lit surfaces onto other surfaces, thereby producing part of the occlusion effect of darker cavities,... The accuracy is infinitely higher than any real time 3d rendering technique could produce.

Sunlight filtering through the cockpit windows.
Night illumination based on panel backlighting only, casting a weak ambient light into the rest of the cockpit.
Left Commander (CDR) fluorescent panel light.
Middle CDR fluorescent panel light.
Middle Pilot (PLT) fluorescent panel light.
Right PLT fluorescent panel light.
Left CDR incandescent ceiling light.
Middle CDR incandescent ceiling light.
Middle PLT incandescent ceiling light.
Right PLT incandescent ceiling light.
All panel lights.
All lights on.

As usual, care has to be taken that light intensity is added correctly in physical rather than perception space.

I love spaceflight

Impressions from a test flight of launch, orbital insertion burn and payload handling.

Leaving the cape.
The northward course to a 51 deg inclination orbit goes roughly parallel to the US coast.
Passing Newfoundland after the ET has been disconnected.
A couple of minutes later we're already in Europe.
Crossing over England.
Handling the Spartan satellite high above California.
Spartan disconnected and floating off.
Canada from some 500 km altitude.

The cockpit

The Space Shuttle has an unbelievably complex cockpit with literally hundreds of switches, gauges and buttons. In addition, it comes with 11 multifunction displays (MDUs). Each of the MDUs can potentially show close to a hundred different pages, and often one page can show close to a hundred distinct data items.

Trying to display that much data all at once is testing new grounds for Flightgear - but the 3d cockpit is progressing well. The basic mesh is based on work by Chris Kuhn, adapted and vertex-reduced by Richard Harrison who also designed the HUD and MDU display structures and code, and animation work is done by Wayne Bragg.

The result is now quite compelling - all forward MDUs are functional and can be controlled via the keyboard units and edgekeys and are capable of displaying the available mixture of GNC (guidance, navigation and control) or SM (systems management) function and MEDS pages.

The current state of the cockpit during the day.
A close-up on the central part of the panel with different DPS functions running on the MDUs.
At night, the cockpit instruments are backlit and their soft glow illuminates interior surfaces.

Payload bay lighting

To be able to continue RMS or EVA operations during the night, the Space Shuttle has a powerful set of floodlights to illuminate the payload bay. These are six sets of metal halide lamps installed in the bay, supplemented by a spotlight at the RMS arm. This type of light takes considerable time (about two minutes) to reach full intensity.

Atlantis operating at night with payload bay floodlights on.

The main challenge of rendering light in the payload bay is that Atmospheric Light Scattering, the rendering scheme of Flightgear giving the best visuals in space, is a forward rendering scheme. This means that lighting is naturally only determined by the relative orientation of a surface to the sun, but objects do not cast shadows. In particular, the payload bay would be illuminated by the sun even with doors closed.

The solution chosen is a number of light and darkmap textures which darken or lighten surfaces controlled by external parameters. In that way, light for all objects in the payload bay can be conditional on the doors being open - while not fully correct, the visuals are nevertheless fairly convincing. The following sequence shows the light distribution when opening the payload bay doors with the sun right in the zenith:

Doors are closed, payload bay is dark. The first door openes a crack and lets sunlight in. As the door opens further, the bay illuminates fully.

The floodlights are implemented as a series of lightmaps on top of that which each take some time to reach full intensity. The following series show the visuals over the two minutes as the lights are gradually switched on from aft to forward lamp groups:

Only aft floodlights ramping up intensity. Aft lights at almost full instensity, mid lights ramping up. All lights at full intensity.

RMS arm deployment and usage

The remote manipulator system (RMS) is used, among other things, to move satellites out of the Shuttle's payload bay. To implement this system in FG, several factors need to come together. The state of the RMS arm (angle of every joint, position of the tip, limits for angles,...) needs to be computed based on the control inputs, and this info needs to be translated into the animation of the arm.

Attaching a payload then involves handing a static model of something in the payload bay over to a model that is dynamically translated and rotated based on the position of the arm. Releasing this model into space finally corresponds to a third handover to a model animation that is tied to the Space Shuttle in position and orientation to an equation of motion solver for an independently orbiting object - which nevertheless needs to inherit the same spatial orientation and position its ancestor had.

In reality, the RMS arm can be driven in a number of different modes, making it somewhat easier to attach it to an object. Right now in FG, only the single joint mode (i.e. only one joint angle at a time is driven) is implemented.

After some initial frustration, the system works very nicely however - here is a demo of the Shuttle releasing a stripped-down satellite into orbit while crossing Africa:

The RMS arm is attached to the payload, ready to lift out. Payload is lifted while retracting the arm a little to avoid hitting the vertical stabilizer.
Arm is almost fully extended. Payload is released - of course it does not move but just orbits with the Shuttle.
Retracting the RMS arm again into cradle position. Atlantis is ready to depart.
A short RCS burn to separate from the satellite... ... and Atlantis is ready to continue with the rest of the mission.

RCS propellant distribution system

To ensure that propellant reaches the thrusters under all condition, the propellant distribution system of the Space Shuttle utilized high-pressure helium storage tanks which in turn pressurize fuel and oxidizer tanks such that fuel is expelled to the thrusters. The whole system utilizes a complex pattern of feed and cross-feed lines for redundancy and a layer of tank and manifold isolation valves - closely mirrored by the schematics depicted on the panel below for the aft RCS modules:

The more interesting challenge is however the computation of available fuel: Should the helium pressurization fail, the remaining high pressure helium in fuel and oxidizer tank is still enough to expel some quantity of fuel in a so-called blow-down mode. This quantity is maximal for about 22% of fuel/oxidizer remaining. For use in Flightgear, the amount of fuel that can be utilized as a function of fuel fraction and tank pressure at the time of helium system failure needs to be accurately modeled and implemented.

Highly realistic RCS modeling

The reaction control system (RCS) of the Space Shuttle, used to control its attitude in orbit and for translational thrusts in proximity and docking operations, is a fairly complicated arrangement of 38 main thrusters and six much weaker Vernier thrusters.

Ideally, thrusters would be arranged with a high degree of symmetry such that they form an orthogonal system in which simple combinations of thrusters give pure yaw, pitch and roll motions or pure X, Y and Z translations. However, in the case of the Shuttle, this simply isn't feasible. The aerodynamical outline implies that the fuselage is narrow at the nose and widens aft, leaving room for a single nose RCS module but a pair of modules at the OMS pods. In addition, the thermal protection system at the lower body of the Shuttle can not be broken by a thruster exhaust without creating a severe vulenerability.

As a result, the actual thrusters at the different stations almost all point slightly away from the orthonormal directions, the number of thrusters is not the same at every station (in particular, the yaw jets which are crucial for stability during atmospheric entry utilize four different thrusters for redundancy) and the table of thrust components along the body axes is rather messy:

For use in FlightGear, this table needs to be converted into a spatial arrangement of thrust direction and the off-axis components translated into engine pitch and yaw angles with respect to a default engine orientation to the spacecraft's +X axis (i.e. rear).

Once this is done, a low-level flight control logic layer is needed which determines which actual thrusters are fired in response to a control input. Such logic also needs to address mode mixing, i.e. the fact that e.g. firing a yaw thruster also induces a roll motion since the thrust axis is not through the center of gravity and a translational motion.


Back to main index     Back to Space Shuttle

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