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

Embed Size (px)

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 gesen

Recommended

View more >