Marauders Map

Entwicklung einer ROS Anwendung mithilfe des Android-SDK

Projektbericht

vorgelegt von:

Marcel Hesse

Mat-Nr: 31204309

Gutachter: Prof. Dr. Kurt GeihsBetreuer: Stephan Opfer M. Sc.

29. September 2016

Universität Kassel

Fachbereich Elektrotechnik und Informatik

Sommersemester 2016

Inhaltsverzeichnis

1 Kurzzusammenfassung 2

2 Einleitung 32.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Grundlagen 43.1 TurtleBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.1 ROS Computation Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.2 Adaptive Monte Carlo Localization . . . . . . . . . . . . . . . . . . . . . . 7

3.2.3 Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Implementierung 94.1 Grundstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 UDPProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.4 Kartenoverlays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.5 Gepackte Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.6 Navigationsdatentransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.7 Rechte der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Diskussion 175.1 Vor- und Nachteile der implementierten Lösung . . . . . . . . . . . . . . . . . . 17

5.2 Fähigkeiten und Grenzen von ros-android und rosjava . . . . . . . . . . . . . . . 18

5.3 Besonderheiten beim Betrieb der Applikation unter Android 6.0 . . . . . . . . 18

6 Zusammenfassung und Ausblick 20

7 Literaturverzeichnis 21

1 Kurzzusammenfassung

Diese Projektarbeit hat das Ziel eine Android Applikation zur Interaktion mit TurtleBots [5] zu

entwickeln. Die Funktionalitäten der Applikation sollen dabei die Anzeige einer Karte mit ak-

tuellen Positionen der TurtleBots und Steuerung der TurtleBots über Berührungen eines druck-

oder berührungsempfindlichen Bildschirms eines Smartphones umfassen. Die TurtleBots

verwenden zur Verwaltung einzelner Roboterkomponenten und Interprozesskommunikation

das Robot Operating System, kurz ROS [2]. Bei der Karte handelt es sich um eine Karte des

Nutzungsbereichs, in diesem Fall das Fachgebiet Verteilte Systeme des Elektrotechnik/In-

formatik Fachbereichs der Universität Kassel. Eine Gruppe von Studenten hat diese Karte

erstellt. Die TurtleBots nutzen zur Kommunikation mit der Applikation ein UDP Protokoll auf

Basis von ROS Messages. Jeder TurtleBot nutzt ROS zur Kommunikation zwischen eigenen

Prozessen und Roboterkomponenten. Durch Verwendung von ros-android werden bestehende

ROS Messages auch auf dem Smartphone nutzbar gemacht.

2

2 Einleitung

Roboter werden schon seit jeher, mithilfe von Computern gesteuert. Dabei werden Informa-

tionen vom Roboter an den steuernden Computer gesendet und auch Daten des Computers

vom Roboter empfangen. Im Laufe der letzten Jahre haben Smartphones weite Verbreitung

gefunden. Dadurch ergeben sich auch neue Möglichkeiten für die Steuerung von Robotern,

da es sich bei einem Smartphone im Wesentlichen um einen Taschencomputer handelt. Eines

dieser Steuerungsszenarien ist die Fernsteuerung eines TurtleBot.

2.1 Motivation

Bisher wurden die TurtleBots1 im Fachgebiet Verteilte Systeme der Universität Kassel, über

die Software rviz auf einem Notebook oder Arbeitsplatzrechner gesteuert. Dies bedeutet

meist einen eingeschränkten Mobilitätsradius, da der Roboter schnell aus dem Sichtfeld,

des am Schreibtisch sitzenden Programmierers verschwindet. Ein Notebook konstant in

der Hand zu halten um damit die Roboter steuern zu können ist ähnlich unpraktisch. Die

Steuerung und Positionsanzeige der Roboter über eine Android-Applikation, führt zu einer

erhöhten Mobilität. Außerdem ist sie leichter zu bedienen, da im Vergleich zur Steuerung

über rviz nicht erst ein roscore von Hand über die Konsole gestartet werden muss, und die

Benutzeroberfläche weniger Bedienelemente als rviz enthalten wird.

2.2 Aufgabenstellung

Ziel dieser Arbeit ist die Implementierung einer Android-Applikation, mit der eine Steuerung

von TurtleBots über einen berührungsempfindlichen Bildschirm eines Smartphones möglich

ist. Auf dem Bildschirm soll eine Karte einer zuvor gescannten Umgebung angezeigt werden.

Auf der Karte sollen Roboter, die sich lokalisiert haben angezeigt werden. Nicht lokalisierte

Roboter sollen über Berührungen des Kartenbildschirms lokalisiert werden können. Über den

Kartenbildschirm soll man durch einfaches Tippen, die einzelnen TurtleBots zu bestimmten

Punkten auf der Karte schicken können. In der Anwendung soll außerdem auswählbar sein

welcher TurtleBot im Moment gesteuert wird.

1TurtleBots sind eine offene Roboterplattform näheres in Kapitel 3.1

3

3 Grundlagen

Zur Umsetzung des Projektes als Android Applikation werden unterschiedliche Technolo-

gien verwendet, auf die hier näher eingegangen wird. Android Applikationen werden in

der Programmiersprache Java mithilfe des Android Software Development Kit, kurz SDK,

entwickelt. Es ist auch möglich C++ mit dem Android Native Development Kit, kurz NDK,

zur Entwicklung zu nutzen. Diese Kombination kann genutzt werden um höhere Leistung in

