Start Person Technik Reisen Fotos
Kapitel 3 English Kapitel 5

4 Simulation

4.1 Anbindung an FlightGear

Die Erfahrungen aus dem Projekt EasyBot zeigen, dass Entwicklung und Test der Steuerungssoftware für ein autonomes Flugzeug bis zu einem gewissen Punkt am echten Flugobjekt möglich ist. Allerdings wird dieses Vorgehen zunehmend zeitaufwändig, wenn die Steuerung komplexer wird. Um Fehler ich echten Flug zu finden, müssen mitunter mehrfach Testflüge mit intensiven Logging der relevanten Variablen durchgeführt werden. Hinzu kommt, dass es schwer fällt, sich auf dem Flugplatz auf das Finden und Korrigieren des Fehlers zu konzentrieren. Die Steuerung komplexer Abläufe wie des Landeanflugs ist nur noch mit einem Simulator vernünftig zu programmieren.

Die Entwicklung eines eigenen Simulators wäre sicherlich aufwändiger als die der Steuerung selbst. Es wurde daher ein Flugsimulator gesucht, der sich möglichst einfach an die Steuerungssoftware anbinden lässt. Der Simulator X-Plane kam zunächst in Betracht, jedoch war es anfangs schwierig hierfür die Möglichkeiten der Anbindung auszuloten. Als nächstes wurde der Open-Source Simulator "FlightGear" untersucht. Die Überlegung war zunächst, die Sourcen des Simulators so anzupassen, dass die Kommunikation mit dem Autopilot im gewünschten Format möglich wird. Es stellte sich allerdings schnell heraus, dass dieser Aufwand nicht nötig ist, denn FlightGear verfügt über eine sehr offene und erweiterbare Schnittstelle.


Kopplung mit Flugsimualtor

Mittels sog. Protokolldateien lässt sich bestimmen, welche Daten der Simulator ausgibt und welche er als Input entgegennimmt. Um den Autopilot mit dem Simulator in eine Schleife zu hängen, ist es notwendig, dass der Simulator Position, Geschwindigkeit und Richtung (Attitude, Heading) ausgibt und der Autopilot mit Steuerdaten für Motor und alle relevanten Ruder antwortet. Der Generic Input/Output gestattet 3 Medien für den Datenaustausch: file, serial und socket (TCP / UDP). Im Startscript für FlightGear lässt sich per Parameter Übertragungsart und -häufigkeit festlegen. Tests der Übertragung über serielles Kabel waren nicht erfolgreich. Anscheinend führt die Pufferung der Daten zu einem zeitlichen Versatz, so dass die Steuerdaten des Autopilot den Simulator erst nach Sekunden erreichen. Die Übertragung per TCP ist zwar unter Umständen geeignet, kann aber in der speziellen Situation zu einem Deadlock führen, da das System solange blockiert, bis die Nachricht zugestellt ist. UDP mit seinem Fire-and Forget-Ansatz ist daher als Protokoll am besten geeignet. Obwohl es prinzipiell vermieden werden sollte, toleriert FlightGear das Fehlen von Input-Paketen ohne die Simulation zu stören.

#! /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
Startscript für Simulator und Autopilot

Die Steuersoftware wurde um einen FlightGear-Adapter erweitert. Dieser simuliert die wichtigsten Sensoren wie GPS, IMU und Sonar und leitet die Steuerbefehle um. Der Adapter wird per Kommandozeilen-Parameter "-sim" aktiviert. Als Flugmodell wird hauptsächlich das "Rascal 110" verwendet. FlightGear und Autopilot werden gleichzeitig auf dem Entwicklungs-Rechner gestartet und tauschen 50 Mal pro Sekunde Daten per UDP aus. Möglich ist auch, dass beide Komponenten auf verschiedenen Rechnern laufen. Sofern eine schnelle Netzverbindung zum Bordrechner des Flugzeugs möglich ist, könnte FlightGear sogar mit der echten Hardware gekoppelt werden.

Die Simulation erhöht die Entwicklungsgeschwindigkeit erheblich. Neue Ansätze können sofort getestet werden. Die Unterstützung vieler Flugzeugtypen fördert das Entstehen einer generischen Steuerung. FlightGear mag zwar graphisch noch nicht mit kommerziellen Flugsimulatoren mithalten können, die Möglichkeiten der Konfiguration und des Debuggings machen ihn aber zum ausgezeichneten Testwerkzeug.

Autonomer Flug im Simulator
Download: sim.tar.gz Simulationsumgebung (92kB). Voraussetzung: FlightGear, Ubuntu oder ähnliches Linux-System
Videos: autofly 737 Autonomer Flug Boeing 737 mit Landung auf KSFO

4.2 Visualisierung der Logdaten

Die während eines Fluges anfallenden Sensordaten werden in ein Logfile geschrieben. Das Format der Daten orientiert sich am NMEA-Format. Jeder Datensatz beginnt mit einem '$', gefolgt von zwei Buchstaben zur Kennzeichnung des Talkers, dann drei weitere Buchstaben, die den Inhalt beschreiben. In der Regel hat jeder Datensatz auch einen Zeitstempel, damit die zeitliche Abfolge der Daten bestimmt werden kann. Neben den genormten Datensätzen enthält das Logfile noch Debugging-Ausgaben und Fehlermeldungen.

Zur Darstellung der Datensätze wurde eine grafische Oberfläche entwickelt. Das Programm diente anfangs nur der Abbildung der GPS-Daten, wurde aber bei Bedarf um die Visualisierung weiterer Datensätze erweitert.

Aktuell existieren folgende Anzeigen:

  • Grafische Darstellung der Flugbahn mit Einblendung von Karten / Luftbildern
  • Terraingitter in perspektivischer Ansicht
  • Höhenprofil und Geschwindigkeitsverlauf
  • Motordrehzahl
  • Sonar
  • Servostellungen
  • sichtbare Satelliten
  • Geschwindigkeit und zurückgelegte Strecke
  • künstlicher Horizont mit Heading und Kugellibelle
  • GPS-Rohdaten, Temperatur, Bordspannungen, Windgeschwindigkeit (IAS)
  • Flugplan und aktuelles Kommando
  • Schieberegler mit Zeitanzeige (UTC)


Screenshot der Visualisierung

Auf der Webseite des Projektes EasyBot kann die Visualisierung in einer webstartfähigen Version gestartet werden.

Kapitel 3
13.03.2009, Achim Walther, Mail
Kapitel 5