All posts by hgross

Livedemo- und Testflüge (Zusammenfassung)

Zum Abschluss des Projekts folgen einige synchronisierte Zusammenstellungen vergangener Flüge

  1. Flug vom 04.07.2013
  2. Zweiter Flug vom 04.07.2013
  3. Flug vom 06.07.2013
  4. Demoflug vom 12.08.2013 mit TakePhoto Commands
  5. Demoflug vom 12.08.2013

Und natürlich die abschließende Projektdokumentation mit allen Details zur Umsetzung.

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:

GPS-Daten auf der AR.Drone mit gpsd auslesen und exponieren

Das nun erfolgreich auf der AR.Drone montierte und auslesbare GPS-Modul wollen wir mittels geeigneter Schnittstellen anderen Programmen, wie unserer Basisstation zur Verfügung stellen. Hier müssen wir zum Glück nicht auf dem weißen Papier anfangen, sondern können das Open Source Programm gpsd verwenden, das unter anderem auch auf Android-Geräten (ab Android 4) Anwendung findet. Das Programm stellt die GPS-Daten unterschiedlichster GPS-Empfänger und Protokolle mittels Ethernet und/oder Shared Memory auf Linux Systemen als Daemon zur Verfügung.

Vorraussetzungen

Wir gehen wieder von unserer Crunchbang 11 Entwicklungs-VM aus und installieren noch folgende Abhängigkeiten

 Build

Nun werden wir zwei Versionen bauen: Die gpsd ARM-Binary ohne Client-Anwendungen und Tools und einmal die i686 Version für die VM inkl. der Tools und Clients. Wir beginnen mit dem auschecken und vorbereiten der beiden Verzeichnisse

Dem ARM-Build müssen wir mittels einer .scons-option-cache Datei etwas modifizieren, da wir die Tools und Clients auf der AR.Drone nicht benötigen (und auch keinen Speicherplatz zu verlieren haben).

Wir tragen nun folgendes ein, beenden nano wieder und speichern die Änderungen.

Der verwendete arm-linux Cross-Compiler und co sollten aufgrund des SDK-Builds bereits installiert sein. Jetzt den Build beider Versionen durchführen

 Verwendung

Damit wir das an der AR.Drone an /dev/ttyO3 angeschlossene GPS mit gpsd verwenden können, müssen wir die vermeintlichen Debug-Ausgaben auf diesem Gerät zunächst deaktivieren:

Wir können nun die Binary gpsd aus dem gpsd_for_arm/gpsd Verzeichnis mittels FTP auf die AR.Drone übertragen und starten

Nun innerhalb der Entwicklungs-VM einen Client starten und damit zum laufenden gpsd auf der AR.Drone verbinden

Weiterführende Informationen zur Verwendung von gpsd (zum Beispiel das Ausführen als Daemon) finden sich auf der gpsd man page. Mehr zu den mitgebrachten Clients und Tools finden sich auf der gpsd Projekt-Webseite.

GPS Montage auf AR.Drone 2.0

Heute war Basteltag: Das Royaltek RGM-2000 GPS Modul wurde auf der AR.Drone 2.0 montiert. Ziel dabei war unter anderem auch die beiden AR.Drone Hüllen verwenden zu können; Das GPS-Modul sollte also auf beide Hüllen aufsteckbar sein und es sollte möglichst wenig Zusatzgewicht dafür anfallen, da die AR.Drone – laut Community – maximal 200 Gramm Zusatzlast tragen kann. An das GPS-Modul wurde also eine Steckverbindung angelötet, um es komfortabler auf die verschiedenen Hüllen aufstecken zu können.

Eine mit einer angelöteten Kabelsteckverbindung und dem passenden Stiftsockel für die AR.Drone 2.0 zurechtgebastelte RGM-2000 GPS-Maus zum Anschluss an die TTL-Schnittstelle.

Eine mit einer angelöteten Kabelsteckverbindung und dem passenden Stiftsockel für die AR.Drone 2.0 zurechtgebastelte RGM-2000 GPS-Maus zum Anschluss an die TTL-Schnittstelle.

GPS Montage

Zur Montage wurde das Metallblatt eines günstig zu erwerbenden, handelsüblichen Heftstreifens verwendet. Das GPS-Modul wurde um seine (schweren) Magnete erleichtert, die zugleich vier Löcher im GPS-Gehäuseboden hinterlassen, die wiederum hervorragend zur Befestigung des GPS-Moduls auf der AR.Drone Hülle verwendet werden können. Alle Schritte zur Montage des GPS-Moduls auf der Hülle:

Für die Kabel-Steckverbindung wurde ein Loch von oben durch die Hülle gebohrt. Das Kabel wird dann – wie die Batterie – im Batteriegehäuse angesteckt und verstaut. Um den Stecker von der Drohnen-Platine in das Batteriegehäuse zu verlegen, muss ebenfalls ein Loch in den Schaumstoff zwischen Batteriegehäuse und Board geschnitten werden.

Flugverhalten