einer Applikation zu erreichen. In der NDK Dokumentation wird davon abgeraten das NDK

zu nutzen, wenn es nicht aus Effizienzgründen notwendig ist, da es zusätzliche Komplexität

in die Anwendung einführt und für die meisten Anwendungen nur einen geringen Nutzen

hat [7]. Daher wird in diesem Lösungsansatz auf das NDK verzichtet.

3.1 TurtleBot

Der TurtleBot ist eine offene Roboterplatform, die von der Open Source Robotics Foundation

entwickelt wurde und sich mittlerweile in der 2. Entwicklungsgeneration befindet. Für die-

ses Projekt wird ein TurtleBot 2 genutzt. Der TurtleBot 2 hat eine annähernd kreisförmige

Grundfläche mit einem Radius von 177 mm und ist 41 cm hoch. Zur Fortbewegung wird

ein elektrischer Differentialantrieb genutzt. Zwei Bumper sind links und rechts in der Basis

des TurtleBots eingebaut um Kollisionen zu erkennen. Eine Klippenerkennung ist ebenfalls

vorhanden. Sie funktioniert über einen Infrarotsensor, der erkennt wenn der TurtleBot über

den Rand einer Plattform zu fahren droht. Eine XBox Kinect zur Erkennung von Gegenstän-

den und Umgebung ist auch Teil der Plattform. Zusätzlich kann er erkennen, wenn ein Rad

durchhängt. Außerdem kann der TurtleBot autonom seine Ladestation erkennen und an ihr

andocken. Die Kosten für einen TurtleBot 2 variieren je nach Händler zwischen ca. 1.400

€ [18] und ca. 2.700 € [19].

Bei dem TurtleBot, der in diesem Projekt verwendet wird, handelt es sich um den Turt-

leBot 2. Für dieses Projekt wird zusätzlich ein 2-D-Laserscanner von Hokuyo, und zwar

das Modell UTM-30LX zur Lokalisierung verwendet. Dieser Laserscanner ermöglicht eine

Erkennung der Umgebung in einem 270°-Winkel auf bis zu 30 m Entfernung. Dadurch wird

die Qualität der Navigation und Lokalisierung des TurteBots verbessert.

4

Abbildung 3.1: Links:TurtleBot wie auf turtlebot.com dargestellt[21].Mitte und Rechts: Seit- undFrontansicht eines TurtleBot mit Hokuyo UTM-30LX Laserscanner

3.2 Robot Operating System

Robot Operating System, kurz ROS ist ein großes Rahmenwerk; eine Middleware zur Inter-

prozesskommunikation [8] und Erstellung von Robotersoftware, die mehrere Werkzeuge

und Bibliotheken in sich vereinigt. So sind eine Hardwareabstraktionsschicht, hardwarenahe

Gerätekontrolle und Paketmanagement einige der durch ROS gegebenen Funktionalitäten [8].

ROS ist in verschiedenen Sprachen wie C++, C#, Python und Java implementiert. ROS wird

fortlaufend weiterentwickelt. Um nicht laufend die Version aktualisieren zu müssen, wird für

dieses Projekt die Version indigo verwendet.

3.2.1 ROS Computation Graph

Der ROS Computation Graph ist die Grundlage dieses Projekts. Es ist eine der Kernkomponen-

ten von ROS. Daher wird hier noch einmal genauer auf einzelne Aspekte dieser Komponente

eingegangen.

Nodes ROS Nodes sind Prozesse innerhalb des Netzwerks. Jeder Node innerhalb des Netzwer-

kes übernimmt eine Aufgabe wie das Senden von Sensordaten eines Laserscanners oder

die Pfadplanung eines Roboters. Nodes sollten modular aufgebaut sein. Jeder Node soll-

te eine atomare oder semantisch zusammenhängende Aufgaben übernehmen. Nodes

werden mithilfe einer ROS-Clientbibliothek wie roscpp oder rosjava implementiert. No-

des in der Applikation senden Befehle für den TurtleBot und empfangen Positionsdaten

von diesem.

Master Der ROS Master stellt Namensregistrierung und -verwaltung für den Rest des Netzwerks

zur Verfügung. Ohne ihn könnten die Nodes sich nicht finden und keine Nachrichten

austauschen, da er die Verbindung zwischen ihnen vermittelt. Er stellt damit innerhalb

3.2 Robot Operating System 5

Abbildung 3.2: Beispielhafte Darstellung des Verhaltens der Abonnieren/Publizieren Logik

des ROS Computation Graph eine Notwendigkeit zum Funktionieren des Systems

dar. Nodes melden zudem einen Fehler, wenn sie keinen Master im Netzwerk finden

können. Es kann innerhalb des ROS Computation Graph nur einen Master geben.

Messages Nodes kommunizieren über Messages miteinander. Messages sind Datenstrukturen,

bestehend aus getypten Feldern. Die Typen sind dabei durch ROS vorgegeben. Es lassen

sich auch Arrays dieser Typen als Felder oder Messages in Messages als Feld ange-

ben. Letzteres wird in diesem Projekt zum Verpacken der Messages verwendet(siehe

Abschnitt 4.5).

Topics Messages werden über eine Abonnieren/Publizieren Logik verteilt. Nodes senden Mes-

sages indem sie eine Message unter einem gewissen Topic (Thema) mithilfe eines

Publishers publizieren. Das Topic wird dazu verwendet um den Inhalt der Message

zu erkennen. Nodes die an bestimmten Daten interessiert sind abonnieren die ent-

