[LWN Logo]
[LWN Feature]
Weekly Edition
Daily updates
Events Calendar
Book reviews
Penguin Gallery

About LWN.net

Sharing the Dream of Flight

June 20, 2000
Alexander Perry

The FlightGear project is collaboratively developing a flight simulator under the leadership of Curtis Olson.

From the dawn of aviation, early pioneers understood the need for flight simulation.  Even as early as 1910, simulators were being used as a tool to reduce new pilot death on their first flight. The technologies available have improved over the decades and these have been applied to flight simulation. Simulators can now be so realistic that there is no benefit in using a real airplane. Although a high end simulator usually costs more than a real plane on a per hour basis to buy and maintain, they still are cost-effectively used:
  • Teaching new pilots to fly on instruments, or learn the basic operations and feel of a plane.
  • Enhancing pilot teamwork skills, to work together effectively
  • Transitioning pilots to a new aircraft (especially single seat!)
  • Researching how a new aircraft will handle, before it's built
  • Designing cockpit layouts for practicality and ease-of-use
  • Practicing formation maneuvering and dog-fighting techniques
  • Reviewing emergency procedures and recovery sequences
Early simulator

FlightGear aims to do things right, but we don't have an exact mechanical copy of a specific cockpit, a wraparound display, or that huge motion system. Omitting all that stuff knocks two or three zeros from the price of your simulator installation. Although the core project doesn't have those neat things yet, there are groups all over the place who are working to change that. Watch this space, as they say. 
LWCE expo photo Meanwhile, all you need to run FlightGear is:
  1. An ordinary computer running Linux or Windows
    (ports are in progress for MacOS and other flavors of unix),
  2. A video card with hardware-accelerated OpenGL and texturing support,
  3. A joystick, unless you are very good with the keyboard keys.
At the LinuxWorld Expo 2000 in San Jose, our booth (shown in the picture) demonstrated a 400 MHz Celeron machine from VA Linux running Debian GNU/Linux 2.2 with a Matrox G200 8MB video card using the Utah-GLX project's 3D driver and CH Products' USB FlightStick. It flew well throughout the show and is quite sufficient for normal use. It is still true that having more is better, so several of our developers are upgrading to dual Athlon computers and/or GeForce video cards.

The FlightGear project is aiming to achieve "best of breed" by avoiding short-cuts and incorporating the best implementations of each aspect of the simulation.  We are using open-source technology to achieve this goal.  In fact, what makes the FlightGear project unique is that we are pioneering the use of "Open Source technology" towards improving flight simulation and making it more accessible, more usable, and more affordable than ever before.

Can we really become the best simulator available, given that many companies are actively developing and selling software in this market? I think so.  First of all, many other Open Source projects have demonstrated the power of this approach and have been very successful.  Secondly, flight simulation is a very difficult task.  It lends itself well to a long-term, Open Source, cooperative project.

Game companies that need to put out a successful product in a short amount of time have a very difficult time investing enough resources to compete technically while being able to make a profit at the same time.  Our approach is slow and methodical, but we have made great strides.  We don't have the do or die pressure of making a quick profit so we can take the time to do things right, because simulation is a hard problem.

Simulation is a lot more than writing programs to read a joystick and draw pictures on the screen. At the core of a realistic simulator are hundreds of models, derived from the engineering characteristics of the aircraft. Together, these describe how that aircraft will respond. In addition to developing (and coding), the models need numerical parameters that configure them to match a specific aircraft design.

Some parameters are easier than others; finding out how well the wings work for cruise flight is a lot easier than learning how they handle when they appear to be going backwards at 40 miles per hour. But this is what can happen when taxiing around an airport, on a windy day. Pilots that forget to take this into account may find themselves unexpectedly up-side-down. A simulation should have the same fate, even if it lets you avoid the embarrassing conversation with the NTSB.

FlightSimulation is a lot more than just modeling the behavior of an airplane.  You also have to model the behavior of the world and atmosphere through which you are flying.  Everybody would like to have worldwide and good-looking scenery. We could take satellite photos of the whole of the earth's surface with one meter resolution, but we'd need about a million gigabytes of storage. Even then, one meter resolution looks pretty bad when you're close to the ground. Try comparing the runway and buildings of this satellite-based scenery with an actual photo from the PilotAge.com website.

