Hi,I am a student at the University of Alabama and am working on a flight simulator project along with a professor in the ECE dept. We have a cockpit with full controls(for I believe a Cessna), and were previously running scene generation software that was written in house. We discovered the software was used for helicopter controls and physics engine, so are looking for new software to run the system. Currently we are running the scene generation on 3 computers(1 for each panel to create a more full cockpit feel), and are using the cockpit controls that are read into a computer. As I don't know much about Flight Gear, I was wondering how difficult it would be to a)create the 3 panel display using Flight Gear and b)read in the controls from the cockpit to control the software, and how they would need to be connected(USB, network, etc.). Thanks in advance for the help as any will be appreciated.-Ryan

Hi, please note that FlightGear is currently not being officially supported via this forum, so it is generally a much better idea to ask such and similar questions on one of the FlightGear mailing lists, in your case preferably "FlightGear Devel", check the webpage, http://www.flightgear.org and the section "lists" for further details.Apart from that, FlightGear has already been (and is currently being) used for projects similar to yours. So, generally it should be pretty straight forward to use FlightGear for your purposes, simply because it is not only highly configurable but also easily modifiable and extendable. Many features can easily be configured at runtime, even flight dynamic characteristics are provided by easily editable XML files.Also, FlightGear itself can easily be used with multiple views (screens). However, currently there is essentially no integrated multi-head support for a single machine, meaning you will currently have to run FlightGear on a dedicated machine, so that you end up having multiple instances of FlightGear running on various machines, synchronized via LAN (network). So, multi-head cards (i.e. from Matrox) are currently not really a feasible option (unfortunately), rather you will always want to have one "master" machine and various "slaves" that are fed data (i.e. position, speed, view etc.) from the master. If you take a look at the mailing list archives at www.flightgear.org, you will find various discussions about this very topic and recommendations about how to approach such a configuration, I seem to recall there's even a short "howto" in the Docs folder of the base package available (use the web based CVS viewer if you haven't already downloaded and installed FlightGear, to view these files).Generally, you will want each FlightGear machine to have a current OpenGL card with preferably at least 128 MB RAM installed. As long as you are minimally using a 100 MBIT LAN connection for all machines, it should also be okay to simply share the base package data (scenery, data, aircraft etc.) among all instances via the network (NFS), so that you don't have to install the base package on each machine(if you check out the "projects" section at www.flightgear.org you will find a similar project to yours, a whole boeing cockpit driven by FlightGear).With respect to interfacing FlightGear to other software, this is indeed extremely straight forward, FlightGear features a so called "property tree" which means that all simulation relevant runtime variables (i.e. "IAS", "altitude", "heading" etc.) are exported in an intuitive tree-like representation (i.e. think of a file system), thus you can easily access (read/write) these variables at runtime. There are various ways to actually access this interface, one of the easiest ways would be to use the in-built telnet interface, which would allow you to connect to FlightGear via a telnet client and browse all state variables at runtime, alternatively you can also use a web based interface (using a browser then). You can find examples (runtime options) about how to accomplish this by runningfgfs --help --verboseby simply checking the $FG_ROOT/Docs folder, by search the mailing list archives or this forum.So, make sure to look into the directory $FG_ROOT/Docs (in the base package) or $FG_SRC/mini-docs (source code tarball). Also, in case that you should ever need to export additional internal (C++) variables to this "property tree", this would only require a quick re-compilation. Likewise, you can easily make up your own property paths (and values), no need to re-compile FlightGear then, though.I am not sure whether you intend to display FlightGear's panels on multiple screens or whether you want a hardware panel to be driven by FlightGear, however both scenarios should be quite straight forward, the latter depending mainly on your implementation of the hardware gauges, so that you could easily poll the property tree for updates in order to update your hardware instruments. If all you need to do, is to display a cockpit panel across multiple screens, this would mainly come down to using different view offsets for each running instance of FlightGear.So, this should be mainly configuration-dependent and should not require any source code modifications.Simply because all FlightGear instances would practically be independent of eachother and only be synchronized via the network interface at runtime.However, please note that if you intend to drive external devices using the telnet or browser interfaces, that these interfaces were not designed for highspeed throughput, thus you may want to look into hard-coding your interface for the sake of performance, you can find various examples for hard-coded interfaces under $FG_SRC/Network, these are usually UDP based and can be configured to run with arbitrary priority (update intervals).Apart from the possibility to modify XML based files for practically all crucial functionality in FlightGear (i.e. aircraft, FDMs, cockpits (panels), instruments, sub models etc.), there's also the possibility now to use a scripting language called "Nasal" to add functionality to FlightGear without having to recompile the binary.So, in general you will most likely want to subscribe to the FlightGear Devel mailing list, download and install FlightGear (possibly from source (CVS)) and check out the documentation for FlightGear, as well as possibly the mailing list archives and the search function of this forum. However, please note that the documentation is in many areas lacking and often not up to date, so the latest and most reliable information can usually be obtained by checking the the mailing list (archives).On the other hand, you mentioned a helicopter simulation, that's another thing to consider: FlightGear's support for helicopter flight can currently only be considered to be quite rudimentary, at best. Thus, if you need to model helicopter flight, you may be disappointed by FlightGear's current abilities. Apart from that, FlightGear features several in-built Flight Data Model (FDM) engines that can be configured dynamically using XML files, thus allowing users to easily create and modify existing flight models without the need to modify the (C++) source code. Also, there's always the possibility to drive FlightGear with an external flight model (i.e. using Matlab), this possibility is currently being used by various different projects, too. So, if you should find that FlightGear's existing flight models turn out to be insufficient for your specific project, there would always be the possibility to use or create new flight models, or even a new FDM engine altogether.While the creation of flight data models is indeed somewhat documented, it is currently not yet wizard based, there is not even any sort of GUI for this purpose yet, basically you will usually want to take a look at various other FDM configs and create your own config using a plaintext editor, possibly by copying and pasting from or to other files.So, make sure to download FlightGear (possibly from CVS) and check out the documentation, so that you can ask more specific questions on the FlightGear Developer's mailing list.Good luck!