sprechenden Topics mithilfe eines sogenannten Subscribers. Es können mehrere Nodes

gleichzeitig unter einem Topic senden und empfangen, da ROS die Nebenläufigkeiten

behandelt. Eine Darstellung dieses Prozesses ist in Abbildung 3.2 zu sehen.

Die hier zusammengetragenen Informationen lassen sich ebenfalls im ROS Wiki [8] nach-

schlagen.

6 Grundlagen

Abbildung 3.3: Steuerung eines TurtleBot über rviz mittels ROS amcl

3.2.2 Adaptive Monte Carlo Localization

ROS besitzt ein Paket namens amcl zur Navigation in zweidimensionalen Räumen, das auf

Basis des Monte-Carlo Lokalisierungsalgorithmus funktioniert und eine autonome Routen-

planung zu vorgegebenen Zielen enthält. Monte-Carlo Lokalisierung arbeitet auf Basis eines

Partikelfelds, das potentielle Positionen und Orientierungen, zusammen die Pose, des Robo-

ters auf eine vorhandene Karte legt und diese mit den Sensordaten des Roboters abgleicht [1].

Durch Bewegung des Roboters kommen neue Sensordaten zustande, die zu einem weiteren

Abgleich der potenziellen Posen des Partikelfeldes führen. Dadurch sollten die Abschätzungen

des Partikelfeldes zu der tatsächlichen Pose des Roboters konvergieren. In Abbildung 3.3

ist dies zu sehen. Der grüne Punkt in der Abbildung besteht bei genauer Betrachtung aus

mehreren Pfeilen, gemeinsam bilden sie das Partikelfeld.

3.2.3 Implementierungen

Dieses Projekt verwendet zwei verschiedene Implementierungen von ROS. Das Smartphone

nutzt rosjava um seine ROS Kommunikation abzuwickeln. Der TurtleBot verwendet roscpp.

roscpp Der TurtleBot nutzt die C++ Umsetzung von ROS. Diese heißt roscpp und ist die

meistgenutzte Implementierung [9]. Sie ermöglicht die Nutzung aller Kernkonzepte

von ROS, wie Topics, Nodes, Messages, Services usw.

rosjava rosjava ist eine Umsetzung von ROS für die Programmiersprache Java. Nach ihrer

Ankündigung auf der Google I/O 2011 [12] gab es im folgenden Jahr eine Rede auf

3.2 Robot Operating System 7

der RosCon, in der auch die Ziele der Entwicklung von rosjava beschrieben wurden. Zu

diesen Zielen zählte auch Funktionalitätengleichheit mit roscpp [13]. rosjava schreitet

im Vergleich zur C++ Implementierung, jedoch nicht so schnell in seiner Entwicklung

voran. Während für C++ die Version Kinetic vom Mai 2016 aktuell ist, wird für rosjava

nur Version Indigo aus dem Juli 2014 unterstützt.

ros-android ros-android ist keine eigenständige Implementierung von ROS sondern nutzt rosjava

um Funktionalitäten für Android Applikationen bereitzustellen [6]. Es beschränkt sich

auf eine Integration der rosjava Funktionalitäten in das Android SDK. Zudem integriert

es sich problemlos in Android Studio, welches die offizielle Entwicklungsumgebung des

Android SDK ist [10]. Die Smartphone Applikation dieses Projekts nutzt ros-android

zur Implementierung eigener Nodes, Messages und Topics.

8 Grundlagen

4 Implementierung

Die Implementierung der Applikation erfolgt mit Java unter Zuhilfenahme des Android SDK,

OpenJDK 8 und ros-android. Bei der Implementierung der Lösung wurde ein besonderer Wert

auf leichte Erweiterbarkeit durch Interfaces und abstrakte Klassen gelegt, siehe Abschnitt 4.3

bis 4.5. Eine Darstellung dieser Schnittstellen ist in Abbildung 4.1 zu sehen. Der Quellcode

der Android-Applikation ist auf GitHub vorhanden[22].

4.1 Grundstruktur

Die Applikation unterteilt sich in Nodes, Commands, Activities und Utilitys, wie man an

der Auflistung unten erkennen kann. Sämtliche dieser Komponenten sind als Java-Packages

realisiert. Die Activities sind hierbei Klassen, die das Bindeglied zwischen der Netzwerk-

komponente, den ROS Nodes, der Modelllogik und der Oberfläche darstellen. Die Nodes

Komponente umfasst die ROS Nodes, die Publisher und die Subscriber zu den verschiedenen

Topics, auf die die Anwendung reagieren soll. Für das aktive Senden von Topics, das aus

der Oberfläche heraus steuerbar sein soll, ist die Command Komponente zuständig. Sie

umfasst alle als Anweisung an den TurtleBot sendbaren Befehle als ROS Messages. Die Model

Komponente hält Daten über die im System aktiven TurtleBots und zentrale Objekte der

Anwendung. Alle Klassen die nicht direkt diesen Komponenten zuzuordnen sind finden sich

im Util Package. Dazu zählen unter anderem Klassen zum Lesen und Schreiben von PGM

Ressourcen und der UDPProxy.

Hier nun eine Auflistung der einzelnen Java Packages:

model model enthält die Modellklassen TurtleBot, Triple und Root.

node node umfasst die Nodes: AliciaPlanTreeInfoListener, AMCL_PoseListener, MapListener(nicht

aktiv), ParticleCloudListener.

command Das command Package enthält die Klassen Command, GlobalCommandList,

InitialPoseCommand und SendToGoalCommand.

activity Das activity Package umfasst die Activities MapScreen und MaraudersMap. Außerdem

enthält es die beiden Subpackages ui und map.

9

Abbildung 4.1: Komponentendiagramm in der Android Applikation.

map Das map Subpackage beinhaltet Klassen zur Kartendarstellung

wie AbstractMapOverlay, MapDrawer und RobotPositionOverlay.

ui Das ui Subpackage enthält Listener- und Oberflächenklassen.

util Das util Package besteht aus den Klassen PGMUtils und ROS2UDPProxy.

4.2 UDPProxy

Der UDPProxy ist die zentrale Netzwerkkomponente der Applikation. Die Applikation schickt

und empfängt ROS Messages über eine UDP-Verbindung zum TurtleBot, die durch den UD-

PProxy verwaltet wird. Umgekehrt nutzt der TurtleBot ebenfalls eine Implementierung des

UDPProxy in roscpp. Diese Umsetzung des UDPProxys in roscpp wurde vom Fachgebiet Ver-

teilte Systeme entwickelt. Da Smartphone und TurtleBot jeweils einen eigenen ROS Master

betreiben, können sie nicht im selben Computation Graph sein (siehe Abschnitt 3.2.1). Daher

tauschen die UDPProxy Nodes von TurtleBot und Smartphone Applikation Messages zwischen

den beiden ROS Masters über eine Multicastgruppe aus. Jeder Teilnehmer der Multicast-

gruppe kann Messages an die Gruppe senden und empfangen. Die Applikation konnte die

bisherige Implementierung nicht nutzen, da sie in roscpp vorlag. Deswegen reimplementiert

die Applikation den UDPProxy Node in Java mit ros-android. Dabei fällt auf, dass die Reim-

plementierung nicht äquivalent zur ursprünglichen Implementierung ist, da es Unterschiede

in den Funktionalitäten von rosjava und roscpp gibt. In roscpp übergibt man einem neu

erstellten Subscriber eine Funktion, die als Übergabeparameter ein MessageEvent erwartet.

Eine solche Klasse gibt es in rosjava nicht. Sie ist jedoch essentiell um abfragen zu können

von welchem ROS Node eine Message verschickt wurde. Um daher zirkulär im Netzwerk

10 Implementierung

Abbildung 4.2: Der UDPProxy als Bindeglied zwischen zwei verschiedenen ROS Computation Graphs.

wandernde Messages zu vermeiden sollten Nodes der Applikation nie das selbe ROS Topic

senden und empfangen. Eine Lösung des Problems könnte das Hinzufügen eines Feldes für

den sendenden Node oder ein fortlaufend inkrementierten Identifikator an der Message sein.

Eine beispielhafte Visualisierung der Nodes und ihrer Interaktionen im Netzwerk befindet

sich in Abbildung 4.2.

4.3 Commands

Die Applikation muss mehrere Messages verschicken um Aktionen durchführen zu können.

Eingangs benötigt der TurtleBot eine Angabe an welcher Position der Karte er sich befindet.

Später soll er sich auf eine vom Benutzer gewählte Position der Karte stellen, wenn dieser

über die Applikation eine Angabe dazu macht. Weitere solcher Commands wären denkbar, wie

zum Beispiel: “Fahre in die Küche” und der TurtleBot begibt sich auf die als Küche gespeicherte

Position der Karte. Zu diesem Zweck enthält die Applikation eine abstrakte Command Klasse.

Über sie sind ROS Messages als Commands definierbar. Zusätzlich wird das Verpacken der

Messages ebenfalls durch das Command behandelt. Dadurch ist sichergestellt, dass nur

der TurtleBot für den die Nachricht bestimmt ist auf das Command reagiert1. Commands

werden einer globalen Liste hinzugefügt. Nodes oder andere Threads können sich an jeder

beliebigen Stelle des Programms die Commandliste durch den CommandTalker geben lassen

und ein Command verschicken. Commands enthalten die Logik zum Versenden bereits und

verschicken gepackte ROS Messages direkt per UDP anstatt eine Message zu publizieren, die

1Das Konzept der gepackten Nachrichten wird in Abschnitt 4.5 näher erklärt.

4.3 Commands 11

Abbildung 4.3: Commandworkflow von Anfrage durch Node bis zum Empfang beim Rezipienten

anschließend durch den UDPProxy versendet wird. Dieser Arbeitsablauf ist in Abbildung 4.3

visualisiert.

4.4 Kartenoverlays

Der Kartenbildschirm, welchen man in Abbildung 4.4 sehen kann, ist das größte Oberflä-

chenelement der Applikation. Bei ihm handelt es sich um ein Canvas. Eine Zeichenoberfläche

auf der geometrische Formen, Bitmaps und Text gezeichnet werden können. Grundlegend

zeichnet das Canvas die Karte des Fachgebiets. Wenn TurtleBots im Netz sind werden ihre

Positionen auf das Canvas gezeichnet. Tatsächlich soll zuerst die Karte gezeichnet werden und

weitere (dynamische) Elemente eine Ebene darüber angezeigt werden. Zu diesem Zweck gibt

es in der Applikation ein Overlay Konzept. Die Applikation zeichnet zuerst die Karte als unters-

te Ebene mithilfe der MapOverlay Klasse. Die Darstellung der TurtleBot Positionen erfolgt eine