So, even presuming that most people will happily allow us to use a few gigabytes of disk space to store the scenery (as opposed to a million gigabytes), we would need a million-to-one compression ratio, coupled with a fantastically fast algorithm, to realistically apply it to these huge amounts of satellite data.

FlightGear is currently following an alternative approach, driven by the TerraGear project. This constructs real-looking synthetic scenery from databases of airports, lakes, roads, mountain terrain, vegetation, and so on. The results are already good enough that most pilots can comfortably navigate around areas they're familiar with - just by looking at the view of the scenery on the screen.

Screenshot of short final for runway 27 at Ramona CA airport

These are all science and engineering challenges, even before we reach the challenge of writing software to implement the solutions. There are experts available world-wide, each of whom know how to solve a few of these challenges properly and efficiently. Given the hundreds of models needed to make a single aircraft type fly right, it will take a lot of experts to resolve all the challenges at top quality.

Imagine the effort needed to create a broad suite of aircraft where knowledgeable pilots will recognize all their individuality and characteristics. It is virtually impossible for a software company to find and collect all these experts and thus meet the challenges properly. Instead, they choose a small representative set of experts, and their software engineers use guesswork to extrapolate the answers into all the numbers needed for the models. As a result, even though such a simulation program might have a huge number of aircraft supported, they all feel unnaturally limited to a pilot with broad experience.

A Velocity LW RG in flight In contrast, the GPL gives FlightGear the opportunity to accept aircraft models and retain the individual characteristics that make them all so interesting. Suppose an EAA member has almost finished building their own aircraft (such as this Velocity LW RG pictured) and is starting to get a bit worried when thinking about the near future. That owner will be a real-life test pilot when the time comes to take their pride and joy into the air for the first time. If they wish to practice beforehand with a simulator, just how many corners do you think that inexperienced test pilot wants the programmer to have cut, while writing the software?

I would expect that the owner might take the time to describe their aircraft, in every available detail, to the fully parametric flight data model (FDM) called JSBSim. With every aircraft having its own peculiarities, there is a good chance that some effect or feature will not be supported. Unlike most other simulators, FlightGear has several FDM modules to choose from, but even this variety may not be sufficient. If the project is lucky, this concerned pilot would write up a careful description of the feature that is lacking and explain how the model can be extended to make it available.

Most readers are probably already familiar with the Bazaar development analogy, which explains how these kinds of projects generate stable and high quality source code. FlightGear presents the opportunity to take this one step further, and apply it to the science, engineering and research work. Will the research community take advantage and participate? There are two direct reasons for them to consider it:

  1. Research, by definition, attempts to explore areas that are previously unexplored, so proprietary/closed source flight simulation packages are often not very useful.  However, because FlightGear is Open Source, it can be relatively straightforward for a researcher to test an unusual solution to an unusual problem.
  2. It is often difficult to determine whether the solution to that specific problem is valid and generally useful. By inserting it into FlightGear, the research team can ask pilots who are familiar with the problem to evaluate their solution and thus provide direct feedback on the effectiveness of their work.

An impression of our progress so far can be gained by browsing through our news log. The flight models are fully aerobatic capable, even if some aircraft do not have the performance necessary. If the flight occurs at night (weather permitting), I will be able to see the stars and planets in the correct positions in the sky for date, time, and location, so I can use celestial navigation. Or, I can add cloud layers, reduce the visibility and use radio navigation systems to find my way around. I can use any navaid-based instrument approach to find my way to a runway. The project lead Curtis Olson is currently generalizing his runway markings code so that all runways in our world wide database will have approved markings.

I'm looking forward to the project advancing to the point where the FAA can approve it for training pilots, Jon Berndt is working to complete a realistic X-15, Oliver Delise is aiming to allow formation flight among worldwide users, others are working to provide real weather data and modeling, realistic engine models, and a host of other things that the various developers are interested in. Are these goals incompatible? Not really, although I'm not sure how well the real-world ATC system would cope with having a couple of dozen hypersonic aircraft whizzing around.

Alexander Perry is one of the FlightGear developers using Linux, an instrument-rated private pilot and advanced ground instructor, a PhD electronic engineer and a senior member of the IEEE.

Eklektix, Inc. Linux powered! Copyright 2002 Eklektix, Inc. all rights reserved.
Linux ® is a registered trademark of Linus Torvalds