Projekt Easybot

Das Projekt EasyBot ist die Weiterführung des Flobo-Projektes, welches ich zunächst aufgrund der Probleme mit dem Flobo-Prototyp aufgegeben habe. Mit dem EasyBot möchte ich zeigen, dass die autonome Steuerung eines Modellflugzeugs nur mittels GPS möglich ist, sofern das Modell eigenstabil ausgelegt ist.

Motivation

Nachdem die Tests mit dem autonomen Fahrzeug Zonda weitestgehend zufrieden stellend verlaufen waren, entschied ich mich im Sommer 2006 dazu, die Steuerungssoftware für ein Modellflugzeug weiter zu entwickeln. Als Testplattform wählte ich den allseits bekannten „Easy Star“, weil er ein gutmütiger Anfängerflieger ist, eigenstabil fliegt, also bei guter Trimmung selbständig wieder eine horizontale Fluglage einnimmt und leichte bis mittelschwere Abstürze durch die Elapor-Bauweise gut wegsteckt.

Plattform

Die beiden Rumpfhälften des Easy Star wurden beim Zusammenbau nicht wie vorgeschrieben geklebt, sondern mit 4 Nylonschrauben zusammengeschraubt. Zusätzlich wurde der Rumpf mit Klebeband verstärkt. Dadurch war es möglich, den Rumpf später wieder zu öffnen und die Anordnung der Komponenten zu verändern. Nach einigen Tests mit dem Originalmotor und einem 7-Zellen-Akku stellte sich heraus, dass der Flieger das Zusatzgewicht von ca. 150 Gramm kaum bewältigen kann. Also wurde der Motor durch einen 480er von Jamara ersetzt, eine Graupner Cam-SpeedProp Luftschraube 5,5 x 4,3 und ein 8-Zellen-Akku eingesetzt. Schließlich wurde auch das Seitenruder vergrößert, um die Steuerung auch bei Rückenwind und ausgeschaltetem Motor zu gewährleisten. Mit diesen Modifikationen erreicht der EasyBot auch mit Zusatzgewicht schnell eine Sicherheitshöhe, in der die ersten Tests zum autonomen Flug durchgeführt werden konnten.

Trial and Error

Nachdem die Software auf die zusätzliche dritte Dimension erweitert war, wurden zunächst Testflüge zum Datenlogging vorgenommen. Dann folgten Tests zum autonomen Geradeausflug. Dies bedeutete, der Flieger musste einfach nur seine Geschwindigkeit, Höhe und Richtung beibehalten, wobei jede Größe mit einer separaten PID-Regelung gesteuert wurde. Da aber die Regler-Parameter nicht bekannt waren, schwang sich die Regelung schnell auf und brachte das Modell fast zum Absturz. Daher entschied ich mich, die Parameter für jede Stellgröße einzeln auszutesten, d.h., das Modell teilautonom zu fliegen (in der Reihenfolge Seitenruder, Motor, Höhenruder). Weiterhin stellte ich fest, dass man die Stellgrößen nicht unabhängig betrachten darf, sondern dass sie sich gegenseitig beeinflussen. Das erscheint logisch – schließlich beeinflusst das Höhenruder die Wirkung des Seitenruders und der Schub hat wiederum Einfluss auf die Steigrate. Also führte ich in die Software sog. Mixer ein, die diese Beeinflussung modellieren. Auf diese Weise gibt es nun schon mehr als 10 Parameter, die abzustimmen sind. Im November 2006 gab es dann erste autonome Flüge über mehrere 100 Meter.

Probleme und Behebung

Neben den bereits beschriebenen Widrigkeiten gab es noch einige weitere Probleme, die behoben oder umgangen werden mussten:

• Reichweitenprobleme: die selbstgebaute Elektronik stört anscheinend erheblich den Empfang der RC-Signale. Die Störungen wurden gemildert, indem der Empfänger im Rumpf weiter hinter gelegt wurde – die Servos sind ja wegen des Servoumschalters nicht direkt mit dem Empfänger verbunden -, zusätzlich Ringfilter in die Signalleitung eingebracht, die Antenne frei hängend angebracht und die Motorkabel nach oben verlagert wurden.
• das Logfile weist Lücken auf, die nicht anhand der Software zu erklären sind. Das regelmäßige Flushen des Logfiles scheint das Problem noch zu verstärken. Auf der Linux-Konsole ist die Meldung „FAT: Filesystem panic clusters badly computed“ abzulesen, jedoch glaube ich nicht, dass die verwendete MMC-Karte schon am Ende ihres Lebenszyklus ist. Die bisherige Lösung ist ein regelmäßiges „fdisk /dev/mmc/mmc0/disk“. Eine softwareseitige Pufferung der Logdaten konnte das Problem bis auf wenige Ausnahmen beseitigen.
• Höhenmessung: ein unter der Tragfläche angebrachter Ultraschall-Sensor (Sonar) soll genaue Höhenangaben bei Bodenannäherung liefern. Der zuerst verwendete Sensor SRF02 erwies sich als unbrauchbar und wurde durch den SRF08 ersetzt. Dieser Sensor lässt sich über zwei Parameter konfigurieren. Damit kann die Empfindlichkeit und Reichweite soweit eingeschränkt werden, dass die Messdaten bis zu einer Höhe von 3 Metern zuverlässig sind. In größer Höhe gibt es unregelmäßig unsinnige Messdaten, die aber über eine softwareseitige Plausibilisierung ausgefiltert werden.
• nach ca. 100 Testflügen machte der 8-Zellen NiMH-Akku schlapp. Er wurde durch einen LiPo-Akku mit 7,4V / 2500 mAh ersetzt. Dieser gestattet deutlich mehr Testflüge pro Akkuladung als der alte Akku.
• GPS-Rate: die Update-Rate des Ublox-GPS musste von 5Hz auf 4Hz reduziert werden, da das Modul bei 5Hz anscheinend überlastet war und gelegentlich Messungen auslies. Die Rechenlast des Moduls hängt vermutlich auch vom eingestellten Platform Model ab (anfangs „3 – Automotive“, derzeit „5 – Airborne < 1g“).