Das Flugverhalten mit dem zusätzlichen Gewicht des GPS-Moduls unterschied sich – wie zu erwarten war – sehr deutlich zu dem ohne GPS-Modul. Die AR.Drone reagiert deutlich träger und muss bei Verringerung der Flughöhe, schnellen Richtungsänderungen und auf der Stelle stehend sehr heftig korrigieren. Wir haben sie noch nicht zum Absturz gebracht – es allerdings auch nicht darauf angelegt und sind mit sehr defensiven Flugeinstellungen (Maximale Neigungswinkel, Maximalgeschwindigkeit) geflogen.

AR.Drone 2.0 unter Linux mit einem Joystick fliegen

ardrone_joystick

Auf dem Weg zu unserem Fernziel, die Drohne autonom einige GPS-Wegpunkte abfliegen zu lassen, sowie auch für die fertige Software macht es Sinn, die Kontrolle im Notfall selbst wieder übernehmen zu können. Hierzu evaluieren wir die Möglichkeit, die Drohne mit einem Joystick über die Bodenstation zu steuern.

Wir werden dabei zunächst die zuvor aufgesetzte Crunchbang Linux VM mit dem AR.Drone SDK verwenden, um die Drohne mit einem Logitech Freedom 2.4 USB-Joystick zu steuern. Zur Projektdokumentation und Benefit für andere, werden wir dies hier im Stile einer Anleitung verfassen. Um die Drohne mit einem USB-Joystick steuern zu können, müssen wir diesen als erstes von der Host-Maschine mittels eines USB-Filters an die VirtualBox-VM durchreichen:

Nun den USB-Stecker abziehen und direkt wieder anstecken. Im Log der Gastmaschine sollte das USB-Gerät erkannt worden sein. Wir vergewissern uns, ob dies auch so ist:

System log beim Anschluss eines USB-Joysticks

System log beim Anschluss eines USB-Joysticks

Der Joystick wurde erkannt und kann nun verwendet werden. Nun ermitteln wir noch den Pfad, unter dem wir das Gerät ansprechen können:

Interessant sind hier die mit js beginnenden Geräte

Interessant sind hier die mit js beginnenden Geräte

In meinem Fall war das /dev/input/js2 – dies kann aber abweichen. Wer sichergehen will, installiert nun noch die joystick-Pakete zum Kalibrieren und Testen seiner Eingabegeräte:

Mittels jscal kann der Joystick – falls nötig – nun kalibriert werden. Mit dem ebenfalls enthaltenen Tool jstest kann der Joystick dann getestet werden:

jstest

Nach dem Start der zuvor gebauten, mit dem AR.Drone SDK 2.0.1 mitgelieferten Beispielanwendung, wird dort unser Joystick auch angezeigt – lässt sich allerdings nicht konfigurieren:

Der Joystick wird zwar von der Beispielanwendung erkannt, kann aber nicht konfiguriert werden.

Der Joystick wird zwar von der Beispielanwendung erkannt, kann aber nicht konfiguriert werden.

Für ein spezifisches Eingabegerät, wie hier der Logitech Joystick, muss in diesem Fall noch eine Konfigurationsdatei der Beispielanwendung angepasst werden. In der ardrone.xml (Bei Verwendung der Crunchbang-VM im Verzeichnis ~/ARDrone_SDK_2_0_1/Examples/Linux/Build/Release) tragen wir die Device-ID des Joysticks ein. Die ID können wir mit folgendem Befehl ermitteln:

Die beiden Hexadezimalwerte nach

Die beiden Hexadezimalwerte nach “ID” repräsentieren Vendor- und Device-ID

Die ermittelte ID “046d:c213″ müssen wir nun noch in das Dezimalsystem konvertieren (74301971) und in die ardrone.xml eintragen. Der Eintrag für den verwendeten Logitech Freedom 2.4 Joystick sieht wie folgt aus:

Hierzu sei erwähnt, das die value-Attribute die Achs- bzw. Button-Nummer des Joysticks darstellen, die bei Buttons mit denen des zuvor erwähnten jstest-Tools identisch sind – aber Vorsicht: Die Achsennummer die hier angegeben wird ist die Achsennummer von jstest + 1 (jstest Achse 0 -> Valuewert=1). Das Typ Attribut spezifiziert, ob es sich um einen Button (3) oder eine Achse (1) handelt. Ist ein Eintrag vom type=”3″, so kann der zugehörige value-Eintrag negativ sein – hiermit wird die Richtung der Achse spezifiziert. Um es noch einmal zu erwähnen: Bevor nun geflogen werden kann, sollte eine Kalibrierung des Eingabegeräts vorgenommen worden sein. Bei meinen Tests ergab die Überprüfung, ob das Gerät kalibriert ist via

immer die Rückmeldung “jscal: axes not calibrated”. Augenscheinlich wird dort überprüft, ob die Mittelstellung exakt getroffen wird, was bei den Achsen des erwähnten Joysticks als auch denen eines ebenfalls getesteten Gamepads selbst nach einer Kalibrierung nicht zutraf. Man muss also damit leben, den Joystick zuerst mittels