Ebene darüber, über das RobotPositionOverlay, welches angibt wo Kreise in verschiedenen

Farben auf den Kartenbildschirm gezeichnet werden sollen. Frei nach diesem Prinzip können

weitere Overlays geschrieben werden. Diese müssen dazu nur die drawOverlay-Methode

der abstrakten Karten Overlay Klasse (AbstractMapOverlay) implementieren. In ihr wird

angegeben was auf das Canvas gezeichnet wird. Aus Effizienzgründen sollten hier keine

komplexen Berechnungen stattfinden sondern bereits vorbereitete Daten zum Zeichnen auf

der Karte verwendet werden.

12 Implementierung

Abbildung 4.4: Kartenbildschirm der Applikation

4.4 Kartenoverlays 13

4.5 Gepackte Nachrichten

Die TurtleBots versenden ROS Messages mit ihren Positionen und erhalten Messages um sich

auf eine bestimmte Position zu begeben. Dabei verhält sich jeder TurtleBot so als wenn er

allein im Netzwerk wäre. Die Nachrichten besitzen keine Identifikatoren für den entspre-

chenden TurtleBot. Zentrale Anforderung an dieses Projekt ist aber, dass die Applikation

für mehrere TurtleBots gleichzeitig nutzbar ist. Dies war bisher auch über Steuerung mit

einem Computer nicht möglich. Daher ist speziell für diese Anforderung ein separater ROS

Node für den TurtleBot in C++ geschrieben worden. Die Implementierung ist dabei an der

des UDPProxys orientiert. So gibt es einen Generator für einen Handler von gepackten

Nachrichten, der anhand einer Konfigurationsdatei generiert wird. Die Konfigurationsdatei

orientiert sich dabei an dem Aufbau der relaysMsgs.conf für den UDP Proxy Generator[15].

Der Generator erzeugt für jede Zeile der Konfigurationsdatei, bestehend aus einem ROS Topic,

einem ROS Nachrichtentypen für gepackte Nachrichten, einem ROS Nachrichtentypen für

entpackte/nicht verpackte Messages und optional einer Warteschlangenlänge für Messages,

eine Behandlungsmethode für das Topic und den zugehörigen Nachrichtentypen. Hierbei

wird zwischen Topics zum Senden und Empfangen unterschieden, da die Android Applikation

aufgrund der in Sektion 4.2 angesprochenen Schwächen eine Message des gleichen Typs

mit gleichem Topic nicht senden und empfangen kann. Wird ein Topic mit Nachrichtentyp

als sendbar angegeben so wird in der Behandlungsmethode die zu sendende Message über

einen ROS Subscriber entgegengenommen und anschließend die Message in eine Message des

gepackten Nachrichtentyps kopiert und anschließend an ROS mit dem selben Topic, dem ein

"/wrapped/" vorangestellt wird, publiziert. Die gepackten Nachrichten werden dann vom UDP

Proxy ins Netzwerk verschickt. Gepackte Nachrichten sind als ROS Message die eine 32-Bit

Ganzzahl als id verwenden und die eigentliche Message als Payload namens msg enthalten.

Die Definition einer solchen gepackten Nachricht ist beispielhaft in Listing 4.1 zu sehen. Sie

umschließt Nachrichten des Typs PoseWithCovarianceStamped und ermöglicht dadurch diese

Message über den Identifikator id einem TurtleBot zuzuordnen. Das Empfangen der Messages

funktioniert analog zum Senden der Messages, das heißt aus den gepackten Nachrichten

wird msg entnommen und unter dem selben Topic, allerdings ohne "/wrapped/" publiziert.

Auf Seiten der Android Applikation werden gepackte Nachrichten explizit abonniert und

verarbeitet beziehungsweise an die entsprechende Klasse zur Verarbeitung delegiert. Zum

Senden gepackter Nachrichten kann die Applikation zum Beispiel ein Command versenden.

Listing 4.1: Definition der gepackten ROS Nachricht AMCLPoseWrapped

1 int32 r e c e i v e r I d

2 geometry_msgs/PoseWithCovarianceStamped msg

14 Implementierung

4.6 Navigationsdatentransformation

Die Applikation zeigt einen Kartenbildschirm an. Auf ihm werden TurtleBots auf ihren ge-

rade lokalisierten Positionen angezeigt. Die Bilddarstellung unter Android oder in digitaler

Bilddarstellung allgemein erfolgt mit Pixeln anders als die im AMCL-Paket von ROS genutzte

Datendarstellung, die in Metern erfolgt. Um zwischen diesen beiden Darstellungen wechseln

zu können, wie es für die Darstellung der Position eines TurtleBots oder das Senden neuer

Fahrtziele notwendig ist, benötigt die Applikation eine Karte die in einer dieser Darstellungen

vorliegt. Zur Erstellung der Karte wurde das gmapping Paket [4] aus dem ROS Fundus

verwendet. Es handelt sich dabei um eine Anwendung zur Kartografierung und Lokalisierung

innerhalb einer unbekannten Umgebung [3]. Sie exportiert die erfassten Umgebungsdaten

als binär kodierte PGM2. Im Dateiheader sind dabei der Ersteller der Datei und die Auflösung

in Meter pro Pixel angegeben. Zusätzlich wird eine YAML-Datei mit weiteren Metadaten

gespeichert. Die Applikation benötigt eine solche PGM Datei, die zu diesem Zweck angelegt

wurde. Beim Start der Applikation wird die PGM über eine Parsermethode eingelesen und in

