Home About Technology Travel Pictures
Chapter 3 Deutsch Chapter 5

4 Simulation

4.1 Connecting to FlightGear

My experiences from the EasyBot project is that development and testing of software for an autonomous model aircraft can be done with the actual flying object until a certain level of complexity. The more complexity increases the more time the testing and bug-fixing takes. Sometimes multiple test flights with debug logging have to be performed in order to find bugs in real flights. In addition, it is much harder to concentrate on finding and correcting bugs in the field. After all, development of complex processes like an approach for a landing can only be done reasonably using a simulator.

The development of a simulator was out of question because it would have been more time-consuming than the autopilot itself. Thus a simulator was searched for that could be easily connected to the autopilot software. X-Plane came into consideration first but then I stumbled upon the Open Source simulator FlightGear. The first idea was to extend the simulators sources in a way to make communication possible to the autopilot. But then it emerged that this was not necessary because FlightGear has a very open and extendable interface.


In loop with FlightGear

Using so called Protocol files it is possible to define which data the simulator sends out and receives as input. In order to connect the autopilot in a loop the simulator has to send postion, velocity, attitude and heading to the autopilot. The autopilot on the other hand has to send control data for engines and all relevant control surfaces back to the simulator. The generic Input/Output provides 3 media for data exchange: file, serial and socket (TCP / UDP). Mode and exchange frequency are configured via command line parameter. I tried data exchange via serial cable first but noticed drastic delays in the loop, perhaps caused by the buffering in serial transmission. Transmission via TCP might be applicable but may lead to deadlocks in the special loop situation. Hence UDP is best qualified due to its "fire and forget" nature. Even though lost or unsent packets should be avoided, FlightGear tolerates missing packets without interrupting the simulation.

#! /bin/sh
xterm -e fgfs --aircraft=Rascal110-JSBSim --airport=EDFE --disable-panel
 --enable-hud --disable-anti-alias-hud --disable-hud-3d --timeofday=noon
 --generic=socket,out,50,127.0.0.1,5505,udp,fgsimout
 --generic=socket,in,50,,5507,udp,fgsimin --model-hz=100 &

./autofly -sim -aircraft rascal -command rascal_test
Start script for simulator and autopilot

The autopilot software was extended by a FlightGear adapter. It emulates the relevant sensors like GPS, IMU and sonar and redirects the servo commands. The adapter is activated by the command-line argument -sim. For simulation of a model airplane I mostly use the simulator aircraft "Rascal 110". FlightGear and the autopilot are started simultaneously by a shell script on the development machine and exchange data via UDP 50 times per second. The internal simulation frequency of FlightGear should therefore be set to a multiple of 50 Hz, e.g. 100 Hz. It is also possible to run both software components on different machines. Provided a fast Ethernet connection to the onboard computer it is even possible to connect the simulator with the real hardware, almost like a hardware-in-the-loop testing.

Using the simulator my development speed increased considerably. New approaches or variants can be tested immediately. Furthermore the availability of many aircraft models helps developing a generic control software. FlightGear may not keep up with commercial products regarding graphic details but the freedom of configuration and debugging make it an excellent UAV testing environment.

Autopilot flight of a C172p
Download: sim.tar.gz Sim environment (92kB). Requires FlightGear on Ubuntu or similar Linux
Videos: autofly 737 Boeing 737-300 autonomous landing at KSFO

4.2 Flight Path Visualization

All sensor data that accumulate in flight are written to a log file. The format of this file is inspired by the NMEA format. Every sentence starts with a '$', followed by two letters for the talker id, then three futher letters that describe the sentence type. Normally every sentence has a timestamp too. This makes it easier to keep the sentences in a chronological order. Besides the NMEA-like sentences the log file has debugging info and error messages in a special format.

For visualization of the log data a graphical user interface was developed. In the beginning the program was used for display of GPS data only but was enhanced for further data sentences when required.

Currently there are the following displays:

  • Two-dimensional display of the flight path including maps
  • Terrain grid in perspective view
  • elevation and speed profile
  • Engine RPM
  • Sonar
  • Servo positions
  • Visible satellites
  • Speedometer and milage in meters
  • Artificial horizon including heading und inclinometer
  • GPS raw data, temperature, on-board voltage, airspeed
  • Flight plan with current command
  • Time slider (UTC)


Screenshot of flightviz

The EasyBot contains a webstart version of this software where real log files can be downloaded and displayed.

Chapter 3
13.03.2009, Achim Walther, Mail
Chapter 5