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:

Remote Debugging auf der AR.Drone 2

Unser Ziel ist es, das Programm zur autonomen Steuerung auf der AR.Drone 2 auszuführen. Für die Entwicklung ist es daher hilfreich, das Programm direkt auf der Drohne ausführen und Debuggen zu können.
In diesem Post wird erklärt wie man sich eine Entwicklungsumgebung auf Xubuntu 10.04 für Remote Debugging auf der AR.Drone 2 einrichtet.

1. Schritt) Eclipse herunterladen und einrichten
Zunächst laden wir uns das aktuelle Eclipse (Juno) in der CDT-Edition herunter,
entpacken und starten es.

Als nächstes richten wir uns eine Remote Connection ein. Unter File > New > Other (oder Strg+N) wählen wir Connection aus.

Im nächsten Fenster wählen wir “Telnet Only (Experimental)” und klicken auf Next. Danach geben wir bei HOST die IP-Adresse der Drohne ein (192.168.1.1).

Im folgenden Dialog ändern wir unter “Telnet Settings” die Property “Login.Required” auf false und “Command.Prompt” zu “#”.
Mit einem Klick auf “Finish” schließen wir die Connection-Einrichung ab.

Jetzt können wir ein neues C-Projekt erstellen: File > New > C-Project. Wir erzeugen ein Hello-World-Projekt namens ARDrone und wählen rechts “Cross Toolchain”.
Wir klicken uns durch bis zu den Cross-Compiler Optionen. Hier geben wir den Prefix unseres Cross-Compilers an: arm-linux-gnueabi-
Ein Klick auf Finish erzeugt das Projekt.


2. Schritt) NFS einrichten
Die einfachste Methode, die kompilierten Dateien Remote auszuführen, ist, euren lokalen Workspace via NFS auf der ARDrone zu mounten.
Hierzu installieren wir zunächst das nfs-kernel-server Paket, falls noch nicht geschehen.

Als nächstes machen wir unseren Workspace im Netzwerk zugreifbar, indem wir die exports Datei editieren.

Hier fügen wir folgende Zeile ein:

Die Zeile sagt, dass die IP 192.168.1.1 Read-Only (ro) Zugriff auf den Pfad /home/manu/workspaces/ardrone hat.

Den Pfad zum Workspace müsst ihr natürlich entsprechend anpassen. Danach weisen wir den NFS-Server an, die Exports neu zu laden

Nun können wir auf der AR.Drone via Telnet den Workspace mounten:

IP und Pfad müssen natürlich wieder an eure Konfiguration angepasst werden.

3. Schritt) Automatisches Mounten des NFS auf der Drohne
Dieser Mount-Vorgang muss jedes mal wiederholt werden, wenn die Drohne neu gestartet wird.

Um das nicht jedes mal tun zu müssen, kann man es mit diesem NFS Mount Script automatisieren.
In der Datei 02ardrone_mount.sh müsst ihr eure euren Pfad und ggf. das Network-Interface anpassen, sowie eine ID angeben, unter der euer Workspace gemounted wird. Danach die Dateien an die richtigen Stellen kopieren.

Die 02ardrone_mount.sh wird nun jedesmal ausgeführt wenn eine Netzwerkverbindung hergestellt wird. Ist es die Verbindung zur AR.Drone, wird das Expect-Script ardrone_mount.exp ausgeführt, welches eine Telnet-Verbindung zur Drohne aufbaut und unseren Wokspace mounted.

Solange nicht mehrere Entwickler im Team die selbe ID vergeben haben, ist es somit auch problemlos möglich gleichzeit auf der ARDrone zu arbeiten.

4. Schritt) gdb herunterladen und kompilieren
Zum Remote Debuggen werden zwei Executables benötigt: zum einen der gdbserver, welcher auf der AR.Drone läuft, zum anderen der gdb.
Zwar ist auf der AR.Drone ein gdbserver in der Version 7.39 vorhanden, allerdings ist es so, dass gdbserver und gdb sehr wählerisch bei der Zusammenarbeit sind und zickig werden, wenn nicht auf beiden Seiten die selbe Version benutzt wird.
Deshalb laden wir uns die aktuelle gdb-Version aus der Linaro-Toolchain herunter und entpacken diese.
Zum kompilieren brauchen wir noch das expat-Paket, danach bauen wir uns zunächst den gdb

Als nächstes Cross-Compilieren wir den gdbserver:

Wenn alles geklappt hat, haben wir jetzt eine Executable names gdbserver. Diese laden wir über FTP auf die AR.Drone und kopieren sie danach via Telnet in das /bin Verzeichnis. Vorher machen wir noch ein Backup der bereits existierende Version.

