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