Sharing the Dream of Flight
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:
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.
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.
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.
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:
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.
Eklektix, Inc. all rights
Linux ® is a registered trademark of Linus Torvalds