In the same way that aircraft manufacturers reuse much of their designs and instruments across product lines, many XML files are included by multiple aircraft models. Once loaded, this information is integrated into the simulation.
For example, one can look into the cockpit from outside, as shown in figure 4, and see the live instrument panel indications. This is the same exact instrument panel being shown to the pilot when inside the cockpit, demonstrating that FlightGear has a fully working 3D animated cockpit that is visible from inside or out.
Some aircraft types have `glass cockpit' displays, as shown in figure 7. The independent project OpenGC[8] is a multi-platform, multi-simulator, open-source tool for developing and implementing high quality glass cockpit displays for simulated flightdecks. Due to the resolution and size limitations of computer monitors, the OpenGC images are best on a separate monitor from FlightGear.
The head up display of a real aircraft uses computer generated graphics, so the software can generally detect, and correct for, the flaws and inaccuracies in the sensors that are feeding it data. As a result, the information presented to the pilot is generally accurate. Simulating that is relatively easy, since the actual state of the aircraft (in the properties) can be retrieved and directly displayed.
An important aspect of learning to fly an aircraft (without computer assistance) is understanding what the limitations and errors of the various instruments are, and when their indications can be trusted as useful flight data. Unfortunately, the information from panel instruments has errors, which in general only read a single sensor value with negligible correction for the limitations of the sensors being used. When the FlightGear panel advanced from no errors to having only two of the limitations implemented (VSI lag and compass turning errors), the non-pilot developers went from trivially flying instrument approaches to frequent ground impacts. Many more limitations have been realistically implemented since.
Considerable effort is needed to write this code. Gyroscopes can slow down and wobble, their rotation axis can drift, they can hit gimbal stops and tumble and their power source can be weak or fail. Air-based instruments are wrong in certain weather conditions, tend not to respond immediately, can be blocked by rainwater in the lines, or become unusable when iced over. Radio navigation is subject to line-of-sight, signals bounce off hills and bend near lake shores or where another aircraft is in the way and distant stations can interfere. Still more errors are associated with the magnetic compass, and other instruments that seem 'trivial'.
Currently, the communication radios are not implemented, so that pilots cannot use their microphone inputs to interact. Radio usage is a large part of the complexity in operating at large and busy airports. Unfortunately, this often encourages pilots to fly the microphone and forget about the airplane, occasionally with disastrous results. We hope to implement this feature soon, to provide another source of challenging distractions to the pilot.
Although voice communication between pilots is not yet supported, there is an artificial intelligence (AI) subsystem that seeks to make the airspace feel less empty. This subsystem moves other aircraft around the sky as a source of distraction, issues ATC style instructions and responses, and ATIS messages. Somewhat surprisingly, everywhere in the world, the ATIS always has a British accent.
alex.perry@flightgear.org