eine Bitmap konvertiert und gespeichert, falls dies noch nicht zu einem vorherigen Zeitpunkt

geschehen ist. In der Applikation sind zur Laufzeit demnach Länge, Breite und Auflösung

des Kartenbilds bekannt. Zusätzlich ist der Ursprung des Koordinatensystems des TurtleBots

in der YAML-Datei erfasst, da das AMCL-Paket bei der Erstellung der Karte die Startposition

des betreffenden Roboters als Ursprung des Kartenkoordinatensystems zu Grunde legt. Da-

her sind alle Daten die für den TurtleBot zu verarbeiten sind relativ zum Ursprung seines

Koordinatensystems gespeichert. Die Transformation, die die Applikation daher durchführen

muss, lässt sich leicht anhand eines Beispiels erklären: Klickt jemand auf eine Position auf

dem Kartenbildschirm, so trifft er oder sie einen Pixel auf der Kartenbitmap. Der Pixel stellt

hierbei ein Tupel (x,y) dar, wobei x zwischen 0 und der Breite des Bildes und y zwischen 0

und der Höhe des Bildes liegen muss. Die beiden Variablen x und y lassen sich nun separat

voneinander in Meter umrechnen. Für y:

Y PixelZuMeter (y) = (y − hohe) ∗ au f l osung + ursprungY

Die Höhe wird hierbei subtrahiert da die Y-Achse des Bildes in die entgegengesetzte Rich-

tung zu klassischen kartesischen Koordinatensystemen verläuft. Für x wird analog dazu

berechnet, hierbei verlaufen die X-Achse des Bildkoordinatensystems und des kartesischen

Koordinatensystems gleich daher muss hier keine Subtraktion der Breite erfolgen:

X PixelZuMeter (x) = x ∗ au f l osung + ursprungX

2Portable Graymap, kurz PGM, ist ein Datenformat zur Ablage von Graubildern. Im Dateiheader sind siedurch den ASCII-Code P5 definiert, darauf folgt Platz für Kommentare, Länge und Breite des Bildes, der maximaleGrauwert (schwarz) und schließlich die Daten.

4.6 Navigationsdatentransformation 15

Um von den TurtleBots gesendeten Daten in Metern umzurechnen werden die Umkehrfunk-

tionen der beiden oben zu sehenden Formeln genutzt.

4.7 Rechte der Applikation

Die Applikation benötigt um zu Funktionieren eine Liste von Rechten vom Android Betriebs-

system. Die Rechte ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, CHANGE_WIFI_STATE

und CHANGE_NETWORK_STATE autorisieren Zugriff auf den Netzwerkstatus und erlauben

diesen zu ändern. Diese Rechte werden von ROS zum Starten des Cores benötigt. Zusätzlich

ist für freien Netzwerkzugriff das INTERNET Recht erforderlich. WRITE_EXTERNAL_STORAGE

wird zum Schreiben der im PGM-Format vorliegenden Karte benötigt. Die Karte, die als

Ressource mit der Applikation ausgeliefert wird, wird beim ersten Starten der Applikation in

den externen Speicher geschrieben. Sie kann dadurch falls später eine neue Karte verwendet

werden soll einfach vom Benutzer ersetzt werden. Da von da an die Karte stets vom externen

Speicher gelesen wird, wird auch das READ_EXTERNAL_STORAGE Recht benötigt. Die Appli-

kation sammelt zudem keine persönlichen Daten, Metadaten über Netzwerkverbindungen

und Benutzungsstatistiken. Außerdem werden keine Nachrichten an Computer oder andere

Geräte außerhalb des lokalen Netzwerks versendet.

16 Implementierung

5 Diskussion

Für dieses Kapitel wurden die Funktionalitäten der Applikation getestet. Dabei stellte sich

heraus, dass die Applikation die Aufgabe zur Steuerung der TurtleBots vollumfänglich er-

füllt. Es wurde unter Android 4.4 und Android 4.1.2 getestet und funktionierte problemlos.

Daher konzentriert sich die Diskussion mehr auf das Software-Design beziehungsweise die

Bibliotheken mit denen die Applikation umgesetzt wurde.

5.1 Vor- und Nachteile der implementierten Lösung

Die Applikation wurde unter Zuhilfenahme von rosjava implementiert, eine Alternative dazu

wäre die Nutzung der roscpp Implementierung und Entwicklung mit dem Android NDK

zur Verbesserung der Performance gewesen. Für die Zukunft könnte ein Umstieg allerdings

notwendig werden, wenn die rosjava Implementierung auf Nachrichtenebene nicht mehr

kompatibel ist, da ein fortschreiten der Entwicklung auf GitHub innerhalb des letzten Jahres

nicht zu beobachten ist[11]. Funktionale Änderungen in roscpp sind zumindest im Bezug auf

die Applikation nicht relevant solange sich am Format der ROS Messages nichts ändert, da

die Nachrichtenverarbeitung in rosjava vorhanden ist und im Rahmen dieser Arbeit stabil

funktioniert hat.

Auch die Anzeige der Karte hat einige Schwächen. So kann es passieren, dass wenn na-

he genug heran gezoomt wird nur noch eine weiße Fläche erkennbar ist, da keine weiteren

Hindernisse in der Nähe zu sehen sind, wodurch die Orientierung erschwert wird. Hier

ließe sich ein Raster einblenden, dass den Abstand zwischen den Rasterlinien einblendet.

