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.

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:

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.

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