Hinweis: Aufgrund von konstruktionsbedingten Problemen mit dem Flugmodell wird das beschriebene Projekt nicht weiter betrieben. Die Aussagen zur Naviagtion, Simulation sowie zu den verwendeten Komponenten haben aber weiter Gültigkeit. Informationen über die aktuelle Entwicklung finden Sie unter EasyBot.

1 Einleitung

Flobo steht für Flying Robot und ist ein Projekt, aus dem irgendwann mal ein selbständig lenkendes Modellflugzeug werden soll (UAV, Aerial Robot). Diese Seite soll die Ideen und Konzepte für die Entwicklung eines solchen Flugzeuges darstellen und den Fortschritt beim Bau dokumentieren.

Seit 1996 beschäftige ich mich mit dem Thema GPS und dessen Anwendungsmöglichkeiten. 1997 kaufte ich mir das „Motorola Oncore GT“ GPS-Board und experimentierte damit herum. Da Modellfliegen ein weiteres Hobby von mir ist, entwickelte sich die Idee, GPS als Navigationsinstrument für ein autonomes Modellflugzeug zu benutzen. Bereits 1995 gab es in den USA einen Wettbewerb fliegender Robotor, an denen vor allem Teams von Universitäten teilnahmen. In den folgenden Jahren wurde es ruhiger bis ich Anfang 2004 die Idee wieder aufnahm.

Inzwischen hat sich auf diesem Gebiet schon eine Menge getan. So gibt es z.B. Anbieter von kompletten Autopilot-Systemen und Autonome Flugzeuge finden mittlerweile Anwendung auch außerhalb des Militärs, Beispielsweise in der Überwachung von Autobahnen. Flobo wird also nicht das erste Projekt dieser Art sein, aber zumindest gibt es meines Wissens in Deutschland zurzeit nur eine Handvoll ähnliche Projekte.

2 Anforderungen

Auch wenn man ein Projekt nur allein betreibt und deshalb eigentlich wissen sollte, was man bauen will, ist es trotzdem sinnvoll, zu Beginn die Gesamtanforderungen zu definieren. Die Anforderungen ermöglichen eine bessere Konzeption und helfen am Ende zur überprüfung und Einschätzung des Ergebnisses.

Die allgemeinen Anforderungen und Randbedingungen sind:

  • Verwendung eines gewöhnlichen Modellflugzeugs
  • Abfliegen eines vorgegebenen Flugplans mit Wegpunkten, Flugfiguren etc.
  • autonome Starts und Landungen
  • Umschalten auf manuelle Steuerung jederzeit möglich
  • Streckenflug, d.h. Start und Landung an verschiedenen Orten
  • Nachtflugfähigkeit
  • vernünftige Gesamtkosten
  • Erweiterbarkeit
  • Ausfallsicherheit, Redundante Auslegung wichtiger Komponenten

Abbildung 1 beschreibt den angestrebten Ablauf eines autonomen Fluges. Während der Startvorbereitung wird das Steuerungssystem gestartet, ein Flugplan eingegeben, der Motor gestartet und ggf. manuell Einstellungen vorgenommen. Dann arbeitet das Modell den Flugplan schrittweise durch alle Phasen ab, bis es nach der autonomen Landung zum Stehen kommt. Wenn erforderlich, können nun aufgezeichnete Daten abgefragt werden.

Abbildung 1: Flugphasen und autonomer Anteil

2.1 Zu messende Größen

Die nachfolgend aufgeführten Messgrößen beziehen sich auf ein einzusetzendes Flugmodell mit 1,5 – 2,5 m Spannweite und einem Verbrennungsmotor mit ca. 1 PS Leistung. Es sind alle Größen aufgeführt, die für einen autonomen Flug als notwenig erachtet werden.

MessgrößeErwarteter WertebereichGeeigneter Sensor
Geschwindigkeit über Grund0 – 30 m/sGPS
Höhe über Grund0 – 1000 mHöhenmesser, Ultraschall, GPS, Bodenradar
Windgeschwindigkeit-10 – +30 m/sStaudruckmesser, Windrad
PositionWürfel von +/- 10 km * +/-10 km * 1km vom StartpunktGPS
Fluglage / -richtungVollkreis um alle 3 Achsen, Winkelgeschwindigkeit max. 45°/sIMU, (GPS)
Motordrehzahl0 – 10000/sFotodiode, Hallsensor
Bodenkontakt0 / 1Schalter
Steig- / Sinkgeschwindigkeit+/- 5 m/s(berechnet)
Bodenannäherung+/- 2m/s(berechnet)

Von den aufgeführten Sensoren werden zunächst GPS, Ultraschall, IMU, Bodenkontakt und Drehzahlmesser mit Fotodiode betrachtet.

2.2 Ãœberblick

Aus den Anforderungen und den Messgrößen ergibt sich ein schematischer Aufbau des Steuerungssystems, wie ihn Abbildung 2 zeigt. Er bestehend aus Sensoren, Aktoren, Steuerungsbausteinen und Schnittstellen zur Programmierung und zum Monitoring. Als Sensoren kommen primär ein GPS-Empfänger, eine IMU sowie Ultraschallsensor, Motordrehzahlgeber und Bodenkontaktschalter in Betracht. Sollten die Daten dieser Komponenten nicht ausreichend sein, werden möglicherweise noch Geschwindigkeitssensor und Höhenmesser hinzugefügt. Für die Motorik werden gewöhnliche Modellbauservos eingesetzt. Um der Anforderung eines Rückfallkonzepts auf manuelle Steuerung gerecht zu werden, ist ein RC-Empfänger weiterhin nötig, jedoch ist er nicht mehr direkt an die Servos gekoppelt. Der als RC-Relais bezeichnete Baustein soll zwischen autonomer und manueller Steuerung umschalten. Ausgewählte Flug- und Statusdaten werden per Telemetrie an eine Bodenstation übertragen. Weiterhin ist ein Display geplant, welches vor allem während der Startvorbereitung Informationen über den Zustand oder Fehlersituationen liefern soll.

