FlightGear Simulator

Have you ever wanted to control an aircraft in a simulated environment? For example, you have a hobby in making your own RC planes and you would like to program these planes to fly autonomously but you don’t have a chance to test your program. Well, my application FGSim together with FlightGear give you the opportunity to actually test your solution before you put it into the real RC plane.

My solution is composed out of 4 parts:

  • FlightGear, the actual flying simulator
  • FlightGear Simulator (or FGSim) is both GUI and a bridge between FlightGear and your code
  • FGSimApi, set of classes that your code can work with
  • Plugin, the code placed in a Dll, which handles the simulation output and provides simulation input

This diagram shows the basic concept of my FGSim application:

FlightGear has the ability to communicate with outside world through some interfaces, like serial port or socket (UDP or TCP). I decided to go on with the socket communication, which allows both output (values such as altitude, speed, GPS positions, etc.) and input (elevator, aileron, throttle, pretty much everything you can control in an aircraft). To see the full list of properties which can be set/obtained through socket, click here. However, to simplify the FGSim to meet my needs, the output currently contains: altitude, altitude above ground level, ground elevation, latitude, longitude, roll, pitch, heading, roll rate, pitch rate, yaw rate, airspeed, mach, speed north, speed east, speed down, u-body, v-body, w-body, vertical speed, acceleration in north/east/down. The input consists of: aileron, elevator, rudder, flaps, 4 engines (throttle), left and right brake, gear, 3 lights (landing, nav, strobe). Please note, that this application (FGSim) was developed to allow testing of the “autopilot” code for a glider. Expanding the output/input is possible.

So how does the FGSim work? I can describe the FGSim as an server/client application with the ability to display aircraft-specific information. It operates in three modes. The first one communicates directly with FlightGear, capturing all the simulation data, process these data trought a plugin then send the simulation input back into FlightGear. The second mode works similarly except the simulation output is taken from a playback file insted of the FlightGear. The playback file is made automatically during the first-mode simulation (output data taken from FlightGear). In the third mode, simulation data is being generated by a LUA script. FGSim updates global variables IFrameTime and IFrameInterval, them calls LUA function Update(), checks for result (true means simulation can continue) and copies global variables O* into a playback-like simulation model. Thanks to this, your plugin won’t know the difference between playback and script-generated output and can act like it’s being captured from FlightGear while you can focus on specific simulation factors, like if you want your aircraft to handle it’s roll, then you can simulate multiple behaviors using LUA script and then handle it using your plugin (which can be also a LUA script)

Detailed description of the first mode simulation: after you click the “Start” button (“Spustiť” in slovak), the application will try to initialize your plugin (note that FGSim can run without plugins, in such a case the FGSim doesn’t call the “ProcessFrame” event). If the plugin was initialized, FGSim will ask the plugin to create a handler for the simulation output, if no plugin was specified the FGSim will create a default CFGRawOutput object to handle the simulation output. Then the input handler is created, this step also involves the plugin, which is asked (if available) if the input is supported. Because your plugin can only process the simulation output and interpret it in a different way, there’s no need to have the simulation input running if it’s not needed. After these objects are initialized (at least the output handler, input handler is not necessary), the FGSim will create a new simulation object, initialize it and run it. If the simulation handler was set up correctly and is running, the FGSim will initialize both instruments view and map view. These two views then enter simulation mode and update their content according to the settings. Note that it is possible to set various modes of the simulation, you can have the instruments view update every time a new output is received from the FlightGear or you can set an internal cycle which will refresh the view in exact steps. The simulation handler will then create a thread to handle the output from FlightGear using an UDP socket set to listen on a specific address. The default is 127.0.0.1:666

The second mode (playback) differs only in the creation of a simulation handler. Insted of using a simulation handler that would listen on an UDP socket, playback simulation creates a thread in which it will load a playback file with a specific structure and read the file frame by frame. Every frame has a timestamp or a frame time which tells the simulator how long it should wait till it sends the frame to be processed by the frame listener. This allows the playback simulation to follow the time the real simulation took. It also supports fast forwarding or slowing down the playback or even pause the playback.

When the simulation handler (from FlightGear or playback) receives a frame, it sends this frame to a set of sub-listeners. One of them is the main application window which then sends this frame to a plugin (if any) and then sends the same frame to the active view (instruments or map). That’s pretty much all. The instruments and map views just process the frame and update their controls (instruments updates a copy of the simulation dataset, so when the paint function is invoked a new data is drawn on the window, map also updates a copy of the simulation dataset so the bing map can be synchronized).

FGSim is in a working state with a prebuild plugin which executes a LUA script every frame. Both FGSim and the default plugin uses LUA 5.2. I didn’t intend to put this application for downloading BUT if you find this solution interesting, feel free to leave a comment and if you would like to get this simulator, let me know and I will send you a copy.

Reklamy

3 comments

  1. Nicely done! I would be interested in seeing your source code, even though I am working in linux – if you could let me have a copy – I would be grateful! Thanks!

  2. Hi,

    I am trying to develop an S Function to interface Simulink with Flightgear. I have no problem to send data from Simulink to flightgear, but I don’t know why, I can’t do the operation the other way around, i.e, receiving data from Flightgear to simulink. I thought that maybe it would be useful for me if I could explore the source code of your interfacing application. I would appreciate if you send me a copy of your code via email.


Pridaj komentár

Zadajte svoje údaje, alebo kliknite na ikonu pre prihlásenie:

WordPress.com Logo

Na komentovanie používate váš WordPress.com účet. Odhlásiť sa / Zmeniť )

Twitter picture

Na komentovanie používate váš Twitter účet. Odhlásiť sa / Zmeniť )

Facebook photo

Na komentovanie používate váš Facebook účet. Odhlásiť sa / Zmeniť )

Google+ photo

Na komentovanie používate váš Google+ účet. Odhlásiť sa / Zmeniť )

Connecting to %s