Enwurf und Implementierung eines Komponentenkatalogs für automatisierte Tests

Download Enwurf und Implementierung eines Komponentenkatalogs für automatisierte Tests

Post on 22-Nov-2015

36 views

Category:

Documents

5 download

DESCRIPTION

Bachelor thesis to the topic of creating a component catalogue to better compare various ROS-components from the perspective of a component / application developer.

TRANSCRIPT

  • 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...

Recommended

View more >