Abbildung 2: Übersicht über die Bestandteile des Steuerungssystems

Der Controller – als zentraler Bestandteil des Systems – liest und verarbeitet sämtliche Sensordaten, gleicht diese mit den Fluglagevorgaben und dem Flugplan ab und sendet entsprechende Steuerimpulse an die Motorik. Sowohl Controller als auch RC-Relais sollen stationär in der Schaltung programmierbar sein. Weiterhin soll der Controller über eine Schnittstelle verfügen, die Änderung von Flugplan und Konfigurationsdaten während der Startvorbereitung ermöglicht. Schließlich sollen nach dem Flug sämtliche gemessenen Daten und Logdateien auf einem PC gespeichert werden können.

2.3 Anforderungen an die Sensoren

GPS:

  • Positionsgenauigkeit < 5m für Länge, Breite und Höhe
  • Update-Rate 2 Hz, besser 4 oder 5 Hz
  • Geringer Stromverbrauch, niedriges Gewicht
  • serielle Schnittstelle mit TTL-Pegel, alternativ ähnliche Schnittstelle ohne zusätzlichen Schaltungsaufwand
  • NMEA-Ausgabeformat oder gut dokumentiertes Binärformat
  • WAAS-Unterstützung bzw. gleichwertiges Korrektursystem

IMU:

  • Messen von min. 6 Freiheitsgraden der Fluglage
  • Liefern einer stabilen Referenzlage über mehrere Minuten hinweg
  • Eigenstabilität des Flugzeugs wird dabei berücksichtigt
  • vibrationsgedämpft
  • Update-Rate min. 25 Hz, besser 50 Hz (entspricht der Servo Update-Frequenz)
  • Signale über genormte Schnittstelle

Ultraschallsensor:

  • Messung der Höhe über dem Boden während Start und Landung
  • Messbereich 0 – 8 Meter
  • Messgenauigkeit < 2 Meter
  • Genauigkeit und Update-Rate besser als GPS
  • gute Messergebnisse auch über Gras / unebenem Gelände besonders für geringe Höhen (Landeanflug)

Drehzahlmesser:

  • Rückkopplung des Throttle-Servos (Laufeigenschaft des Motors)
  • mögliche Rückschlüsse auf Windgeschwindigkeit bzw. Ãœberlastung während des Starts

Bodenkontakt:

  • zuverlässige Rückmeldung über Bodenkontakt bei Start und Landung
  • Bereinigung der Messungenauigkeiten von GPS-Höhenangaben und Ultraschallsensor

2.4 Anforderungen an die Steuerungskomponenten

2.4.1 RC-Relais

  • Umschalter zwischen autonomer Steuerung und Fernsteuerung
  • Als Eingangssignal dient PPM vom RC-Empfänger
  • Schaltet auf autonome Steuerung bei gesetztem Schaltkanal oder fehlendem Fernsteuersignal. Schaltkanal kann optional extern konfiguriert werden (Kanal 5, 6, 7 oder 8)
  • wird elektrisch vom RC-Akku gespeist und ist somit unabhängig von der Stromversorgung der autonomen Steuerungssystems
  • Kommuniziert mit dem Controller über I2C-Bus als Slave. Die Adresse kann optional extern konfiguriert werden (z.B. 4 Bit der 7-Bit Adresse)
  • im autonomen Modus werden Servovorgaben als 10-bit Werte über den Bus entgegengenommen
  • im Fernsteuermodus können die Servostellungen mit 10-bit Auflösung über den Bus abgefragt werden
  • Update-Rate 50 Hz (entspricht Servo-Update-Frequenz), besser 100 Hz im autonomen Betrieb
  • Notfallprogramm für gleichzeitigen Ausfall von Controller und Fernsteuerung
  • geringer Stromverbrauch, geringer Platzbedarf
  • ISP-Anschluss für die Programmierung

2.4.2 Controller

Die Anforderungen an den Controller sind bisher noch wenig konkret. Eine Orientierung geben vorhandene Produkte und Lösungen im Bereich der Robotik. Anzustreben wäre hier eine präzise Abschätzung der benötigten Rechenleistung auf Basis der oben gemachten Anforderungen an die Peripherie. Aufgrund der Ungenauigkeiten dieser Anforderungen und der Möglichkeit der späteren Erweiterbarkeit erscheint es besser, die Leistungsanforderungen großzügig zu stellen.

Schnittstellen:

Diese Anforderung lässt sich noch relativ einfach aus Abbildung 2 ablesen:

  • 2 – 3 bidirektionale serielle Schnittstellen min. 38400 Bit/s mit TTL-Pegel, passend zu den seriellen Sensorbausteinen
  • ein Peripherie-Bus-System, bevorzugt I2C bzw. CAN
  • komfortable Schnittstelle zur Programmierung, z.B. Ethernet / WLAN
  • binäre I/O-Leitungen mit der Möglichkeit externer Interrupts
  • 8 A/D-Wandler (ADC) mit 10 Bit Auflösung zur späteren vereinfachten Anbindung der IMU-Sensoren

Rechenleistung:

An dieser Stelle lässt sich nur die Rechenleistung abschätzen, die für die Verarbeitung der Sensordaten benötigt wird. Dies wäre im Einzelnen:

