-
Bachelorarbeit
Enwurf und Implementierung einesKomponentenkatalogs fr
automatisierte Tests
von
Simon Ebner
Betreuer: Prof. Dr.Ing. Alexander VerlDipl.Ing. Florian
Weihardt
am
Institut fr Steuerungstechnikder Werkzeugmaschinen und
Industrieroboter,
Universitt Stuttgart
in Zusammenarbeit mit dem
Fraunhofer-Institut frProduktionstechnik und
Automatisierung,
Institutszentrum Stuttgart
August 2013
-
Inhaltsverzeichnis
Eidesstattliche Erklrung vi
Abkrzungsverzeichnis viii
Nomenklatur ix
1 Einleitung 1
2 Grundlagen und Stand der Technik 32.1 Robot Operating System .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2
Versionierte Verwaltung von Sourcecode . . . . . . . . . . . . . .
. . . . . 42.3 Kontinuierliche Integration mit Hilfe des
Jenkins-Servers . . . . . . . . . . 42.4 Softwaretests . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Problemstellung 73.1 Aufgaben und Probleme des
Komponentenentwicklers . . . . . . . . . . . 73.2 Aufgaben und
Probleme des Applikationsentwicklers . . . . . . . . . . . . 83.3
Gemeinsame Probleme von Komponenten- und Applikationsentwickler . .
10
4 Lsungsansatz 114.1 Anforderungen des Komponenten- und
Applikationsentwicklers an das
Testframework und den Komponentenkatalog . . . . . . . . . . . .
. . . . 114.2 Aufbau von Komponentenkatalog und Testframework . . .
. . . . . . . . 12
4.2.1 Schematische Funktionsweise . . . . . . . . . . . . . . .
. . . . . . 124.3 Das Testframework . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 15
4.3.1 Syntheseschritt . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 164.3.2 Analyseschritt . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 18
4.4 Der Komponentenkatalog . . . . . . . . . . . . . . . . . . .
. . . . . . . . 194.4.1 Datenbank . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 194.4.2 Visualisierung . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 20
4.5 Aufbau von Testpaketen und Integration in einen CI-Server .
. . . . . . . 27
5 Implementierung 285.1 Implementierung des Testframeworks . . .
. . . . . . . . . . . . . . . . . . 285.2 Aufbau des
Syntheseschritts . . . . . . . . . . . . . . . . . . . . . . . . .
. 28
5.2.1 Testvorbereitung . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 305.2.2 Einbindung des Basistests . . . . . . . . . .
. . . . . . . . . . . . . 30
iii
-
5.2.3 Implementierung des Testablaufs . . . . . . . . . . . . .
. . . . . . 325.2.4 Konfigurationsmglichkeiten des Syntheschritts .
. . . . . . . . . . 335.2.5 Zusammenspiel des Syntheseschritts im
Prozess der kontinuierli-
chen Integration . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 355.3 Funktionsweise des Analysemoduls . . . . . . . . . .
. . . . . . . . . . . . 355.4 Implementierung des
Komponentenkatalogs . . . . . . . . . . . . . . . . . 39
5.4.1 Implementierung des Backends . . . . . . . . . . . . . . .
. . . . . 395.4.2 Implementierung des Frontends . . . . . . . . . .
. . . . . . . . . . 40
6 Auswertung und Analyse 436.1 Vergleich verschiedener Roboter
mit derselben Navigationskomponente . . 456.2 Vergleich
verschiedener Navigationskomponenten mit demselben Roboter 466.3
Vergleich des simulierten und realen Verhaltens . . . . . . . . . .
. . . . . 48
7 Zusammenfassung 50
iv
-
Eidesstattliche ErklrungIch versichere hiermit, dass ich, Simon
Ebner, die vorliegende Bachelorarbeit mit demThema
Enwurf und Implementierung eines Komponentenkatalogs fr
automatisierte Tests
selbststndig angefertigt, keine anderen als die angegebenen
Hilfsmittel benutzt undsowohl wrtliche, als auch sinngem entlehnte
Stellen als solche kenntlich gemachthabe. Die Arbeit hat in
gleicher oder hnlicher Form noch keiner anderen Prfungsbe-hrde
vorgelegen.
Simon EbnerStuttgart, den 11. August 2013
vi
-
AbkrzungsverzeichnisCBSE . . . . . . . . . . Component-Based
Software EngineeringCI . . . . . . . . . . . . . . Continous
IntegrationCOB . . . . . . . . . . . Care-O-botCVS . . . . . . . .
. . . Concurrent Versions SystemDOM . . . . . . . . . . . Document
Object ModelHTML . . . . . . . . . Hypertext Markup LanguageHTTP .
. . . . . . . . . Hypertext Transfer ProtocolIPA . . . . . . . . .
. . . Institut fr Produktionstechnik und AutomatisierungJSON . . .
. . . . . . . JavaScript Object NotationMVC . . . . . . . . . . .
Model-View-ControllerOSRF . . . . . . . . . . Open Source Robotics
FoundationROS . . . . . . . . . . . Robot Operating SystemSCM . . .
. . . . . . . . Source Code ManagementSLAM . . . . . . . . . .
Simultaneous Localization and MappingSVN . . . . . . . . . . .
Apache SubversionURI . . . . . . . . . . . . Uniform Resource
IdentifierW3C . . . . . . . . . . . World Wide Web ConsortiumXHR .
. . . . . . . . . . XMLHttpRequestXML . . . . . . . . . . .
Extensible Markup LanguageYAML . . . . . . . . . YAML Aint Markup
Language
viii
-
Nomenklatur
KomponenteEine Komponente ist eine logische Funktionseinheit.
Die genauen Grenzen sind nichtklar definiert und sind abhngig vom
betrachteten System. Im ROS-kosystem setztsich eine Komponente
blicherweise aus mehreren Paketen zusammen. Zu einer
Naviga-tionskomponente gehren beispielsweise Bahnplanung,
Lokalisierung und Pfadregelung.
Komponentenbasierte SoftwareentwicklungAls Component-Based
Software Engineering(CBSE) bezeichnet man die Entwicklung ei-ner
Software anhand einer komponentenbasierten Architektur. Hierbei
handelt es sichum eine etablierte Methodologie, die unter anderem
Ausdrcke wie plug-and-play ge-prgt hat. Dieser Begriff
verdeutlicht, dass einzelne Komponenten isoliert
voneinandererstellt, und nach Belieben in ein bestehendes System
integriert werden knnen. Im Ide-alfall wird hierbei
Codeduplizierung vollstndig vermieden, da smtliche
Funktionalitteinmalig in einer Komponente gekapselt und anschlieend
beliebig oft wiederverwendetwerden kann. In einer solchen
Architektur gibt es grundstzlich die zwei unterschiedli-chen
Entwicklergruppen der Applikations-und Komponentenentwickler.
KomponentenentwicklerEin Komponentenentwickler bernimmt die
klassische Aufgabe eines Programmierers.Er entwirft und verbessert
Softwarekomponenten und ist dabei bestrebt die Qualittseiner
Software kontinuierlich zu verbessern. Zu den wichtigsten
Attributen der Soft-warequalitt zhlen: Funktionsumfang,
Zuverlssigkeit, Bedienbarkeit, Effizienz, War-tungsfreundlichkeit
und Portabilitt [1].
ApplikationsentwicklerDer Applikationsentwickler entwirft keine
eigenen Komponenten. In einer komponenten-basierten Architektur
verwendet er Pakete unterschiedlicher Entwickler und fgt diesezu
einer neuen, komplexen Applikation zusammen.
ix
-
ROS-PackageSmtliche Software in ROS ist in Pakete gegliedert.
Diese ROS-Pakete knnen ROS-Nodes, ROS-Launchfiles aber auch
beliebige andere, ROS-unabhngige Software undDateien enthalten.
ROS-Pakete enthalten oftmals ein Makefile, so dass diese
kompiliertwerden knnen.
ROS-StackEin ROS-Stack ist eine logische Einheit, die mehrere
Pakete bndelt. Der Stack hatdarber hinaus keine relevante
Bedeutung.
ROS-NodeEin ROS-Node ist die kleinste Einheit eines ROS-Pakets.
Es ist ein Programm, welchessich in dem ROS-Framework registriert.
Anschlieend ist jeder ROS-Node in der Lagemit anderen ROS-Nodes ber
ROS-Topics und ROS-Services zu kommunizieren. bli-cherweise spaltet
sich jede Komponente in viele ROS-Nodes mit individuellen
Aufgabenauf.
ROS-LaunchfileEin ROS-Launchfile ist eine Datei im Extensible
Markup Language (XML)-Format, de-ren Hauptaufgabe darin besteht,
verschiedene ROS-Nodes zu starten. Die Datei wirdinnerhalb des
zugehrigen Pakets gespeichert und kann ber den Befehl roslaunch
oderrostest ausgefhrt werden. Der Befehl rostest wird dazu
verwendet die Unit-Tests aus-zufhren. ROS-Node werden innerhalb des
Launchfiles entweder als normaler Node oderTest-Node deklariert.
Test-Nodes werden nur gestartet, wenn das Launchfile ber denBefehl
rostest ausgefhrt wird, andernfalls werden diese bersprungen. Das
Launchfilebietet die Mglichkeit, den Nodes verschiedene Parametern
zu bergeben. Diese Parame-ter knnen entweder explizit gesetzt oder
ber eine Parameterdatei geladen werden. berif und else Tags besteht
die Mglichkeit der Logiksteuerung innerhalb eines Launchfiles.Mit
Hilfe des Tags group, knnen verschiedene Nodes in einem gemeinsamen
Namespacegestartet werden. Um Launchfiles bersichtlich zu
strukturieren ist es mglich, Launch-files ineinander zu
verschalten. Dies wird durch das include-Tag ermglicht, welches
einexternes Launchfile in das aktuelle Launchfile einbindet.
Allgemein ist die Syntax vonLaunchfiles sehr flexibel und
leistungsfhig. Sie beinhaltet eine Vielzahl an unterschied-lichen
Tags und Parametern [2].
ROS-TopicEin ROS-Topic ist die ROS-spezifische Implementierung
des Publish-Subscribe-Entwurfmusters. Ein ROS-Topic kann von einem
oder mehreren ROS-Nodes gesendet
x
-
werden. Es ist dabei ber einen Topicnamen und einen Topictyp
spezifiziert. Der Topic-typ legt fest, welche Daten innerhalb einer
Nachricht gesendet werden. Jeder ROS-Node,der Interesse an der
jeweiligen Nachricht hat, kann sich zu dem ROS-Topic verbinden.Dazu
bergibt er den Topicnamen und eine Callback-Funktion, welche fr
jede neueNachricht aufgerufen wird.
ROS-ServiceEin ROS-Service ermglicht einen Aufruf einer fernen
Prozedur (Remote Procedure Call).Dabei gibt es einen Client, der
die Prozedur aufruft, und einen Server, welcher dieProzedur zur
Verfgung stellt. Identifiziert wird die Prozedur ber einen
Servicenamenund einen Servicetyp. Der Aufruf erfolgt synchron, dies
bedeutet der Client blockiertsolange bis er eine Antwort des
Servers erhlt. Mit jedem Aufruf werden Daten vomClient an den
Server gesendet, welcher ber seine Antwort Daten zurckgibt. ber
denNachrichtentyp wird definiert, Wie diese Daten aufgebaut sein
mssen. In ROS kannjeder Node einen Service bereitstellen. Dieser
kann daraufhin von jedem Node aufgerufenwerden, der ber den
passenden Servicenamen verfgt.
ROS-BagfileROS bietet die Mglichkeit sogenannte ROS-Bagfiles
aufzuzeichnen. Darin knnen belie-bige ROS-Topics gespeichert und zu
einem spteren Zeitpunkt erneut abgespielt werden.Dies ist besonders
vorteilhaft, wenn man zu einem spteren Zeitpunkt eine Analyse
be-reits durchgefhrter Experimente vornehmen mchte. Das Experiment
kann in diesemFall sowohl in der Simulation als auch in der Realitt
vorgenommen worden sein.
GazeboGazebo ist eine, auf Roboter ausgelegte,
Simulationsumgebung. Diese ist in der Lageeinen oder mehrere
Roboter, sowie dessen Sensoren und Aktuatoren in einer drei
dimen-sionalen Welt zu simulieren. Ermglicht wird dies durch eine
Physik-Engine die auf derPhysik starrer Krper
(Rigid-Body-Mechanics) basiert. Die Gazebo wird von ROS
nativuntersttzt und kommuniziert mit Hilfe von Topics und
Services.
JenkinsJenkins ist ein CI-Server, dessen Entwicklung ursprnglich
im Jahre 2004 unter dem Na-men Hudson begann. Er wurde von Kohsuke
Kawaguchi als Hilfstool fr seine Arbeit imRahmen des Konzerns Sun
Microsystems entwickelt. Im Jahre 2008 wurde das Programmauf Grund
hoher Popularitt in einem selbstndigen Projekt weitergefhrt. Nach
derbernahme von Sun Microsystems durch den Oracle Konzern im Jahre
2010 endeten dieSpannungen zwischen den neuen Eigentmern und der
Hudson-Entwicklergemeinschaft
xi
-
schlussendlich in einer Trennung: Die ehemalige
Entwicklergemeinschaft stellte ihren Co-de auf der
Open-Source-Plattform GitHub zur Verfgung und benannte ihr Projekt
inJenkins um. Das ehemalige Projekt Hudson wurde von Oracle
parallel weiterentwickelt,verlor aber stark an Popularitt.Der
Jenkins-CI-Server besticht vor allem durch seine hohe Flexibilitt.
Da er in Java
geschrieben ist, kann er unter nahezu allen verbreiteten
Betriebssystemen eingesetzt wer-den. Zustzlich verfgt er ber ein
Plugin-System, so dass beliebig erweitert werden kann.Alle Plugins
stehen zum freien Download in einem zentralen Plugin-Manager zur
Verf-gung, so dass fr viele der gngigen Probleme bereits
fertiggestellte Lsungen verfgbarsind. Die Basisaufgabe von Jenkins
besteht darin, ein SCM-Repository zu berwachen,bei neuen
Codenderungen die Software herunterzuladen, zu bauen und
anschlieendzu testen. Standardmig wird zudem eine E-Mail
Benachrichtigung versendet, die denzustndigen Entwickler darber
informiert ob der Kompilier- und Testvorgang erfolg-reich war. Alle
weiteren Konfigurationsmglichkeiten der Jenkins-CI-Software
knnender Literatur entnommen werden [3].
GITGIT ist eines der populrsten dezentralen SCM-Tools. Es wurde
von Linus Torvalds,dem Mitbegrnder des Linux Kernels konzipiert. Um
Dateien mit Hilfe von GIT zusynchronisieren bentigt es mindestens
zwei sogenannter Repositories. Ein Repositoryist ein GIT-Projekt.
In der Regel wird dabei ein Repository auf dem lokalen
Computereingerichtet und das andere auf einem externen Server.
Zwischen diesen beiden Re-positories knnen anschlieend Daten
ausgetauscht werden. Andere Entwickler knneneine lokale Kopie des
zentralen Repositories anlegen, falls sie die bentigte
Leseberech-tigung besitzen. Verfgen sie ber zustzliche
Schreibrechte, knnen sie auerdem ihrelokalen nderungen auf den
zentralen Server hochladen und somit allen Entwicklernzur Verfgung
stellen. Generell kann ein GIT-Repository mit jedem beliebigen
anderenGIT-Repository synchronisiert werden, vorausgesetzt die
bentigten Schreibrechte sindverfgbar. Die detaillierte Arbeitsweise
von GIT wird im Rahmen dieser Arbeit nichtbesprochen und kann der
entsprechenden Literatur entnommen werden [4]. Als
GIT-Serviceanbieter haben sich GitHub und BitBucket etabliert. Die
groe Verbreitung vonGIT spiegelt sich auch an den drei Millionen
Nutzern der Plattform GitHub wider. [5]
xii
-
1 EinleitungLet the future tell the truth and evaluate each one
according to his work andaccomplishments. The present is theirs;
the future, for which I really worked,is mine. [6]
Im 18. Jahrhundert legte Nikola Tesla, der Mann von dem dieses
Zitat stammt, im Ma-dison Square Garden die Grundsteine fr die
moderne Robotik. Sein mit Radiowellengesteuertes Roboterboot [7]
lste eine unaufhaltsame Entwicklung aus, die dazu fhrte,dass
Maschinen aus unserem heutigen Alltag nicht mehr wegzudenken sind.
Industriero-boter entwerfen in modernen Arbeitsstraen nahezu
autonom komplette Automobileoder nehmen uns gefhrliche und lstige
Arbeiten wie das Tragen schwerer Lasten undPallettieren ab [8].
Industrieroboter sind jedoch durch ein beschrnktes Set fester
Ar-beitsablufe programmiert. Dem entgegen steht das Feld der
Servicerobotik.Auch wenn es keine allgemeingltige Definition gibt,
welche Serviceroboter von an-
deren Formen der Robotik abgrenzt, so versteht man darunter in
der Regel autonomeRoboter, die zum Zweck haben den Menschen in
seinen (alltglichen) Aufgaben zu unter-sttzen [9]. Sie
unterscheiden sich mageblich von Industrierobotern durch ihre
Fhigkeitje nach Situation selbstndig kontextsensitive
Entscheidungen treffen zu knnen. Diesist notwendig, um sich in
ihrer unstrukturierten Umgebung zu Recht zu finden. Das be-ginnt im
Kleinen bei modernen Staubsaugrobotern, die eigenverantwortlich die
Wohnungsubern und setzt sich fort bis zu riesigen
Weltraummissionen, in denen ein Roboter gr-tenteils autark fremde
Planeten erforscht [10]. Doch auch auf der Erde gibt es
Probleme,bei denen sich intelligente Serviceroboter verdient machen
knnen. Zu einer der groenHrden der Zukunft zhlt die immer lter
werdende Gesellschaft, die in mittelfristigerZukunft zu starken
Engpssen in Pflegeheimen fhren wird. Dabei knnten Robotergleich auf
mehrere Weisen helfen. Selbstndig sind sie in der Lage Trinkglser
und Es-sensteller zu servieren oder Pfleger beim Heben schwerer
Menschen zu helfen. Durchdie Unterstzung lterer Menschen in ihrem
eigenen Haus knnen Seniorenresidenzienprventiv entlastet weden.
Erste Versuche, die sich dieser Thematik annehmen, werdenbereits im
Rahmen der WIMI-Care- [11] und SRS-Projekte [12] durchgefhrt. Die
Anzahlmglicher Einsatzgebiete ist zahlreich: Katastrophenhilfe und
autonome Fahrzeuge sindnur zwei Beispiele fr mgliche Anwendung in
mittelfristiger Zukunft. Letztere werdenzurzeit bereits erfolgreich
von der Firma Google in Kalifornien erprobt [13]. Sie sollenblinden
und alten Menschen zu mehr Mobilitt verhelfen.In der Robotik steht
die Sicherheit des Menschen an erster Stelle. Die Kollaboration
von Mensch und Maschine birgt im Fehlerfall groe Gefahren mit
lebensgefhrlichenKonsequenzen [14]. Neben den
Sicherheitsanforderungen ist die hohe Komplexitt unterwechselnden
Bedingungen intelligente Entscheidungen zu treffen ausschlaggebend
da-
1
-
fr, dass noch kein revolutionrer Serviceroboter bis zur
Marktreife vorangeschritten ist.Dabei bieten drei groe Trends der
letzten Jahre das Potential die Entwicklung sprung-haft
voranzutreiben. Durch den Paradigmenwechsel von Closed-Source zu
Open-Source-Software kann sich eine millionengroe
Entwicklergemeinschaft bilden, die dezentral berden Globus verteilt
arbeitet. Durch moderne Sourcecode-Verwaltungssysteme und
dazu-gehrigen kostenlosen Serviceanbietern wie Github werden neue
Pfade der Kollaborationbeschritten. Auf diesen Trend setzt auch das
in den letzten Jahren stark an Popularittgewonnene Robot Operating
System (ROS). Die komponentenbasierte Architektur er-mglicht, dass
individuelle Teams einzelne Module des Roboters unabhngig
entwickelnund verbessern. Diese Module knnen zu einem komplexen
Gesamtsystem kombiniertwerden.Um eine hohe Sicherheit und
Zuverlssigkeit der Roboter-Komponenten zu garantie-
ren, muss diese durch eine Vielzahl verschiedener Softwaretests
bewiesen werden. Dievorliegende Arbeit soll Entwickler bei der
Konzipierung von Softwaretests mageblichuntersttzten. Dabei wird
ein Testframework vorgestellt, das Entwickler von groenTeilen der
repetitiven Arbeit entbindet. Zustzlich bietet dieses Framework die
Mg-lichkeit mit seinen Schnittstellen problemlos in den Prozess der
kontinuierlichen Inte-gration eingegliedert zu werden. Desweiteren
wird ein Komponentenkatalog entworfen,der Testergebnisse zentral
speichert und visualisiert. Das Zusammenspiel aus automa-tisierten
Tests, Auswertung und anschlieender Visualisierung befreit den
Entwicklervon der mhsamen Arbeit der Testerstellung und frdert ihn
zustzlich durch schnellereFeedback-Zyklen. ber die lckenlose
Dokumentation kann der Fortschritt der Kompo-nente nachvollzogen
werden. Dem Entwickler steht somit mehr Zeit zur Verfgung sichauf
die Verbesserung der Komponente konzentrieren. Auerdem wird die
Einstiegshrdezur testbasierten Softwareentwicklung fr neue
Entwickler gesenkt und damit wichtigePraktiken der Softwaretechnik
vereinfacht. Insgesamt soll damit die Qualitt
beliebigerRoboterkomponenten erhht werden, wobei der Fokus auf der
Steigerung der Effizienzund Zuverlssigkeit liegt.Ausgangspunkt
dieser Arbeit bildet das Fraunhofer-Institut fr
Produktionstechnik
und Automatisierung (IPA) und der dort entwickelte Roboter
Care-O-bot (COB). Frdiesen Roboter soll mit Hilfe einer hheren
Testdichte die Softwarequalitt gesteigertwerden. Desweiteren
besteht durch die Fragmentierung der eingesetzen Software
dieNotwendigkeit automatisierte Tests durchzufhren. So sind
beispielsweise rund 200 Testsnotwendig, um alleine den kompletten
IPA-Navigationsstack unter smtlichen auftreten-den Kombinationen
und Bedingungen zu testen. Das entwickelte Testframework ist in
derLage dem Entwickler groe Teile dieser Arbeit abzunehmen. In
Kombination mit demKomponentenkatalog kann eine Langzeitanalyse
durchgefhrt und verschiedene Kom-ponenten miteinader verglichen
werden. Durch die Kollaborationsmglichkeiten ist einunkomplizierter
Austausch mit Projektpartnern gewhrleistet.
2
-
2 Grundlagen und Stand der TechnikFr die Entwicklung dieser
Arbeit wurde auf bereits bestehende Technologie aufgebaut.Die
verwendeten Softwarepakete und Bibliotheken werden nachfolgend
vorgestellt.
2.1 Robot Operating SystemDas Robot Operating System (ROS) [15]
ist ein Framework mit Schwerpunkt auf derEntwicklung von
Roboter-Software. Die Entwicklung begann 2007 in Stanford und
wurdeanschlieend vom Forschungsteam Willow Garage unter Open Source
Lizenz weiterge-fhrt. Inzwischen ist die Entwicklung von ROS in die
Verantwortung der Open SourceRobotics Foundation (OSRF)
bergegangen. ROS versteht sich selbst als kosystem,
dasunterschiedlichste Robotertypen mit verschiedener Konfiguration
untersttzten mchte.Durch seinen modularen Aufbau ist es flexibel
genug sowohl in der Service-Robotik alsauch bei Industrierobotern
Anwendung zu finden. Unter ROS wird jeder Bestandteileines
Robotersystems (Navigation, Bilderkennung, Armregelung, etc.)
unabhngig von-einander entwickelt. Eine solche Funktionseinheit
wird in ROS als Paket bezeichnet. Mitdiesem Ansatz ist es mglich,
sich fr unterschiedliche Roboter aus dem groen Angebotvorhandener
Pakete die jeweils bentigten zusammenzustellen und somit eine
individuel-le Roboter-Konfiguration aufzubauen. ROS selbst dient
dabei als Schnittstelle zwischenden verschiedenen Modulen. Die
dadurch entstehende Flexibilitt spiegelt sich in derlangen Liste
von 41 Roboter [16] wider, die erfolgreich unter ROS betrieben
werden. DasKonzept von ROS ist plattform- und sprachunabhngig
konzipiert, sodass Implementie-rungen fr mehrere Sprachen
existieren. Der Fokus liegt jedoch auf C++ und Python.ROS basiert
auf folgenden drei Sulen:
1. ROS bietet ein eigenes Paketmanagement und Buildysystem.
Sommit knnen Ab-hngigkeiten automatisch aufgelst und bersichtlich
strukturiert werden. Mit Hil-fe des durchdachten Paketmanagment
kann Funktionalitt in logischen Einheitengekapselt werden. Dies
frdert die Wiederverwendbarkeit des jeweiligen Codes.ROS bietet
zudem viele Wrapper-Klassen, sodass sich bekannte und etablierte
Bi-bliotheken direkt mit ROS verwenden lassen. Beispiel dafr ist
OpenCV und KDL.
2. ber Topics und Services schafft ROS eine standardisierte
Mglichkeit der Kom-munikation zwischen verschiedenen Nodes. Da ROS
in verschiedenen Sprachen im-plementiert ist, knnen somit sowohl
Programme die in Python als auch in C++entwickelt sind miteinander
Daten austauschen.
3. Durch seine groe Popularitt und die Verbreitung hat sich eine
weitlufige Ent-wicklergemeinschaft gebildet, welche aktive Fehler
meldet und behebt. Durch den
3
-
Einsatz von Open Source Technik kann der Quellcode von jedem
eingesehen undeditiert werden. Jeder ROS-Entwickler wird
eingeladen, sich an der Verbesserungder Codebasis zu beteiligen.
ROS selbst wird in hohem Tempo weiterentwickelt,sodass alle sechs
Monate eine neue Version verffentlicht wird.
2.2 Versionierte Verwaltung von SourcecodeDie versionierte
Verwaltung von Sourcecode mittels Source Code Management (SCM)ist
ein essentieller Bestandteil der Softwareentwicklung. SCM ermglicht
dem Entwick-ler einen Schnappschuss der aktuellen Code-Basis
anzulegen und abzuspeichern. DieseDaten werden fr gewhnlich in
einem SCM-Repository auf einem externen Server abge-legt. Neben
erhhter Redundanz der Daten wird damit die Kollaboration
verschiedenerEntwickler ermglicht: Der Code kann ausgehend von
einer gemeinsamen Basis von un-terschiedlichen Personen
weiterentwickelt werden. Nachdem ein Entwickler sein
Featureimplementiert hat, synchronisert er seine Arbeit mit dem SCM
Server. Dieser versuchtdie nderung der verschiedenen Personen
automatisch zusammenzufhren. Oftmals ge-lingt dies autonom,
andernfalls muss der Entwickler seinen Code manuell
einpflegen.Grundstzlich wird zwischen zentralen und dezentralen
SCM-Werkzeugen unterschie-den. Zu den prominentesten zentralen
SCM-Tools gehren Apache Subversion (SVN)und Concurrent Versions
System (CVS). Bei zentralen SCM-Tools knnen Entwick-ler ihren
Quellcode lediglich mit einem bestimmtem Server synchronisieren.
DezentraleSCM-Tools hingegen erlauben es, das ursprngliche
Repository zu klonen und auf be-liebigen Datentrgern abzuspeichern.
Die Grundidee ist, dass smtlicher Code immerlokal verfgbar ist und
nur bei Bedarf synchronisiert wird. Die Daten knnen dabeimit
beliebig vielen verschiedenen Repositories synchronisiert werden.
Die verbreitetstendezentralen SCM-Werkzeuge sind Git und
Mercurial.
2.3 Kontinuierliche Integration mit Hilfe des
Jenkins-ServersContinous Integration (CI) wird in der Regel in
Zusammenspiel mit einem SCM-Toolverwendet. Nach jeder Codenderung,
die auf den SCM-Server hochgeladen wird, er-stellt der CI-Server
eine Kopie des aktuellen Quellcodes, kompiliert ihn und stellt
si-cher, dass dabei keine Fehler auftreten. Anschlieend wird der
Entwickler informiert,ob und welche Art von Problemen aufgetreten
sind. Wenn die Software fehlerfrei kom-piliert wurde, werden
etwaige Software-Test gestartet. Hiermit wird sichergestellt,
dassdurch die letzte nderung keine logischen oder funktionalen
Fehler eingefhrt wurden.Durch den kontinuierlichen und
automatisierten Bau- und Testvorgang wird eine erhh-te
Softwarequalitt erreicht. Die verbreitetsten CI-Softwares sind
Hudson, sowie dessenWeiterentwicklung Jenkins und Travis CI.Die
Kombination aus SCM, CI-Server und Testsuite ist ein wertvolles
Werkzeug, wel-
ches kontinuierlich den neusten Code kompiliert und ihn testet.
Fehler knnen damit sofrh wie mglich erkannt werden.
4
-
2.4 SoftwaretestsSoftwaretests sind ein essenzieller Bestandteil
der Softwareentwicklung. Mit Hilfe vonTests kann verifiziert
werden, dass die Software die die Spezifikationen erfllt.
Desweite-ren bietet eine groe Testbasis Sicherheit bei
Codenderungen: Sofern weiterhin kein Testein Fehler aufzeigt, kann
davon ausgegangen werden, dass durch die nderungen keinneuer Fehler
eingefhrt wurde. Eine groe Sammlung an Tests bezeichnet man als
Test-suite. Man unterscheidet generell zwischen White-Box-Testing
und Black-Box-Testing:
White-Box-Testing bezeichnet eine Form des Testens, in der die
innere Strukturdes Programmcodes bekannt ist. Der Test berprft die
innere Struktur des Codesund kann somit logische Fehler frhzeitig
erkennen. Mit Hilfe von Unit-Tests wirdfehlende Funktionalitt oft
nicht identifiziert, da nur vorhandener Code getestetwird.
Black-Box-Testing bezeichnet eine Form des Testens, in der die
innere Struktur desProgrammcodes unbekannt ist. Stattdessen wird zu
einem Set von Eingangspara-metern ein spezielles Ausgangsverhalten
erwartet. Mit Black-Box-Testing kann dieordnungsgeme Zusammenarbeit
verschiedener Programmteile sichergestellt wer-den. Auf die genaue
Fehlerursache kann meistens jedoch nur schwer
rckgeschlossenwerden.
Desweiteren gibt es verschiedene Ebenen der Software-Tests. Man
unterscheidet generellzwischen Unit-Tests, Integrationstests und
Systemtests, wobei die Zuordnung der einzel-nen Tests in White-Box-
oder Black-Box-Testing nicht immer eindeutig getroffen
werdenkann.
Unit-Tests testen den Programmcode auf der tiefsten Ebene. Dabei
werden ein-zelne Klassen oder Funktionen auf die korrekte
Arbeitsweise berprft. Man ord-net sie deshalb der Klasse der
White-Box-Tests zu. In dem Programmierstil dessogenannten
Test-Driven-Development werden die Unit-Tests sogar vor dem
ei-gentlichen Programmcode entwickelt und stellen somit die
Spezifikation dar. DerProgrammierer schreibt anschlieend den
Programmcode, der die Unit-Tests er-fllt.
Integrationstests stellen sicher, dass eine Gruppe verschiedener
Module fehlerlos zu-sammenarbeiten. Das erfolgreiche Bestehen aller
Unit-Tests der beteiligten Moduleist dabei eine Voraussetzung.
Integrationsstests werden hufig als White-Box-Testsdurchgefhrt.
Systemtests stellen die hchste Ebene der Softwaretests dar.
Zuvor sollten alleUnit- und Integrationstests ausgefhrt worden
sein. Systemtests stellen auf derobersten Ebene sicher, dass
smtliche Module und sogar unterschiedliche Softwa-repakete
miteinander harmonieren. Systemtests sind dabei ausschlielich
Black-Box-Tests, die das korrekte Verhalten der Software in der
Produktionsumgebungsicherstellen.
5
-
Integrationstests und Systemtests lassen sich selbst noch feiner
granulieren und inverschiedene Gruppen unterteilen. Die weiteren
Ebenen des Softwaretests knnen derLiteratur entnommen werden [17],
[18].
6
-
3 ProblemstellungDas ROS-kosystem hat sich der
komponentenbasierten Architektur unterworfen undprofitiert
dementsprechend von der groen Entwicklungsfreiheit. ROS erbt
dadurch je-doch auch einige der Probleme und Anforderungen, die
CBSE zu eigen sind. Nachfolgendsollen die Schwierigkeiten fr den
Komponenten- und Applikationsentwickler aufgezeigtwerden.
3.1 Aufgaben und Probleme des KomponentenentwicklersDer
Komponentenentwickler konzipiert und entwickelt neue sowie
erweitert bestehendeSoftwarepakete. Dabei ist er bemht die
Softwarequalitt kontinuierlich zu verbessern.Um gute Software zu
entwickeln, reicht es allerdings nicht aus die Qualitt durch
Code-inspektion als befriedigend anzusehen. Vielmehr muss ein
Beweis erbracht werden, dervalidiert, dass die Software tatschlich
den gestellten Anforderungen gerecht wird. Dazuverwendet ein
Softwareentwickler Tests, welche die korrekte Funktionsweise
nachweisen.Um die vollstndige Komponente zu testen greift ein
Entwickler hier auf sogenannte
Systemtests zurck. Dabei ist zu beachten, dass sich kein
Algorithmus unter wechselndenBedingungen identisch verhlt. Es gibt
zum Beispiel Navigationskomponenten, die sichin hindernisfreien
Umgebugen besonders gut zurecht finden, jedoch in groe
Schwierig-keiten geraten, sobald der direkte Pfad durch Objekte
blockiert wird. Da die ServiceRoboter unter unstrukturierten
Umgebungen zum Einsatz kommen, ist es wichtig, dassder
Komponentenentwickler die korrekte Funktionsweise in
unterschiedlichen Szenariendurch ein breites Spektrum an Testfllen
sicherstellt. Auch mgliche Wechselwirkungenmit anderen Komponenten
sind nicht vollstndig auszuschlieen, obwohl die modulareStruktur
von ROS diese Wechselwirkungen zu verhindern versucht. Denkbar ist,
dasssich beispielsweise eine Navigationskomponente und eine
Greifer-Komponente gegensei-tig behindern, indem sie beide
versuchen den Roboter zu verfahren. Im Idealfall werdendie
Komponente so abgestimmt, dass sie sich die vorhanden Ressourcen
sinnvoll teilen.Auch hierfr sollte der Programmierer Testflle
erstellen, die garantieren, dass die entwi-ckelte Komponente mit
gngigen anderen Modulen des Roboters harmoniert. Dies kannunter dem
Attribut Zuverlssigkeit zusammengefasst werden.Neben der
Zuverlssigkeit, die den Grundpfeiler der Komponente bildet, sind
die ver-
ursachten Kosten ein wichtiges Kriterium. Der Entwickler
versucht, die entstehendenKosten zu minimieren. Eine
Kostenfunktion, die fr nahezu jede Komponente eine wich-tige Rolle
spielt, ist die bentigte Zeit zur Problemlsung. Es gibt jedoch auch
vieleandere Kostenfunktionen, die je nach Komponententyp variieren
knnen. Mit Hilfe derim Rahmen der Zuverlssigkeitsanalyse erstellten
Tests kann der Komponentenentwick-ler seine Software analysieren.
Dazu beobachtet der Entwickler die verursachten Kosten
7
-
unter den verschiedenen Testbedingungen. Somit ist er in der
Lage zu berprfen, frwelche Einsatzgebiete die Komponente bereits
befriedigende Ergebnisse liefert und frwelche noch
Optimierungsarbeit ntig ist. Sollten die vorhandenen Tests noch
keine auf-schlussreichen Ergebnisse liefern, kann der
Komponentenentwickler auch gezielt neueTests fr diesen Schritt
erstellen. Diese Qualittseigenschaft kann auch als durch Effizi-enz
beschrieben werden.Erschwerend kommt fr den Komponentenentwickler
hinzu, dass ROS selbst in einen
Releasezyklus von sechs Monaten eine neue Version verffentlicht.
Hierbei wird dieSchnittstelle oftmals grundlegend verndert, so dass
der Komponentencode entsprechendadaptiert werden muss, um mit der
neuen Version kompatibel zu sein. Gleichzeitig ist esjedoch nicht
empfehlenswert lediglich gegen die neuste ROS-Version zu
entwickeln, dagrere Organisationen fr die Umstellung auf eine neue
ROS-Version meistens deutlichmehr Zeit bentigen oder einzelne
Versionen komplett berspringen. Zustzlich kannes innerhalb einer
ROS-Version zu unterschiedlichem Verhalten je nach
Betriebsystembzw. Betriebssystemversion kommen. Damit
unterschiedliche Applikationsentwickler dieerstellte Komponente
problemlos unter verschiedenen ROS-Versionen und Betriebssyste-men
einsetzen knnen, muss der Komponentenentwickler verschiedene
Varianten seinerSoftware erstellen. Um die zustzliche
Fragmentierung seines Codes gegen Fehlerquellenzu schtzen, sollte
er auch hier weitere Testreihen fr jede ROS-Version und jedes zu
un-tersttzende Betriebssystem erstellen. Diese Faktoren des
Qualittsattributs bezeichnetdas Merkmal der Portabilitt.Fr den
Entwickler wird es schnell sehr aufwendig die groe Anzahl an
Testfllen ma-
nuell zu verwalten. Die Testsuite wchst fr jede zu
untersttztende Komponente oderROS-Version um ein Vielfaches an.
Insgesamt lsst sich die Anzahl an Tests folgender-maen
zusammenfassen:
nTests =nOS nROS-V ersionen nAndere Komponenten nUmgebungen
nRoboterGleichzeitig ist es essentiell, dass der Entwickler eine
hohe Softwarequalitt garantiert.
Dies ist ein wesentlicher Bestandteil der CBSE-Architektur, in
welcher jede Komponentefr eine korrekte Arbeitsweise verantwortlich
ist. Der hohe Aufwand einer Testsuitespiegelt sich auch in der, von
Entwicklern auf das Testen von Software verwendeten Zeitwider.
Diese betrgt durchschnittlich etwa 30% - 50% der tglichen
Arbeitszeit [19]. Diedadurch entstehenden Kosten sind nicht
unerheblich.
3.2 Aufgaben und Probleme des ApplikationsentwicklersDer
Applikationsentwickler erstellt selbst keine eigenen Komponenten.
Er benutzt vonanderern Entwicklern verffentliche Pakete. Durch die
unterschiedliche Kombination sol-cher Module kann ein komplexes
Szenario zusammengestellt werden. Beispiel dafr istein Szenario in
welchem ein Roboter autonom in einer unbekannten Umgebung
navigiertund nach einem bestimmten Objekt sucht, um dieses an eine
definierte Zielposition zutransportieren. Die dominanten
Komponenten in diesem Beispiel sind Navigation, Objek-terkennung
sowie Arm-und Greifplaner. Das Testzenario setzt sich aus der
gemeinsamen
8
-
Einheit von Roboter, dessen Aufgabe und Umgebung in der er sich
bewegt, zusammen.Wenn ein Applikationsentwickler ein neues
Testszenario konzipiert, muss er aus einer
Vielzahl von ROS-Komponenten auswhlen. In ROS gibt es bereits
ber 2000 Paketeund Bibliotheken [20]. Innerhalb dieser Pakete gibt
es viel Code- oder zumindest Logik-wiederholung. Dies ist zum einen
der groen Entwicklungsfreiheit der ROS-Plattform,zum anderen einer
mangelnden Kommunikation unterschiedlicher
Entwicklungsteamsgeschuldet. Deshalb tritt es hufig auf, dass
dieselbe Problemstellung von verschiedenenPaketen gelst wird [21].
Da viele Komponentenentwickler die in Kapitel 3.1 bespro-chenen
Qualittsstandards nicht einhalten, ist es hufig nicht
offensichtlich, welchenAnforderungen die jeweiligen Pakete gengen.
Desweiteren kann der Komponentenent-wickler auch speziell
konstruierte Szenarien im Vorhinein nicht testen. Daher kann
dasVerhalten eines Algorithmus, selbst wenn er in allen getesteten
Anwendungsfllen guteErgebnisse liefert, im Szenario des
Applikationsentwicklers stark divergieren.
WichtigeQualittskriterien fr den Applikationsentwicklern zeigen
sich in der Zuverlssigkeit undder Fehlerrobustheit eines Pakets.
Weitere Kriterien, mit niedrigerer Prioritt, sind
dieEntwicklungszyklen der Komponente und eine aktive
Entwicklergemeinschaft, die aufmgliche Fehler reagiert und diese
zeitnah behebt.Der Applikationsentwickler bentigt dieses Wissen und
muss anhand dieser Informa-
tionen passende Komponenten in Hinblick auf sein konzipiertes
Szenario bewerten. Inder Regel orientiert er sich bei seiner
Bewertung an physikalischen Gren. So ist frein Navigationsszenario
die Minimerung des zurckgelegten Fahrwegs oder der ben-tigten Zeit
wnschenswert. Dabei sollte dieses Ergebniss im Idealfall immer
zuverlssigerbracht werden. Sucht der Entwickler nach einer sehr
robusten Lsung, entscheidet ersich mglicherweise fr eine
Komponente, die ein Vielfaches der Zeit bentigt, dafraber unter
allen getesteten Bedingungen die Aufgabe erfllt. Dies liegt im
Ermessen desApplikationsentwicklers.Da Informationen ber die
Qualitt des Komponentencodes oder die durchschnittliche
Zeit fr die Lsung eines Problems unter den gewnschten
Bedingungen in der Regelnicht vorliegen, muss der
Applikationsentwickler dieses Wissen generieren. Hierbei greifter
auf Testreihen zurck, in denen er gezielt einzelne Komponenten
unter verschiedenenBedigungen testet. Dabei sollte er bei einem
lang angelegten Testszenario kontinuierlichdie besten Methoden
evaluieren, um seine Daten dem neusten Entwicklungsstand
anzu-passen. Fr ein aussagekrftiges Ergebnis muss der
Applikationsentwickler viele Testseri-en starten und kann
anschlieend aus den gewonnen Daten einen realistischen
Mittelwerteinschlielich dazugehriger Standardabweichung erhalten.
Die Anzahl der Tests kannschnell stark anwachsen, da der
Applikationsentwickler im Idealfall alle Kombinatio-nen mglicher
Komponenten miteinander testet. Bereits die Navigation des
Roboterslsst sich aufteilen in drei Komponenten, die verantwortlich
fr Bahnplanung, Lokalisie-rung und Pfadregelung sind. Bereits der
IPA-Fraunhofer eigene Stack beinhaltet dabeifr jede dieser
Komponenten mindestens zwei verschiedene Alternativen [22]. Um
alleKombinationen miteinander zu testen, sind daher fr den
IPA-Stack bereits mehr als20 Testflle notwendig. Fr jede weitere
Komponente, zum Beispiel fr eine zustzlicheObjekterkennung, wchst
die Anzahl der Tests um ein Vielfaches an.
9
-
3.3 Gemeinsame Probleme von Komponenten-
undApplikationsentwickler
Die Probleme des Komponenten- und Applikationsentwicklers haben
mehrere Schnitt-punkte. Beide wollen gewisse Komponententypen mit
Hilfe einer groen Testserie bereinen langen und kontinuierlichen
Zeitraum evaluieren und dabei verschiedene Metrikenanalysieren,
quantifizieren und vergleichen. Die Testlogik selbst ist dabei
innerhalb einesKomponententyps nahezu identisch: Der Test startet
die jeweilige Komponenten in einerunterschiedlichen Umgebung mit
vordefinierten Eingangsparametern und erwartet einLsungsverhalten.
Auf dem Weg der Lsungsfindung protokolliert der Test
verschiedeneMerkmale. Eine weitere gemeinsame Problemstellung ist
die Kollarborationsmglichkeit.Wenn mehrere Entwickler gemeinsam in
einem Team arbeiten, so mssen sie regelmigdie Daten der neusten
Tests austauschen. Sie mssen sich hierbei auf einen
gemeinsamenKanal einigen und alle Daten synchron halten.Die
Probleme des Komponenten- und Applikationsentwicklers unterscheiden
sich
hauptschlich dadurch, dass innerhalb der Testszenarien eines
Komponentenentwick-lers die Zielkomponente immer dieselbe bleibt.
Andere Parameter wie z.B. Roboter undUmgebung werden variiert. Der
Applikationsentwickler hingegen tauscht immer nur dieKomponente
eines speziellen Komponetentyps aus, whrend er das restliche
Setting desSzenarios identisch hlt. Am Beispiel der
Navigationskomponente kann dies nochmalsstellvertretend
verdeutlicht werden:
Komponentenentwickler: Stets selbe Navigationskomponente mit
wechselnederUmgebung, verschiedenen Hindernissen und
unterschiedlichen Robotern.
Applikationsentwickler: Verschiedene Navigationskomponenten mit
identischerUmgebung, selben Hindernissen und Roboter.
Abbildung 3.1: Schematische Darstellungen der verschiedenen
Testflle
10
-
4 LsungsansatzEin Entwickler verbringt durchschnittlich bis zu
der Hlte seiner Arbeitszeit mit derErstellung und Durchfhrung von
Softwaretests [19]. Diese Arbeit trgt zur Entlastungbei und bndelt
einen groen Teil der repetitiven Testerstellung in einem
wiederver-wendbaren Softwarepaket. Dabei werden die in Kapitel 3
erluterten Problemstellungenbercksichtigt, so dass sowohl der
Komponentenentwickler, als auch der Applikationsent-wickler bei
ihrer Arbeit sinnvoll untersttzt werden. Dies geschieht durch die
aufeinanderabgestimmten Softwarepakete des Testframeworks und
Komponentenkatalogs. Das Test-framework enthlt Basistests die mit
Hilfe der standardisierten ROS-Schnittstellen Vor-lage fr
Komponententests bieten. Die Tests knnen dabei mit Hilfe von
Parametern aufdie Bedrfnisse des Entwicklers zugeschnitten werden.
Komplexe Tests knnen somiterstellt werden ohne eigenen Programmcode
zu entwickeln. Nach dem Testdurchlaufswerden verschiedene Testgren
automatisch analysiert und in einer zentralen Daten-bank
gespeichert. Diese Daten knnen mit Hilfe des Komponentenkatalogs
visualisiertwerden.
4.1 Anforderungen des Komponenten- undApplikationsentwicklers an
das Testframework und denKomponentenkatalog
Ein Werkzeug, das beide Entwicklertypen professionell
untersttzten soll, muss den An-sprchen dieser beiden Gruppen
gerecht werden. Wie in der Problemstellung bereitsangesprochen,
gibt es einige berschneidungen bei Komponenten- und
Applikations-entwickler. Da die Erstellung von Tests fr beide
Gruppen ein sehr zeitaufwendigesUnterfangen ist, kann ein
Testframework die Arbeit der repetitiven Testerstellung
er-leichtern. Darin ist ein Basistest enthaltet, der durch Adaption
der Parameter auf jedesSzenario zugeschnitten werden kann. Um
automatisiertes Testen nach jeder Codende-rung zu ermglichen soll
die Software direkt in einen CI-Server integriert werden.
DieVisualisierung der Daten erfolgt anschlieend ber einen Browser.
Jedoch verfgen beideEntwicklergruppen in der Regel ber kein tiefes
Verstndnis von Internet-Technologien.Die Software soll sich deshalb
ber die ROS-eigenen Tools bauen und starten lassen.Fr den
Komponentenentwickler ist die Nutzung von Web-Technologien und die
leich-te Anbindung des Komponentenkatalogs an das Intra-/Internet
besonders ntzlich, daer den resultierenden Katalog als Referenz und
Validierung der eigenen Arbeit pr-sentieren kann. Hinzu kommt, dass
durch die Anbindung an das Internet verschiedeneEntwickler
unterschiedliche Tests zu der Suite hinzufgen und das Verhalten
analysie-ren knnen. Dies bietet groe Kollarborationsmglichkeiten in
dezentral organisierten
11
-
Teams, so dass ein mglichst umfangreicher Komponentenkatalog
enstehen kann. DieAuswertungssoftware selbst soll ber diverse
Filter und Sortiermglichkeiten die Optionbieten Testszenarien nach
unterschiedlichen Metriken zu sortieren. Dies erleichtert dieSuche
nach Szenarien, fr welche die Komponente optimiert werden muss bzw.
fr welchedie Komponente bereits gut funktioniert. Bei der Analyse
sollen verschiedene Diagram-me dabei helfen die Entwicklung der
Komponente darzustellen. Ntzlich hierfr sindLiniendiagramme ber die
Zeit. Darber hinaus sind weitere Debug-Mglichkeiten einwichtiges
Hilfsmittel fr den Komponentenentwickler. Im Falle eines starken
Ausreiersoder ungewhnlichen Testergebnissen (zum Beispiel eine hohe
Anzahl an Kollisionen)mchte der Komponentenentwickler den
Testverlauf nachvollziehen.Fr den Applikationsentwickler sind
Filter- und Sortiermglichkeiten ebenfalls ein
wichtiges Hilfsmittel um den Komponentenkatalog zu ordnen. Der
Entwickler kann so-mit die fr ein Szenario am geeignetsten
Komponenten einfach ermitteln. ber die An-bindung an das Internet
knnen verschiedene Entwickler neue Tests leicht hinzufgen.Damit
kann die Tauglichkeit neuer Komponenten fr das vorgegebene Szenario
evaluiertwerden. So ist es denkbar, dass externe Entwickler
eingeladen werden, ihre Komponen-tenentwickler unter den
geforderten Rahmenbedingungen zu demonstrieren. Mit Hilfegroer
Testreihen knnen anhand des resultierenden Mittelwerts und der
Varianz In-formationen bezglich der Zuverlssigkeit gewonnen werden.
Durch die Vergleichsmg-lichkeit aller Komponenten wird es mglich fr
jedes Szenario die ideale Komponenteauszuwhlen.
4.2 Aufbau von Komponentenkatalog und TestframeworkAnhand der in
Kapitel 3 vorgestellten Probleme des Komponenten- und
Applikationsent-wicklers und deren Ansprche soll im Folgenden eine
Software entwickelt werden. Diesesoll den in Kapitel 4.1 gestellten
Anforderungen gerecht werden. Die Software wird dabeibeispielhaft
fr die Klasse der Navigationskomponenten konzipiert. Sie ist jedoch
flexibelgenug, weitere Komponententypen zu untersttzen. Gleichsam
kann das Arbeitsschemabeibehalten und lediglich das Testframework
muss um zustzliche Basistests erweitertwerden.Tabelle 4.1 zeigt
eine bersicht ber die Metriken die fr die Klasse der
Navigations-
komponenten ausgewertet werden.
4.2.1 Schematische FunktionsweiseDie Software teilt sich in
mehrere Module auf. Diese lassen sich in die zwei
Kategorieneinordnen:
1. Das Testframework stellt den Testcode bereit, auf welchen der
Entwickler aufbauenkann und ist verantwortlich fr die Analyse der
Daten sowie fr die Extraktionder Metriken.
12
-
2. Der Komponentenkatalog bietet eine Mglichkeit, die
Testergebnisse zentral zuspeichern. Zum Komponentenkatalog gehrt
auch ein Webserver mit Visualisie-rung, welche die gespeicherten
Daten optisch aufbereitet und ber den Browser andie verschiedenen
Clients sendet.
Metrik Beschreibung Einheit
Distanz Kumulierte Distanz, die der Roboter innerhalb des Test
zu-rckgelegt
Meter
Rotation Kumulierte Rotation des Roboters whrend des Tests
Grad
Dauer Zeitliche Dauer, die der Roboter bentigt um von
demStartpunkt zum Endpunkt zu gelangen
Sekunden
Kollisionen Anzahl der detektierten Kollisionen whrend des
Testdurch-laufs
ohneEinheit
Tabelle 4.1: Metriken fr die Klasse der Navigationstests
Abbildung 4.1 zeigt die schematische Darstellung des
Lsungsansatzes. Die in Kapi-tel 4.1 aufgestellten gemeinsamen
Anforderungen knnen hiermit bedient werden. Diebeschwerliche
Aufgabe der Erstellung neuer Tests wird den Entwicklern durch das
Test-framework abgenommen. Ermglicht wird dies durch
standardisierte Schnittstellen vonROS. So knnen beispielsweise alle
Navigationskomponenten ber eine gemeinsame Ac-tion gesteuert und
berwacht werden. hnliche Actions sind fr andere
Komponentenverfgbar. Diese standardisierten Schnittstellen sind die
Grundvorausssetzung fr dieErstellung abstrakter Basistests. Um
einen Test auf Basis des Testframeworks zu erstel-len muss der
Programmierer lediglich Metainformationen an die Testbasis
weitergeben.Dies geschieht in Abbildung 4.1 in Schritt 1. Die
Meta-Pakete enthalten eine abstrakteBeschreibung des zu
erreichenden Ziels. Im Falle eines Navigationstests entspricht
diesdies im Wesentlichen der abzufahrenden Route. Fr ein
Objekterkennunsgszenario kannes eine Beschreibung der zu
erkennenden Gegenstnde sein. Die Meta-Pakete beinhaltenin der Regel
keinen oder nur wenig Programmcode. Das Testframework kmmert sichum
die Protokollierung der Daten, das Senden der entsprechenden
Befehle und Abfangenvon Ausnahmen und Fehlern. Es wurde mit
Hinblick auf die gemeinsame Nutzung miteinem CI-Server konzipiert
und soll daher mglichst leicht in einen solchen integrierbarsein.
Ermglicht wird das durch Schnittstellen und Skripte die Teil des
Testframeworkssind und eine problemlose Zusammenarbeit ermglichen.
Die Entwickler mssen ihreerstellten Testpakete damit nur noch auf
den Server hochladen. Dieser bernimmt an-schlieend das
automatisierte Testen und Auswerten. In Abbildung 4.1 ist dies
durchSchritt 2 verdeutlicht.Die weiteren Arbeit wird ab diesem
Zeitpunkt von dem Testframework bernommen.
Die Software wird im Hintergrund gebaut, getestet,
protokolliert, mitgeschnitten und die
13
-
Abbildung 4.1: Schematische Darstellung des Lsungsansatzes
resultierenden Daten werden anschlieend auf einen im
Inter-/Intranet verfgbaren Ser-ver gespeichert. All dies ist fr den
Entwickler abstrahiert. Er bentigt kein Fachwissenber
Web-Technologien oder die Kodierung von Videos. Nachdem sein
Testpaket in denCI-Server integriert ist muss er lediglich auf eine
Benachrichtigung warten, dass der Testdurchgefhrt wurde.
Anschlieend kann er in seinem Browser den
Komponentenkatalogaufrufen und sich die Testergebnisse ansehen. Im
Fall eines fehlgeschlagenen Testes hater ber den Komponentenkatalog
die Mglichkeit mit Hilfe eines aufgezeichneten Videosden
Sachverhalt nachzuvollziehen.
14
-
4.3 Das TestframeworkA good way to stay flexible is to write
less code. [23]
Diesen Ansatz propagieren Andrew Hunt und David Thomas [23].
Gemeinsam empfeh-len sie den Einsatz sogenannter
Metaprogrammiersprachen um wiederkehrende Aufgabenzu vereinfachen.
Diese Aufgabe soll das Testframework bernehmen. Es ist
verantwort-lich fr die gesamte Logik und Steuerung whrend des
Testdurchlaufs. Als Metasprachewirken ROS-Launchfiles, welche mit
Hilfe einer Parametrisierung erlauben das Testfra-mework nach den
jeweiligen Vorstellungen des Entwicklers zu adaptieren. Da die
ServiceRobotik ein sehr heterogenes Gebiet ist, in dem
unterschiedlichste Roboterkonfiguratio-nen zum Einsatz kommen, muss
das Testframework diesem Umstand gerecht werden.Daher ist es
mglichst generisch gestaltet um viele Roboter zu untersttzen.
Hierbeiwurde ROS als Ausgangsbasis gewhlt, damit ein Kompromiss
zwischen Flexibilitt undKomplexitt getroffen werden kann. Dies ist
sinnvoll, da ROS eine weite Verbreitung inder Robotik geniet.
Entwickler sind vertraut mit den notwendigen Schritten um eineauf
ROS basierende Software zu konfigurieren, kompilieren und
auszufhren. Desweite-ren bietet ROS standardisierte Schnittstellen,
die generische Basistests fr eine VielzahlRoboter berhaupt
ermglichen. Zustzlich besteht die Mglichkeit der
Kommunikationzwischen ROS-Paketen verschiedener Entwickler. Dies
ist wichtig, wenn es sich beispiels-weise um die Vorbereitung des
Roboters auf einen Testdurchlauf handelt. Vor jedem Testmssen
spezielle Vorkehrungen getroffen werden. Welche
Initialisierungsschritte durchge-fhrt werden mssen hngt vom
jeweiligen Roboter ab und daher werden diese in einemeigenen - dem
Roboter zugehrigen - Paket gekapselt. Vor Testbeginn
kommuniziertdas Framework mit einem solchen Paket und stellt die
ordnungsgeme Initialisierungsicher. Um den unterschiedlichen
Ansprchen gerecht zu werden, muss das Frameworkmglichst flexibel
sein, sollte jedoch auch den Entwickler von fr ihn unrelevanten
Detail-fragen entbinden. Ermglicht wird das ber sinnvoll gesetzte
Standardwerte. Der Ablaufeines Tests unter Verwendung des
Testframeworks gliedert sich in zwei entkoppelte Pha-sen:
1. Syntheseschritt: Hierbei wird der eigentliche Test
durchgefhrt. Der Roboter wirdin der Simulation oder in der realen
Welt bewegt. Dabei wird ein ROS-Bagfileerstellt, welches auf einem
zentralen Server gespeichert wird.
2. Analyseschritt: In diesem Teil wird das Bagfile analysiert.
Hierbei werden die re-levanten Informationen extrahiert.
Anschlieend werden diese in einer zentralenDatenbank gespeichert.
Diese Datenbank stellt die Schnittstelle zu dem Kompo-nentenkatalog
dar.
Es gibt mehrere Grnde dafr, dass Synthese und Analyse der Daten
in zwei Schrittengetrennt voneinander erfolgen. Zunchst ist es von
der resultierenden Programmstruk-tur sauber gegliedert.
Codenderungen knnen leicht dem einen oder anderen Paketzugeordnet
werden. Desweiteren besteht die Mglichkeit, alle relevanten
Statusinforma-tionen und Zustandsnderungen des Roboters nachtrglich
(erneut) nachzuvollziehen.
15
-
Smtliche Informationen sind in einem Bagfile gespeichert. Dieses
kann zu beliebigenZeitpunkten abgespielt werden. Dabei werden die
gesendeten Nachrichten so wiederge-geben, wie sie indem
ursprnglichen Test publiziert wurden. Dies gilt sowohl fr denrealen
Roboter, wie auch fr die Simulation. Dadurch werden interessante
Debugmg-lichkeit fr Entwickler erffnet, da auf ROS-Ebene verfolgt
werden kann, was whrenddes Tests geschehen ist.Ein weiterer
wichtiger Punkt ist das aufgezeichnete Video. Es ermglicht ein
schnel-
les Nachvollziehen des Testdurchlaufs. Dies ist sowohl zur
Fehleranalyse, als auch zurValidierung des ordnungsgemen
Testsverlaufs interessant. Im Fall eines Navigations-tests kann
somit die Roboterfahrt leicht erfasst werden und die Ursache
unerwarteterKollisionen oder eines Timeouts eingegrenzt werden. Fr
die Aufzeichnung des Videosist jedoch eine grafische Oberflche
ntig. Whrend dies in der Simulation vorausgesetztwerden kann, ist
das auf dem realen Roboter oftmals nicht der Fall. Diese
Problematikwird umgangen, in dem auch smtliche Bildinformationen
whrend des Syntheseschrit-tes in das Bagfile gespeichert werden.
Erst innerhalb des Analyseschrittes, der auf einemexternen Computer
vollzogen wird, ist eine grafische Oberflche notwendig. Durch
dieklare Trennung von Synthese und Analyse kann somit der gleiche
Testcode sowohl aufdem realen Roboter als auch in der Simulation
eingesetzt werden. Dadurch ist es mg-lich, whrend des
Testdurchlaufs auf dem realen Roboter ein Videobild aufzunehmenund
es spter ber den Komponentenkatalog wiederzugeben. Dies knnen
Bilddaten ausbeliebigen Quellen sein. Zu den interessantesten
Kameraquellen gehren 3D-LaserscanBilder, die Daten der Stereokamera
oder eine extern montierte Kamera, die den Roboterwhrend des
Testdurchlaufs filmt.
4.3.1 SyntheseschrittUm einen Testdurchlauf mit dem
Testframework durchzufhren sind nicht viele Schrit-te notwendig. Es
wird vorausgesetzt, dass der Nutzer bereits ber eine
funktionsfhigeSimulationsumgebung oder einen realen Roboter verfgt.
Auf dem Roboter, sowohl inder Simulation als auch in der Realitt,
wird dabei die zu testende Komponente be-reits erfolgreich
betrieben. Ausserdem muss die Komponente ber eine
standardisierteSchnittstelle steuerbar sein, fr welche ein
entsprechender Basistest im Testframeworkvorhanden ist. Ausgehend
von dieser Grundlage kann der Entwickler ein Testpaket
zu-sammenstellen. Er startet dazu wie gewohnt seine Simulation
einschlielich aller Kompo-nenten und inkludiert zustzlich den
Basistest des Testframeworks. Im Rahmen dieserArbeit wurde ein
Basistest fr Navigationskomponenten entworfen. Dieser wertet
dieMetriken Distanz, Dauer, Rotation, Kollisionen sowie
verschiedene Fehlerflle aus. Diebeiden wichtigsten Fehlerursachen
sind Timeout1 und Aborted2. Das Konzept eines sol-chen Katalogs
lsst sich auch auf weitere Problemstellungen bertragen.
1Der Test hat eine zeitliche Beschrnkung berschritten2Die
Navigation kann keinen Pfad zu dem Ziel finden
16
-
Videomitschnitt
Fr jeden Testdurchlauf besteht die Mglichkeit ein Video
mitzuschneiden. Dies bietetfr Komponenten- und
Applikationsentwickler einen schnellen Einblick in den Verlaufder
Tests. In der Simulation wird hierbei die Vogelperspektive des
Roboters automatischaufgezeichnet. Der Entwickler kann nach
Belieben weitere Quellen hinzufgen. Zu deninteressantesten
Kameraquellen, die sowohl in der Simulation als auch auf dem
Robo-ter verfgbar sind, zhlen 3D-Laserscandaten und
Stereo-Kameradaten. Whrend desTestdurchlaufes auf dem realen
Roboter kann auch das Videobild einer extern mon-tierten Kamera
aufgenommen werden. Dies ist ein adquater Ersatz fr die
fehlendeVogelperspektive der Simulation. Mit Hinblick auf
Navigationsszenarien und inbeson-dere sogenannte Simultaneous
Localization and Mapping (SLAM)-Navigationsszenarienbietet der
Videomitschnitt eine weitere interessante Einsatz- und
Hilfsmglichkeit: BeiSLAM-Navigationsszenarien verfgt der Roboter zu
Beginn des Tests ber keine Kennt-nis seiner Umgebung, sondern
erstellt sich im Laufe des Tests eine eigene Karte. Daherist es
interessant auch die Karte, die der Roboter kontinuierlich aufbaut,
aufzuzeichnen.Kartendaten und Robotervideo knnen spter
nebeneinander abgespielt werden und derAufbau der Karte kann
schrittweise nachvollzogen werden.Grundstzlich knnen die meisten
Informationen auch durch das erneute Abspielen des
Bagfiles durch Entwickler gewonnen werden. Der Videomitschnitt
bietet jedoch mehrereentscheidende Vorteile. So eignet sich die
Videodatei wesentlich besser zur Archivierung:Whrend ein Bagfile
nach einer Minute schon eine Dateigre von etwa einem
Gigabyteerreicht hat ist das entsprechende Video nur rund 20
Megabyte gro. Die Bagfiles werdendeshalb in der Regel nach einer
gewissen Zeitdauer vom Server gelscht um
Speicherplatzwiederzugewinnen. Desweiteren beinhaltet das Bagfile
nicht alle Informationen. Objekte,die vom Komponenten- oder
Applikationsentwickler als Teil des Testpakets in die Kartegeladen
wurden sind nicht enthalten. Im Falle eines Navigationstests kann
beispielsweisedie Rekonstruktion einer Kollision des Roboters mit
einem Hindernis somit nur schwerdurchgefhrt werden. Abschlieend
besteht ein weiterer groer Vorteil des Videos darin,dass es bequem
ber den Browser abgespielt werden kann. Fr gewhnlich treten in
denmeisten Testfllen keine schweren Ausnahmen auf. Mchte der
Entwickler deshalb nureinen kurzen berblick gewinnen ist es sehr
mhselig, das Bagfile herunterzuladen undmit den entsprechenden
ROS-Tools zu analysieren. Das Video hingegen kann per Knopf-druck
ber den Komponentenkatalog gestartet werden, ohne dass eine
ROS-Software aufdem Computer installiert ist.
Abstraktion von Komplexitt am Beispiel der
Kollisionsdetektion
Das Testframework besitzt eine Schnittstelle um mgliche
Kollisionen zu protokollie-ren. Dabei wurde ein mglichst
generischer Ansatz gewhlt, der es ermglicht beliebigeRobotersysteme
zu untersttzten. Dazu erhlt das Testframework einen optionalen
Pa-rameter CollisionsTopic. Dieser ist ein ein anschauliches
Beispiel dafr, wie komplizierteKonfigurationen von dem Benutzer
abstrahiert werden knnen. Mchte der Entwicklerdie aufgetretenen
Zusammenste nicht protokollieren, zum Beispiel weil sein
Simula-
17
-
tionsmodell nicht in der Lage ist, Kollisionen zu detektieren,
kann er den Parameterbedenkenlos auslassen. Verwendet der Benutzer
hingegen die fr ROS bliche Simulati-onsumgebung Gazebo, so kann er
Zusammenste ber ein Kollisionspaket detektieren,welches Bestandteil
des Testframeworks ist. Kollisionen knnen in Gazebo ber so
ge-nannte Bumper detektiert werden. Diese senden dazugehrige
Bumper-Topics aus. Umdas Kollisionspaket zu verwenden, muss der
Benutzer dieses lediglich in sein Testpaketeinbinden und ihm die
entsprechenden Bumper-Topics bergeben. Die restliche Kommu-nikation
zwischen Kollisionspaket und Testframework wird transparent im
Hintergrunddurchgefhrt. Durch Hinzufgen eines Moduls ist es somit
mglich eine groe Anzahl anNutzfllen abzudecken.Es gibt allerdings
auch verschiedene Umstnde unter denen der Benutzer eine
komplett
eigene Kollisionslsung bevorzugt. Die Ursache kann
beispielsweise darin liegen, dass ereine andere Simulationsumgebung
verwendet, die Bumper nicht untersttzt. Oder derEntwickler mchte
die Kollisionen an einem realen Roboter protokollieren. Wenn
dieserkeine entsprechenden Sensoren besitzt, kann er eine eigene
Komponente entwickeln, dieauf Tastendruck eine Kollision
detektiert. Die neue Komponente kann beliebig imple-mentiert sein,
wichtig ist lediglich, dass sie die entsprechenden
Kollisionsnachrichten anden ber den Parameter CollisionsTopic
festgelegten Kanal sendet.Dieser Mechanismus zeigt auf, wieviel
Handlungsfreiraum dem Entwickler zugestan-
den wird. Er kann auf vorgefertigte Lsungen zurckgreifen und
diese leicht auf seinSzenario konfigurieren. Sollte dies fr einen
speziellen Fall nicht mglich sein, so besitzter die Freiheit, eine
eigene Lsung umzusetzen und diese in die bestehende Struktur
zuintegrieren.
Ausnahmeflle
Im Syntheseschritt werden verschieden Ausnahmezustnde abgefangen
und protokolliert.Ein Testdurchlauf kann kontrolliert aus einem der
folgenden Grnde fehlschlagen:
Der Test luft in die zeitliche Beschrnkung (Timeout).
Die Navigationskomponente sendet ein Abbruchs-Signal (z.B. weil
kein Pfad frdie Zielposition gefunden werden kann).
Die Navigationskomponente navigiert falsch: der Roboter steht
nicht auf der er-warteten Zielposition.
In jedem dieser Fehlerflle wird eine entsprechende
Statusnachricht an das Bagfile an-gehngt. Dieses ermglicht im
anschlieenden Analyseschritt den Fehler ordnungsgemzu detektieren
und den Test als fehlgeschlagen zu markieren. Ansonsten wird jedoch
einregulres Bagfile identisch zu einem erfolgreichen Test generiert
und abgespeichert.
4.3.2 AnalyseschrittNachdem ein Bagfile aufgenommen wurde, wird
es auf dem lokalen Computer oder einemNetzwerk-Rechner gespeichert.
blicherweise werden die Daten zentral auf einem Server
18
-
im Intranet gelagert, welcher nachfolgend als Analyseserver
bezeichnet wird. Auf demAnalyseserver luft ein so genannter
Analyse-Daemon. Dies ist ein Softwareprozess, derstndig aktiv ist
und im Hintergrund berprft ob neue Bagfiles verfgbar sind. Ist
diesnicht der Fall ruht das Programm fr ein bestimmtes
Zeitintervall. Sobald es ein Bagfilevorfindet, startet es den
Analysevorgang und extrahiert die gewnschten Metriken. ImFalle des
Navigationstests sind dies die Daten Distanz, Rotation, Dauer und
Kollisionen(Tabelle 4.1).Der Analysevorgang spielt das im
Syntheseschritt erzeugte Bagfile erneut ab. Dabei
werden Daten, die whrend der Synthese live mitgeschnittenen
wurden, identisch wieder-gegeben. Simultan zu diesem Vorgang werden
durch das Analysetool im Hinter- und Vor-dergrund verschiedene
Prozess gestartet, die alle ntigen Informationen generieren. Umdie
Daten fr Rotation und Distanz zu erzeugen werden bestimmte
ROS-Nachrichten, sogenannte Transformationsnachrichten untersucht.
Diese enthalten die aktuelle Positionund Orientierung des Roboters
zu jedem Zeitschritt. Daraus lsst sich die Distanz undRotation
zwischen zwei aufeinanderfolgenden Zeitpunkten bestimmen. Diese
Zeitstckewerden zur insgesamt zurckgelegten Wegstrecke und Rotation
aufsummiert. Paralleldazu werden die im Syntheseschritt
aufgenommenen Kamerabilder dargestellt und mitHilfe eines
Videoprogrammes mitgeschnitten. Wenn es sich um einen
fehlgeschlagenenTest handelt, zum Beispiel weil dieser die
zeitliche Beschrnkung berschritten hat, sowerden dennoch alle
Metriken wie Distanz, Rotation, Kollisionen etc. protokolliert.
Inden Testergebnissen wird allerdings zustzlich ein Fehlercode
gesetzt, um ihn im Kom-ponentenkatalog entsprechend markieren zu
knnen.
4.4 Der KomponentenkatalogDer Komponentenkatalog gliedert sich
in die Datenbank und die Visualisierung der Da-ten. Ein Benutzer
muss in seinem Browser eine URL ansteuern und kann danach aufalle
Daten zugreifen.
4.4.1 DatenbankDie Datenbank des Komponentenkatalogs selbst ist
eine Ansammlung von Testergebnis-Dateien. Diese Dateien werden
unter einer zentralen Adresse gespeichert. Zur Speiche-rung und
Synchronisation der Daten wird das SCM-Tool GIT benutzt. Da dieses
Ver-sionierungstool groe Verbreitung geniet, ist es leicht mglich,
einen eigenen Kompo-nentenkatalog zu erffnen. Dazu muss lediglich
ein sogenanntes GIT-Repository angelegtwerden. Anschlieend knnen
Testergebnisse mit dem neuen Katalog synchronisiert wer-den. Die
einfache und schnelle Mglichkeit neue Komponentenkataloge anzulegen
bietetder Kollaboration viel Freiraum. So ist es fr Entwickler
leicht mglich, an einer Vielzahlunterschiedlicher Kataloge
mitzuarbeiten oder selbst neue Kataloge zu erffnen.
19
-
Abbildung 4.2: Interaktionsdiagramm zwischen User und
Komonentenkatalog
4.4.2 VisualisierungDie Visualisierung selbst ist eine in
CoffeeScript bzw. JavaScript entwickelte Web-An-wendung. Das
Komponentenkatalogpaket beinhaltet auerdem einen Webserver, der
esermglicht Browseranfragen zu bedienen. Es ist somit nicht ntig,
einen eigenen Webser-ver zu installieren und zu konfigurieren.
Verbindet sich ein Benutzer sich mit dem Kom-ponentenkatalog, so
synchronisiert sich dieser mit der Datenbank und sendet
anschlie-end die neusten Daten an den Benutzer zurck (Abbildung
4.2). Aus dieser Abbildungwird auerdem ersichtlich, dass die
Testergebnisdaten und die Videodaten von zwei un-terschiedlichen
Servern abgerufen werden. Diese dezentrale Anordnunge bietet den
Vor-teil, dass der Videoserver leicht ausgetauscht werden kann. Es
ist zum Beispiel vorstell-bar, dass die Videos nicht mehr auf einem
eigenen Server gespeichert, sondern an einenInternetdienst wie
Vimeo oder Youtube ausgelagert werden. Analyse- und
Videoserverknnen jedoch auch auf dem gleichen Computer betrieben
werden. Es ist auch denkbarkeinen Videoserver zur Verfgung zu
stellen. In diesem Fall funktioniert der Komponen-tenkatalog
ordnungsgem, lediglich Videos knnen nicht mehr abgespielt
werden.Der Webserver muss einmalig konfiguriert und gestartet
werden. Hierbei mssen die
Adresse des Datenbank und des Videoservers eingestellt werden.
Anschlieend ist derServer betriebsbereit. Dabei verrichtet er
selbststndig seinen Dienst und aktualisiertsich in regelmigen
Abstnden mit den neusten Daten der Datenbank. Wenn sich derBenutzer
mit dem Komponentenkatalog verbindet, prsentiert sich ihm das
Interfaceaus Abbildung 4.3. Im oberen Bereich sind die fr
Komponenten- und Applikationsent-wickler gleichermaen interessanten
Sortier- und Auswahlmglichkeiten angezeigt. DieTabelle (vergrert
dargestellt in Abbildung 4.4) listet alle verfgbaren Tests auf.
Diesewerden jeweils nach Roboter, Szenario und Komponente
gruppiert. Diese Gruppe wirdnachfolgend als Testgruppe oder
Testreihe bezeichnet. Aus Platzgrnden befinden sichim Tabellenkopf
fr viele Felder Abkrzungen. Die entsprechenden Bedeutung der
ein-zelnen Felder sind in Tabelle 4.2 aufgefhrt. Dem Anwender
werden diese Erklrungenprsentiert, sobald er mit der Maus ber ein
entsprechendes Feld fhrt. Durch einenKlick auf den Spaltenkopf kann
der Katalog nach jener Spalte sortiert werden. Wennder Anwender die
SHIFT -Taste gedrckt hlt, ist es auch mglich den Katalog
nachmehreren Spalten zu sortieren.Fr groe Kataloge gibt es
zustzlich noch weitere Filtermglichkeiten, um die Liste
20
-
Abkrzung Erklrung
# Anzahl der Tests.
#ERR Gesamte Anzahl aller fehlgeschlagenen Tests.
#ABRTD Anzahl der Tests, die fehlgeschlagenen sind, weil die
Navigations-komponente abgebrochen hat. Dies ist zum Beispiel der
Fall wenndas Ziel unerreichbar ist.
#FLD Anzahl der Tests, die fehlgeschlagen sind, weil die
Navigationskom-ponente einen undefinierten Ergebnisstatus
zurckgegeben hat. Indiesem Fall ist nicht klar, was genau
vorgefallen ist und der Testwird abgebrochen. Dies deutet auf eine
unsaubere Programmierungder Komponente hin.
#MISS Anzahl der Tests, die fehlgeschlagen sind, da die
Komponente zwareinen positiven Ergebnisstatus zurckgeliefert hat,
die Roboterposi-tion jedoch nicht mit der gewnschten Zielposition
bereinstimmt.
#TO Anzahl der Tests, die aufgrund eines Timeouts fehlgeschlagen
sind.
#Col Durchschnittliche Anzahl an Kollisionen summiert ber alle
Tests.
Roboter Die verwendete Roboterbezeichnung.
Navigation Die verwendete Bezeichnung fr die Navigation.
Scenario Die verwendete Bezeichnung fr das Szenario
Duration Durchschnittliche Anzahl der bentigten Dauer in
Sekunden um dasSzenario zu absolvieren.
Distance Durchschnittlich zurckgelegte Distanz. Angabe in
Metern.
Rotation Durchschnittliche Rotation des Roboters whrend des
Testdurch-laufs. Angabe in Grad.
Tabelle 4.2: Metriken fr die Klasse der Navigationstests
21
-
Abbildung 4.3: Interface des Komponentenkatalogs
der Testserien weiter einzugrenzen. Dazu stehen dem Anwender im
Komponentenkatalogin der oberen linken Hlfte des
Komponentenkatalogs mehrere Filtermglichkeiten zurVerfgung. Mit den
beiden Feldern From und To aus Abbildung 4.3 ist es mglicheinen
Start- und Endzeitpunkt festzulegen. Sobald dieser Suchzeitraum
anpasst wirdaktualisiert sich die Tabelle mit den Testdaten
interaktiv. Testreihen, die keinen denKriterien entsprechenden Test
beinhalten werden ausgeblendet. Bei allen anderen werdendie Daten
entsprechend der noch zutreffenden Test aktualisiert. Dies
bedeutet, dasssich die angezeigte durchschnittliche Testzeit auf
die tatschlich verbleibenden Testsbezieht und nicht auf die
Gesamtheit aller Tests in der Serie. Selbiges gilt analog fr
dieanderen Felder. Mit Hilfe des dritten Testfelds Last n kann der
Komponentenkatalog soeingschrnkt werden, dass von der Gesamtheit
aller Tests jene Tests ausgewhlt werden,die zu den letzten n (im
Testfeld eingegebener Wert) durchgefhrten Tests gehren.Dies ist
eine ntzliche Suchmglichkeit, wenn der betreffende Test zeitnah
durchgefhrtwurde, der Anwender ihn jedoch nicht nher eingrenzen
kann.Unterhalb dieser drei Textfelder hat der Entwickler schlielich
die Mglichkeit die Tes-
tergebnisse mit Hilfe einer Textsuche zu filtern (vergrert
dargestellt in Abbildung 4.5).Standardmig werden hierbei die Felder
Roboter, Navigation und Szenario durchsucht.Alle Testserien, die
den entsprechenden Suchtext nicht beinhalten, werden
ausgeblendet.Bei Drcken der Enter-Taste erscheint ein zweites
Textfeld, welches ber eine UND-Beziehung mit ersterem verknpft ist.
Per Klick auf das linke Icon neben dem Textfeld
22
-
Abbildung 4.4: Tabelle des Komponentenkatalogs beinhaltet alle
gespeicherten Daten
Abbildung 4.5: Textfelder zum Filtern der Testdaten. Links ist
der Standardzustand dar-gestellt. Beim Klick auf das linke
Listen-Icon werden zustzliche Optio-nen sichtbar. Dieser erweiterte
Dialog ist auf der rechten Seite abgebildet
lassen sich die Sucheinstellungen bei Bedarf weiter verfeinern.
So ist es mglich, nurinnerhalb eines der Felder Roboter, Navigation
oder Szenario zu suchen. ber excludeanstatt include kann festgelegt
werden, dass nur solche Testserien angezeigt werden,welche den
entsprechenden Suchtext nicht beinhalten. ber einen Klick auf das
||-Iconanstatt Drcken der Enter-Taste bzw Klicken auf das
&&-Icon, lassen sich mehrereTextzeilen ber eine
Oder-Beziehung verknpfen.Eine weitere Funktion, die sowohl
Komponenten- als auch Applikationsentwicklern zur
Verfgung steht ist das Abspielen des aufgenommenen Videos. Dazu
klickt der Entwick-ler auf das Lupen-Icon, das am linken Rand jeder
Testgruppe in der Tabelle angezeigtwird (Abbildung 4.4). Durch
Bettigung dieses Icons werden die Testreihen ausgeblendetund durch
eine Tabelle ersetzt, welche die einzelnen Testdurchlufe innerhalb
der Grup-pe auflistet. Auch diese Tabelle lsst sich wieder durch
Klicken der einzelnen Spaltensortieren. Die Abkrzungen im
Tabellenkopf sind analog zu vorheriger Tabelle gewhlt.Zustzlich
gibt es zwei neue Felder Error Code und Video. Ersteres zeigt eine
dem Fehlerentsprechende Bezeichnung an. Im Falle eines fehlerfreien
Tests ist dieses Feld leer. Letz-teres Feld beinhaltet einen Link
um das Video abzuspielen - sofern vorhanden. Kann frden jeweiligen
Test kein Video gefunden werden, so wird anstelle eines Hyperlinks
derausgegraute Text No video available angezeigt. Fr den Fall, dass
gar kein Videoser-ver gestartet wurde, oder die Verbindung zu
diesem von dem Webserver nicht hergestelltwerden konnte, wird bei
allen Videos der Text Could not connect to server angezeigt.Wenn
ein Video verfgbar ist, und der Hyperlink angeklickt wird, so ffnet
sich ein Po-pup, welches das Video automatisch abspielt. Ein
Screenshot ist in Abbildung 4.6 zusehen.
23
-
Abbildung 4.6: Ein Testvideo wird ber den Browser absgepielt
Werkzeuge fr den Komponentenentwickler
Um ein ntzliches Werkzeug fr den Komponentenentwickler zu sein
und ihn in seinertglichen Arbeit untersttzten zu knnen, muss die
Software auf seine eigenen Anspr-che eingegangen werden. In Kapitel
4.1 wurde die geforderte Funktionalitt aufgezeigt,die fr die Gruppe
der Komponentenentwickler von groer Bedeutung ist. Whrend vie-le
dieser Punkte bereits in Kapitel 4.4.2 behandelt wurden, fehlt noch
die Mglichkeitzur Langzeitanalyse der Daten. Um in die fr einen
Komponentenentwickler ausgelegteAnsicht zu gelangen, muss der
Benutzer in dem Komponentekatalog im unteren Bereichden Reiter
Component Developer auswhlen. Wenn der Entwickler nun eine
Testserieaus der oberen Tabelle auswhlt, so werden ihm im unteren
Bereich Liniendiagrammezu den Metriken Distanz, Rotation und
Zeitdauer prsentiert (Abbildung 4.7). Auf derY-Achse ist dabei die
jeweilige Einheit: Meter, Grad und Sekunden aufgetragen. Aufder
X-Achse wird die jeweilige Testnummer abgebildet. Fhrt der
Entwickler ber einenPunkt in dem Liniendiagramm, stehen ihm
zustzliche Informationen wie das Datumzur Verfgung (Abbildung 4.7).
Fehlgeschlagene Tests werden innerhalb des Diagrammsanstelle eines
blauen Punkts durch ein rotes Quadrat dargestellt. Der angezeigte
Ordina-tenwert entspricht jedoch den tatschlich bis zu dem Fehler
gemessenen Daten. Im Falleeines Timeouts wird zum Beispiel die dem
Timeout entsprechende Zeitdauer verwendet.Im unteren Bereich der
Komponentenentwickleransicht besteht eine weitere Sortier-
mglichkeit fr die dargestellten Diagramme. ber die Optionen Sort
by duration, Sortby distance und Sort by rotation ist es mglich die
Diagramme bezglich dieser dreiMetriken zu sortieren. Dabei werden
die Datenpunkte von klein nach gro sortiert, sodass sich fr diese
Metrik eine monton steigende Kurve einstellt. Da sich dadurch
dieReihenfolge der Tests ndert, werden die jeweils anderen
Diagramme ebenfalls entspre-chend sortiert. Abbildung 4.8 zeigt
diesen Vorgang exemplarisch fr die Option Sort byduration auf. ber
die Checkbox Show errors, die sich rechts der
Sortiermglichkeiten
24
-
befindet, lsst sich einstellen, ob fehlerhafte Tests in den
Diagrammen angezeigt oderausgeblendet werden sollen.
Abbildung 4.7: Diagramme fr den Komponentenentwickler. V.l.n.r.:
Bentigte Zeitdau-er in Sekunden, Fahrtweg in Metern, Rotation in
Grad
Abbildung 4.8: Bei Selektierung der Option Sort by duration wird
der Graph mit der be-ntigten Zeit monton aufsteigend sortiert. Die
jeweiligen anderen Chartswerden entsprechend umsortiert.
25
-
Werkzeuge fr den Applikationsentwickler
Die Ansicht des Applikationsentwicklers ist bei Aufruf des
Komponentenkatalogs stan-dardmig ausgewhlt. Ansonsten kann er diese
ber den Tab Application Developeraktivieren. Nachdem bereits eine
Vielzahl der Anforderungen des Applikationsentwick-lers errtert und
in Hinblick auf den Komponentenkatalog behandelt wurden
verbleibtals vorrangiges Interesse des Applikationsentwicklers der
Vergleich verschiedener Testse-rien. Im Falle eines
Navigationstests ist es sinnvoll jeweils unterschiedliche Roboter
beigleichbleibender Navigationskomponente und Umgebung, sowie
verschiedene Navigati-onskomponente bei gleichbleibendem Roboter
und Umgebung zu vergleichen. Die Ge-genberstellung von
unterschiedlichen Umgebungen liefert keinen Mehrwert, da
hierbeikeine aussagekrftigen Rckschlsse getroffen werden knnen.
Werden beispielsweise einesehr komplexe und eine sehr einfache
Umgebung miteinander verglichen, so ist es wenigverwunderlich, dass
Unterschiede in der bentigten Zeitdauer ermittelt werden. Um
zweiverschiedene Testserien miteinander zu vergleichen, whlt der
Entwickler die relevantenSerien aus. Selektiert er dabei Serien,
die sich in der Umgebung unterscheiden, so wirdihm eine
Fehlermeldung angezeigt. Selbiges passiert wenn Testserien
ausgewhlt werden,die sich sowohl in der Navigationskomponente, als
auch im Roboter unterscheiden. Whltder Applikationsentwickler
jedoch mehrere Testserien aus, die sich lediglich im Roboteroder in
der Navigationskomponente unterscheiden, so erhlt er drei
vergleichende Bal-kendiagramme, die die Metriken Distanz, Rotation
und Dauer gegenberstellen. Dies istin Abbildung 4.9 dargestellt.
Der weie Streifen in der Mitte der groen Balken stelltdabei den
Mittelwert dar. Der Balken selbst gibt die Standardabweichung in
positiverund negativer Richtung an. Je kleiner der Balken, desto
geringer ist die Streuung umden Mittelwert. Dies bedeutet, dass die
Komponente ein sehr zuverlssiges Verhaltenaufweist.
Abbildung 4.9: Analysediagramme fr den Applikationsentwickler:
Verschiedene Robo-ter werden auf der selben Route mit der selben
Navigationskomponen-te eingesetzt. Anschlieend wird die bentitgte
Zeit, der zurckgelegteFahrweg und die Rotationen gegenber gestellt.
Der weie Balken sym-bolisiert den Mittelwert, die Gre des Balkens
visualisiert die Standard-abweichung in positiver und negativer
Richtung.
26
-
4.5 Aufbau von Testpaketen und Integration in einen CI-ServerUm
das Testframework in einen CI-Server zu integrieren, sind
verschiedene Skripte ver-fgbar, die speziell auf den CI-Server
abgestimmt und insbesondere auf die Zusammen-arbeit mit dem
Pipeline-Tool [24] des Fraunhofer IPA optimiert sind. Durch diese
Kom-bination ist es mglich, das zu testende Projekt bequem ber die
Jenkins-Oberflche zukonfigurieren. So gibt es durch den
Pipeline-Konfigurator die Mglichkeit mit Hilfe soge-nannter
Matrixjobs das Projekt auf verschiedenen Betriebssystemen und
verschiedenenROS-Versionen zu testen. Auch das direkte Bauen und
Testen der Software auf einemRoboter wird untersttzt. Durch die
Funktion des Testframeworks, die resultierendenBagfiles auf einen
Server zu exportieren wird das Bagfile zur spteren Analyse auf
einemzentralen Computer gesichert. Um das Testen einer bestimmten
Navigationskomponenteber Jenkins zu ermglichen, muss der Entwickler
zunchst ein Metatestpaket erstellen.Hierin startet er wie gewohnt
die Simulation und inkludiert das Testframework. Er spezi-fiziert
ber einen Parameter des Testframeworks die gewnschte Route und
konfiguriertweitere notwendige Parameter wie Name des Roboters,
Name der Umgebung etc. (einedetailierte bersicht der mglichen
Konfigurationsoptionen ist in dem Kapitel 5.2 auf-gelistet). Der
Entwickler ldt dieses Metapaket anschlieend ber das
SCM-Werkzeugseiner Wahl auf einen Server hoch. Dem Jenkins-Server
bergibt er daraufhin die Adressedieses Pakets und konfiguriert ber
dessen Oberflche weitere Optionen wie das zu tes-tende
Betriebssystem, die verwendete ROS-Version und die bentigten
Abhngigkeiten.Nach diesem Schritt ist der automatisierte Test
konfiguriert und wird bei jeder Code-nderung der
Navigationskomponente automatisch ausgefhrt. ber den
Analyseserverwerden alle Bagfiles sukzessiv ausgewertet, so dass
ohne weiteren Aufwand von Seitendes Entwicklers der
Komponentenkatalog kontinuierlich gepflegt wird.
27
-
5 ImplementierungDie Implementierung nahezu aller Komponenten
basiert auf ROS und ermglicht so eineleichte Integration in
bestehende ROS-Projekte. Hierbei wurde die Python-Bibliothekvon ROS
verwendet. Der berwiegende Teil des ROS-Codes wurde fr das
Testframe-work entwickelt, whrend der Komponentenkatalog zu groen
Teilen auf Javascript ba-siert. Um Code-Duplizierung zu vermeiden,
wurden alle Klassen und Module, die vonmehr als einem Paket genutzt
werden in einem zentralen Helferpaket gebndelt. Die-ses Paket trgt
den Namen navigation_test_helper. Der wichtigste Bestandteil
diesesPakets sind die ROS-Nachrichtentypen fr das Status- und
Kollisionstopic, welche so-wohl vom Synthese- als auch vom
Analysepaket bentigt werden. Darber hinaus istinsbesondere das
Kollisionstopic auch fr externe Entwickler interessant. Das
naviga-tion_test_helper-Paket beinhaltet auerdem verschiedene
Klassen, beispielsweise umGIT-Repositories komfortabel zu
kontrollieren, oder den Roboter zu navigieren. Wannimmer es ntig
ist roboterspezifischen Code zu entwickeln, wurde dieser in eigenen
Pa-keten gekapselt. Somit wird die Codebasis generisch gehalten und
kann auch fr andereRoboter verwendet werden. Ein Beispiel fr ein
roboterspezifisches Modul ist das
Paketcob_navigation_test_prepare_robot. Dieses ist verantwortlich
fr die ordnungsgemeTestvorbereitung des Care-O-bots.
5.1 Implementierung des TestframeworksDas Testframework gliedert
sich in mehrere Pakete auf. Dazu zhlen unter anderemdie Hauptmodule
navigation_test_skeleton und navigation_test_analysis, die fr
dieSynthese und Analyse von Bagfiles verantwortlich sind.
5.2 Aufbau des SyntheseschrittsAbbildung 5.1 zeigt ein
schematisches Interaktionsdiagramm der relevanten ROS-Kommunikation
whrend eines Syntheseschritts. Dabei bernimmt das sogenannte Pa-ket
navigation_test_skeleton die wichtigste Rolle: Es beinhaltet den
Basistest sowie denBagrecorder. Diese beiden Nodes sind die
zentralen Kommunikationsknoten. Fr denBagrecorder wurde auf eine
adaptierte Implementierung zurckgegriffen, die im Rah-men eines
anderen Projektes am IPA-Fraunhofer entwickelt wurde. Generell gibt
es keineUnterschiede ob der ROS-Code auf einem echten Roboter oder
in einer Simulation ver-wendet wird. Lediglich zu Beginn des
Testablaufs unterscheiden sich die beiden Flle inder
Vorbereitungsphase: Whrend fr die Simulation die Gazbo-Umgebung
initialisiertwird, muss fr den echten Roboter eine quivalente
Treiberschicht gestartet werden.
28
-
Abbildung 5.1: Schematische Darstellung der Kommunikation aller
ROS-Komponentenwhrend des Syntheseschritts
29
-
Dieser Prozess ist jedoch unabhngig von dem Testframework.
Nachdem der Robotererfolgreich eingerichtet wurde, wird das
Testframework geladen, initialisiert und konfi-guriert. Als
Resultat dieses Prozesses erhlt man ein generiertes Bagfile, das
alle ntigenInformationen fr den Analyse-Schritt enthlt.
5.2.1 TestvorbereitungDer gesamte Kommunikationsfluss innerhalb
eines Syntheseschritts verluft nach fol-gendem Schema: Das von
einem Entwickler erstellte Meta-Testpaket startet zuerst
dieGazebo-Simulationsumgebung und fhrt ein Paket aus, das alle
weiteren Basiskompo-nenten wie Laserscanner, Videokameras und
sonstige low-level Bestandteile des Robotersinitialisiert. Dieses
Metapaket zur Initialisierung des Roboters wird blicherweise
bringupbezeichnet. Es ist auf einen speziellen Roboter
zugeschnitten und kann nicht generischimplementiert werden. Danach
knnen weitere high-level Komponenten des Robotersgestartet werden.
Dazu zhlen zum Beispiel Objekterkennung oder Navigation. Da
sichdiese Arbeit auf Navigationstests beschrnkt, ist in Abbildung
5.1 lediglich die Navigati-onskomponente als tauschbare Komponente
gekennzeichnet. Sie wird abhngig von demzu testenden Szenario
ausgewhlt. Bis zu diesem Punkt wurden ausschlieilch
Paketegestartet, wie sie, unabhngig davon ob es sich um einen
Navigationstest handelt, auchin einem normalen Simulationsdurchlauf
verwendet werden. Listing 5.1 skizziert beispiel-haft ein
Launchfile, wie es hnlich fr den Care-O-bot verwendet wird um die
Simulationmit dem Roboter und der Navigationskomponente zu starten.
Soll der Roboter anstelleder Simulation in einer realen Umgebung
verwendet werden, so muss lediglich das Paketvon cob_brinup_sim
durch cob_bringup ausgetauscht werden.
Listing 5.1: Beispielhaftes Initialisierungslaunchfile um einen
Roboter in der Simulationzu starten
An dieser Stelle sei darauf hingewiesen, dass die
Startreihenfolge aufgrund der asyn-chronen Arbeitsweise von ROS
irrelevant ist. Die gewhlte Anordnung wurde lediglichaus
anschaulichen Grnden ausgesucht.
5.2.2 Einbindung des BasistestsNachdem in Listing 5.1 das
Launchfiles des Testspakets schon so weit entworfen wur-de, dass
damit der Roboter und die Navigationskomponente sowohl in der
Simulation,
30
-
als auch in der Realitt gestartet werden kann, besteht der
nchste Schritt darin, denTestvorgang vorzubereiten und den
Basistest zu starten.Um den Roboter auf den Test vorzubereiten wird
ein roboterspezifischer Initiali-
sierungsnode gestartet. Dieses Initialisierungspaket ist nicht
Teil des Testframeworks,da es nicht generisch gestaltet werden
kann, sondern auf den jeweiligen Roboter zu-geschnitten sein muss.
In Abbildung 5.1 trgt der Initialisierungsnode den
Namencob_navigation_prepare_robot. Dieser Node stellt einen
Initialisierungsservice zur Verf-gung, der in Abbildung 5.1 den
Namen prepare_robot trgt. Die Bezeichnung des
Initia-lisierungsservices kann willkrlich gewhlt werden, sie muss
lediglich als Parameter demNavigations-Basistest bergeben werden.
Auf die verschiedenen Konfigurationsmglich-keiten wird in Kapitel
5.2.4 eingegangen. Welche Aktionen bei dem Aufruf des
Servicesprepare_robot ausgefhrt werden, ist beliebig und hngt von
dem jeweilige Roboter ab.Im Falle des Care-O-bots wird sein
Greiferarm in eine angewinkelte Position eingefahrenund sein
Tablett gesenkt.Als nchster Schritt wird die Kollisionserkennung
gestartet. Sofern die Gazebo-
Simulationsumgebung in Zusammenspiel mit Bumper benutzt wird,
kann das Paketnavigation_test_collisions_detection verwendet
werden. Wie in Abbildung 5.1 verdeut-licht, wirkt dieses Paket als
Vermittlungsschicht zwischen dem Bumper-Topic und demfr das
Navigationsframework verstndliche Collisions_Topic. Auch dieser
Name desKollisionstopics kann ber einen Parameter beliebig
konfiguriert werden. Als Nachrich-tentyp dient hierbei die
Collisions-Nachricht aus dem navigation_test_helper-Paket.Unter
Verwendung dieser Nachricht kann wie in Kapitel 4.3.1 angesprochen
auch eineeigene Kollisions-Mittelschicht entwickelt werden. In
Abbildung 5.1 ist dies durch dasBild eines Menschen symbolisiert.
Abschlieend werden die Kernpakete des Testframe-works, namentlich
der Basistest und der Bagrecorder, gestartet. Diese beiden Pakete
sindin einem Meta-Launchfile navigation.test in dem Paket
navigation_test_skeleton zusam-mengefasst. Damit ist ein Testpaket
erfolgreich erstellt. Listing 5.2 zeigt den zweiten Teildes
Testmetapakets.
1 2
3 4 5
6 7 8 9
10 11 12
13 14 15
31
-
16 17
18 19 20 21 22 23 24
Listing 5.2: Zweiter Teil des Meta-Testpakets startet den
Initialisierungsnode, dieKollisionsdetektion, sowie den Basistest
und den Bagrecorder
5.2.3 Implementierung des TestablaufsWie in der schematischen
Darstellung 5.1 veranschaulicht, bilden die beiden Nodes
desBasistests und des Bagrecorders das Bindeglied zwischen allen
relevanten Topics undServices. Nachdem der Basistest gestartet
wurde, wartet dieser zunchst auf den alsParameter bergebenen
Service prepare_robot. Standardmig ist der Parameter nichtgesetzt,
so dass der Roboter als betriebsbereit vorausgesetzt wird. Ist der
Parameterjedoch gesetzt, so blockiert der Test bis dieser Service
verfgbar ist, oder ein Timeout-Fehler auftritt. Nachdem die
ordnungsgeme Initialisierung ber einen Statuscode in
derServiceantwort sichergestellt ist, wird ber die move_base-Action
das erste Zwischenzielder Route vorgegeben. Der Name der Action
kann als Parameter spezifiziert werden.Standardmig wird /move_base
verwendet. Sobald der Roboter in Bewegung ist, wirdseine Position
kontinuierlich mit Hilfe der Transformationsnachricht (/tf )
berwacht.Falls die Navigationskomponente die Planung abbricht oder
ihr Ziel verfehlt, wird einFehler erzeugt und der Test abgebrochen.
Wurde ein Zwischenziel jeodch erfolgreichangefahren wird der
Navigationskomponente der nchste Wegpunkt als Ziel
vorgegeben.Parallel wird zu diskreten Zeitpunkten eine
Statusnachricht gesendet. Diese dient so-
wohl zur spteren Analyse der bentigten Zeit, als auch zum
Austausch von Metain-formationen zwischen Test und Analyse. Dieses
Topic ist in Abbildung 5.1 beispielhaftals /test27/status
bezeichnet. Der Namespace /test27 soll hierbei verdeutlichen,
dassder Test in einem beliebigen Namespace gestartet werden kann.
Somit mssen keineglobalen Parameter gesetzt und mgliche
Namenskonflikte knnen verhindert werden.Ermglicht wird dies ber
eine gemeinsame group in dem Testlaunchfile (Listing 5.2,Zeile 6).
Im Namespace dieser group wird typischerweise auch die
Kollisionserkennungund die Roboterinitialisierung gestartet und die
Testkonfiguration geladen. Somit stehenalle Parameter anschlieend
auf dem Parameter-Server im selben Namespace zur Verf-gung und
smtliche ROS-Nodes der group haben Zugriff darauf. Dies birgt den
Vorteil,dass smtliche Testparameter in einer zentralen
Parameterdatei abgelegt werden kn-nen. Diese Parameterdatei ist in
dem unter ROS weit verbreiteten YAML Aint MarkupLanguage
(YAML)-Format gespeichert. Kapitel 5.2.4 gibt eine bersicht der
mglichenKonfigurationsptionen.
32
-
Aus der schematischen Darstellung der ROS-Kommunikation in
Abbildung 5.1 gehtdeutlich die Aufgabenteilung der beiden Pakete
Basistest und Bagfilerecorder hervor.Bereits aus der Abbildung ist
sichtbar, dass vom Basistest mehrheitlich Kommunikati-on nach auen
stattfindet, whrend der Bagfilerecorder ausschlielich Daten
empfngt.So kmmert sich der Basistest um alle logischen
Programmablufe. Er stellt eine ord-nungsgeme Initialisierung
sicher, sendet Navigationskommandos und berwacht diekorrekte
Ausfhrung dieser Befehle. Die fr die Vorgabe verschiedener
Navigationszieleverwendete actionlib-Bibliothek ist in der Lage
zwischen den Zustnden Rejected, Re-called, Preemtepd, Succeeded,
Aborted zu unterscheiden [25]. In einem dieser Zustndebefindet sich
die Navigationskomponente nach jedem angesteuerten Zielpunkt. Der
Testwird mit einem Fehler beendet, sobald sich die Komponente in
einem andere Zustand alsSucceeded befindet. Explizit wird dabei der
Zustand Aborted bercksichtigt. Wann immerdieser Zustand auftritt,
ist der Fehler anschlieend im Komponentenkatalog einsichtbar.Alle
anderen Statusflle werden unter einem gemeinsamen Fehlercode
zusammengefasst.Weitere Fehlerquellen die im Verlaufe eines Tests
auftreten knnen sind die berschrei-tung der Maximaldauer, sowie ein
fehlerhaftes Navigieren trotz des Zustands Succeeded.Im Gegensatz
zum Basistest, der grtenteils Befehle delegiert, sammelt der
Bagrecor