Weiterentwicklung

Im Laufe der Zeit habe ich den EasyBot überarbeitet und ihm zusätzliche Sensoren verpasst. Hinzugekommen ist ein Anemometer (Umbau eines EA-3000), ein Drehzahlmesser, sowie der bereits genannte Ultraschall-Sensor. Die Steuerungssoftware wurde grundlegend überarbeitet: das Auslesen der GPS-Daten geschieht nun in einem eigenen Prozess, die Umsetzung der Flugplan-Kommandos wurde vereinheitlicht und das Logging verbessert. Der Flugplan besteht hauptsächlich aus Kommandos zum Fliegen von Geraden und Kurven, aber auch aus speziellen Anweisungen zum Start aus der Hand, der Zielhöhe und -geschwindigkeit. Nach der Umstellung der Regelung konnten im August 2007 erstmals autonome Streckenflüge vom Handstart bis zum Anflug durchgeführt werden.

Als nächstes soll die Navigation durch eine Planungsschicht erweitert werden. Diese soll komplexe Navigationsanweisungen und Flugmuster in die Streckenprimitive zerlegen. Auf diese Weise wird das Anfliegen eines Wegpunktes, die Patrouille eines vorgegebenen Gebiets oder die Rückkehr zum Startpunkt unter Beachtung der Ausrichtung der Landebahn umgesetzt. Sofern es Sensoren und Regelung erlauben, soll der Flieger schließlich auch autonom landen.

Diese soll komplexe Navigationsanweisungen und Flugmuster in die Streckenprimitive zerlegen. Auf diese Weise wird das Anfliegen eines Wegpunktes, die Patrouille eines vorgegebenen Gebiets oder die Rückkehr zum Startpunkt unter Beachtung der Ausrichtung der Landebahn umgesetzt. Sofern es Sensoren und Regelung erlauben, soll der Flieger schließlich auch autonom landen.

Leider kam es im Oktober 2007 bei einem Test neuer Regelungsparameter zu einem schweren Absturz, der den Rumpf des Easystar zerstörte. Es wird einige Zeit dauern, bis der neue Rumpf wieder entsprechend eingerichtet ist.

Regelung

Obwohl die separate Regelung einzelner Stellgrößen funktionierte (Bsp. Geschwindigkeit, Höhe), schwang sich das System bei autonomer Regelung aller drei Größen wieder auf. Die Ursache dafür ist vermutlich die eingangs erwähnte Kopplung der Stellgrößen, aber auch eine gewisse „Trägheit“ von GPS und Anemometer.

Ich entschied mich daher für eine konservative Regelung, bei der die Flughöhe nicht über das Höhenruder, sondern primär über den Schub geregelt wird. Um Höhe zu gewinnen, wird ein Vorgabewert zum PID-Wert der Geschwindigkeitsregelung addiert. Ein Mischer zwischen Gas und Höhenruder neutralisiert die schubabhängige Abwärtsbewegung. Das Höhenruder wird nur im Kurvenflug und minimal zur Geschwindigkeitsregelung im Steig- und Sinkflug eingesetzt. Um ein Übersteuern und damit Trudeln zu vermeiden, musste die Kursabweichung vor der Übergabe an die PID-Regelung begrenzt werden (+- 10 Grad). Obwohl dieser pragmatische Ansatz funktioniert, bemühe ich mich doch, ihn etwas zu systematisieren und damit auch den Sourcecode verständlicher zu machen.

An dieser Stelle möchte ich Harald „mare_crisium“ aus dem Roboternetz danken, der mich seit Anfang 2007 bei Fragen zur Regelung berät und bei Rückschlägen moralisch unterstützt!

Downloads

Der aktuelle Stand der Onboard-Software autofly findet sich hier. Weiterhin stelle ich die Logfiles der Testflüge zur Verfügung. Dieses können mit der Software FlightViz betrachtet werden. Das Programm wird über Java-Webstart geöffnet und setzt voraus, dass Java Version 1.4 oder höher installiert ist. Demnächst mehr über die Anzeigen und Bedienung des Programms sowie den Aufbau der Logfiles.