ModulRechenoperationHäufigkeitInstruktionen / s
GPSChecksummenprüfung, String-zu-Dezimal-Konvertierung, trigonometrische Funktionen5 / s10000
IMUChecksummenprüfung, Hex-zu-Integer-Konvertierung50 / s5000
UltrasonicBinär-zu-Dezimal-Konvertierung, Plausibilitätsprüfung, Fehlerkorrektur25 / s1000
DrehzahlBinär-zu-Dezimal-Konvertierung150 / s1500
Air SpeedBinär-zu-Dezimal-Konvertierung50 / s1000
ServoansteuerungDezimal-zu-String-Konvertierung50 / s1000
TelemetrieString-Konvertierung und -Formatierung2 / s500
Summe20000

Wie die Tabelle zeigt, schlägt der geschätzte Aufwand für die Bedienung der Peripherie kaum ins Gewicht und könnte wahrscheinlich von einem kleineren 8-bit Mikrokontroller bewältigt werden. Nicht zu vernachlässigen ist hier jedoch das Timing – die Signale treffen an zufälligen Zeitpunkten ein und müssen möglichst in Echtzeit verarbeitet werden.

Will man die Update-Rate der GPS-Positionsdaten künstlich erhöhen, also extrapolieren und wird es notwendig, einen Kalman-Filter für die Fehlerkorrektur aus den Sensordaten einzusetzen, erhöht sich der Rechenaufwand nochmals beträchtlich. Leider können zu diesem Zeitpunkt keine genauen Angaben darüber gemacht werden.

Es ergeben sich zunächst folgende Anforderungen:

  • 16-bit oder besser 32-bit Prozessor
  • Gleitkomma-Arithmetik-Unterstützung (FPU)

Speicher:

Diese Abschätzung fällt etwas leichter. Den größten Anteil des Speichers werden wahrscheinlich die gesammelten Sensordaten und Log-Dateien benötigen.

ModulGrösse eines Datensatzes (Byte)HäufigkeitByte / s
GPS1005 / s500
IMU4050 / s2000
Ultrasonic825 / s200
Drehzahl85 / s40
Air Speed85 / s40
Servo-Ansteuerung4050 / s2000
Sonstige Logs1005 / s500
Summe5280

Dies entspricht ca. 310 kByte pro Minute. Für einen 10-minütigen Flug würden also 3 MByte an Sensordaten anfallen. Schätzt man nochmals 1 MByte für Programm und Echtzeit-Betriebssystem, so ergibt sich ein Speicherbedarf von min. 4 MByte.

sonstige Anforderungen:

  • geringe Baugröße, z.B. Scheckkartenformat
  • geringer Stromverbrauch
  • robust, unempfindlich gegen Stöße
  • Echtzeitbetriebssystem bzw. Echtzeitprogrammierung möglich
  • unkomplizierter Anschluss, Entwicklungsboard und Entwicklungsumgebung
  • weit verbreitet, d.h., User-Community vorhanden

2.5 Flugplan

Der Flugplan besteht aus einem Script von Kommandos, das von der Steuerung sequentiell abgearbeitet wird. Für den ersten Ansatz sind keine Schleifen, Sprünge, Subroutinen oder ähnliches vorgesehen. Vorstellbar ist jedoch ein Deklarationsteil, der die Definition von Konfigurationsparametern, Wegpunkten oder Ausnahmebehandlungen enthält. Ein solches Script könnte folgendermaßen aussehen:

waypoint 1 50.1234N 10.4567E
waypoint 2 50.1200N 10.4580E

start 175
ascent 50
heading 180
straight 200
flyto waypoint 1
flyto waypoint 2
descent 50
approach 175
stop

3 Navigation

Dieses Kapitel beschäftigt sich mit der mathematischen Umsetzung der Ausführung eines Flugplans. Es werden Lösungen für die Berechung der Flugbahn vorgestellt. Es wird dabei davon ausgegangen, dass die Navigation auf ein System zur Lagestabilisierung aufsetzt, welches gesondert behandelt wird.

3.1 Bezugssysteme

Dem globalen Positionierungssystem GPS liegt ein geodätisches Bezugssystem zugrunde. Eine GPS-Position besteht aus geografischem Breitengrad (Latitude, λ), Längengrad (Longitude, φ) und Höhe über Meeresspiegel (Altitude, h).

Abbildung 3: geodätisches und lokales Bezugssystem

Eine für Deutschland gültige GPS-Position ist z.B. 50°27′ N, 12°33′ E, 310 m. Die Position ist z.B. aus dem NMEA-Datensatz GGA auszulesen:$GPGGA,205208.00,5048.1125,N,01242.3116,E,1,08,1.3,485.0,M,,M,,*72

Mit diesen Daten lässt sich zwar prinzipiell rechnen, jedoch ist es etwas umständlich. Deshalb wird ein lokales Bezugsystem (LB) eingeführt, dem ein rechtwinkliges Koordinatensystem zu Grunde liegt. Der Ursprung des lokalen Bezugssystems wird als der Startpunkt der Route des autonomen Roboters festgelegt, die X-Achse entspricht einer Gerade von West nach Ost, die Y-Achse einer Gerade von Süd nach Nord, jeweils durch den Ursprung und die Z-Achse einer gedachten Linie von Erdmittelpunkt durch den Ursprung. Abbildung 3 zeigt die Beziehung der Systeme zueinander.

Um nun eine GPS-Position in Koordinaten des LB umzurechnen, muss zunächst die GPS-Position des Startpunkts (Ursprung, O) bekannt sein. Weiterhin wird ein Umrechnungsfaktor f für die Einheiten Grad und Meter benötigt. Dieser kann aus dem Erdradius ermittelt werden, nachfolgend wird er mit 111200 m/grad angesetzt. Die Berechnung ist dann wie folgt:

Für den beschriebenen Zweck ist diese Umrechnung durchaus ausreichend, jedoch sollte man sich bewusst sein, dass sie nicht exakt ist, da sie unter anderem nicht die Abflachung der Erdkugel berücksichtigt. Sie ist weiterhin nicht geeignet für große Entfernungen, bei denen die Erdkrümmung einen zunehmenden Einfluss hat bzw. in Gebieten nahe des Nord- und Südpols.