5. Schritt) Debug-Configuration in Eclipse
Im letzten Schritt richten wir uns die Debug-Configuration in Eclipse ein. Zunächst bauen wir das Projekt, falls noch nicht geschehen: Project > Build All.
Dann öffnen wir das “Debug Configuration” Menu unter Run > Debug Configurations und erzeugen unter dem Listenpunkt “C/C++ Remote Application” ein neues Element.
Hier wählen wir bei Connection unsere zuvor erstellte Verbindung zur AR.Drone und tragen bei “Remote Absolute File Path for C/C++ Application” den Pfad ein, unter dem die Binary auf der AR.Drone zu finden ist.
Unter dem Tab “Debugger” wählen wir unseren zuvor kompilierten gdb. Dann noch bei “Shared Libraries” den Pfad zu den Linaro-Libs hinzufügen, bei mir ist das /usr/arm-linux-gnueabi/lib.

Das wars! Jetzt müsste sich unser Hello-World-Programm Remote Debuggen lassen.

Navilock NL-551EUSB GPS auf ARDrone 2 und Kernel-Module Cross-Compilen

Nachdem wir die RGM-2000 TTL GPS-Maus unter freiem Himmel auf einem Fußballfeld testen konnten, mussten wir feststellen, dass diese eine Kaltstartzeit von über 30 Minuten hat. Dies ist für unsere Zwecke nicht praktikabel. Deshalb versuchten wir, ein anderes GPS-Modul an die ARDrone anzuschließen. Hierfür steht uns das Navilock NL-551EUSB zur Verfügung, das eine Kaltstartzeit von 30 Sekunden verspricht. Dieses Modul wird nicht, wie das RGM-2000 über TTL mit der Drohne verbunden, sondern über einen USB-Anschluss. Dank der Dokumentation der seriellen Schnittstelle wissen wir, dass man über die selbe Schnittstelle auch USB-Devices anschließen kann. Hierfür fehlen auf der Drohne allerdings die entsprechenden Treiber, die man sich zunächst Cross-Compilieren muss.

Die offizielle Dokumentation des GPS-Chips schlägt den cdc_acm Treiber vor, deshalb entschieden wir uns diesen auch zu benutzen.

Zunächst benötigt man einen ARM-Cross-Compiler. Ich benutze die Linaro-Toolchain auf Xubuntu 10.04.
Um Module für die ARDrone zu kompilieren benötigt man außerdem den Kernel-Sourcecode (die linux.tar.gz)
Das Archiv herunterladen und entpacken

Um den Kernel erfolgreich zu bauen benötigt man eine .config Datei, in welcher die Konfiguration des Builds festgehalten ist. Ich empfehle die hier verlinkte. Sie unterscheidet sich von der Originalen, welche Parrot unter dem Namen kernel.config mit dem Kernel-Sourcecode mitliefert, nur darin dass die benötigten Treiber jetzt als Module kompiliert werden und die CONFIG_LOCALVERSION_AUTO Flag deaktiviert wurde. Diese Datei nun in das Kernel-Verzeichnis kopieren.

Als nächstes müssen wir dafür sorgen, dass unsere kompilierten Module den selben Versionmagic-String wie unser AR.Drone-Kernel haben. Ist dies nicht der Fall, dann bekommt man beim Laden des Moduls die Meldung

Um den Version-String herauszufinden, mit Telnet auf die Drohne verbinden und

aufrufen. Man bekommt die Version des Kernels angezeigt, bei unserer ARDrone ist das 2.6.32.9-gbb4d210

Nun die Makefile im Kernel-Verzeichnis öffnen und die Zeile

ersetzen durch

Jetzt kann man mit

alle Kernelmodule bauen.
Die CROSS_COMPILE Flag bezeichnet den Präfix, der den allen Compiler Binaries (gcc, g++, ar, …) vorangestellt wird.
Die fertigen Module liegen dann in den entsprechenden Ordnern, in denen ihre Quellcode-Dateien liegen.
Für unser Projekt benötigen wir <kernel_path>/drivers/usb/class/cdc-acm.ko

Diese Datei wird per FTP auf die AR.Drone kopiert. Danach verbinden wir uns via Telnet mit der AR.Drone und laden das Modul.

Wenn man jetzt den GPS-Empfänger einstöpselt, erscheint das Device /dev/ttyACM0.

Der Aufruf von

zeigt, dass alles funktioniert hat. Das Start-Kommando für gpsd ändert sich dann natürlich entsprechend:

Quellen:

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

GPS Navigation mit der Parrot AR.Drone 2.0