Alternativ wäre auch das einblenden einer Miniaturansicht der Karte oder eines Kartenaus-

schnitts in einer der Ecken des Kartenbildschirms möglich, um eine bessere Orientierung zu

ermöglichen. Im Vergleich zu rviz, dem Visualisierungswerkzeug von ROS, welches bisher

hauptsächlich zur Steuerung der TurtleBots im Fachgebiet Verteilte Systeme genutzt wird,

kann die Applikation keine aktuelle Sicht des TurtleBots einblenden. Mit der aktuellen Sicht

ist der Datenstrom vom Laserscanner des TurtleBots gemeint, über den Hindernisse und

ihr Abstand vom TurtleBot und ihre Position auf der Karte angezeigt werden können. Die

Datenmenge benötigt zur Visualisierung eine hohe Datenverarbeitungsgeschwindigkeit, die

nicht auf jedem Android-fähigen Gerät gegeben ist. Wenn eine solche Funktionalität in der

17

Zukunft implementiert werden soll, empfiehlt sich eine vorherige Filterung oder Zusammen-

fassung der Daten. Die Applikation hat durch ihre Implementierung mithilfe von rosjava und

ros-android auch Vorteile, so lassen sich leicht bestehende Bibliotheken aus der Android- und

Java-Welt integrieren um sie zu nutzen. In der Applikation wird YamlBeans[16], eine Biblio-

thek zum Lesen und Schreiben von YAML-Dateien, und PhotoView[17], eine Bibliothek für

Android zur Anzeige von zoom- und scrollbaren Bildern, genutzt. Die Androidapplikation ist

zudem durch die Klassenhierarchien für Kommandos, Kartenoverlays, gepackte Nachrichten

und den UDP-Proxy leicht erweiterbar.

5.2 Fähigkeiten und Grenzen von ros-android und rosjava

Die Java-Implementierung von ROS ist wie in Abschnitt 4.2 angesprochen nicht äquivalent

in seiner Funktionalität zu roscpp. Das Fehlen der MessageEvent Klasse ist in dieser Hinsicht

zwar ein Mangel, kann aber durch eine Erweiterung der Messages und Nachrichtenverarbei-

tung einer rosjava Anwendung stets ausgeglichen werden. Bei ros-android ist vor allem die

Initialisierung der ROS Nodes ein Nebenläufigkeitsproblem. Die Initialisierungsmethode einer

RosActivity, ist nicht blockierend, was wiederum dazu führt, dass während einer Initialisie-

rung der ROS Nodes einer Applikation, die Anwendung bereits gestartet werden kann. Das ist

nicht im ROS Wiki dokumentiert und kann daher zu unerwarteten Nebenläufigkeitsproble-

men führen, wie es beispielsweise auch in diesem Projekt zu einigen gekommen ist. Trotzdem

lässt sich auf Basis von rosjava beziehungsweise ros-android eine stabile ROS-Anwendung

programmieren, da grundlegende Dinge, wie ROS Messages, und die Möglichkeit aus vor-

handenen ROS Messages Java-Klassen zu generieren, um mit bestehenden ROS-Paketen zu

interagieren, Publisher und Subscriber vorhanden sind und funktionieren.

5.3 Besonderheiten beim Betrieb der Applikation unter Android6.0

Die Applikation wurde unter Android 4.4, 4.1.2 und Android 6.0 getestet. Dabei fiel auf das

es einige Unterschiede im Betrieb der Applikation unter Android 6.0 gibt. So werden hier

nicht mehr automatische die Schreibrechte für die SD-Karte erteilt, sodass ein erstes Starten

der Anwendung scheitert. Es sei denn es wird im voraus in dem Anwendungsmanager von

Android eingestellt, dass dieses Recht erteilt wird. Die Applikation scheint unter Android 6.0

keine Probleme zu verursachen, obwohl keine TurtleBots angezeigt werden und auch keine

Nachrichten an sie versendet werden können. Tatsächlich ist die Ursache dieses Problems,

dass unter Android 6.0 standardmäßig kein Multicast mehr erlaubt ist. Dieser wird aber vom

UDPProxy zum Verschicken der Nachrichten im Netzwerk benötigt. Durch einen Kommili-

tonen, der ein gerootetes Smartphone mit Android 6.0 besitzt konnte ich die Applikation

18 Diskussion

damit testen. Mit dieser Gerätekonfiguration funktionierte die Applikation problemlos. Nach

einiger Recherche stellte sich heraus, dass der Linux Kernel des Systems mit der benötigten

Komponente für den Multicast von Google standardmäßig für die meisten neu erscheinenden

Geräte nicht mehr mit kompiliert wird und Drittanbieter von Android Smartphones diese

Standardeinstellungen von Google nicht weiter bearbeiten [20].

5.3 Besonderheiten beim Betrieb der Applikation unter Android 6.0 19

6 Zusammenfassung und Ausblick

Die Applikation funktioniert wie in der Aufgabenstellung gefordert. Doch könnte man gerade

im Hinblick auf die Kompatibilität der verschiedenen Androidversionen noch einiges verbes-

sern. Es wäre möglich einen Webservice zu entwickeln der die selbe Funktionalität ausliefert.

Im Backend der Webanwendung könnte ein ROS Node laufen. Die Logik für die Anwendung

in ROS ist bereits vollständig vorhanden. Einzig die Oberflächenlogik müsste reimplementiert

werden. Dies hätte den Vorteil das jedes Gerät das einen modernen Webbrowser hat die