Eine weitere Vereinfachung von Formel 1 ist die Verwendung von cosφ0 anstelle von cosφP. Hier wird davon ausgegangen, dass die maximale Entfernung einer Position P vom Ursprung nur wenige Kilometer beträgt, was auf die Winkeldifferenz von φ nur sehr geringen Einfluss hat und vernachlässigt werden kann. Somit muss nur einmalig eine trigonometrische Funktion ausgeführt werden, was Rechenleistung spart.

Beispiel 1

3.2 Grundbegriffe

3.2.1 Position

Wie in Beispiel 1 schon vorweggenommen, ist eine Position im lokalen Bezugssystem durch seine x-, y-, und z-Koordinaten gekennzeichnet. Mathematisch gesehen, ist es ein dreidimensionaler Vektor.

3.2.2 Bewegungsrichtung

Die Bewegungsrichtung lässt sich ebenso als Vektor darstellen. Dieser zeigt von der aktuellen Position in die Richtung der aktuellen Bewegung. Er wird nachfolgend auch als (Attitude) bezeichnet. Es ist sinnvoll, den Bewegungsrichtungsvektor zu normieren, so dass er unabhängig von der Geschwindigkeit v der Bewegung wird. Für eine geradlinig, gleichförmige Bewegung gilt demnach:

Mit GPS-Daten als einzige Basis gibt es zwei Möglichkeiten, die Bewegungsrichtung zu bestimmen. Zum einen kann die Differenz der Position von zwei zeitlich nacheinander liegenden Messungen errechnet, zum anderen direkt der Heading- bzw. Track-Wert ausgelesen werden.

Umrechnung Winkel zu Vektor:

Der Track-Wert kann beispielsweise aus dem NMEA-Datensatz VTG gelesen werden. Dort steht er als erster Wert nach der Satzkennung: $GPVTG,205.1,T,,M,0.4,N,0.8,K*6A

Er gibt den Winkel im Uhrzeigersinn zur Nordrichtung an. Unser geometrisches Koordinatensystem bezieht sich jedoch auf die x-Achse und läuft entgegen dem Uhrzeigersinn (siehe Abbildung 4). Die Umrechnung geschieht wie folgt:

Zur Umwandlung eines Richtungswinkels in einen Richtungsvektor werden die Sinus- und Cosinus-Funktion benutzt

Abbildung 4: Track und geometrischer Winkel

Umgekehrt lässt sich der Arcustangens nutzen

Dabei ist zu beachten, dass der x-Anteil des Vektors nicht 0 sein darf. Wenn x = 0 ist, verläuft der Vektor parallel zur y-Achse, ist a also – abhängig von y – 90° oder 270°. Manche Programmiersprachen bieten für diesen Fall spezielle Funktionen, welche x und y als Parameter haben und Sonderfälle berücksichtigen. In Java beispielsweise die Methode Math.atan2(double y, double x).

3.3 2D-Manöver

3.3.1 Ansteuern eines vorgegebenen Punktes

Wir gehen davon aus, dass sich ein Flugzeug zu einem gewissen Zeitpunkt im Punkt A befindet und sich geradlinig gleichförmig in Richtung fortbewegt. Es bekommt nun den Befehl, einen Punkt C anzusteuern. Dazu muss es seine Bewegungsrichtung ändern, also eine Kurve fliegen. Als Vereinfachung kann diese Kurve als Kreissegment angesehen werden, das in Punkt A beginnt und in Punkt B endet. Nachdem Punkt B erreicht ist, geht die Flugbahn wieder in eine Gerade über.

Abbildung 5: Anfliegen eines Punktes

Für die Berechnung der Flugbahn ist nun der Punkt B gesucht. Er kann geometrisch als Tangentenberührungspunkt angesehen werden, der die Kreisbahn schneidet, welche die Kurve darstellt.

Abbildung 6: Darstellung von B als Berührungspunkt

Abbildung 6 zeigt einen Kreis mit dem Radius r und Mittelpunkt M, der zur Darstellung der Kurve dient. Es ist ersichtlich, dass es zwei mögliche Tangenten für den Kreis gibt, die durch Punkt C gehen. Im gezeigten Fall ist der Punkt Bl gesucht.

Doch zunächst müssen wir den Kreismittelpunkt M berechnen. Dazu muss entschieden werden, ob eine Rechts- oder Linkskurve geflogen wird.

Rechts oder Links?

Die Frage nach einer Links- oder Rechtskurve lässt sich auf die Frage zurückführen, auf welcher Seite des Bewegungsvektors a sich der anzusteuernde Punkt C befindet. Also, ob der Winkel zwischen a und AC positiven oder negativen Drehsinn hat. Dies lässt sich einfach über die Determinante tun:

Für den Fall aus Abbildung 6 gilt:

Beispiel 2

Orthogonale Vektoren

Wir wissen nun, dass unser Flugzeug eine Linkskurve fliegen muss. Also muss auch der Mittelpunkt der Kurve auf der linken Seite liegen. Da das Flugzeug sofort mit der Kreisbewegung beginnt (Vereinfachung, siehe oben), können wir den Richtungsvektor als Tangente an der Kreisbahn betrachten. In diesem Fall steht der Radius der Kreisbahn senkrecht auf dem Richtungsvektor. Um den Mittelpunkt M zu finden, müssen wir also einen zu a senkrechten Vektor bestimmen, der die Länge des Kurvenradius r hat.

Dazu führen wir eine Rotation um 90° auf a aus. Da a normiert ist, d.h. die Länge 1 hat, muss der um 90° gedrehte Vektor noch mit r multipliziert werden. Formel 7 zeigt die Herleitung über die Rotationsmatrix. Es ergibt sich die in Formel 9 gezeigte Lösung.

