All posts by Manuel Hermenau

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: