Category Archives: Benutzeroberfläche (GUI)

Dritter Testtag

Nach zwei Fehlschlägen (Fehlschlag 1, Fehlschlag 2) beim Start wegen falsch gesetzten GPS-Koordinaten und starkem Wind konnten wir zuletzt relativ stabil unsere Wegpunkte abfliegen (Videozusammenstellung des GUIs und des Fluges). Beim erfolgreichen Flug wurden drei Durchgänge der Kommando-Warteschlange geflogen und dabei die Geschwindigkeit inkrementell erhöht. Beim dritten Durchlauf versagt die Höhensteuerung der Drohne und es kommt zur Notlandung – als Grund hierfür vermuten wir das höhere Gewicht durch das GPS-Modul und Reparaturen am Rotorenkreuz.

Zweiter Testtag mit autonomen AR.Drone Flügen

Zum heutigen Testtag haben wir zwei weitere Kontroll-Algorithmen implementiert und getestet. Beim ersten autonomen Flug setzten wir noch auf einen naiven und sehr defensiven Algorithmus, der ab einer definierbaren YAW-Winkelabweichung zum Ziel zunächst stoppte und die YAW-Ausrichtung der Drohne vor dem Weiterfliegen anpasste. Dies funktionierte auf Anhieb wie gewünscht und brachte die Drohne zuverlässig ans Ziel.

ROLL, PITCH, YAW / Rollen, Neigen, Gieren

Der in dieser Videozusammenstellung des zweiten Fluges zu sehende Algorithmus steuert nicht mehr nur ausschliesslich nur eine sowie abwechselnd der beiden Achsen YAW und PITCH der AR.Drone, sondern kombiniert die Kurskorrekturen in beiden Achsen ständig.

Der dritte Algorithmus korrigiert neben den YAW und PITCH auch noch die Höhe auf ein bestimmtes Niveau. Aus den Videos geht augenscheinlich hervor, dass dieser Algorithmus die AR.Drone wesentlich langsamer und ungenauer zu seinem Ziel führt. Hier geht es zur Videozusammenstellung des dritten Fluges.

Allerdings konnten wir nach diesem Test ein beschädigtes Kabel ausfindig machen und mussten dieses erneut anlöten. Dieser Defekt hatte fehlerhafte GPS-Daten zur Folge, die vermutlich starken Einfluss auf den Testflug hatten.

Beschädigtes GPS-Kabel

Beschädigte GPS-Steckverbindung

Erster autonomer Flug mit der AR.Drone 2

Unser erster autonomer Flug mit der AR.Drone 2 ist geglückt. Hier geht es zum Video und parallelen Screencast - die Videos sind zum Zeitpunkt des Starts synchronisiert. Die AR.Drone wird dabei von der Bodenstation aus mit Kommandos bestückt und arbeitet diese dann wie im Video zu sehen ab.

Auf dem Screencast ist die Kontroll-Anwendung zu sehen, die auf NASA WorldWind aufbaut und das Zusammenklicken eines Flugpfades über eine Satellitenaufnahme des Flugbereichs ermöglicht. Der Flugpfad und weitere Kommandos werden als eine Kommando-Warteschlange repräsentiert und nacheinander abgearbeitet. Architektur und beispielhafte Sequenzdiagramme/Zustandsdiagramme der Kommando-Warteschlange folgen.

Nachfolgend noch einmal beide Videos einzeln:

AR.Drone 2.0 SDK Build mit crunchbang 11

Der Build des AR.Drone 2.0 SDK (v2.0.1) funktionierte nicht auf Anhieb reibungslos, weshalb ich das Vorgehen für Nachahmer und zur eigenen Dokumentation hier noch einmal aufführe.

Wir arbeiten mit der 32-bit Version von crunchbang linux 11 (eine Debian-Distribution), die jeweils in einer VirtualBox-VM abläuft. Achtung, laut Developer-Guide des AR.Drone SDK sind die enthaltenen Beispiele explizit nur auf 32-Bit-Systemen lauffähig. Es sei am Rande vermerkt, dass die Installation der VBox-Additions (zum Nutzen von Shared-Folders des Host-Systems) unter crunchbang nicht ohne weiteres funktionierte – Abhilfe schafft hier dieser Post im crunchbang-Forum.

Nach der Installation von crunchbang 11 und dem upgrade der Pakete müssen zunächst die folgenden SDK-Abhängigkeiten installiert werden:

Nun das AR.Drone SDK 2.0.1 von der Projekt-Webseite beziehen und entpacken

und den Build starten:

Nun den Host-Computer mit dem W-LAN der AR.Drone 2.0 verbinden und sicherstellen, dass das crunchbang Gastsystem via NAT auf die AR.Drone zugreifen kann (Standard IP ist die 192.168.1.1). Ist die Drohne anpingbar, so können die mitgelieferten Linux-Beispielanwendungen gestartet werden:

Nun kann der Spaß beginnen ;-)

Linux-Beispielanwendungen des AR.Drone 2.0 SDKs

Linux-Beispielanwendungen des AR.Drone 2.0 SDKs

UI mittels NASA World Wind und weitere ARDrone-Hacking-Recherchen

Nach der Evaluierung möglicher UI-Umsetzungen per JXMapViewer, gmap-viewer, simpler Google-Maps-API-Nutzung mit JavaScript und per NASA World Wind-Projektes, wurde das NASA World Wind-Projekt als das vielversprechendste identifiziert. Allein schon die Demos zeigen, welch großes Potential in der NASA Wold Wind-Nutzung für unser Projekt steckt. Deshalb war heute eines der zentralen Punkte die Einrichtung der Arbeits- und Entwicklungsumgebung. Konkret: NetBeans + World Wind Java SDK zum Laufen zu bringen.  Anschließend wurde erfolgreich eine erste Beispielanwendung aufgesetzt.

Um World Wind unter einem 64-Bit-System nutzen zu können, müssen anstatt der mitgelieferten Bibliotheken gluegen-rt.jar und jogl.jar sowie deren nativen Implementierungen (*.dll bzw. *.so Dateien) die entsprechenden Äquivalente für das Host-System eingebunden werden. Diese finden sich unter diesem Link. Wichtig ist, die hier verlinkte Version 1.1.1 zu benutzen, mit den neueren scheint World Wind nicht zu funktionieren.

Auf meinem Ubuntu-Laptop erschien beim Start der Anwendung zunächst die Fehlermeldung

Dank des Users garyvdm auf ubuntuforums.org war die Lösung des Problems schnell gefunden:

Nebenher wurden die Recherchen bzgl. des Hackens der AR.Drone fortgesetzt, um den späteren Eingriff in das OS der AR.Drone zu beschleunigen.

Weiterhin haben wir heute eine Bestätigung für den QSL-Antrag erhalten.

nächste Schritte:

  • UI fertigstellen
  • Schnittstellendefinition zwischen AR.Drone und Basis/UI
  • Drohne bestellen bzw. auf diese warten =) oder eher =(