Damit kann der Mittelpunkt der Kreisbahn ermittelt werden, der links neben Punkt A liegt. Für den Fall dass M rechts liegt, also eine Rechtskurve geflogen wird, handelt es sich um einen negativen Drehsinn, und entsprechend ist der Winkel a = -90°. In diesem Fall ändert sich nur das Vorzeichen, wie in Formel 10 zu sehen ist.

Um Formel 9 und 10 zu verallgemeinern, führen wir den Parameter s ein, der den Drehsinn der Kurve angibt. s kann nur die Werte -1 ^= rechts und +1 ^= links annehmen.

Tangente

Nun kann der in Abbildung 6 gesuchte Punkt Bl ermittelt werden. Dabei sind drei Dinge bekannt. Die Länge der Strecke MC, da Punkte M und C bekannt sind. Die Länge der Strecke MB, nämlich r, sowie der Winkel zwischen MB und BC, nämlich 90°. Mit Hilfe des Pythagoras kann nun zunächst die Länge von BC ermittelt werden, für spätere Zwecke wird der Faktor q eingeführt, der das Verhältnis zwischen den Längen von BC und r angibt.

Wie in Formel 12 angemerkt ist q nicht definiert, wenn der Radius 0 und der Abstand zwischen M und C kleiner als der Radius ist. Beides ist grafisch leicht nachvollziehbar. Weiterhin muss angemerkt werden, dass q eigentlich zwei Werte annehmen kann, nämlich einen positiven und einen negativen. Im gezeigten Zusammenhang ist eine negative Streckenlänge jedoch nicht sinnvoll, weshalb der negative Wert nicht verwendet wird.

Da die Strecke BC senkrecht auf MB mit positivem Drehsinn steht, kann Formel 8 angewendet werden:

Daraus wird nun Bl hergeleitet:

Für Rechtskurven ist die Berechnung analog mit dem negierten Wert von q ausführbar.

Beispiel 3

Nun stellt sich die Frage, ob die Berechung der Tangentenberührungspunkte wirklich notwendig ist. Schließlich kann ein autonomes Flugzeug ja auch durch häufiges Messen von Abstand und Winkel feststellen, ob die Bewegung in der Kreisbahn fortgesetzt werden muss oder nicht. Der Vorteil von der Berechnung ist zum einen sicher die höhere Genauigkeit – der Zeitpunkt des Endes des Kurvenflugs kann exakter berechnet werden, als es die Messzyklen (bei GPS 1 – 4 Hz) zulassen. Zum anderen ist es die Grundlage zur Berechnung des nächsten Manövers, welches mit Hilfe eines einfachen Regelkreises nicht mehr genau gesteuert werden kann.

3.3.2 Ansteuern eines Punktes aus einer gegebenen Richtung

Für den Landeanflug ist es zwingend notwendig, dass die Landebahn genau im Winkel ihrer Ausrichtung angeflogen wird. Während des finalen Sinkflugs vor dem Aufsetzen sollte keine Kurve mehr geflogen werden, also ergibt sich die Aufgabe, den Eintrittspunkt für den finalen Sinkflug im vorgegebenen Winkel der Landebahn anzufliegen.

Abbildung 7: Anfliegen von Punkt D aus einer gegebenen Richtung

In Abbildung 7 ist zu erkennen, dass für das Manöver zwei Kreisbewegungen nötig sind. Die erste Kreisbewegung dient zur Annäherung an den Eintrittspunkt – hier mit D bezeichnet. Die zweite Kreisbewegung führt schließlich zur Richtungsänderung entsprechend der Vorgabe. Die Richtungsänderung wird so ausgeführt, dass sie genau in Punkt D beendet ist. Die vorgegebene Richtung in Punkt D wird nachfolgend mit d bezeichnet.

Die Aufgabe ist nun, die Verbindungsstrecke BC zwischen den beiden Kreisbahnen zu bestimmen. Geometrisch betrachtet, handelt es sich dabei um die Tangente zwischen zwei Kreisen. Abhängig davon ob die erste und die zweite Kurve den selben Drehsinn haben oder nicht, ist es eine äußere bzw. innere Tangente. Zunächst muss also der Drehsinn der beiden Kurven ermittelt werden.

Drehsinn der Kurven

Ein einfacher Algorithmus für die Bestimmung des Drehsinns der Kurven ist, die kürzeste Verbindung zwischen den Punkten A und D zu benutzen und sie jeweils mit den Richtungsvektoren a und d zu vergleichen. Aus den beiden sich ergebenden Determinanten lässt sich der jeweilige Drehsinn ermitteln. Wie später noch gezeigt wird, führt das Verfahren unter gewissen Bedingungen zu Fehlern bzw. nicht optimalen Lösungen.

Abbildung 8: Ermittlung des Drehsinns der Kurven

äußere Tangenten

Mathematisch leicht zu lösen ist die Berechnung der äußeren Tangenten, also der Verbindungsstrecken für zwei Kurven mit gleichem Drehsinn. Für den Fall, dass die beiden Kurven den gleichen Radius haben – was wir hier voraussetzen – ist nämlich die Tangente parallel zur Verbindungsstrecke der Mittelpunkte. Sie hat außerdem die gleiche Länge und bildet zusammen mit dem jeweiligen Radius ein Rechteck.

Abbildung 9: Konstruktion der äußeren Tangente

Die Mittelpunkte M und N können mithilfe der zu a und d orthogonalen Vektoren wie bereits gezeigt berechnet werden. Dazu müssen a und d normiert vorliegen:

Nun wird Vektor b eingeführt und normiert.

Ausgehend von M und N können nun die Punkte B und C über die orthogonalen Vektoren von b mit der Länge r errechnet werden. Der Drehsinn ist hier dem der Kurven entgegengesetzt:

Beispiel 4

Innere Tangenten

Für die Berechnung der inneren Tangente ermitteln wir zunächst wieder die Mittelpunkte M und N der beiden Kreisbahnen. Nun führen wir den Punkt E als Schnittpunkt der Strecken MN und BC ein. Dabei gilt

und folglich

Abbildung 10: Konstruktion der inneren Tangente

Nun wird B als Tangentenberührungspunkt der Tangente durch Punkt E berechnet.

q n. def. für r = 0 und |MN| < 2r

C wird jetzt als Verlängerung der Strecke BE mit Faktor 2 berechnet.

Beispiel 5

Problemfälle

Wie schon kurz erwähnt, ist der Algorithmus zur Bestimmung des Drehsinns der beiden Kurven nicht fehlerfrei. Im Folgenden werden zwei Fälle vorgestellt, in denen er eine falsche Lösung liefert.

Abbildung 11: Verfahren liefert falsche Lösung

In Abbildung 11 liegt D von a aus gesehen rechts. Es könnte also zuerst eine Rechtskurve geflogen werden. Da aber auf diese Weise D niemals in Richtung d angeflogen werden kann, muss zuerst eine Linkskurve und dann eine Rechtskurve geflogen werden.

Abbildung 12: Verfahren liefert ungünstige Lösung

Abbildung 12: Verfahren liefert ungünstige Lösung

In Abbildung 12 liegt D von a aus gesehen rechts. Demnach wäre die erste Kurve rechts. Von der Innentangente zeigt d nach links, also wäre die zweite Kurve eine Linkskurve. Tatsächlich ist es aber kürzer, zwei Linkskurven zu fliegen.

3.4 Anmerkungen

3.4.1 Genauigkeit

Die vorgestellten Lösungen können nur als Vereinfachung einer tatsächlichen Flugbahn betrachtet werden. In der Realität wechselt eine geradlinig gleichförmige Bewegung niemals abrupt in eine Kreisbewegung sondern es findet ein Übergang statt. Die dabei entstehende Flugbahn wird Klotoide bezeichnet. Für genauere Berechnungen sollten also zukünftig die Klotoide einbezogen bzw. ein Verfahren geliefert werden, welches den Übergang von geradliniger und Kreisbewegung hinreichend genau modelliert.

3.4.2 Ausblick

Die vorgestellten Lösungen sind nur ein kleiner Teil dessen, was zur Steuerung eines autonomen Flugzeugs benötigt wird. Die Berechnung wichtiger Wegpunkte wurde vorgestellt – nun werden Lösungen benötigt, die eine Kontrolle über die Einhaltung der geplanten Bewegung ermöglichen. Beispielsweise sollte die Steuerung während eines Kurvenflugs ständig die aktuelle Position mit der Vorgabe vergleichen und entsprechende Korrekturen einleiten können. Für den Geradeausflug ist eine Korrektur des Seitenwinds wünschenswert. Weiterhin wurden dreidimensionale Manöver bisher ausgelassen, ebenso der Einfluss der Fluggeschwindigkeit. Für den Landeanflug – dem wohl schwierigsten Manöver – wird der Einfluss aller genannten Größen eine Rolle spielen, ebenso muss auch die Bahnkorrektur die Faktoren Position, Richtung und Geschwindigkeit gleichzeitig einbeziehen.

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.gzSimulationsumgebung (92kB). Voraussetzung: FlightGear, Ubuntu oder ähnliches Linux-System

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

5 Hardware

5.1 Flieger

Zum Fliegen braucht man erstmal ein Flugzeug. 1999 hatte ich schon mal einen Prototyp angefangen und im Sommer 2004 fertiggestellt. Leider hatte er den Jungfernflug nicht überlebt. Die Tatsache, dass die Ursache wahrscheinlich ein Pilotenfehler war, ermutigte mich, einen neuen Prototyp zu entwickeln. Wie der erste sollte er über Rückstrahlantrieb verfügen und durch einen 6 ccm Verbrennermotor getrieben werden. Im Rückstrahlantrieb sehe ich den Vorteil, dass Abgase und Treibstoffrückstände sich nicht am Rumpf festsetzen können und somit nicht die dort angebrachten Sensoren beeinflussen können. Als Tragflächen wollte ich die meines ersten Elektroseglers (Graupner Thermik Sport) verwenden – sie haben 2.5 m Spannweite und sind durch V-Form und Flügelohren einfach zu fliegen.

Diesmal verwendete ich ein CAD-Programm zur Konstruktion. Die Zeit, die zur Einarbeitung aufgewendet werden musste, zahlte sich später aus. So konnte ich verschiedene Lösungsvarianten durchspielen und das Modell aus allen Ansichten betrachten und Fehler beseitigen, bevor es gebaut wurde.

Abbildung 15: Konstruktionszeichnung
Download:Flobo1 DXF225kB

Der Rumpf des Flugzeuges besteht aus 6mm Sperrholz, das einen sehr stabilen Kastenrahmen bildet. Zusätzliche Verstrebungen dienen als Motorträger, Aufnahme des Tanks oder Verbindung zum V-Leitwerk. Durch den relativ schweren Motor (700g mit Auspuffanlage) liegt der Schwerpunkt des Modells ziemlich weit hinten. Aus diesem Grund lohnt es nicht, durch allzu große Aussägungen Gewicht sparen zu wollen. Der Rumpf ist mit Balsaholz beplankt und mit Folie bespannt. Zwei Kohlefaserrohre verbinden den Rumpf mit dem Leitwerk, welches aus Balsa besteht. Ein 300 ml Tank befindet sich unterhalb der Tragflächen. Weil der Tank einige Zentimeter unterhalb des Vergasers liegt, kam es zu Problemen mit der Treibstoffzufuhr. Aus diesem Grund wurde später der Motor nach unten gedreht.

Schwerpunkt und andere dynamische Eigenschaften konnten nicht am Computer berechnet werden. Nachdem das Modell fertiggestellt wurde, mussten noch 350g Blei an der Front angebracht werden, um den Schwerpunkt herzustellen. Erste Rollversuche waren erfolgreich. Es zeigt sich jedoch, dass das Modell mit knapp 4 kg insgesamt zu schwer ist. Nach dem Einbau eines lenkbaren Bugrades und erneuter Trimmung ging es zum erstem Mal in die Luft. Leider wurde das Flugzeug nach kurzer Zeit unkontrollierbar und begann sich um die Längsachse zu drehen. Die Ursache könnte in er Aufhängung des Leitwerks liegen, welche vermutlich starken Strömungskräften ausgesetzt war. Der Absturz war hart, aber der Schaden relativ gering. Ich überlege nun, ob ich es nicht besser mit einem gekauften Modell versuchen sollte…

Abbildung 16: Fertiges Flobo-Flugzeug

5.2 Controller

Als Controller habe ich mich zunächst für das Gumstix-Controllerboard entschieden. Dabei handelt es sich um einen extrem kleinen Rechner auf ARM-Basis, auf dem ein Embedded-Linux mit 2.6er Kernel läuft. Nähere Info zum Board finden sich auf der Gumstix-Homepage. Das Board verfügt über einen Intel XScale-PXA255-Prozessor mit 200MHz Systemtakt. Es bietet 3 serielle, eine I2C-Schnittstelle und einen Slot für SD / MMC-Karten. Zusätzlich gibt es eine Reihe von IO-Pins, die allerdings alle über einen winzigen Connector angeschlossen werden müssen. Für Einsteiger empfiehlt es sich, ein sogenanntes Breakout-Board mit zu bestellen. Über dieses sind die wichtigsten Schnittstellen, wie auch I2C herausgeführt. Allerdings gibt es keine AD-Converter. Diese müssen bei Bedarf extern realisiert und über die Schnittstellen angebunden werden.

Abbildung 17: Gumstix Controller-Board

Mittlerweile habe ich das Board auch schon zum Leben erweckt. Dazu musste ich allerdings noch ein zweites Board bauen, das Stromversorgung und RS232-Treiber bereitstellt. Nach dem Einschalten startet zunächst der uboot-Bootloader und anschließend das eigentliche Linux. Über eine serielle Leitung mit 115200 Bit/s kann man den Bootvorgang mitverfolgen und sich anschliessend auch einloggen. Anfängliche Problem mit der Übertragungsqualität habe ich inzwischen behoben. Die Ursache waren falsch gepolte Elkos am MAX3232 Pegelwandler. Mit dem entsprechenden Breakout-Board lässt sich der Gumstix auch über USB mit dem PC verbinden. Im Gumstix-Wiki ist beschrieben, wie im PC eine Brücke zum LAN hergestellt und der Gumstix schliesslich an das LAN angeschlossen wird. Nachdem dieser sich per DHCP eine IP-Adresse besorgt hat, ist es möglich, ihn per HTTP oder SSH anzusprechen. Das Programmieren und Übertragen von Programmen ist nun leicht möglich.

Abbildung 18: Gumstix-Console auf dem Palm

5.3 GPS

Nachdem ich mehrere Produkte verglichen hatte, habe ich mich für ein U-Blox Modul entschieden. Speziell das SAM-LS scheint für meine Zwecke gut geeignet zu sein. Es hat eine integrierte Antenne, also erspart man sich zusätzliche Antennenkabel. Besonders vorteilhaft ist die Position-Update-Rate von 4Hz. Die Positionsdaten werden also maximal 4 mal pro Sekunde über zwei serielle Schnittstellen entweder im NMEA-Format oder in anderen Binärformaten ausgegeben. Dazu gibt es von der Webseite des Herstellers gute Dokumentation und Software zur Evaluation und Konfiguration des Moduls.

Nachteilig ist allerdings der Anschluß des Moduls. Dazu benötigt man ein sogenanntes FFC-Kabel mit 20 Adern im Raster von 0.5 mm. Modul und Kabel können als Sample direkt bei U-Blox in der Schweiz bestellt werden. Dies kostet ca. 120 Euro plus Steuer und Versand. Wesentlich günstiger habe ich es beim deutschen Vertrieb Pointis bekommen. Dort kostet das Modul 59 Euro plus MWSt und Versand. Leider war das Kabel nicht vorrätig. Und es ist ein echtes Problem, ein solches Kabel mit Stecker zu bekommen. Letzlich habe ich mir Kabel verschiedener Länge und entsprechende Buchsen bei Digikey bestellt, was auch nicht ganz billig war.

Abbildung 19: U-Blox SAM-LS Modul ohne Anschlusskabel

Wenige Augenblicke nach dem Anschluss des Moduls an mein Testboard erschienen schon Satelliten- und Positionsdaten über die Schnittstelle. Allerdings tauchen echte Probleme auf, wenn GPS und Gumstix in unmittelbarer Nähe zueinander betrieben werden. Das Gumstix-Board scheint so viel elektromagnetische Störungen zu erzeugen, dass der Satellitenempfang völlig ausfällt. Die beiden Komponenten sollen aber in Zukunft sehr nahe beienander plaziert werden. Also besteht die nächste Aufgabe in der Abschirmung des Gumstix-Boards.

5.4 IMU