Anwendung nutzen könnte, wozu Geräte mit Betriebssystemen wie Windows, Mac, Linux,

Android, iOS und viele weitere zählen. Außerdem hätte es den Vorteil, dass roscpp anstelle

von rosjava verwendet werden kann, was alle Punkte in Abschnitt 5.2 und 5.3 erschlagen

hätte. Natürlich hätten sich in einem solchen Szenario die Latenzen des Nachrichtenverkehrs

erhöht. Um diese zu verringern könnte ein TurtleBot den Service selbst anbieten und dadurch

eine Kommunikation über Loopback (für lokale Anweisungen) oder Interprozesskommunika-

tion von ROS mit dem UDPProxy für Steuerung von mehreren TurtleBots nutzen. Außerdem

würde damit das Updaten der Anwendung für alle Nutzer einfacher, da jede Änderung an der

Webanwendungen beim nächsten Aufruf der Seite automatisch für den Nutzer in Kraft tritt.

20

7 Literaturverzeichnis

[1] Frank Dellaert, Dieter Fox, Wolfram Burgard und Sebastian Thrun.

„Monte carlo localization for mobile robots“.

In: Robotics and Automation, 1999. Proceedings. 1999 IEEE International Conference

on.

Bd. 2.

IEEE. 1999,

S. 1322–1328.

[2] Morgan Quigley, Ken Conley, Brian Gerkey, Josh Faust, Tully Foote, Jeremy Leibs,

Rob Wheeler und Andrew Y Ng.

„ROS: an open-source Robot Operating System“.

In: ICRA workshop on open source software.

Bd. 3.

3.2.

Kobe, Japan. 2009,

S. 5.

[3] G. Grisetti, C. Stachniss und W. Burgard.

Improved Techniques for Grid Mapping with Rao-Blackwellized Particle Filters.

Bd. 23: IEEE Transactions on Robotics.

2007.

[4] gmapping.

Package Summary.

9. Dez. 2015.

URL: http://wiki.ros.org/gmapping?distro=indigo (besucht am

25. 06. 2016).

[5] TurtleBot Internetseite.

4. Apr. 2016.

URL: http://www.turtlebot.com/ (besucht am 25. 06. 2016).

[6] Android Implementierung von ROS.

1. März 2015.

URL: http://wiki.ros.org/android (besucht am 25. 06. 2016).

21

[7] Android NDK Dokumentation.

13. Apr. 2016.

URL:https://developer.android.com/ndk/guides/index.html

(besucht am 25. 06. 2016).

[8] ROS Introduction.

1. März 2015.

URL:http://wiki.ros.org/ROS/Introduction (besucht am 21. 06. 2016).

[9] ROS C++ Implementation.

2. Nov. 2015.

URL: http://wiki.ros.org/roscpp (besucht am 21. 06. 2016).

[10] ROS Java Implementation.

1. März 2015.

URL: http://wiki.ros.org/rosjava (besucht am 21. 06. 2016).

[11] ROS Java GitHub Repository.

20. Juni 2016.

URL: https://github.com/rosjava (besucht am 21. 06. 2016).

[12] rosjava/rosjava_core.

An implementation of ROS in pure Java with Android support.

21. Okt. 2013.

URL: https://github.com/rosjava/rosjava%5C_core (besucht am

09. 09. 2016).

[13] Damon Kohler.

Introduction to rosjava.

Google Inc.

22. Aug. 2013.

URL:http://roscon.ros.org/wp-uploads/2012/06/Introduction%

20to%20rosjava%20(ROSCon%202012).pdf (besucht am 09. 09. 2016).

[14] ROS Multimaster Projects.

2. Apr. 2015.

URL: http://wiki.ros.org/sig/Multimaster%5C#Projects (be-

sucht am 21. 06. 2016).

[15] Github Carpe Noctem Cassel UDP Proxy Generator.

29. Apr. 2016.

URL:https://github.com/carpe-noctem-cassel/supplementary/

tree/master/udp%5C_proxy%5C_generator (besucht am 21. 06. 2016).

[16] YamlBeans Github Repository.

3. Juni 2016.

22 Literaturverzeichnis

URL: https://github.com/EsotericSoftware/yamlbeans (besucht

am 21. 06. 2016).

[17] Chris Banes.

PhotoView GitHub Repository.

16. Mai 2016.

URL: https://github.com/chrisbanes/PhotoView (besucht am

21. 06. 2016).

[18] TurtleBot 2 Complete + Options Package.

21. Juni 2016.

URL: http://www.active-robots.com/turtlebot-2-complete-

and-options-package (besucht am 21. 06. 2016).

[19] TurtleBot 2 - Mobile Roboter Plattform.

21. Juni 2016.

URL:https://nodna.de/TurtleBot-2-Mobile-Roboter-Plattform

(besucht am 21. 06. 2016).

[20] Many devices have multicast disabled in the kernel.

6. Jan. 2016.

URL: https://code.google.com/p/android/issues/detail?

id=51195 (besucht am 18. 09. 2016).

[21] turtlebot_2_lg.png.

26. Aug. 2016.

URL: http://www.turtlebot.com/assets/images/turtlebot%

5C_2%5C_lg.png (besucht am 18. 09. 2016).

[22] MaraudersMap App.

26. Aug. 2016.

URL:https://github.com/carpe-noctem-cassel/cnc-turtlebots/

tree/master/ttb%5C_apps (besucht am 27. 09. 2016).

23