Category Archives: GPS

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:

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.

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

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.

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 =(

AR.Drone und RGM-2000 GPS

Da wir die Beschaffung der für dieses Projekt benötigte AR.Drone 2.0 durch die QSL-Kommission zunächst abwarten müssen, befinden wir uns bezüglich Beschaffung von Hardware aktuell im “Blindflug”. Da wir auf jeden Fall eine GPS-Empfänger benötigen und diesen an der AR.Drone anbringen müssen, haben wir heute die verwaiste GPS-Maus eines betagten PocketPCs um ihr Gehäuse erleichtert um diese auf deren Eignung für unser Projekt zu untersuchen. Die GPS-Maus stammt von dem Hersteller RoyalTek und trägt die Typenbezeichnung RGM-2000. Die GPS-Maus ist weit verbreitet, da sie in großen Mengen von einem deutschen Discounter verkauft wurde und im Netz finden sich viele Artikel und Dokumentation zu diesem Modell. Dank einer ausführlichen Untersuchung der GPS-Maus durch einen Forennutzer der Seite mikrocontroller.net sowie einer Dokumentation der AR.Drone-Schnittstelle durch Max Ogden konnten wir zusammen mit unserem Betreuer Prof. Dr. Kaiser die im TTL-Pegel kodierten Signale der GPS-Maus nachvollziehen.

Schnittstelle des AR.Drone 2 Boards – von Max Ogden

Wir gehen nun also davon aus, dass wir nach dem Anschliessen der GPS-Maus an Position 3 (gelbes Kabel) und 5 (weißes Kabel) des AR.Drone-Boards die Signale an einem tty des auf der AR.Drone installierten Linux-Betriebssystems abgreifen und nutzen können. Um dies zu ermöglichen, müssen wir uns nach Erhalt der AR.Drone (vermutlich Ende Mai) zunächst Zugang zu diesem Betriebssystem verschaffen.