Das Projekt Do it yourself UAV entwickelt einen Autopilot für Modellhubschrauber. Die zugehörige Hardware besteht aus 2 Beschleunigungssensoren, 3 Gyro-Sensoren und einem ATMega-Controller. Es ist in der Lage, selbständig Servos anzusteuern, jedoch sind diese Features schlecht bzw. gar nicht dokumentiert. Zum Projekt gehört die Firma Rotomotion, welche komplette Module oder Bausätze vetreibt. Für rund 300 Dollar plus Versand und Zoll habe ich mir das 6DOF IMU Kit bestellt und aufgebaut. Mit der zugehörigen Software lassen sich Beschleunigungen und Drehbewegungen erfassen und verarbeiten. Im unbewegten Zustand kann also die Lage bezüglich der Raumachsen gemessen werden.

Das Modul wurde bisher nur auf dem Schreibtisch getestet. Von daher können noch keine Aussagen zur Drift und Temperaturabhängigkeit gemacht werden. Auch inwiefern intern schon ein Kalman-Filter realisiert ist, ist nicht dokumentiert und nur anhand des Quellcodes herauszufinden. Sobald das Flugzeug einige erfolgreiche Testflüge absolviert hat, werde ich Controller, GPS und IMU einbauen und Messungen durchführen.

Abbildung 20: Rotomotion 6DOF-IMU

Abbildung 20: Rotomotion 6DOF-IMU

5.5 Sonar

Zur Abstandsmessung zu Boden soll das Polaroid Ultrasonic Ranging System eingesetzt werden. Mein Kumpel Frank hat mir freundlicherweise ein OEM-Kit mit zwei Modulen der 6500er Serie zur Verfügung gestellt. Das Modul liefert Entferungsmessungen im Bereich von 1 bis 10 Metern und wird mit einem kleinen ATMega gesteuert.

Im Versuchsaufbau konnten bereits Entfernungsmessungen vorgenommen und die Messdaten auf den PC übertragen werden. Der Messbereich lag dabei zwischen 0,5 und 6 Metern. Allerdings wurden auch Störungen und Abweichungen festgestellt. Hier muss also weiter an der Kalibrierung gearbeitet werden. Ebenso sind exakte Messungen im Freien mit verschiedenem Untergrund durchzuführen.

Abbildung 21: Polaroid Sonar im Versuchsaufbau

5.6 Weitere Sensoren

Die Messung der Geschwindigkeit in der Luft (Airspeed) soll durch ein Windrad vorgenommen werden. Auf diese Idee brachte mich die Datenlogger-Seite von Dietrich Meissner. Das Windrad wurde aus einem Prozessorlüfter für Notebooks gebaut. Es kann mit minimaler Beschaltung an einen AD-Converter eines ATMega angeschlossen werden.

Die Drehzahl des Motors wird mit Hilfe einer Reflexlichtschranke (SFH 9201) gemessen. Dazu wurde die Nabe der Propellerbefestigung entsprechend schwarz lackiert, so dass die Lichtschranke pro Umdrehung einen Impuls sendet. Die Impulse sollen später ebenfalls mit dem ATMega erfasst und in Umdrehungen pro Minute umgewandelt werden. Die Daten sollen schließlich per I2C an den Hauptcontroller gesendet werden.

Abbildung 22: Sensoren für Airspeed und Motordrehzahl

5.7 Adapter-Board

Das Adapter-Board dient zur Stromversorgung des Gumstix-Controllers, sowie zu dessen mechanischer Befestigung und natürlich zur Anbindung sämtlicher Sensoren und Module. Der Hirose-60-Connector ist auf der Rückseite des Boards angebracht. Fast alle anderen elektronischen Bauteile befinden sich auf der Vorderseite. Die Leiterplatte wurde so entworfen, dass der Gumstix von einer Abschirmung umgeben werden kann. Wie oben bereits erwähnt, bereitet die Störstrahlung des Gumstix Probleme beim Satellitenempfang, also muss er von einer möglichst dichten Schirmung umgeben werden.

Abbildung 23: Fertiges Adapter-Modul im Gehäuse

Die mittlerweile zweite Version des Adapterboards hat folgende Merkmale:

  • Spannungsregelung von 3.3V und 5V für die Versorgung mit 4- oder 5-Zellen RC-Akkus
  • Anbindung des GPS-Moduls über serielle Schnittstelle sowie Speicherpufferung mit Knopfzelle
  • Anbindung von Sonar, Drehzahlmesser, Airspeed-Sensor, Temperatursensor und zwei Schaltkanälen
  • ein ATMega8 mit I2C-Schnittstelle zum Gumstix zuständig für das Sammeln der Sensordaten
  • nach aussen werden zwei RS232-Schnittstellen angeboten, über die Gumstix-Console, beide GPS-Schnittstellen sowie der ATMega8 verfügbar sind
  • I2C Levelshifter zum Umsetzen der I2C-Leitungen zwischen 3.3V und der Spannung des RC-Empfängers (5V)
  • Messen der Akku-Spannung beider Stromkreise über entspr. Spannungsteiler und AD-Konverter
  • Statusanzeige über 4 externe LEDs, die per Kabel angesteckt werden können
Abbildung 24: Schaltplan Gumstix-Adapter
Download:gum_adaptor3.schgum_adaptor3.brd

Die Leiterplatte habe ich fertigen lassen. Das Löten der meisten SMD-Bauteile gestaltet sich einfach mit Ausnahme des Hirose-Connectors. Dieser hatte mir bei der ersten Version des Boards enorme Probleme mit Lötbrücken bereitet, die das Board schliesslich auch unbrauchbar gemacht haben. Deshalb habe ich mich diesmal dazu entschieden, den Connector im Reflow-Verfahren von einer Firma einlöten zu lassen. Für die Schirmung wurde Weissblech von Getränkedosen verwendet – Jever passt hier farblich gut. Das Blech ist allerdings so dünn, dass es bei der Bearbeitung mit einem Profil für höhere Steifigkeit versehen werden sollte. Fertig bestückt und in ein Gehäuse verpackt wiegt das gesamte Modul etwas weniger als 60 Gramm.