zu kalibrieren und anschließend per

selbst abzuschätzen, ob die Mittelstellung “genügend genau” erreicht wird. Um einige Werte zu nennen: Nach der Kalibrierung verfehlte mein Joystick die Mittelstellung in einigen Achsen um bis zu 2000, wobei die Achsen auf Werte von -32767 bis +32767 abgebildet werden. Bei den Flugtests stellte sich dies als nicht sonderlich problematisch heraus, weshalb auf weitere Recherchen zum konfigurieren von Tot- und Sättigungszonen der Achse verzichtet wurde – falls hier jemand eine Lösung hat, möge er uns doch bitte mit seinem Kommentar erleuchten ;-)

Zum Fliegen selbst. Wir starten die Beispielanwendung (neu)

und Konfigurieren unterhalb des Menüpunktes “Input Configuration” via Klick auf “USB configuration” unseren Joystick aus der Dropdown-Liste und klicken “OK”.

Konfiguration des USB-Joysticks

Konfiguration des USB-Joysticks

Zum Starten jetzt den Button am Joystick drücken, der mit Emergency/Reset belegt ist. Dabei sollten die LEDs der AR.Drone ihre Farbe wechseln – bei den Tests funktionierte das nicht immer und der Button musste einfach mehrfach gedrückt werden. Ab hier kann mit dem Take-Off-Button gestartet und geflogen werden. Für den ersten Start empfiehlt es sich mittels des “Flight-Control-Settings”-Buttons die maximalen Neigungswinkel und Geschwindigkeiten etwas zu drosseln. Bei der zuvor aufgeführte XML-Belegung (ardrone.xml) für den Joystick, wurden neben den drei Hauptachsen folgende Buttons – der Nummerierung auf dem Joystick selbst folgend – belegt:

Button-Nummer
Aktion
6Emergency/Reset
7Takeoff/Land
1Höhe +
2Höhe -

Die Korrekturen durch jscal können zur späteren Wiederverwendung gespeichert werden

Das Ergebnis ist dann eine Datei (hier) Logitech_Freedom_2.6_calibration.jscal, die einen Kommandozeilenbefehl enthält, der die Kalibrierungsdaten wieder übernimmt. Für den getesteten Joystick war das

Die Daten können dann später einfach per

wiederhergestellt werden.

 

TTL GPS-Maus auf der AR.Drone 2.0 auslesen

Die RGM-2000 TTL GPS-Maus, an der wir vor Beschaffung der Drohne bereits rumgespielt haben, konnten wir nun erfolgreich direkt auf der AR.Drone 2.0 auslesen. Einige Bastelei später sah die GPS-Maus so aus:

Nach Anschluss der GPS-Maus an die Serielle Schnittstelle der AR.Drone (siehe Pinbelegung und Spezifika zum Anschluss einer RGM-2000 an die AR.Drone) und dem Aufbau der telnet-Verbindung mit der AR.Drone

muss die Baudrate für das entsprechende tty device (im Falle unserer AR.Drone 2.0 war das /dev/ttySO3) richtig eingestellt (4800 Baud)

werden. Hierbei kam es beim jeweils ersten Versuch nach dem Start der Drohne zu einem Fehler – der zweite Versuch funktioniert dann allerdings. Jetzt kann man den Output des GPS-Moduls mittels

auslesen und sich über die telnet-Verbindung ausgeben lassen. Die Kaltstartzeit der GPS-Maus war sehr hoch und lag etwa bei ca. 30 Minuten, also nicht wundern, wenn zunächst erst einmal keine verwertbaren Koordinaten ausgegeben werden. Diese Kaltstartzeit ist allerdings ungewöhnlich hoch (siehe GPS-Basics). Als nächstes werden wir ein C-Programm implementieren, welches die GPS-Daten ausliest und neben den Navigationsdaten, die bereits von der AR.Drone bereitgestellt werden, zum Abruf verfügbar macht bzw. aktiv an eine Bodenstation sendet und hoffentlich einen Weg finden, die lange Kaltstartzeit zu verkürzen.

TTL-GPS-Daten via Telnet von AR.Drone

TTL-GPS-Daten via Telnet von AR.Drone

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

RGM-2000 GPS Daten per TTY auslesen

Die Drone und weitere benötigte Hardware wird uns aller Voraussicht nach nächste bzw. übernächste Woche endlich zur Verfügung stehen. Trotzdem haben wir heute bereits das vorhandene RGM-2000 GPS-Modul an einen Linux-Rechner angeschlossen um uns mit dem Datenformat vertraut zu machen und eventuell auch schon einige Software vorbereiten zu können. Hierzu musste der 3,3V TTL-Pegel des GPS-Moduls in den +-12V Pegel der RS232-Schnittstelle umgewandelt werden, wozu ein MAX323-Transceiver verwendet wurde. Mittels Seyon konnten wir der RGM-2000 dann die ersten Daten entlocken und durch Setzen der richtigen Baudrate von 4800 auch menschenlesbar interpretieren. Die anhängenden Bilder zeigen den Aufbau noch einmal.