Bachelorarbeit im Fachbereich Elektrotechnik & Informatik...

71
Florian Burka Kameragest¨ utzte Objektverfolgung in Echtzeit im Kontext mobiler Roboter Bachelorarbeit

Transcript of Bachelorarbeit im Fachbereich Elektrotechnik & Informatik...

Page 1: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Florian Burka

Kameragestutzte Objektverfolgung in Echtzeitim Kontext mobiler Roboter

Bachelorarbeit

Bachelorarbeit eingereicht im Rahmen der Bachelorprufungim Studiengang Angewandte Informatikam Studiendepartment Informatikder Fakultat Technik und Informatikder Hochschule fur Angewandte Wissenschaften Hamburg

Betreuender Prufer Prof Dr rer nat Gunter KlemkeZweitgutachter Prof Dr rer nat Kai von Luck

Abgegeben am 21 Marz 2007

Florian Burka

Kameragestutzte Objektverfolgung in Echtzeit imKontext mobiler Roboter

Florian Burka

Thema der BachelorarbeitKameragestutzte Objektverfolgung in Echtzeit im Kontext mobiler Roboter

StichworteMobile Roboter Autonome Roboter Echtzeit-Bildverarbeitung RoboCup Farbsegmentie-rung IEEE 802154

KurzzusammenfassungIn dieser Arbeit wurde ein System geschaffen mit dem man farblich markierte Objekte inEchtzeit - mit einer Kamera - verfolgen kannUm dies zu erreichen analysiert ein Kameraserver auf einem leistungsstarken Computer dieBilder einer Kamera sucht die richtigen Farbobjekte bestimmt Position und Winkel dieserObjekte und sendet diese Informationen an autonome Roboter Hierzu werden verschiedeneMethoden gezeigt Farben Farbklassen zuzuordnen und Objekte zu erkennen Des Weite-ren wird eine Architektur eines Systems zur Objekterkennung sowie dessen Realisierungerlautert

Florian Burka

Title of the paperRealtime object tracking of mobile robots

Keywordsautonomous robots mobile robots real-time image processing RoboCup color-segmentation IEEE 802154

AbstractThis work deals with a real-time object tracker The object tracker was used to trackmobile robots playing soccer to inform them about their heading and positionTherefor a camera server was deployed on a high-performance desktop class computer Thesystem has a camera that observes the playground The images captured by the cameraare then segmented into color classes which are used to identify the robots and the ballThe algorithms to segment an image into color classes and to locate objects are describedAn architecture for an object tracker is shown as well as its implementation

Danksagung

Hiermit mochte ich mich bei meinem Betreuer Prof Dr Gunter Klemke fur die vieleZeit und die wertvollen Inspirationen bedanken Von dieser guten Zusammenarbeit hat dieBachelorarbeit sehr profitiert

Danken mochte ich auch meinen Lektoren welche mir dort weiterhalfen wo mir alles zuselbstverstandlich war

Und danken mochte ich auch meiner Freundin und meiner Familie fur die viele Geduld undUnterstutzung

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einfuhrung 111 Motivation 212 Zielsetzung 313 Gliederung 3

2 Analyse 521 Anforderungen 522 Farbmodelle 7

221 RGB 8222 CMYK 9223 HSV 10224 YUV 13

23 Rahmenbedingungen 14231 Spielfeld 15232 Kamera 15233 Roboter 18234 Funk 18235 Computer 20

24 Algorithmen 20241 Farbsegmentierung 21242 Objekterkennung 23243 Nebenlaufigkeit 24

25 Verwandte Arbeiten 24

3 Design 2931 Systemarchitektur 2932 Programmablauf 3033 Farbkonfiguration 3134 Klassendiagramme 31

341 Ubersicht 32342 Bildquelle 33

Inhaltsverzeichnis vi

343 Farbsegmentierung 34344 Objekterkennung 34345 Ausgabefilter 35346 Ergebnisausgabe 35347 Bild 37348 Ringpuffer 37

35 Farbmodell 38

4 Realisierung 3941 Programmiersprache 3942 Entwicklungsumgebung 4043 Bibliotheken 40

431 Libdc1394 41432 CMVision 41433 GEOS 42434 CPPUnit 42435 ConfigFile 42436 CImg 43

44 Nebenlaufigkeit 4345 Komponenten 44

451 Farbsegmentierung 44452 Objekterkennung 44453 Ausgabefilter 48454 Objekt-Wiederverwendung 50455 Bild 50

46 Optimierung 50461 Profiling 50462 Speicherlecks 52

5 Fazit 5451 Ergebnisse 5452 Problemlosungen 5753 Ausblick 5854 Resumee 59

Literaturverzeichnis 60

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 2: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Bachelorarbeit eingereicht im Rahmen der Bachelorprufungim Studiengang Angewandte Informatikam Studiendepartment Informatikder Fakultat Technik und Informatikder Hochschule fur Angewandte Wissenschaften Hamburg

Betreuender Prufer Prof Dr rer nat Gunter KlemkeZweitgutachter Prof Dr rer nat Kai von Luck

Abgegeben am 21 Marz 2007

Florian Burka

Kameragestutzte Objektverfolgung in Echtzeit imKontext mobiler Roboter

Florian Burka

Thema der BachelorarbeitKameragestutzte Objektverfolgung in Echtzeit im Kontext mobiler Roboter

StichworteMobile Roboter Autonome Roboter Echtzeit-Bildverarbeitung RoboCup Farbsegmentie-rung IEEE 802154

KurzzusammenfassungIn dieser Arbeit wurde ein System geschaffen mit dem man farblich markierte Objekte inEchtzeit - mit einer Kamera - verfolgen kannUm dies zu erreichen analysiert ein Kameraserver auf einem leistungsstarken Computer dieBilder einer Kamera sucht die richtigen Farbobjekte bestimmt Position und Winkel dieserObjekte und sendet diese Informationen an autonome Roboter Hierzu werden verschiedeneMethoden gezeigt Farben Farbklassen zuzuordnen und Objekte zu erkennen Des Weite-ren wird eine Architektur eines Systems zur Objekterkennung sowie dessen Realisierungerlautert

Florian Burka

Title of the paperRealtime object tracking of mobile robots

Keywordsautonomous robots mobile robots real-time image processing RoboCup color-segmentation IEEE 802154

AbstractThis work deals with a real-time object tracker The object tracker was used to trackmobile robots playing soccer to inform them about their heading and positionTherefor a camera server was deployed on a high-performance desktop class computer Thesystem has a camera that observes the playground The images captured by the cameraare then segmented into color classes which are used to identify the robots and the ballThe algorithms to segment an image into color classes and to locate objects are describedAn architecture for an object tracker is shown as well as its implementation

Danksagung

Hiermit mochte ich mich bei meinem Betreuer Prof Dr Gunter Klemke fur die vieleZeit und die wertvollen Inspirationen bedanken Von dieser guten Zusammenarbeit hat dieBachelorarbeit sehr profitiert

Danken mochte ich auch meinen Lektoren welche mir dort weiterhalfen wo mir alles zuselbstverstandlich war

Und danken mochte ich auch meiner Freundin und meiner Familie fur die viele Geduld undUnterstutzung

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einfuhrung 111 Motivation 212 Zielsetzung 313 Gliederung 3

2 Analyse 521 Anforderungen 522 Farbmodelle 7

221 RGB 8222 CMYK 9223 HSV 10224 YUV 13

23 Rahmenbedingungen 14231 Spielfeld 15232 Kamera 15233 Roboter 18234 Funk 18235 Computer 20

24 Algorithmen 20241 Farbsegmentierung 21242 Objekterkennung 23243 Nebenlaufigkeit 24

25 Verwandte Arbeiten 24

3 Design 2931 Systemarchitektur 2932 Programmablauf 3033 Farbkonfiguration 3134 Klassendiagramme 31

341 Ubersicht 32342 Bildquelle 33

Inhaltsverzeichnis vi

343 Farbsegmentierung 34344 Objekterkennung 34345 Ausgabefilter 35346 Ergebnisausgabe 35347 Bild 37348 Ringpuffer 37

35 Farbmodell 38

4 Realisierung 3941 Programmiersprache 3942 Entwicklungsumgebung 4043 Bibliotheken 40

431 Libdc1394 41432 CMVision 41433 GEOS 42434 CPPUnit 42435 ConfigFile 42436 CImg 43

44 Nebenlaufigkeit 4345 Komponenten 44

451 Farbsegmentierung 44452 Objekterkennung 44453 Ausgabefilter 48454 Objekt-Wiederverwendung 50455 Bild 50

46 Optimierung 50461 Profiling 50462 Speicherlecks 52

5 Fazit 5451 Ergebnisse 5452 Problemlosungen 5753 Ausblick 5854 Resumee 59

Literaturverzeichnis 60

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 3: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Florian Burka

Thema der BachelorarbeitKameragestutzte Objektverfolgung in Echtzeit im Kontext mobiler Roboter

StichworteMobile Roboter Autonome Roboter Echtzeit-Bildverarbeitung RoboCup Farbsegmentie-rung IEEE 802154

KurzzusammenfassungIn dieser Arbeit wurde ein System geschaffen mit dem man farblich markierte Objekte inEchtzeit - mit einer Kamera - verfolgen kannUm dies zu erreichen analysiert ein Kameraserver auf einem leistungsstarken Computer dieBilder einer Kamera sucht die richtigen Farbobjekte bestimmt Position und Winkel dieserObjekte und sendet diese Informationen an autonome Roboter Hierzu werden verschiedeneMethoden gezeigt Farben Farbklassen zuzuordnen und Objekte zu erkennen Des Weite-ren wird eine Architektur eines Systems zur Objekterkennung sowie dessen Realisierungerlautert

Florian Burka

Title of the paperRealtime object tracking of mobile robots

Keywordsautonomous robots mobile robots real-time image processing RoboCup color-segmentation IEEE 802154

AbstractThis work deals with a real-time object tracker The object tracker was used to trackmobile robots playing soccer to inform them about their heading and positionTherefor a camera server was deployed on a high-performance desktop class computer Thesystem has a camera that observes the playground The images captured by the cameraare then segmented into color classes which are used to identify the robots and the ballThe algorithms to segment an image into color classes and to locate objects are describedAn architecture for an object tracker is shown as well as its implementation

Danksagung

Hiermit mochte ich mich bei meinem Betreuer Prof Dr Gunter Klemke fur die vieleZeit und die wertvollen Inspirationen bedanken Von dieser guten Zusammenarbeit hat dieBachelorarbeit sehr profitiert

Danken mochte ich auch meinen Lektoren welche mir dort weiterhalfen wo mir alles zuselbstverstandlich war

Und danken mochte ich auch meiner Freundin und meiner Familie fur die viele Geduld undUnterstutzung

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einfuhrung 111 Motivation 212 Zielsetzung 313 Gliederung 3

2 Analyse 521 Anforderungen 522 Farbmodelle 7

221 RGB 8222 CMYK 9223 HSV 10224 YUV 13

23 Rahmenbedingungen 14231 Spielfeld 15232 Kamera 15233 Roboter 18234 Funk 18235 Computer 20

24 Algorithmen 20241 Farbsegmentierung 21242 Objekterkennung 23243 Nebenlaufigkeit 24

25 Verwandte Arbeiten 24

3 Design 2931 Systemarchitektur 2932 Programmablauf 3033 Farbkonfiguration 3134 Klassendiagramme 31

341 Ubersicht 32342 Bildquelle 33

Inhaltsverzeichnis vi

343 Farbsegmentierung 34344 Objekterkennung 34345 Ausgabefilter 35346 Ergebnisausgabe 35347 Bild 37348 Ringpuffer 37

35 Farbmodell 38

4 Realisierung 3941 Programmiersprache 3942 Entwicklungsumgebung 4043 Bibliotheken 40

431 Libdc1394 41432 CMVision 41433 GEOS 42434 CPPUnit 42435 ConfigFile 42436 CImg 43

44 Nebenlaufigkeit 4345 Komponenten 44

451 Farbsegmentierung 44452 Objekterkennung 44453 Ausgabefilter 48454 Objekt-Wiederverwendung 50455 Bild 50

46 Optimierung 50461 Profiling 50462 Speicherlecks 52

5 Fazit 5451 Ergebnisse 5452 Problemlosungen 5753 Ausblick 5854 Resumee 59

Literaturverzeichnis 60

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 4: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Danksagung

Hiermit mochte ich mich bei meinem Betreuer Prof Dr Gunter Klemke fur die vieleZeit und die wertvollen Inspirationen bedanken Von dieser guten Zusammenarbeit hat dieBachelorarbeit sehr profitiert

Danken mochte ich auch meinen Lektoren welche mir dort weiterhalfen wo mir alles zuselbstverstandlich war

Und danken mochte ich auch meiner Freundin und meiner Familie fur die viele Geduld undUnterstutzung

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einfuhrung 111 Motivation 212 Zielsetzung 313 Gliederung 3

2 Analyse 521 Anforderungen 522 Farbmodelle 7

221 RGB 8222 CMYK 9223 HSV 10224 YUV 13

23 Rahmenbedingungen 14231 Spielfeld 15232 Kamera 15233 Roboter 18234 Funk 18235 Computer 20

24 Algorithmen 20241 Farbsegmentierung 21242 Objekterkennung 23243 Nebenlaufigkeit 24

25 Verwandte Arbeiten 24

3 Design 2931 Systemarchitektur 2932 Programmablauf 3033 Farbkonfiguration 3134 Klassendiagramme 31

341 Ubersicht 32342 Bildquelle 33

Inhaltsverzeichnis vi

343 Farbsegmentierung 34344 Objekterkennung 34345 Ausgabefilter 35346 Ergebnisausgabe 35347 Bild 37348 Ringpuffer 37

35 Farbmodell 38

4 Realisierung 3941 Programmiersprache 3942 Entwicklungsumgebung 4043 Bibliotheken 40

431 Libdc1394 41432 CMVision 41433 GEOS 42434 CPPUnit 42435 ConfigFile 42436 CImg 43

44 Nebenlaufigkeit 4345 Komponenten 44

451 Farbsegmentierung 44452 Objekterkennung 44453 Ausgabefilter 48454 Objekt-Wiederverwendung 50455 Bild 50

46 Optimierung 50461 Profiling 50462 Speicherlecks 52

5 Fazit 5451 Ergebnisse 5452 Problemlosungen 5753 Ausblick 5854 Resumee 59

Literaturverzeichnis 60

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 5: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einfuhrung 111 Motivation 212 Zielsetzung 313 Gliederung 3

2 Analyse 521 Anforderungen 522 Farbmodelle 7

221 RGB 8222 CMYK 9223 HSV 10224 YUV 13

23 Rahmenbedingungen 14231 Spielfeld 15232 Kamera 15233 Roboter 18234 Funk 18235 Computer 20

24 Algorithmen 20241 Farbsegmentierung 21242 Objekterkennung 23243 Nebenlaufigkeit 24

25 Verwandte Arbeiten 24

3 Design 2931 Systemarchitektur 2932 Programmablauf 3033 Farbkonfiguration 3134 Klassendiagramme 31

341 Ubersicht 32342 Bildquelle 33

Inhaltsverzeichnis vi

343 Farbsegmentierung 34344 Objekterkennung 34345 Ausgabefilter 35346 Ergebnisausgabe 35347 Bild 37348 Ringpuffer 37

35 Farbmodell 38

4 Realisierung 3941 Programmiersprache 3942 Entwicklungsumgebung 4043 Bibliotheken 40

431 Libdc1394 41432 CMVision 41433 GEOS 42434 CPPUnit 42435 ConfigFile 42436 CImg 43

44 Nebenlaufigkeit 4345 Komponenten 44

451 Farbsegmentierung 44452 Objekterkennung 44453 Ausgabefilter 48454 Objekt-Wiederverwendung 50455 Bild 50

46 Optimierung 50461 Profiling 50462 Speicherlecks 52

5 Fazit 5451 Ergebnisse 5452 Problemlosungen 5753 Ausblick 5854 Resumee 59

Literaturverzeichnis 60

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 6: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Inhaltsverzeichnis vi

343 Farbsegmentierung 34344 Objekterkennung 34345 Ausgabefilter 35346 Ergebnisausgabe 35347 Bild 37348 Ringpuffer 37

35 Farbmodell 38

4 Realisierung 3941 Programmiersprache 3942 Entwicklungsumgebung 4043 Bibliotheken 40

431 Libdc1394 41432 CMVision 41433 GEOS 42434 CPPUnit 42435 ConfigFile 42436 CImg 43

44 Nebenlaufigkeit 4345 Komponenten 44

451 Farbsegmentierung 44452 Objekterkennung 44453 Ausgabefilter 48454 Objekt-Wiederverwendung 50455 Bild 50

46 Optimierung 50461 Profiling 50462 Speicherlecks 52

5 Fazit 5451 Ergebnisse 5452 Problemlosungen 5753 Ausblick 5854 Resumee 59

Literaturverzeichnis 60

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 7: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Abbildungsverzeichnis

11 Der Gesamtuberblick uber das System 3

21 Additive Farbmischung der Farben Rot Grun und Blau 822 Subtraktive Farbmischung der Farben Turkis Magenta und Gelb 823 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weiss

und Schwarz 924 Der CMYK-Farbraum 1025 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-

Team 2007)) 1126 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farbton

(Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce 2005) 1327 Das Spielfeld 1528 Das UV-Farbspektrum aus dem YUV-Farbmodell 1629 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spater

auch erkannt werden sollen 16210 Die Sony DFW-V500 Kamera 17211 Das Farbspektrum der Sony DFW-V500 Kamera 17212 Die Imagingsource DFK 21BF04-Z Kamera 17213 Das Farbspektrum der Imagingsource DFK 21BF04-Z Kamera 17214 Der Pioneer Roboter 19215 Ein Lego-Roboter gesteuert durch das Aksen Board 19216 Ein Roboter mit omnidirektionalem Antrieb 19217 Ein Lego-Roboter 19218 Ein CT-Bot 19219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor

(httpvertolmitedu) am MIT 24220 Die Vorgehensweise beim rdquoRoboCuprdquo 25221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006 26

31 Die Systemarchitektur im Uberblick 2932 Der Ablauf des Programms 3033 Anwendungsfalle fur die Farbkonfiguration 3134 Klassendiagramm rdquoUbersichtrdquo 32

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 8: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Abbildungsverzeichnis 0

35 Klassendiagramm rdquoBildquellerdquo 3336 Klassendiagramm rdquoAusgabefilterrdquo 3537 Klassendiagramm rdquoErgebnisausgaberdquo 3638 Klassendiagramm rdquoBildrdquo 3739 Klassendiagramm rdquoRingpufferrdquo 38

41 Videobild nach der Aufnahme 4442 Bild nach der Farbklassifizierung 4443 Ein mit den Farben Grun Rot Pink und Turkis markierter Roboter welcher

im System als rdquogrptrdquo identifiziert wird 4544 Ein mit Gelb markierter Ball 4545 Falschlich erkannte rdquoRoboterrdquo ohne Filterung 4646 Falschlich markierte Farbflachen ohne Filterung 4647 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird 4648 Ein mit den Farben Rot Grun Pink und Turkis markierter Roboter 4849 Das Ergebnisbild zu Abbildung 452 48410 Ein durch die Farbe Gelb markierter Ball 48411 Das Ergebnisbild mit dem Ball zu Abbildung 452 48412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung 51413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierung

fur die Anzeige (Rest) 52

51 CPU-Zeiten bei der Verarbeitung 5552 Anpassung der Farbklassen 5653 Die Farberkennung lasst sich nicht so leicht storen 5654 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm 57

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 9: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

1 Einfuhrung

Roboter sind in ihren Ursprungen als Helfer bei der Arbeit entworfen worden So gibtes im tschechischen das Wort Robot fur den rdquoFrontdienstrdquo und im Russischen das WortrdquoRobotardquo welches fur Arbeit steht Fruher waren Roboter meist einfache Flieszligbandarbeiterheutzutage jedoch nehmen uns Roboter nicht nur die Arbeit ab sondern sind auch inanderen Bereichen aktiv

Kinder lernen viel durch das Spielen warum nicht auch Roboter

Das RoboCup Projekt1 formuliert folgendes ZielBy the year 2050 develop a team of fully autonomous humanoid robots that can winagainst the human world soccer champion teamrdquoRoboter-Fuszligball ist eine Herausforderung fur die Robotik und die kunstliche Intelligenzgleichermaszligenrdquo(Robocup)Beim Roboter-Fuszligball wird das Spielfeld als Versuchslabor benutzt So wird die Arbeit zumSpiel und die Arbeitsroboter zu SpielroboternSpielende Roboter helfen nicht nur der Wissenschaft sie schaffen es auch Faszination furTechnik zu wecken und so neue motivierte Forscher zu rekrutieren

Menschen haben Sinne - Roboter SensorenDie Menschliche Wahrnehmung profitiert von den unglaublichen Fahigkeiten unseres Ge-hirnsMit diesen Fahigkeiten muss nun die Roboterforschung konkurrierenEiner der kompliziertesten Sinne des Menschen ist die visuelle Wahrnehmung Diese Artder Wahrnehmung auch den Maschinen zu ermoglichen ist ein weites Forschungsfeld

An der Hochschule fur Angewandte Wissenschaften Hamburg gibt es seit Jahren vieleKurse und Projekte in denen Roboter verwendet werdenUnd so wurde dort der CT-Bot ein Roboter der von dem rdquoHeise Zeitschriften Verlagrdquomit dem Ziel entwickelt wurde die Forschung auch ohne groszlige Labore zu ermoglichen alsGrundlage fur ein neues Roboter-Projekt verwendet

Nun gilt es diese Grundlage auszubauen

1httpwwwrobocuporg

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 10: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

1 Einfuhrung 2

11 Motivation

Die CT-Bots sind in ihren Moglichkeiten auf wenige Sensoren beschrankt Mit ihnen Fuszligballzu spielen ist moglich aber auch nicht sehr vielseitig da man in seinen Moglichkeitenbeschrankt ist An der Hochschule fur Angewandte Wissenschaften Hamburg wurde schonviel mit Robotern Fuszligball gespielt die ein klein wenig mehr konnen als die CT-Bots

Es lag also nahe die CT-Bots mit weiteren Sensoren auszurusten um das Spiel komplexerund die moglichen Aufgabenstellungen interessanter zu gestalten Eine Gruppe Studentenbeschaftigte sich deswegen damit den CT-Bot mit einer Kamera auszustatten sodassdieser seine Umgebung genauer beurteilen kann Eine weitere Moglichkeit den CT-Botmit Informationen zu versorgen ist eine Kamera in die Lage zu versetzen das gesamteSpielfeld zu uberblicken Dadurch kann die Position jedes CT-Bots und des Balls genaubestimmt werden

Ein solcher Object Tracker wird derzeit auch bei Roboter-Fussballturnieren verwendetHierfur hat jede Mannschaft ihre eigene Software die meist eng mit der Strategieplanungund Koordination der Roboter verzahnt und in den meisten Fallen nicht frei verfugbar ist

An der Hochschule fur Angewandte Wissenschaften Hamburg wurden schon mehrere Ver-suche gestartet das Problem zu beheben aber leider fuhrten die Ansatze nicht zu befrie-digenden Losungen

Daher musste eine Losung her die auch wahrend eines Projektes verwendet werden kann

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 11: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

1 Einfuhrung 3

12 Zielsetzung

Die CT-Bots brauchen mehr Informationen um besser in ihrer Umgebung agieren zu kon-nen

Daher sollen sie diese Informationen von einer externen Instanz bekommen welche die Weltin der die Roboter sich bewegen komplett uberblicken kann

Diese Instanz zu realisieren ist nun das Ziel dieser Arbeit

Abbildung 11 Der Gesamtuberblick uber das System

Um dieses zu ermoglichen wird eine Kamera so aufgehangt dass diese das gesamte Spielfelduberblicken kann die Roboter und der Ball erhalten Farbmarkierungen Ein Kameraserverauf einem leistungsstarken Computer soll die Bilder der Kamera analysieren die richtigenFarbobjekte suchen Position und Winkel dieser Objekte bestimmen und diese Informatio-nen an die autonomen Roboter senden

13 Gliederung

In dem Kapitel rdquoAnalyserdquo(2) werden zunachst die Anforderungen an die zu entwickelndeLosung gesammelt Anschlieszligend werden verschiedene Farbmodelle (22) diskutiert unddie zur Verfugung stehenden Technologien (23) an der Hochschule fur Angewandte Wis-senschaften Hamburg betrachtet Das Kapitel stellt schlieszliglich verschiedene Moglichkeiten

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 12: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

1 Einfuhrung 4

zur Losung einander gegenuber (24) und bietet eine Ubersicht an Arbeiten die sich mitvergleichbaren Themen beschaftigen (25)

Der Entwurf der Losung wird im Kapitel rdquoDesignrdquo(3) durch die Beschreibung des Program-mablaufs und ihre Struktur mit Hilfe von Klassendiagrammen dargestellt

Das nachfolgende Kapitel rdquoRealisierungrdquo(4) widmet sich der Umsetzung der Anforderungenund des Designs anhand des Anwendungsbeispiels Roboter-Fuszligball Es beinhaltet zunachsteinen Uberblick uber die gewahlte Programmierumgebung (41 42) die verwendeten Bi-bliotheken (43) Vorgehensweisen (45) zur Realisierung von Nebenlaufigkeit (44) undMethoden zur Auffindung und Vermeidung von Speicherlecks (462)

Abschlieszligend stellt das Fazit (5) die erreichten Ergebnisse (51) aufgetretene Problemeund deren Losungen (52) und einen Ausblick auf Erweiterungsmoglichkeiten (53) dar

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 13: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse

In diesem Kapitel werden zunachst die genauen Anforderungen abgesteckt

Nachfolgend werden die Grundlagen vermittelt die fur das Verstandnis der Losung not-wendig sind

Zu den wichtigen Grundlagen gehort ein Uberblick uber die gebrauchlichen rdquoFarbmodel-lerdquo(22) Dies ist wichtig da die Objekterkennung auf der Erkennung von Farben basiertund die gute und stabile Verarbeitung und Erkennung dieser Farben wichtig fur die Ge-samtfunktionalitat des Systems ist

Die Rahmenbedingungen an der Hochschule fur Angewandte Wissenschaften Hamburg zei-gen in welchem Umfeld und mit welchen Mitteln gearbeitet wurde Zur Beschreibung dieserMittel wird auch kurz gezeigt welche Roboter (233) an der Hochschule fur AngewandteWissenschaften Hamburg verwendet werden

Um eine effiziente Farberkennung zu implementieren bedarf es einer genauen Kenntnisder verschiedenen Farbmodelle (22) Zudem sollten die von der Kamera (232) geliefertenBilder moglichst brillant1 sein Daher wird kurz gezeigt welche gravierenden Unterschie-de es bei vermeintlich ahnlichen Kameras gibt Weiterhin werden das rdquoSpielfeldrdquo(231)der rdquoComputerrdquo(235) und die Funktechnologie (234) erklart welche zur Verwendungkamen

Das Kapitel schlieszligt mit einem Blick auf die internationale Forschung ab der zeigt wasbisher in verwandten Arbeiten erreicht wurde

21 Anforderungen

Ziel dieser Arbeit ist es ein System fur kameragestutzte Objektverfolgung zu gestalten

In diesem Fall bedeutet das konkret dass das entwickelte System die Roboter und denSpielball mit Hilfe einer Kamera erkennt und verfolgt sowie die Information uber den je-weiligen Aufenthaltsort weitergeben konnen muss

1Brillante Bilder nutzen den Farbraum moglichst gut aus und beschranken sich nicht auf nur wenigemogliche Farbwerte

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 14: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 6

Das zu entwickelnde System hat die Aufgabe in einem Kurs der Hochschule fur Angewand-te Wissenschaften Hamburg als Kameraserver zu fungieren um Robotern ihre absolutePosition2 mitteilen zu konnen

Des Weiteren soll es folgenden Grundsatzen Genuge tun

bull Konfigurierbarkeit Die Farbklassen sollen einfach einzustellen sein Auch Parameterwie die verwendete Kamera die verwendete Ausgabe fur das Funkmodul und dieEinstellungen fur die Objekterkennung sollen gut konfigurierbar sein

bull Erweiterbarkeit Das System soll in seinem Design so gestaltet sein dass es mit wenigAufwand um neue Funktionen erweitert werden kann (53) und dass auch kompletteKomponenten einfach ausgetauscht werden konnen

bull Portierbarkeit Das System soll moglichst unabhangig von dem verwendeten Systemprogrammiert werden So sollte zum Beispiel das Betriebssystem durch ein anderesersetzt werden konnen

bull Es soll die weiche Echtzeit3 fur die Weitergabe der Informationen an die Robotereingehalten werden

Das Programm soll folgende Anforderungen erfullen

bull Farberkennung

ndash Eine Farbflache soll erkannt werden

ndash Die Position von einem mit einer Farbflache markiertem Objekt soll erkanntwerden

ndash Von einem durch mehreren Farbflachen markiertem Objekt soll die Position unddie Ausrichtung erkannt werden

bull Anzeige und Weitergabe der Ergebnisse

ndash Die Ergebnisse konnen an mehrere Empfanger gefunkt werden

ndash Die Ergebnisse konnen so ausgegeben werden wie der Roboter sie auch emp-fangt (um festzustellen ob ein Fehler beim Roboter oder bei der Erkennungliegt)

2Die CT-Bots (233) haben selber nur begrenzte Mittel zur Bestimmung ihrer Position und konnenhochstens relative Positionsveranderungen bestimmen

3Echtzeit bedeutet dass die Antwortzeiten des Systems unterhalb einer vorher festgelegten Grenze liegen(zB lt 10 ms) Weiche Echtzeit bedeutet dass ein Uberschreiten dieser Zeit zwar nicht gewunschtist aber auch keine fatalen Folgen hat Die Steuerung eines Airbags zum Beispiel hat harte Echtzeitan-forderungen zu erfullen

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 15: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 7

ndash Die Ergebnisse konnen zur Kontrolle auf einem Ergebnisbild angezeigt werden

ndash Man kann sich das Kamerabild zur Kontrolle anzeigen lassen

ndash Es soll eine Moglichkeit geben das Ergebnis und die Funktionsfahigkeit derSoftware einfach auf dem Monitor zu uberprufen da die Berechnungen auf denRobotern schwerer uberprufbar sind

bull Modifizierbarkeit der Ausgabe

ndash Es sollen Filter in die Ausgabe eingehangt werden konnen welche zum Beispieldie Position anhand der aktuellen Geschwindigkeit vorausberechnen

bull Konfigurierbarkeit und Benutzbarkeit

ndash Es soll nachvollziehbar sein wie das System die Farben den Farbklassen zuteiltDurch eine Anzeige dieser Farbklassen soll auch die Erkennung der Roboternachvollziehbarer sein

ndash Die einzelnen Farben konnen wahrend das Programm lauft schnell umgestelltwerden damit Veranderungen in der Beleuchtung ausgeglichen werden konnen

22 Farbmodelle

In der Welt der Informationstechnologie existieren verschiedene etablierte Farbmodelle diefur unterschiedliche Bereiche und Anwendungsfalle entwickelt wurden

Ein Farbmodell beschreibt eine Sicht Farben zu beschreiben Ein Farbraum ist der Raumwelcher durch ein Farbmodell beschrieben wird Ein Farbformat beschreibt die Darstel-lungsform einer Farbe - mit Hilfe eines Farbmodells und innerhalb eines Farbraums - fureinen Computer

Die Wahrnehmung einer Farbe hangt jedoch von weiteren Faktoren ab So scheint zumBeispiel ein mit nur rotem Licht beleuchtetes weisses Blatt Papier auch rot zu sein Da-her ist die Wahrnehmung von Farben auch stark von dem Licht abhangig welches dieseBeleuchtet

Es gibt verschiedene Herangehensweisen eine Farbe im Computer zu speichern Zum einenkann eine Farbe aus mehreren Farben zusammengesetzt werden welche additiv oder sub-traktiv gemischt werden (221 und 222) Zum anderen kann die Farbe als Wert auf demFarbkreis angegeben und durch weitere Angaben erganzt werden (223) Schlieszliglich kanndie Farbe auch getrennt von ihrer Lichtintensitat angegeben werden (224)

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 16: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 8

Es folgt ein Uberblick uber die in der Informatik gebrauchlichsten Farbmodelle die hin-sichtlich ihrer Brauchbarkeit fur die automatischen Farberkennung beurteilt werden Fur dieWahl des Farbmodells ist es ebenfalls notwendig zu beurteilen wie schwierig die Festlegungeines Farbtons oder eines Farbbereichs ist

Eine Auswahl des verwendeten Farbmodells erfolgt erst in Kapitel 35

Abbildung 21 Additive Farbmischungder Farben Rot Grun undBlau

Abbildung 22 Subtraktive Farbmi-schung der FarbenTurkis Magenta undGelb

Die additive Farbmischung entspricht der Farbmischung des Lichts von verschiedenenScheinwerfern hier mit den Farben Rot Grun und Blau (Abbildung 21) Wenn alle Farbenzu gleichen Teilen mit voller Starke gemischt werden ergibt sich im Idealfall Weiss

Die subtraktive Farbmischung (Abbildung 22) hingegen ist mit der Verwendung von Farb-pigmenten wie bei Druckern zu vergleichen Bei der Verwendung der Farben Turkis Magen-ta und Gelb in maximaler Intensitat erhalten wir Schwarz

221 RGB

Das RGB-Farbmodell verwendet die Grundfarben Rot Grun und Blau um eine Farbe zubeschreiben Diese werden in additiver Farbmischung zusammengefugt um die gewunschteFarbe zu erhalten

Dieses Modell wird hauptsachlich fur die Darstellung von Farben auf Computermonitorenund fur die Farbbeschreibung im World-Wide-Web genutzt Es ist auch ahnlich aufgebautwie das menschliche Auge welches uber Farbrezeptoren fur Rot Grun und Blau verfugt

In diesem Farbmodell werden Grautone auch Schwarz und Weiss dadurch ausgedrucktdass jeweils gleiche Anteile von Rot Grun und Blau angegeben werden Weiss erhalt manindem man jeweils den maximalen Farbwert nimmt Schwarz indem man alle Farbwerteauf den minimalen Farbwert setzt Bei den Farben verhalt es sich ahnlich Dunklere Farben

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 17: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 9

werden durch einen geringen Farbanteil hellere Farben durch einen hoheren Farbanteil derGrundfarben dargestellt

Abbildung 23 Der RGB-Farbraum mit den Grauwerten auf der Diagonalen zwischen Weissund Schwarz

Durch diese Eigenschaft des RGB-Farbmodells liegen gleiche Farbtone in etwa in einemZylinder dessen Hauptachse parallel zur Grauwert-Diagonalen verlauft

Da dieses Modell das gangigste aller Farbmodelle ist in vielen Bibliotheken verwendet wird(beispielsweise CImg (Tschumperle 2007) und LTI-Lib (Alvarado u a 2007)) und ambesten unterstutzt wird bietet es sich an dieses ebenfalls zu benutzen

Im RGB-Farbmodell einen Farbton zu beschreiben ist nicht sehr leicht Das liegt an demkomplexen geometrischen Gebilde das konfiguriert werden musste um einen Farbton fest-zulegen

222 CMYK

Im CMYK-Farbmodell wird eine Farbe durch ihre Anteile an Turkis (Cyan) Magenta4 Gelb (Yellow) sowie Schwarz (Key 5) beschrieben welche in subtraktiver Farbmischung zuder gewunschten Farbe vermischt werden

CMYK wird bei Farbdruckern verwendet um die Anteile an Pigmenten anzugeben mitdenen Papier bedruckt wird

Turkis Magenta und Gelb sind die Komplementarfarben zu Rot Grun und Blau Daherkann man das CMYK-Farbmodell auch als invertiertes RGB-Farbmodell betrachten

4Anilinrot ein ins Purpur ubergehendes Rot mit einem leichten lila Farbton5Auch Kontrast oder Black Um Missverstandnissen vorzubeugen da es sonst auch als Blue interpretiert

werden konnte

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 18: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 10

Programmcode 21 Die Umwandlung von CMYK nach RGB

b = (MAXVALUE k) lowast (MAXVALUE c) MAXVALUEg = (MAXVALUE k) lowast (MAXVALUE m) MAXVALUEr = (MAXVALUE k) lowast (MAXVALUE y) MAXVALUE

Der schwarze Anteil wird benutzt um beim Drucken nach CMYK sowohl ein gesattigtesSchwarz zu ermoglichen als auch Farben abzudunkeln da ein reines Ubereinanderdruckenvon Turkis Magenta und Gelb kein absolutes Schwarz sondern ein dunkles Ocker ergibt

Abbildung 24 Der CMYK-Farbraum

Aufgrund der subtraktiven Farbmischung (Abbildung 22) ergibt sich Schwarz durch dieMischung aller Farben mit jeweils maximalen Farbwert analoges gilt fur Weiss

Eine Umwandlung von CMYK in das RGB-System ist einfach und unkompliziert (sieheProgrammcode 21)

Gleichartige Farbtone sind genauso schwer zu beschreiben wie in dem RGB-Farbmodell

223 HSV

Im HSV-Farbmodell wird eine Farbe durch ihren Farbton (Hue) ihre Sattigung(Saturation) und ihren Grauwert (Value) angegeben

Die Farbmodelle HSL HSB und HSI sind dem HSV-Farbmodell sehr ahnlich In diesenFarbmodellen wird lediglich die Helligkeit unterschiedlich angegeben So wird im HSL-Farbmodell die relative Helligkeit (Lightness) im HSB-Farbmodell die absolute Helligkeit(Brightness) und im HSI-Farbmodell die Lichtintensitat (Intensity) angegeben

Die verschiedenen Farben werden im HSV-Farbmodell auf einem Farbkreis angegeben (Ab-bildung 25)

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 19: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 11

Abbildung 25 Der HSV Farbkreis mit den Werten H=9 S=59 und V=76 (aus (GIMP-Team 2007))

Die Sattigung gibt an wie stark der Anteil der Farbe und des Grauwertes an der resul-tierenden Farbe ist Bei einer minimalen Sattigung und einem maximalen Grauwert ist dieresultierende Farbe Schwarz bei einem minimalen Grauwert Weiss Wenn hingegen einemaximale Sattigung verwendet wird hat der Grauwert keinerlei Bedeutung und es kommtnur auf den gewahlten Farbwert an (Abbildung 26)

Es ist recht aufwandig aus einem RGB-Farbwert den korrespondierenden HSV-Farbwertzu berechnen Dies liegt vor allem daran dass die Position der Farbe auf dem Farbkreisbestimmt werden muss (Programmcode 22)

Bei dem HSV-Farbmodell lassen sich Farbtone und -bereiche gut beschreiben indem maneinfach einen Abschnitt auf dem Farbkreis markiert und fur Sattigung und Helligkeit mini-male und maximale Werte angegeben werden

Die Nachteile des HSV-Farbmodells sind folgende

bull Es ist aufwandig eine Farbe aus oder in das RGB-Farbmodell zu konvertieren (Pro-grammcode 22)

bull Nicht stark oder gar nicht gesattigte Farben - wie Grautone - haben sowohl einenbeliebigen als auch einen beliebig schwankenden Farbwert

bull Der Wertebereich der moglichen Farben ist auf einen Kreis abgebildet Dadurchfolgt auf 359 sowohl 360 als auch 0 Wenn also eine Toleranz von 10 um 5

gefordert ist sind alle Werte von 0 bis 15 sowie von 355 bis 360 innerhalb diesesToleranzbereichs

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 20: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 12

Programmcode 22 Die Umwandlung von RGB nach HSV

red green blue value und saturation sind zwischen 0 und MAXVALUE zB 255hue i s t zwischen 0 und 359 Gradvoid rgb2hsv( int red int green int blue int lowast hue int lowastsaturation int lowast

value )

int max val min val lowastGrauwert (value) bestimmenlowast

max val = MAX(red green blue) min val = MIN(red green blue) lowastvalue = max val lowastWenn es sich um einen reinen Grauwert handelt sind wir fe r t ig lowasti f (max val == min val)

lowastsaturation = 0lowasthue = 0

else lowastAber wenn nicht muessen wir noch die Farbe und deren Saettigung

bestimmenlowast

int delta = max valmin val lowastZunaechst bestimmen wir die Saettigung der Farbe lowastlowastsaturation = (0==max val)0 MAXVALUE delta lowastdanach den Farbwert lowasti f ( red == max val )

lowasthue = 60 lowast (green blue) delta i f ( blue lt= green )

lowasthue = lowasthue + 360

else i f ( green == max val )

lowasthue = 60 lowast (blue red) delta + 120else lowast i f ( blue == max val ) lowast

lowasthue = 60 lowast (red green) delta + 240

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 21: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 13

Abbildung 26 Der HSV-Farbraum als Kegel Die Werte H S und V stehen fur den Farb-ton (Hue) die Sattigung (Saturation) und dem Grauwert (Value) (Pierce2005)

224 YUV

Das YUV-Farbmodell verwendet zur Beschreibung einer Farbe deren Lichtstarke und derenGrundfarbe Die Grundarbe ist hierbei in zwei Komponenten aufgeteilt U und V stehenjeweils fur den Anteil an Blau und Rot Y steht fur die Helligkeit

Dieses Farbmodell wird bei Farbfernsehern verwendet Diese ubertragen dabei die Helligkeithaufiger als die Farbinformationen da das menschliche Auge empfindlicher auf Helligkeits-unterschiede als auf Farbunterschiede reagiert

Das gerade angefuhrte Farbmodell ist den Farbmodellen YCrCb und YPbPr sehr ahnlichDer einzige Unterschied besteht in der Skalierung der Farbachsen Dadurch lasst sich bei-spielsweise YPbPr sehr einfach in YUV umwandeln (Programmcode 23)

Programmcode 23 Die Umwandlung von YPbPr nach YUV

u = 0872921 lowast pbv = 1229951 lowast pr

Die Umwandlung in ein anderes Farbmodell ist recht einfach zu bewerkstelligen (Programm-code 24)

Programmcode 24 Die Umwandlung von RGB nach YUV (Jack 1993)

Y = (0257 lowast R) + (0504 lowast G) + (0098 lowast B) + 16

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 22: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 14

Cr = V = (0439 lowast R) (0368 lowast G) (0071 lowast B) + 128Cb = U = (0148 lowast R) (0291 lowast G) + (0439 lowast B) + 128

Es gibt verschiedene Formate die das YUV-Farbmodell als Grundlage benutzen DieseFormate unterscheiden sich in der Reihenfolge und Haufigkeit mit der die einzelnen Kom-ponenten benutzt werden

Fur unser System ist das Format UYVY oder auch YUV 422 interessant In diesem Formatwird der Y-Wert fur jedes Pixel ubertragen und die Werte fur U und V immer abwechselndnur fur jedes zweite (Programmcode 25)6

Programmcode 25 Das UYVY-Format)

uyvy pixel = uy0 v y1

Das YUV-Farbmodell ermoglicht es leicht einen Farbton anzugeben Dies liegt darandass die Farbe auf der Farbflache (Die U und V-Komponenten des YUV-Farbmodells)festgelegt werden kann und diese nur noch durch die maximale sowie minimale Helligkeitabgegrenzt werden muss So ist sowohl eine recht naturliche Art der Abgrenzung einesFarbtons gegeben als auch eine die leicht beschrieben werden kann

23 Rahmenbedingungen

Seit 1996 gibt es an der Hochschule fur Angewandte Wissenschaften Hamburg das ProjektrdquoIntegration Kognitiver Systemerdquo7 In dem Kontext dieses Projektes werden Kurse zumThema mobile Roboter oder Robot-Vision angeboten Fur dieses Projekt stehen auch eineigenes Labor sowie eine Werkstatt zur Verfugung

Im Zuge dieser Kurse wurden im Jahre 2006 mehrere CT-Bots (Heise Zeitschriften Verlag2006) (233) angeschafft die auf einem Spielfeld (231) gegeneinander spielen konnen Esstanden mehrere Kameras zur Verfugung (232) Die Verbindung zu den Robotern wurdeper Funk (234) aufgebaut

6Eine ausfuhrliche Beschreibung weiterer auf dem YUV-Farbmodell basierender Formate ist unter httpfourccorgyuvphp zu finden

7httpusersinformatikhaw-hamburgde~kvl

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 23: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 15

231 Spielfeld

Fur die Roboter wurde ein Spielfeld (Abbildung 27) mit den Maszligen 122 x 183 cm verwen-det Diese Groszlige ist die selbe wie sie beim rdquoRoboCup Junior Soccerrdquo8 fur Spiele 2 gegen 2vorgesehen ist

Das Spielfeld hat eine kleine Schrage vor der Wand welche das Spielfeld begrenzt damitder Ball leichter vom Rand zuruckkommt und einen etwa 4 cm vom Rand entferntenschwarzen Strich damit die CT-Bots erkennen wenn sie nahe am Rand sind

Abbildung 27 Das Spielfeld

232 Kamera

An der Hochschule fur Angewandte Wissenschaften Hamburg stehen mehrere Arten vonKameras zur Verfugung So gab es USB-Kameras Webcams und Firewire-Kameras

Im Verlauf der Entwicklung stellte sich heraus dass die Firewire-Kameras deutlich brillante-re Bilder liefern sodass im weiteren Zuge der Entwicklung hauptsachlich Firewire-Kamerasverwendet wurden

Am wichtigsten fur die Farberkennung war dass die Kamera das vorgegebene Farbspektrum(Abbildung 28) moglichst gut ausnutzt und sich nicht nur auf wenige Werte in einemeingeschrankten Bereich verlasst um einzelne Farben besser voneinander abgrenzen zukonnen Hierzu wurde mit den Kameras eine Testsituation (Abbildung 29) gefilmt undanschlieszligend das von der Kamera gelieferte Bild auf die Ausnutzung des Farbspektrum hinuntersucht

8Die rdquoRoboCup Juniorrdquo Initiative hat das Ziel rdquoKindern und Jugendlichen Roboter und ihre Anwendungvorzustellenrdquo (httpwwwrobocupjuniorde)

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 24: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 16

Abbildung 28 Das UV-Farbspektrum aus dem YUV-Farbmodell

Abbildung 29 Die Testsituation fur die Kameras welche alle Farben beinhaltet die spaterauch erkannt werden sollen

Die Sony DFV-V500 Kamera (Abbildung 210) liefert ein sehr breites Spektrum an Farben(In Abbildung 211 sind nur die von der Kamera gelieferten Farben eingezeichnet)

Die Imagingsource DFK 21BF04-Z (Abbildung 212) hingegen liefert ein deutlich wenigervielfaltiges Farbspektrum (Abbildung 213) unter den gleichen Bedingungen

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 25: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 17

Abbildung 210 Die Sony DFW-V500Kamera Abbildung 211 Das Farbspektrum der

Sony DFW-V500 Kame-ra

Abbildung 212 Die Imagingsource DFK21BF04-Z Kamera

Abbildung 213 Das Farbspektrum derImagingsource DFK21BF04-Z Kamera

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 26: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 18

Die Sony-Kamera nutzt das Farbspektrum nahezu vollstandig aus und liefert auch scharfeBilder Daher wurde diese Kamera verwendet

233 Roboter

An der Hochschule fur Angewandte Wissenschaften Hamburg werden Roboter in vielenProjekten verwendet So gibt es unter anderem den Pioneer-Roboter (Abbildung 214)verschiedene Roboter auf Basis des Aksen-Boards 9 (Abbildung 215 und 216) Roboterauf reiner Lego-Basis (Abbildung 217) und die CT-Bots10 (Abbildung 218)

Wahrend der Entwicklung wurde mit den CT-Bots getestet da diese von einer Gruppe Stu-dierender zusammen mit dem erstellten Programm in einem Praktikum verwendet werdensollten

234 Funk

Fur die Funkverbindung zu den Robotern wurde der Funkstandard IEEE 802154 genutztIEEE 802154 ist ein Funkstandard welcher mit Hinblick auf niedrigen Stromverbrauchbei niedrigen Datenraten konzipiert wurde

Der IEEE 802154 Funkstandard bietet viele Vorteile So erlaubt er Netzwerke mit 216

Einheiten welche gleichberechtigt funken konnen die Latenzzeiten sind im Bereich vonHundertstelsekunden (bei Bluetooth dauert zum Beispiel der Beitritt zu einem Netzwerklanger als 3 Sekunden bei IEEE 802154 etwa 30 Millisekunden) und der Energieverbrauchist auch sehr geringDie Nachteile sind dass der Funkstandard nur fur Reichweiten von 75 Metern geschaffenwurde und dass die Verbindungsgeschwindigkeit bei maximal 250 KBit je Sekunde liegt

ZigBee11 ist ein Netzwerkstack12 fur IEEE 802154 welcher im Hinblick auf mobile Systememit wenig Ressourcen entworfen wurde

9Das Aksen-Board (httpwwwaksen-roboterde) ist ein fertiger Controller fur Roboter an denSensoren und Aktoren angeschlossen werden konnen

10Der CT-Bot (httpwwwheisedectftpprojektect-botct-botshtml) ist ein Robotervom Heise Zeitschriftenverlag welcher einen preiswerten Einstieg in Roboterbau und -programmierungbieten soll

11httpwwwzigbeeorg12Der Netzwerkstack ist die Softwareschicht welche die Vermittlung von Daten hier uber Funk steuert

Der Netzwerkstack ist in etwa zu vergleichen mit der Post Ein beliebiger Mensch kann einfach einenBrief bei der Post abgeben und die Post kummert sich darum dass dieser bei seinem Ziel ankommt

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 27: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 19

Abbildung 214 Der Pioneer Roboter

Abbildung 215 Ein Lego-Roboter ge-steuert durch das AksenBoard

Abbildung 216 Ein Roboter mit omnidi-rektionalem Antrieb

Abbildung 217 Ein Lego-Roboter

Abbildung 218 Ein CT-Bot

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 28: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 20

Mehr dazu bei (Fischer 2006) der das ZigBee Protokoll speziell in Hinblick auf spontaneFunknetzwerke betrachtet hat und bei (Rickens 2005) welcher ein ZigBee Funkmoduluber den CAN-Bus13 an mobile Roboter angebunden hat

Fur dieses Projekt hat Prof Dr Gunter Klemke ein IEEE 802154 Funkmodul sowohl fur dieCT-Bots als auch eines das per USB an einen Computer angeschlossen wird entworfen

235 Computer

Fur die Auswahl eines Computers waren zwei Faktoren entscheidend Zum einen mussteder Computer mit einem Firewire-Port ausgestattet sein welcher auch die Stromversorgungder angeschlossenen Gerate ubernimmt14 und er musste uber genug Rechenkraft verfugenda die bisherigen Ansatze (Schmidt (2005) und Gottwald (2005)) gezeigt haben dass dieRechenkraft bei der Bildverarbeitung schnell zu einem Engpass wird Des Weiteren war esnotwendig kompletten Zugriff auf das System zu haben um die Treiber fur die Kameraauszutauschen

Diese Anforderungen wurden an der Hochschule fur Angewandte Wissenschaften Hamburgvon einem MacBook erfullt welches im weiteren Verlauf unter Linux und Mac OS X zurEntwicklung und Benutzung der Software verwendet wurde Es besaszlig sowohl einen Firewire-Port als auch einen Dualcore-Prozessor15(ein rdquoIntel Core 2 Duordquo mit 2 Ghz) welcher esermoglichte in dem Programm auf jedem dieser Prozessorkerne einen Verarbeitungsstrang(Thread) laufen zu lassen (243)

24 Algorithmen

In diesem Abschnitt sollen die fur die Erkennung von farblich markierten Objekten wichtigenAlgorithmen erlautert werden

Ziel der Objekterkennung ist es den Ball und die mit Farbpunkten markierten Roboter zufinden um den Robotern die Positionen mitteilen zu konnen (234)

Hierzu mussen zunachst die Farbflachen auf den Robotern erkannt werden die dann wie-derum Robotern zugeordnet werden

13Der CAN-Bus ist ein Bus welcher mit maximal 1 Mbit je Sekunde Daten ubertragen kann und bis zu67 km lang sein kann Er ist genauer bei (Rickens 2005) erklart

14Es gibt bei Firewire einen Stecker mit 6 Polen welcher auch Strom fuhrt und auch einen Stecker mitnur 4 Polen bei welchem die angeschlossenen Gerate nicht mit Strom versorgt werden konnen

15Ein Dualcore-Prozessor ist ein Prozessor welcher aus zwei Prozessorkernen besteht die gleichzeitigProzesse verarbeiten konnen

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 29: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 21

Die Zuordnung eines Pixels zu einer Farbklasse ubernimmt die Farbsegmentierung (241)Daraufhin mussen die Farbklassen zu Flachen zusammengefugt werden Mithilfe dieserFlachen findet die Objekterkennung (242) der einzelnen Roboter statt Die Ergebnissewerden mittels der Ergebnisausgabe (346) ausgegeben

241 Farbsegmentierung

Bei der Farbsegmentierung geht es darum ein gegebenes Bild in Farbkategorien aufzuteilenDazu muss jeder Farbpunkt des gegebenen Bildes in eine Farbklasse eingeteilt werden

Um die Farben zu klassifizieren kann man zwischen verschiedenen Vorgehensweisen wah-lenSo kann man mit Grenzwerten in jeder Dimension des Farbraums einen Wurfel aufspannender die gewunschte Farbe beschreibtEin zweiter Ansatz ist die Farbwerte nach ihrem Abstand zu einem Referenzfarbtonim Farbraum zu gruppieren und so Farbgruppen zu bilden Dieser Ansatz ware gut mitKohonen-Netzen (Kohonen 2001) realisierbar

Zu den Anforderungen gehort eine Klassifizierung in Echtzeit zu ermoglichen Deshalbwird das erstgenannte Verfahren verwendet Zudem ist es auch leichter testbar

Da die zu suchenden Farben bekannt sind konnen die Grenzen fur die jeweiligen Farbenvorab festgelegt werden

Klassifizierung eines Punktes

Eine Verfahrensweise zur Feststellung der Farbklasse eines Pixels ist diesen mit allen mog-lichen Farbklassen zu vergleichen bis die ihm zugeordnete Farbklasse gefunden ist Hierzuwaren sechs Vergleiche je Farbe und Pixel notwendig (siehe Programmcode 26)

Programmcode 26 Farbklasse durch Vergleiche bestimmen

i f ( pixe l y gt= threshold y lowampamp pixel y lt= threshold y highampamp pixel u gt= threshold u lowampamp pixel u lt= threshold u highampamp pixel v gt= threshold v lowampamp pixel v lt= threshold v high)pixe l color class = current class

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 30: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 22

Dieses Verfahren ist jedoch sehr aufwandig da fur jede zu klassifizierende Farbe sechsVergleiche und ein potenzieller Sprung auszufuhren sind Eine weniger aufwandige Verfah-rensweise ist es diese Vergleiche durch drei Zugriffe auf eine Tabelle (Look-up Tabelle(Miglino u a 1995)) zu ersetzen die mit booleschen Werten gefullt ist Als Beispiel miteinem auf acht Werte in der Farbtiefe reduzierten Kamerabild in Programmcode 27 ge-zeigt

Programmcode 27 Initialisierung einer Look-up Tabelle

threshold y = 0 0 0 1 1 1 0 0threshold u = 0 1 1 1 1 0 0 0threshold v = 0 0 1 1 1 1 0 0

Dadurch wird die Frage ob ein Pixel in einer Klasse ist mithilfe von zwei logischen ANDsermittelt (siehe Programmcode 28)

Programmcode 28 Bestimmung der Farbkategorie durch Nachschlagen in der Tabelle

while( pixe l color class == 0 ampamp current class = NULL)

i f ( current class threshold y [ pixe l y ]ampamp current class threshold u[ pixe l u]ampamp current class threshold v [ pixe l v ] )

pixe l color class = current class value current class = current class next class

Wenn man nun die booleschen Werte durch 32 Bit Integerwerte ersetzen und in diesendie Farbklasse unter Verwendung einer Bitmask kodiert kann man 32 Farbklassen mitderselben Operation abdecken

Hier als Beispiel die Tabellen mit jeweils nur zwei Farbklassen (siehe Programmcode 29)

Programmcode 29 Initialisierung einer Look-up Tabelle mit Bitmasken

thresholds y = 0001011110100000thresholds u = 0010101111010100thresholds v = 0001010110100000

Dies vereinfacht das Finden der Farbklasse wie folgt

Programmcode 210 Bestimmung der Farbklasse durch Nachschlagen in der Tabelle

pixe l color class = threshold y [ pixe l y ] ampamp threshold u[ pixe l u] ampamp threshold v[ pixe l v ]

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 31: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 23

Die Zugehorigkeit zu einer Farbklasse kann nun festgestellt werden indem gepruft wirdob das jeweilige Bit gesetzt ist (siehe Programmcode 211)

Programmcode 211 Testen ob eine bestimmte Farbklasse in einer Bitmaske gesetzt ist

testen ob die xte Farbklasse gesetzt i s ti f ( pixe l color class amp 2ˆx)

Speichert man eine Bitmaske in einer Look-up Tabelle so ist eine sehr gute Performanceerreichbar (siehe auch Bruce u a 2000)

Farbflachen zusammenfugen

Die einzelnen gefundenen Farbkategorien mussen nun zu Flachen zusammengefugt werdenHierzu bieten sich die Verfahren Connected Components Labeling (Meisel 2006) oderRegion Splitting and Merging (Gonzales u Woods 2002) an

Bei Connected Components Labeling wird das Bild zeilenweise untersucht und hierbei diejeweilige Farbkategorie der Pixel betrachtet Wird ein Pixel gefunden dass in einer ande-ren Farbgruppe als seine Nachbarpixel ist wird dieses einer neuen Farbflache zugeordnetWerden Pixel aus den selben Farbgruppen gefunden werden die jeweiligen Farbgruppender Pixel zusammgengefugt

Bei Region Splitting and Merging wird das Bild solange in Abschnitte geteilt bis in demubrig bleibenden Abschnitt alle Pixel einer Farbklasse zugeordnet werden konnen Daraufwerden die angrenzenden Abschnitte daraufhin untersucht zu welcher Farbklasse sie geho-ren Werden zwei aneinander grenzende Abschnitte welche der selben Farbklasse angehorengefunden werden diese Abschnitte wieder zusammengefugt

242 Objekterkennung

Ziel der Objekterkennung ist es die Roboter und den Ball auf dem Spielfeld zu erkennenHierzu werden die Farbflachen als Eingabe verwendet

Die Roboter sowie der Ball bekommen je eine Markierungsfarbe Die Objekterkennungermittelt danach aus den von der Farbsegmentierung (241) erhaltenen Farbflachen diePosition und Ausrichtung der Objekte auf dem Spielfeld (231)

Der Ablauf gestaltet sich dabei im Groben wie folgt

bull Um die Roboter zu finden werden alle Farbflachen gesucht die in der Nahe derMarkierungsfarbe sind

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 32: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 24

bull Von diesen werden die passendsten Farbflachen herausgesucht (siehe 452)

bull Die gefundenen Farbflachen werden daraufhin im Uhrzeigersinn sortiert

Als Ergebnis wird eine Liste von gefundenen Objekten weitergegeben welche die Postionendes Balls und der Roboter enthalt

243 Nebenlaufigkeit

Die weiche Echtzeit ist nur fur die Weitergabe der Informationen an die Roboter relevant dadie Anzeige des Kamerabildes und der erkannten Farbflachen sowie der erkannten Objektenur die Funktion hat das Ergebnis zu kontrollieren

Um die Anzeige von der Verarbeitung zu trennen werden diese in verschiedene Verarbei-tungsstrange (Threads) aufgeteilt

25 Verwandte Arbeiten

Object Tracker werden fur viele verschiedene Systeme eingesetzt so zum Beispiel vonder Industrie um Objekte auf dem Flieszligband zu erkennen und zu sortieren oder aber inVersuchslaboren wie beim Massachusetts Institute of Technology (Abbildung 219)

Abbildung 219 Schwarm Gesundheitsmanagement in dem Aerospace Controls Labor(httpvertolmitedu) am MIT

Da es sich bei dem Ziel dieser Arbeit um ein System handelt welches fur den Roboterfuss-ball geschaffen wird wird auch der Blick nach verwandten Arbeiten sich auf diesen Bereichkonzentrieren

Vergleichbare Systeme gibt es in der rdquoSmall Size Robot Leaguerdquo des rdquoRoboCuprdquo Dortmussen zwei Teams von kleinen Robotern16 gegeneinander spielen Diese Teams werdenjeweils von einem Computer per Funk koordiniert welcher die Spielsituation mit einerKamera bestimmt (Abbildung 220)

16Die Roboter durfen maximal 180mm Durchmesser haben und 150mm hoch sein

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 33: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 25

Abbildung 220 Die Vorgehensweise beim rdquoRoboCuprdquo

Die meisten der Teams benutzen einen omnidirektionalen Antrieb (Abbildung 221) mit 4Radern die eine Bewegung in alle Richtungen und auch das Drehen wahrend des Fahrensermoglicht

Von diesen Systemen ist jeweils das Bildverarbeitungssystem fur diese Arbeit von Inter-esse und es werden zunachst die Systeme der ersten drei Teams des letzten RoboCupsvorgestellt

Leider sind von diesen Teams meist nur die Doktor- oder Diplomarbeiten verfugbar Diejeweils eingesetzte Software wird - wenn uberhaupt - nur in alten Versionen zu Verfugunggestellt

Skuba

Das Team Skuba17 kommt von der Kasetsart Universitat in BangkokEs benutzt einen Camcorder welcher die Bilder bei 50 Hz mit einer Auflosung von 640x480Pixeln liefertDas Bild wird in einem ersten Verarbeitungsschritt aus dem RGB in das HSV-Bildformatumgewandelt um besser mit Unterschieden in der Beleuchtung umgehen zu konnen

17httpimlcpekuacthskuba

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 34: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 26

Abbildung 221 Der omnidirektionale Antrieb des Plasma-Z Teams 2006

Das System arbeitet mit einer Verzogerung von etwa drei bis funf Bildern (etwa 150 Mil-lisekunden) Diese Verzogerung soll durch eine Abschatzung uber die vermutliche Positionvermindert werden (Srisabye u a 2006)

FU-Fighters

Die FU-Fighters18 von der freien Universitat Berlin benutzen ein Bildverarbeitungssystemwelches Region Growing (von Hundelshausen 2005) benutzt

5dpo

Das Team 5dpo19 wurde zweiter bei dem RoboCup 2006Es benutzt zwei Firewire-Kameras mit einer Auflosung von je 780x582 Pixeln und klassifi-ziert die Farben mit einem Fuzzy-System um kontinuierliche Farbgruppen zu erhalten DerTeambeschreibung des Teams 5dpo (Costa u a 2004) ist auch zu entnehmen dass dasBildverarbeitungsystem mit einer Verzogerung von mindestens 50 Millisekunden arbeitet

18httprobocupmifu-berlindepmwikipmwikiphp19httppaginasfeuppt~robosoc

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 35: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 27

CMDragons

Die CMDragons20 von der Carnegie Mellon Universitat21 haben den RoboCup 2006 gewon-nen

Das von diesem Team benutzte Bildverarbeitungssystem benutzt die Bibliothek CMVision(Bruce u a 2000)

Tekkotsu

Tekkotsu22 ist ein OpenSource Framework fur die Entwicklung von Programmen fur denAIBO23

Das Tekkotsu Framework verwendet ebenfalls die Bibliothek CMVision (Bruce u a 2000)fur die Farberkennung

CMVision

CMVision ist ein Farbsegmentierungssystem fur Interaktive Roboter (Bruce u a 2000)Es bietet eine sehr schnelle Moglichkeit Farbflachen aus einem Bild zu extrahieren undwurde auch in dieser Arbeit (432) sowie in vielen Anderen verwendet

An der Hochschule fur Angewandte Wissenschaften Hamburg

Rainer Balzerowski hat 2002 ein Webcam basiertes Kamera-System fur Lego-Mindstormsrealisiert rdquoRealisierung eines Webcam basierten Kamera Systems fur mobile Robo-terrdquo(Balzerowski 2002)Arne Diekmann rdquoVerbesserung visueller Objekterkennung fur mobile Roboterrdquo(Dieckmann2003) entwickelte 2003 ein System um dem Pioneer(233) eine besser Objekterkennungzu ermoglichenIlia Revout rdquoDesign und Realisierung eines Frameworks fur Bildverarbeitungrdquo (Revout2003) entwickelte ein System fur allgemeine Bildverarbeitung welches den Einsatz meh-rerer Filter ermoglichte um so vielfaltige Probleme im Bereich der Bildverarbeitung zumeistern dieses System ist jedoch mit dem Ziel entwickelt worden neue Algorithmen

20httpwwwcscmuedu~robosoccersmall21httpwwwcscmuedu22httpwwwcscmuedu~tekkotsu23Der AIBO ist ein Roboter-Hund von Sony dessen Produktion im Marz 2006 eingestellt wurde

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 36: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

2 Analyse 28

schnell implementieren zu konnen nicht jedoch mit dem Ziel der Echtzeitfahigkeit

Die Arbeiten die als Vorlaufer des angestrebten System angesehen werden konnen stam-men von Oliver Schmidt rdquoEntwicklung eines Mehrbenutzer-Webservice am Beispiel einesKamera-Servers fur mobile Roboterrdquo (Schmidt 2005) und Michael Gottwald rdquoWebcambasiertes Kamerasystem fur autonome Roboter Erste Konzeption Webcam basiertes Ka-merasystem fur autonome Roboter Erste Konzeptionrdquo (Gottwald 2005) Hierbei hat sichjedoch Oliver Schmidt auf den Aspekt eines sicheren Mehrbenutzer-Webservice konzen-triert und Michael Gottwald lediglich ein Konzept fur weitere Arbeiten geschaffen

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 37: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design

In diesem Kapitel soll eine Ubersicht uber das System vermittelt werden

Hierfur wird zunachst die Architektur des Gesamtsystems (31) betrachtet um einen Uber-blick zu verschaffen Darauf wird die Abfolge der Arbeitsschritte in dem Abschnitt rdquoPro-grammablaufrdquo(32) gezeigt Nachdem diese Grundlagen geschaffen wurden werden die ein-zelnen Komponenten genauer erlautert (34) Dieses Kapitel schlieszligt ab durch die Auswahleines geeigneten Farbmodells (35)

Die jeweilige Implementierung wird in dem folgenden Kapitel rdquoRealisierungrdquo(4) beschrie-ben

31 Systemarchitektur

Abbildung 31 Die Systemarchitektur im Uberblick

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 38: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 30

Das System besteht aus einer Kamera einer Verarbeitungseinheit einer Funkeinheit undeiner Darstellungseinheit Des Weiteren sind Datenpuffer vorhanden welche den synchro-nisierten Datenaustausch1 zwischen den Verarbeitungsstrangen ermoglichen

32 Programmablauf

Der Programmablauf des Gesamtsystems gestaltet sich wie in Abbildung 32 dargestellt

Abbildung 32 Der Ablauf des Programms

Es gibt zwei nebenlaufige Verarbeitungsstrange (243)

Ein Verarbeitungsstrang kummert sich um die Analyse der Bilder und die Weitergabe dergewonnen Informationen an die Konsumenten wie zum Beispiel Roboter und DarstellungDies ist auch der Teil fur den die Echtzeit-Anforderungen (21) gelten da es in unserem

1Synchronisierter Datenaustausch sichert bei gleichzeitigem Zugriff von zwei Verarbeitungsstrangen dasskeine Daten korrumpiert werden

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 39: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 31

Kontext einem Fuszligball spielendem Roboter wenig nutzt wenn er erfahrt wo sich der Ballvor drei Sekunden befunden hatZunachst werden Bilder von der Kamera erwartetDas gewonnene Bild wird in seine Farbflachen zerlegtDie Farbflachen-Informationen werden in der Objekterkennung zur Identifizierung von Ballund Roboter verwendetZuletzt werden die gewonnen Positionen und Ausrichtungen an die Roboter weitergegebenund fur die Anzeige gespeichert

Der andere Verarbeitungsstrang kummert sich um die Anzeige der Bilder Dafur wird dasKamerabild in das RGB-Format konvertiert die Ergebnisse werden eingezeichnet und so-wohl das Kamerabild als auch das Bild der segmentierten Farben auf dem Monitor darge-stellt

33 Farbkonfiguration

Die Farbkonfiguration ermoglicht es die einzelnen Farbklassen einzustellen und anhandeines Histogramms festzustellen welche Farben gerade von der Kamera gesehen werden(Abbildung 33)

Abbildung 33 Anwendungsfalle fur die Farbkonfiguration

34 Klassendiagramme

In diesem Abschnitt werden die Zusammenhange zwischen den einzelnen Komponentendes Systems dargestelltDazu wird jeweils mithilfe eines UML-Diagramms (Oesterreich 2006) eine Komponentemit deren Funktionen und Abhangigkeiten zu anderen Komponenten beschrieben

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 40: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 32

Auf die Implementation der Komponenten wird genauer in Abschnitt 45 eingegangen

341 Ubersicht

Abbildung 34 Klassendiagramm rdquoUbersichtrdquo

Die Ablaufsteuerung (ProcessingFacility Abbildung 34) ist zustandig fur die richtige Ab-folge der ArbeitsschritteSie besteht aus einer Bildquelle (ImageSource 342) einem Farbsegmentierer (ColorSeg-mentation 343) einer Objekterkennung (ObjectIdentification 344) und der Ergebnisaus-gabe (ResultOutput 346)

Die Ablaufsteuerung ist der rdquoMediatorrdquo(siehe Gamma u a 1995 Seite 273-282) zwischenden Komponenten des Systems Sie kapselt die Interaktionen zwischen den Teilsystemenund ermoglicht so eine lose Kopplung zwischen den Komponenten Dies erleichtert es aucheinzelne Komponenten auszutauschen wie es die Anforderung rdquoErweiterbarkeitrdquo fordert(21)

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 41: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 33

Abbildung 35 Klassendiagramm rdquoBildquellerdquo

342 Bildquelle

Die Bildquelle (ImageSource Abbildung 35) liefert dem Programm die zu verarbeiten-den Bilder Die Bilder konnen aus einer Firewire-Kamera einer V4L-Kamera2 oder einemBildgenerator ImageGenerator gewonnen werden

Im Folgenden werden diese Bilder rdquoKamerabildrdquogenannt

Der Bildgenerator generiert Kamerabilder um fur Testfalle (test cases) reproduzierbareAusgangssituationen zu schaffenDie Firewire-Kamera und die V4L-Kamera sind zwei Moglichkeiten das Programm mitweiterzuverarbeitenden Bildern zu versorgen

Jeder Bildgenerator kann erneut das zuletzt aufgenommene Bild oder das nachste Bildliefern Wenn das nachste Bild geliefert werden soll dieses aber noch nicht vorliegt dannwartet der Bildgenerator bis er ein Bild liefern kannEr kann zudem noch gestartet und gestoppt werden um zum Beispiel die Kamera zustarten oder zu stoppen

2Video4Linux ist eine Schnittstelle um unter Linux auf diverse Kameras wie USB-Kameras oder Fernseh-Karten zuzugreifen

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 42: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 34

343 Farbsegmentierung

Die Farbsegmentierung ist verantwortlich fur die Zerlegung des Kamerabildes (342) inseine einzelnen Farbkomponenten

344 Objekterkennung

Die Objekterkennung ermittelt mithilfe des segmentierten Bildes an welchem Ort sichwelche Objekte befinden und wie diese ausgerichtet sind

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 43: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 35

345 Ausgabefilter

Abbildung 36 Klassendiagramm rdquoAusgabefilterrdquo

Die Ausgabefilter beschranken oder verandern die Ausgabe indem alle Ergebnisse zunachstdurch diese geleitet werdenEs gibt hierbei zwei Ausgabefilter (Abbildung 37)Der eine Ausgabefilter merkt sich die letzte Position des Balles und fugt diese in die Listeein falls kein Ball gefunden wurde (BallKeepLastPositionFilter)

Der andere Ausgabefilter errechnet anhand der letzten Position eines Objektes die Ge-schwindigkeit und die sich dadurch ergebende vorraussichtliche neue Position die dannanstelle der Originalposition in die Liste eingefugt wird (ObjectTracker)

346 Ergebnisausgabe

Die Ergebnisausgabe ist fur die Weiterverwendung der ermittelten und gefilterten Ergeb-nisse zustandig Die Ergebnisse sind die Position des Balls sowie die Positionen und Aus-richtungen der Roboter

Die Ergebnisausgabe wird implementiert durch

bull eine Liste welche dazu verwendet wird die Ergebnisse an alle in ihr enthaltenenErgebnisausgaben weiterzuleitenDiese Liste wurde als rdquoCompositerdquo(siehe Gamma u a 1995 Seite 163-173) imple-mentiert sodass sie sich wie eine einfache Ergebnisausgabe verhalt

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 44: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 36

Abbildung 37 Klassendiagramm rdquoErgebnisausgaberdquo

bull eine Ausgabe uber den seriellen Port damit das Ergebnis an die Roboter gefunktwerden kann

bull eine Anzeige auf dem Ergebnisbild der Farbsegmentierung um die Erkennung derObjekte zu uberprufen

bull eine Ausgabe auf der Konsole welche der auf dem seriellen Port entspricht um eineAusgabe zur Uberprufung zu haben deren Rechenaufwand sehr gering ist

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 45: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 37

347 Bild

Abbildung 38 Klassendiagramm rdquoBildrdquo

Die Klasse rdquoBildrdquo(Image Abbildung 38) dient als reine Datenklasse fur das Bild Sie kannauch notige Konvertierungen in die Formate

bull YUYV (224)

bull RGB (221)

bull CImg (436)

vornehmen Hierfur hat sie jeweils einen Puffer um sich die Ergebnisse zu merken

348 Ringpuffer

Der rdquoRingpufferrdquo(RingBuffer Abbildung 39) dient dem Austausch von Daten zwischenverschiedenen Threads

Der Ringpuffer hat eine feste Groszlige Er bietet verschiedene Moglichkeiten ihm Elemen-te hinzuzufugen oder zu entnehmen Diese Zugriffe werden durch Semaphoren geschutzt(Tannenbaum 2003)

bull Normales Hinzufugen und Entfernen (add remove) bei einem vollen bzw leerenRingpuffer wartet diese Methode bis Platz fur ein Element frei ist bzw ein Elementverfugbar ist

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 46: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

3 Design 38

Abbildung 39 Klassendiagramm rdquoRingpufferrdquo

bull Probiertes Hinzufugen und Entfernen (tryAdd tryRemove) diese Methode auf denRingpuffer zuzugreifen versucht ein Element zu entfernen oder hinzuzufugen Solltedies nicht moglich sein so wartet sie nicht sondern gibt ein entsprechendes Ergebniszuruck

bull Erzwungenes Hinzufugen und Entfernen (forceAdd forceRemove) fur diese Metho-de konnen Callbacks3 angegeben werden (setCreator setDisposer) die bei vollemRingpuffer Elemente entsorgen4 oder bei leerem Ringbuffer Elemente bereitstellen

35 Farbmodell

Im RGB-Modell ist es relativ kompliziert eine Farbe unabhangig von der Helligkeit abzu-bilden (221)

Da im YUV-Farbmodell zwei Achsen fur die Farbauswahl und eine Achse fur die Helligkeitder Farbe benutzt werden lasst sich hier eine Farbe leicht durch ein Farbintervall sowieeine maximale und minimale Helligkeit beschreiben

Da zudem die in der Hochschule fur Angewandte Wissenschaften Hamburg verfugbarenFirewire-Kameras alle das YUV-Format direkt unterstutzen wurde dieses verwendet

3Ein Callback ist ein ausfuhrbarer Programmcode der einer Funktion als Argument ubergeben wirdDiese Funktion kann dann auf diesen Callback zugreifen um bestimmte Aufgaben zu erledigen

4Dieses wurde zB verwendet um Objekte die in dem Ringpuffer keinen Platz mehr fanden wieder zuverwenden

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 47: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung

Not to be in production is to be spending money without making money (Beck 2000Seite 131)

Fur die Realisierung ist eine iterative Vorgehensweise mit fruhzeitigem Einsatz in einemPilotprojekt gewahlt worden (continuous integration (Beck 2000)) Nach der Fertigstel-lung des fortgeschrittenen Prototyps ist die Losung gleich in experimenteller Umgebungin dem Roboter Projekt des Wintersemesters 20062007 eingesetzt worden Das inten-sive Feedback durch die Nutzer vereinfachte die Fehlerfindung erheblich und machte dieFeinabstimmung der Anforderungen parallel zur Realisierung erst moglich

So kam zum Beispiel wahrend des Roboter Projektes die Anforderung auf dass der Ballmit seiner letzten Position auch gesendet werden soll wenn dieser nicht mehr vom Systemerkannt wird Diese Anforderung konnte schnell erfullt werden (453)

Im Folgenden werden die gewahlte Programmiersprache die eingesetzte Entwicklungsum-gebung und die Auswahlkriterien dafur beschrieben

Um die Entwicklungszeit zu senken baut die Losung auf bereits existierenden Bibliothekenauf (buy versus build (Brooks 1995)) Dies senkt zusatzlich das Risiko weil die so einge-bundenen Funktionen nicht mehr entwickelt und - in dem Maszlige wie das im Rahmen einerEigenentwicklung notwendig ist - getestet werden mussen

Bevor in diesem Kapitel auf die konkrete Realisierung eingegangen wird beschaftigt es sichmit der verwendeten Programmiersprache (41) und den verwendeten Programmen (42)Es geht auch zunachst auf die benutzten Bibliotheken (43) und deren Verwendung einDanach beschreibt es die Realisierung der einzelnen Komponenten (45) sowie die Opti-mierung der Anwendung (46)

41 Programmiersprache

Als Programmiersprache wurde C++ gewahlt da diese viele der Anforderungen (21) er-fullt

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 48: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 40

So ist C++ auf vielen Systemen verfugbar und genugt somit der Portierbarkeit Des Weite-ren hat C++ keinen Garbage Collector1 was dazu fuhrt dass das Laufzeitverhalten leichterzu bestimmen ist wodurch die Anforderung der weichen Echtzeit nicht mehr durch die Gar-bage Collection gestort werden kann

Leider ist dies auch mit einem erhohtem Programmieraufwand verbunden und mit derGefahr dass man den angeforderten Speicher nicht wieder freigibt Dadurch passiert es inProgrammen ohne Garbage Collector leichter dass man Speicherlecks (462) hat

Auszligerdem sind im Bereich der Bildverarbeitung und der Roboter viele Bibliotheken furC++ vorhanden was die Entwicklungszeit erheblich verkurzt

42 Entwicklungsumgebung

Trac2 wurde als Bug-Tracker fur die Projektplanung und Subversion3 als Versionskontroll-system benutzt (Fogel 2005)

Unter Linux wurden fur die Entwicklung KDevelop4 Emacs5 Valgrind6 und KCachegrind7 benutzt

Unter Mac OS X kam als IDE XCode8 zum Einsatz und MallokDebug zum Finden vonSpeicherlecks

43 Bibliotheken

In diesem Kapitel wird eine Ubersicht uber die verwendeten Bibliotheken nach folgendenKriterien gegeben

bull Funktionsumfang

bull Wo wurde die Bibliothek entwickelt

bull Wofur wird sie noch verwendet

1Garbage Collection ist ein Teil der Speicherverwaltung welcher sich um die Freigabe von nicht mehrverwendetem (Arbeits-)Speicher kummert

2httptracedgewallorg3httpsubversiontigrisorg4httpwwwkdeveloporg5httpwwwgnuorgsoftwareemacs6httpvalgrindorg7httpkcachegrindsourceforgenet8httpdeveloperapplecomtoolsxcode

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 49: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 41

bull Wie wurde die Bibliothek in dieser Bachelorarbeit verwendet

bull Was fur Probleme gab es bei der Verwendung

bull Unter welcher Lizenz steht die Bibliothek

431 Libdc1394

Libdc1394 ist eine Bibliothek fur den Zugriff auf Firewire-Kameras die den IIDCDCAMStandard9 erfullen

Die Bibliothek ist in Version 12 nur unter Linux lauffahig ab Version 2 auch unter MacOS X

Zu Beginn der Entwicklung war rdquoLibdc1394rdquoals Releasekandidat10 verfugbar und bis Ende2006 sollte die finale Version erscheinen Jedoch ist sie bis Mitte Marz 2007 noch nichtfertig gestellt worden

Die Entwicklung basiert deshalb auf dem oben erwahnten Releasekandidaten

432 CMVision

CMVision wurde entwickelt um Robotern das Farbsehen in Echtzeit zu ermoglichen

Die Bibliothek wurde an der Carnegie Mellon University in Pittsburg Pennsylvania in demCORAL Groups Color Machine Vision Project entwickelt

Die Bibliothek wird derzeit in mehreren Projekten verwendet welche sich mit Robotern undFarbsehen beschaftigen So zum Beispiel in Player11 einem Rahmenwerk zum Entwickelnund Testen von Software fur Roboter und Sensoren und in Tekkotsu12 einem Entwicklungs-Rahmenwerk fur den Sony AIBO Roboter

Bei der Verwendung der Bibliothek gab es keine groszligeren Probleme lediglich kleine An-passungen waren notig Allerdings brachte die Konfiguration der Farbgrenzwerte (33) Zu-satzaufwand mit sich der sich jedoch zugig bewaltigen lieszlig

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

9Ein von der 1394 Trade Association ( httpwww1394taorg) spezifiziertes Protokoll Nicht zuverwechseln mit Firewire Camcordern oder DV Kameras

10Ein Releasekandidat ist ein Programm in dem Zustand wie es spater auch letztlich werden soll Es werdenin dieser Phase moglichst nur noch Fehler behoben und keine neuen Funktionen zu dem Programmhinzugefugt

11httpplayerstagesourceforgenet12httpwwwcscmuedu~tekkotsu

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 50: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 42

433 GEOS

GEOS (Geometry Engine - Open Source) httpgeosrefractionsnet ist eine Bibliothekwelche grundlegende geometrische Algorithmen fur im Raum verteilte Objekte zur Verfu-gung stellt Die Bibliothek ist eine Portierung der Java Topology Suit13

GEOS wird unter anderem in der Datenbank PostgreSQL14 als Bibliothek fur die Erweite-rung PostGIS15 genutzt um geographische Objekte in Datenbanken speichern und abfragenzu konnen

In dieser Arbeit wurde die Bibliothek wahrend der Objekterkennung (242) verwendet

Die Bibliothek lieszlig sich gut und ohne Probleme einbinden Man musste nur dafur sor-ge tragen dass samtliche Objekte die von Ihr verwendet wurden auch wieder geloschtwerden

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

434 CPPUnit

rdquoCPPUnitrdquo16 ist eine C++ Portierung des JUnit17 Rahmenwerks fur Unit Tests

Die Bibliothek ist unter der GPL (Free Software Foundation 2007a) veroffentlicht

435 ConfigFile

rdquoConfigFilerdquo18 ist eine C++ Klasse von Rick Wagner um Konfigurationsdateien zu lesen

In dieser Arbeit wurde die Klasse verwendet um eine Konfigurationsdatei zu lesen

Die Bibliothek ist unter der MIT Lizenz (Massachusetts Institute of Technology) freigege-ben

13httpwwwjump-projectorgprojectphpPID=JTSampSID=OVER14httpwwwpostgresqlorg15httpwwwpostgisorg16httpsourceforgenetprojectscppunit17httpwwwjunitorg18httpwww-personalumichedu~wagnerrConfigFilehtml

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 51: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 43

436 CImg

rdquoCImgrdquo19 ist eine Bibliothek fur Bildbearbeitung und Bilddarstellung

Die Bibliothek wurde in dem Odyssee Labor (httpwww-sopinriafrodyssee) andem Inria Sophia-Antipolis Institut20 in Frankreich entwickelt und wird dort fur Vorlesungenaus dem Bereich Bildverarbeitung benutzt

In dieser Arbeit wurde die CImg-Bibliothek verwendet um sowohl das Kamerabild als auchdas Ergebnisbild darzustellen Des Weiteren wurde rdquoCImgrdquoverwendet um ein Histogrammdes Kamerabildes darzustellen und mithilfe von diesem die Anwendung zu konfigurieren

Der Vorteil bei der Verwendung dieser Bibliothek lag darin dass sie unter Mac OS X Linuxund Windows arbeitet und nur eine einzelne Header-Datei21 erfordert

CImg speichert die Bilddaten intern nicht als RGB-Tupel sondern zunachst die kompletterote die grune und dann die blaue Ebene also in einem planaren-Format

Dies fuhrt dazu dass zwischen den verschiedenen Speicherformen konvertiert werdenmuss

Die Bibliothek ist unter der CeCILL-C Lizenz (lizenzcecill 2007) freigegeben welche ahn-lich der LGPL (Free Software Foundation 2007b) ist

44 Nebenlaufigkeit

Da die Anzeige der Bilder etwa zehn mal so lange dauert22 wie die reine Verarbeitung undnur fur die visuelle Kontrolle der Ergebnisse zustandig ist wurden die Anzeige und dieVerarbeitung getrennt

Dadurch wurde es notig eine Moglichkeit zu schaffen Daten zwischen den Verarbeitungs-strangen auszutauschen Dafur wurde ein Ringpuffer mit fester Groszlige programmiert derdie Moglichkeit bietet Objekte die uberlaufen wurden weiterzugeben sodass die Objek-te weiter verwendet werden konnen Dieser Ringpuffer wurde im weiteren Verlauf auchverwendet um die Ergebnisse aus der Objekterkennung mehrfach zu verwenden

19|httpcimgsourceforgenet20httpwww-sopinriafr21Eine Header-Datei ist eine Textdatei die Deklarationen in CC++ enthalt welche wahrend der Pro-

grammerstellung eingebunden werden22Bei einer Auflosung von 640x480 Pixeln braucht die Anzeige bei 15 FPS 100 CPU die Verarbeitung

bei 30 FPS etwa 10-20 CPU Die Verarbeitung konnte also mit etwa 150-300 FPS auf einer CPUlaufen und ist somit mindestens zehn mal so schnell

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 52: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 44

45 Komponenten

In diesem Abschnitt werden die Realisierungen der einzelnen Komponenten des Systemsbeschrieben

451 Farbsegmentierung

Die Farbsegmentierung verwendete die Kamera mit einer Auflosung von 640x480 PixelnSie konnte durch Verwendung der Bibliothek CMVision (Beschreibung siehe 432) realisiertwerden (Abbildung 451 und 451 (Bruce u a 2000)) Diese Bibliothek benutzt fur dieFarbsegmentierung eine Look-up Tabelle (Miglino u a 1995) und fur das berechnen derFlachen einen union based tree mit path compression

Abbildung 41 Videobild nach der Aufnah-me

Abbildung 42 Bild nach der Farbklassifi-zierung

452 Objekterkennung

Die Aufgabe der Objekterkennung ist moglichst viele Objekte auf dem Kamerabild zuerkennen und deren Position und Ausrichtung zu bestimmen

Die Objekterkennung erhalt hierzu als Eingabe die Farbflachen welche in der Farbsegmen-tierung (451) ermittelt wurden

Das Auffinden von Objekten beschrankt sich in unserem Anwendungsfall auf zwei konkreteObjekte

bull Einen Ball der durch eine bestimmte Farbe markiert ist (hier Gelb)

bull Einen Roboter der mit vier Farbpunkten markiert ist Von den Farbpunkten ist einFarbpunkt in einer Farbe nach welcher die Objekterkennung sucht (hier Grun) Diedrei weiteren Farbpunkte werden genutzt um die Ausrichtung des Roboters zu be-stimmen (Grun ist immer vorne) und den Roboter anhand der Farbreihenfolge ein-deutig zu identifizieren (Abbildung 452)

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 53: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 45

Abbildung 43 Ein mit den Farben GrunRot Pink und Turkis mar-kierter Roboter welcher imSystem als rdquogrptrdquo identifi-ziert wird

Abbildung 44 Ein mit Gelb markierter Ball

Filterung der Farbflecken

Um die Anzahl der potentiell moglichen Farbflecken einzuschranken werden diese gefiltertDazu mussen die Farbflecken folgende Kriterien erfullen

bull Das Verhaltnis der Seitenlangen eines um die Farbflachen gezeichneten Rechtecksdarf nicht groszliger als 21 oder kleiner als 12 sein

bull Das Objekt muss mindestens einen bestimmten Prozentsatz der Flache ausfullen dieein das Objekt einfassendes Rechteck beschreibt

bull Das Objekt muss eine Mindestflache ausfullen

bull Das Objekt darf nicht groszliger als eine Maximalflache sein

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 54: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 46

Abbildung 45 Falschlich erkannte rdquoRobo-terrdquo ohne Filterung

Abbildung 46 Falschlich markierte Farb-flachen ohne Filterung

Abbildung 47 Eine Kiste welche dank der Filter nicht in Betracht gezogen wird

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 55: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 47

Finden eines Balles

Zum Finden des Balles mussen nun einfach alle Farbflecken mit der Markierungsfarbegefiltert werden und der erste gultige Fund wird als Ball angenommen23

Finden eines Roboters

Um das Auffinden eines Roboters schneller zu gestalten wird ein Quadtree benutzt DerQuadtree als Datenstruktur bietet eine effiziente Moglichkeit nah zueinander liegendeFarbflachen zu finden ohne jede Farbflache mit jeder anderen zu vergleichen Hierfur teiltder Quadtree das Bild in vier Teile und wiederholt das fur die neuen Teilbilder bis die Anzahlder Farbflachen in einem Teilbild einen bestimmten Wert unterschreitet Dadurch lasst sichdie Nachbarschaft von Farbflachen durch die Hierarchie der Teilbilder leicht herausfinden

Als Vorbereitung zum Auffinden werden alle verbleibenden Farbflachen in einen Quadtree(433) eingefugt Darauf werden die Farbflecken aus dem Quadtree gesucht die sich inder Nahe eines Markierungsflecks finden

Falls mehr als drei Flachen gefunden werden werden diese so sortiert dass die Farbfla-chen die am besten passen weiterverwendet werden Am besten passend sind hierbei dieFarbflachen die am meisten Flache aufweisen und am nachsten an der Markierungsflachesind

Programmcode 41 Wertungskriterium fur gefundene Farbflachen

areavalue = pointsize 2 lowast distance to markerpoint

Dann werden die gefundenen Flachen im Uhrzeigersinn um ihren Mittelpunkt sortiert

Als Bezeichner fur den gefundenen Roboter werden die Anfangsbuchstaben der Farbgrup-pen von den sortierten Farbflecken verwendet Fur Grun Rot Blau Rot steht zum Beispielrdquogrbrrdquo Der Roboter in Abbildung 452 ist zum Beispiel im System mit rdquorgptrdquo bezeichnetDadurch ist es leicht moglich einen neuen Roboter hinzuzufugen ohne etwas konfigurierenzu mussen Der Roboter muss lediglich seine Bezeichnung kennen

Daraufhin werden die gefundenen Punkte im Uhrzeigersinn um ihren Mittelpunkt sortiertund als Ergebnis weitergeben

23Bei zwei Ballen auf dem Spielfeld fuhrt dies dazu dass immer ein beliebiger Ball gefunden wird Da aberbei richtigen Spielen nur mit einem Ball gespielt wurde und dieser auch zuverlassig erkannt wurde istdieses Verhalten akzeptabel

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 56: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 48

Abbildung 48 Ein mit den Farben RotGrun Pink und Turkis mar-kierter Roboter

Abbildung 49 Das Ergebnisbild zu Abbil-dung 452

Abbildung 410 Ein durch die Farbe Gelbmarkierter Ball

Abbildung 411 Das Ergebnisbild mit demBall zu Abbildung 452

453 Ausgabefilter

Ballpositionsmerker

Diese erst spat aufgekommene Anforderung wird realisiert indem sich ein rdquoAusgabefilterrdquodie letzte Ballposition merkt Wird in einer beliebigen zu filternden Ergebnisliste kein Ballgefunden wird die letzte bekannte Ballposition als aktuelle Ballposition angegeben Damitdie Roboter dies auch berucksichtigen konnen wird gezahlt wie viele Bilder in Folge keinBall gefunden wurde und dem Roboter mitgeteilt

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 57: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 49

Objektverfolgung

Eigentlich war es aufgrund der Verzogerung bei anderen Systemen geplant die Positionender Objekte vorauszuberechnen Aufgrund der Qualitat der ausgewahlten Algorithmen hathat es sich jedoch aus unnotig erwiesen

Da aber noch eine Verzogerung von etwa 22 Millisekunden vorliegt lieszlige sich mit derfolgenden Vorgehensweise eine noch genauere Abbildung der tatsachlichen Positionen er-reichen

Da zu verfolgende Objekte sich durch die Verzogerung bei der Bildaufnahme der Bild-ubertragung und der Bildverarbeitung schon weiterbewegt haben konnen kann die Ob-jektverfolgung dies mit einfachen Mitteln auszugleichen versuchen Hierfur berechnet dieObjektverfolgung die vermutlich aktuellen Positionen der zu verfolgenden ObjekteDies tut sie indem sie sich die jeweils letzte Position der Objekte merkt und anhand ihrerneuen Position und der Verzogerung durch die Aufnahme die Verarbeitung und die Wei-terleitung die vermutliche Position berechnetDie Verzogerung die zu berucksichtigen ist kann aus folgender Tabelle entnommen wer-den

Aufnahmeverzogerung 3 ms

Ubertragungsverzogerung von der Kamera zu dem Computer 12 msVerarbeitungsverzogerung 5 ms

Ubertragungsverzogerung via IEEE 802154 2 ms

Gesamtverzogerung 22 ms

Die Verzogerungen fur die Aufnahme ist dem Technischen Handbuch zu der Sony DFW-V500 und DFW-VL500 Kamera (Sony Corporation 2001) entnommen Fur andere Ka-meras gelten hier andere Werte und diese mussten dem jeweiligen Handbuch entnommenwerdenDie Ubertragungszeit geht davon aus dass nur diese Kamera den Firewire-Bus benutztund dass dieser mit 400 Mbps24 lauft Da ein Bild 640x480x2 = 614400 Byte groszlig ist25 und der Bus 50 MByte je Sekunde transportiert braucht er 614400 Byte

50 MByte je Sekunde 12 ms

Die Verarbeitungszeit wurde auf der Grundlage geschatzt dass der Verarbeitungsthreadmit etwa 15 CPU-Last lauft und 30 Bilder pro Sekunde verarbeitetVon einer Sekunde benotigt er also 150 ms fur 30 Bilder also 5 ms je BildDie Ubertragungsverzogerung fur IEEE 802154 ist (Fischer 2006) entnommenDa die Zeit zwischen den einzelnen Bildern bei 1

30Sekunde liegt ist sie mit etwa 33 ms

etwas groszliger als die 22 ms der Gesamtverzogerung

24Mbps bedeutet Megabit per second25x-Auflosung y-Auflosung ein Byte Helligkeit und ein Byte mit einer der beiden Farbinformationen (U

oder V siehe 224)

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 58: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 50

Somit muss einfach (alte Position neue Position)lowast 2233 = wahrscheinliche Position be-rechnet werden um die Position zu erhalten die das Objekt bei unveranderter Geschwin-digkeit und Richtung nach der Verzogerungszeit hat Fur den Winkel muss genauso (alter

Winkel neuer Winkel)lowast 2233 = wahrscheinlicher Winkel berechnet werden

454 Objekt-Wiederverwendung

Die Ergebnisse und Ergebnislisten werden wenn sie nicht mehr benotigt werden in einemRingpuffer zuruck gespeichert um deren Wiederverwendung zu ermoglichen

455 Bild

Das Bild (347) ist fur die Speicherung von Bilddaten und deren Konvertierung in eingewunschtes Format zustandig

Fur die Speicherung hat es jeweils fur die Reprasentationsarten YUV (224) RGB (221)und CImg (436) einen Puffer

Das Bild kann seinen Inhalt in diese Reprasentationsarten konvertiert weitergeben DiePuffer hierfur werden bei Bedarf trage initialisiert (lazy initialization( (Gamma u a 1995)Seite 112) Sobald dem Bild neue Bilddaten zugewiesen werden werden samtliche konver-tierten Puffer als ungultig markiert

Uber die nebenlaufige Verwendung aus mehreren Threads mehr unter 32

46 Optimierung der Anwendung

461 Profiling

Mithilfe von Profiling26 wurde das Programm an kritischen Stellen optimiert

An Abbildung 412 erkennt man zum Beispiel dass scheinbar fast die Halfte der 617 derAusfuhrungszeit fur die Objekterkennung namlich 307 fur Abfragen an die Konfigura-tion verwendet werden Hier lassen sich die in der Konfiguration gespeicherten Variableneinfach in der Objekterkennung speichern und dadurch ist die Objekterkennung doppelt soschnell Man muss allerdings dafur Sorge tragen dass bei einer Anderung der Konfiguration

26Profiling ist eine Methode um ein Profil uber das Laufzeitverhalten eines Programms zu erstellen undzu ermitteln wo im Programm wie viel der Ausfuhrungszeit verbraucht wird

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 59: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 51

Abbildung 412 Ausfuhrungszeiten der einzelnen Teile der Objekterkennung

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 60: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 52

diese Anderungen weitergegeben werden Dies ist mit dem Observer-Pattern (Gamma u a1995) leicht realisierbar

Es hat sich auch gezeigt dass durch ein Ersetzen der CImg-Bibliothek weitere Optimierun-gen moglich sind Zum einen verbraucht die Bibliothek selbst viel CPU-Zeit zum Anzeigender Bilder zum anderen sind Konvertierungen notig um das Bild anzuzeigen (Abbildung413)Es gibt auch Moglichkeiten das Bild ohne Konvertierungen direkt anzuzueigen jedoch sinddiese von Betriebssystem zu Betriebssystem verschieden und hatten so den Wartungsauf-wand erhoht Da die Anzeige auch keinen Echtzeitanforderungen unterliegt wurde hier aufweitere Optimierungen verzichtet

Abbildung 413 CPU-Auslastungsvergleich von der Anzeige (rosa) und der Konvertierungfur die Anzeige (Rest)

462 Vermeidung von Speicherlecks

Um Speicherlecks zu beheben wurde MallokDebug benutzt MallokDebug ist Teil der XCo-de IDE und beobachtet Speicheranforderungen und -freigaben sowie verwendete Speicher-bereiche Dadurch ist MallokDebug in der Lage nicht mehr verwendete Speicherbereichezu finden sowie dem Entwickler dadurch zu helfen dass es aufzeigt wo dieser Speicherangefordert wurde

In der entwickelten Objektverfolgung gab es einige Stellen an denen der Speicher nichtwieder freigegeben wurde Dadurch dass im Verlauf der Entwicklung zudem noch die Ne-benlaufigkeit der Anzeige und der Verarbeitung eingefuhrt wurde und Objekte zwischendiesen beiden Verarbeitungsstrangen ausgetauscht werden mussten war es notig eine Ver-waltung dieser Objekte einzufuhren

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 61: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

4 Realisierung 53

Um die Ergebnisse bedenkenlos zwischen den Verarbeitungsstrangen auszutauschen wur-de der Ringbuffer verwendet Dieser wurde des Weiteren auch verwendet um die Objektesobald sie nicht mehr benotigt wurden zu einem Objektpool hinzuzufugen aus dem An-forderungen fur neue Objekte befriedigt wurden

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 62: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

5 Fazit

In diesem Kapitel werden zunachst die Ergebnisse anhand der Anforderungen gezeigt dannwerden ein paar der aufgetretenen Probleme erlautert und abschlieszligend ein Ausblick aufErweiterungsmoglichkeiten gegeben

51 Ergebnisse

Die Ergebnisse beziehen sich auf die Anforderungen welche allesamt erfullt werden konn-ten

Genauigkeit

Die Genauigkeit des Systems hangt hauptsachlich von der Auflosung der Kamera ab

Bei der verwendeten Auflosung von 640x480 Pixeln entspricht ein Pixel einer Entfernungvon etwa 27 mm auf dem Spielfeld Da es an den Randern der zu erkennenden Objektemeist einen Rand von einem Pixel gab welcher nicht richtig erkannt wurde liegt dieGenauigkeit bei etwa 4 mm

Die Genauigkeit des Winkels liegt bei etwa 5

Effizienz

Das System hat auf dem verwendeten MacBook bei einer Auflosung von 640x480 Pixelnund 30 FPS zwischen 10 und 20 einer CPU belastet Damit liegt die Verarbeitungszeitje Bild bei etwa drei bis sieben MillisekundenSomit wurde die Anforderung der weichen Echtzeit erfulltDa bei 30 Bildern die Sekunde alle 33 Millisekunden ein Bild vorliegt lassen sich nochweitere Berechnungen anschlieszligen ohne das Echtzeitverhalten zu storen

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 63: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

5 Fazit 55

Abbildung 51 CPU-Zeiten bei der Verarbeitung

Benutzbarkeit

Das System war nach dem Aufbau der Kamera und des Spielfeldes innerhalb wenigerMinuten benutzbar Es musste nur die Kamera ausgerichtet werden und gegebenenfallskleine Anpassungen an der Farbklassen vorgenommen werden (Abbildung 52)

Diese Benutzbarkeit wurde besonders dadurch verbessert dass das System wahrend derEntwicklung standig benutzt wurde (4)

Stabilitat

Das System hat die Roboter zuverlassig erkannt (Abbildung 53) Auch Anderungen in derBeleuchtung beeinflussen das System nicht sehr stark und gegebenenfalls lassen sich dieFarbklassen schnell anpassen

Portierbarkeit

Das System funktioniert unter Mac OS X und Linux Um das System unter Windowseinsatzfahig zu machen ware es nur notwendig eine Bildquelle zum Beispiel auf der Basisvon rdquoVideo for Windowsrdquo zu programmieren

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 64: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

5 Fazit 56

Abbildung 52 Anpassung der Farbklassen

Abbildung 53 Die Farberkennung lasst sich nicht so leicht storen

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 65: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

5 Fazit 57

52 Aufgetretene Probleme und ihre Losungen

Langsame Darstellung

Die Anforderung der weichen Echtzeit gilt nur fur die Weitergabe der Informationen an dieRoboterDa aber die Darstellung auf dem Bildschirm deutlich mehr CPU-Zeit brauchte als die Verar-beitung stellte sich im Verlauf der Entwicklung und des Testens heraus dass es notwendigist die Darstellung von der Verarbeitung zu trennen Deshalb wurde die Darstellung ineinen separaten Verarbeitungsstrang gelegt (Siehe hierzu auch 46)Dies bringt auch den weiteren Vorteil dass die Entwicklungs- und Testcomputer besserausgelastet sind da hierfur Doppelkern-CPUs verwendet wurden

Durch die parallele Verarbeitung kam es zu einer unterschiedlichen Auslastung beider CPU-Kerne Der Kern der mit der Verarbeitung beschaftigt war arbeitete mit der Kamerage-schwindigkeit von 30 FPS1 bei einer Auslastung zwischen 10 und 15 Der Kern der dieAnzeige ubernommen hatte war mit 15 FPS voll ausgelastet Bei der Anzeige sind definitivnoch weitere Optimierungen moglich2 die jedoch nicht umgesetzt wurden da sie nur derKontrolle des Bildes und der Farbanzeige dienen

Abbildung 54 Auslastung der CPU-Kerne von 15 und 92 bei laufendem Programm

Portierbarkeit

Die Anforderung Portierbarkeit (21) zu erreichen verursachte folgende ProblemeDie Bibliothek Libdc1394 (436) unterstutzt in Version 20 auch Mac OS X Da sich die

1Frames per second die Anzahl der Bilder die die Kamera je Sekunde liefert2Zum Beispiel lieszlige sich die Anzeige mit einer Bibliothek realisieren welche es ermoglicht ein Bild in

dem YUV-Format direkt anzeigen zu lassen

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 66: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

5 Fazit 58

Fertigstellung der Bibliothek seitens des Herstellers bisher um ca drei Monate verzoger-te und wahrend dieser Phase mehrere Anderungen an den Schnittstellen vorgenommenwurden entstand zusatzlicher Aufwand fur entsprechende Anpassungen

Die Bibliothek CImg verursachte ebenfalls Probleme Da CImg die Daten intern auf andereWeise speichert (436) als sie aus anderen Bibliotheken vorliegen wurden Konvertierungenzwischen den Formaten notwendig Weiterhin benotigt die Bibliothek relativ zur Konver-tierung viel Zeit zum Anzeigen der Bilder (Abbildung 413)

53 Ausblick

Es gibt noch viele Bereiche in denen die Objektverfolgung ausbaubar ist

So konnte

bull das Histogramm nur fur ausgewahlte Bildbereiche dargestellt werden sodass manbeispielsweise auf dem Kamerabild nur den Ball auswahlt damit man die Grenzendes Farbtons leichter bestimmen kann

bull nicht nur ein minimaler und maximaler Grenzwert eines Farbtons bestimmt wer-den sondern dieser durch eine Flache zwischen der U- und der V-Achse (bei demYUV-Farbmodell (224)) angegeben werden Es kann auch direkt ein Farbvolumenangegeben werden wodurch dann ebenfalls das RGB-Farbmodell (221) als Basisfur die Farbtonauswahl herangezogen werden kann

bull die Koordinaten relativ zur Spielflache ausgegeben werden und nicht relativ zumKamerabild3 Dies bietet die weitere Moglichkeit die Kamera so einzustellen dassdiese nur den gewunschten Bereich aufnimmt (regions of interrest) wodurch eineschnellere Reaktionszeit erreichbar ist4

bull man die Grenzwerte fur die Farberkennung automatisch an die vorherrschenden Licht-verhaltnisse anpassen5

bull die Farbsegmentierung durch Region Growing (Gonzales u Woods 2002) ersetztwerden und auch nur die Regionen in denen der Roboter erwartet wird von der

3Dies ist in dieser Arbeit nicht getan worden da die Benutzer des Systems die Koordinaten relativ zumKamerabild von Anfang an benutzten und eine Umstellung hier zu Problemen gefuhrt hatte

4Wenn auch nur eine minimal schnellere da wir ohnehin fast das ganze Bild brauchen Wir konnten beiunserer Konfiguration je 10 weniger Bildflache welche ubertragen werden mussten mindestens 1 mssparen(453)

5Der automatische Weissabgleich fuhrt zu einer Verbesserung der Farberkennung aber es lieszlige sichsicherlich noch mehr erreichen

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 67: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

5 Fazit 59

Kamera abgefragt werden Eine Implementation von Region Growing wird in (vonHundelshausen 2005) beschrieben

bull das System um einen Schiedsrichter erweitert werden der die Tore automatischzahlt und die Roboter uber den Start und das Ende des Spiels informiert sodass einautomatisches Spiel moglich wird

bull die Bibliothek zur Bildanzeige durch eine performantere ersetzt werden

bull die Bildquelle auch mit rdquoVideo for Windowsrdquorealisiert werden wodurch das Programmauch unter Windows benutzbar ware

bull eine verbesserte Konfiguration der Farbwerte programmiert werden die zum Beispielauch das Abspeichern von Farbprofilen fur verschiedene Kameras ermoglicht Bishermuss dies direkt in der Konfigurationsdatei geandert werden

54 Resumee

Die Anforderungen an die Anwendung wurden alle in vollem Umfang erfullt Die Software istgut erweiterbar und bietet der Hochschule fur Angewandte Wissenschaften Hamburg eineGrundlage fur weitere Entwicklungen Das System wurde bereits wahrend eines Projektesmit einem Abschlusswettbewerb getestet und hat sich als zuverlassig erwiesen

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 68: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Literaturverzeichnis

[Alvarado u a 2007] Alvarado Pablo Doerfler Peter Canzler Ulrich LTI-Lib http

ltilibsourceforgenet Version 2007 Abruf 18032007

[Balzerowski 2002] Balzerowski Rainer Realisierung eines Webcam basierten KameraSystems fur mobile Roboter Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2002 httpusersinformatikhaw-hamburgde~legoProjekte

Balzerowskidiplomarbeit-wwwpdf Abruf 18032007

[Beck 2000] Beck Kent extreme Programming explained Addison-Wesley 2000 ndash ISBN0ndash201ndash61641ndash6

[Brooks 1995] Brooks Frederick P The Mythical Man-Month Addison-Wesley 1995 ndash197ndash199 S ndash ISBN 0ndash201ndash83595ndash9

[Bruce u a 2000] Bruce James Balch Tucker Veloso Manuela Fast andInexpensive Color Image Segmentation for Interactive Robots Carnegie MellonUniversity Paper 2000 httpwwwcscmuedu~jbrucecmvisionpapers

CMVision-IROS2000pdf Abruf 18032007

[Costa u a 2004] Costa Paulo Moreira Antonio Marques Paulo Sousa Armando Costa Pedro Gaio Susana 5dpo Robotic Soccer Team for Year 2004 Universida-de do Porto Team Description 2004 httpimlcpekuacthskubaarchiveSkubaTDP2007pdf Abruf 18032007

[Dieckmann 2003] Dieckmann Arne Verbesserung visueller Objekterkennung fur mobileRoboter Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003httpusersinformatikhaw-hamburgde~kvldieckmanndiplompdf Ab-ruf 18032007

[Fischer 2006] Fischer Christian Entwicklung von ZigBee-Modulen fur spontaneFunknetzwerke Hochschule fur Angewandte Wissenschaften Hamburg Bachelorar-beit 2006 httpusersinformatikhaw-hamburgde~ubicomparbeiten

bachelorfischerpdf Abruf 18032007

[Fogel 2005] Fogel Karl Producing Open Source Software OReilly 2005 ndash ISBN 0ndash596ndash00759ndash0

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 69: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Literaturverzeichnis 61

[Free Software Foundation 2007a] Free Software Foundation GPL Lizenz httpwww

gnudedocumentsgpldehtml Version 2007 Abruf 18032007

[Free Software Foundation 2007b] Free Software Foundation LGPL Lizenz httpwwwgnudedocumentslgpldehtml Version 2007 Abruf 18032007

[Gamma u a 1995] Gamma Erich Helm Richard Johnson Ralph Vlissides JohnDesign Patterns Addison Wesley 1995 ndash ISBN 0ndash201ndash63361ndash2

[GIMP-Team 2007] GIMP-Team Gimp httpwwwgimporg Version 2007 Abruf18032007

[Gonzales u Woods 2002] Gonzales Rafael C Woods Richard E Digital Image Pro-cessing Prentice-Hall 2002 ndash 612ndash617 S ndash ISBN 0ndash201ndash18075ndash8

[Gottwald 2005] Gottwald Michael Webcam basiertes Kamerasystem fur autonome Robo-ter Erste Konzeption Hochschule fur Angewandte Wissenschaften Hamburg Studien-arbeit 2005 httpusersinformatikhaw-hamburgde~ubicomparbeiten

studiengottwaldpdf Abruf 18032007

[Heise Zeitschriften Verlag 2006] Heise Zeitschriften Verlag CT-Bots httpwww

heisedectftpprojektect-bot Version 2006 Abruf 18032007

[von Hundelshausen 2005] Hundelshausen Dr F Ortung eines Roboters durchVerfolgen homogener Farbregionen In it-InformationTechnology (2005) AprilNr 47(5) 258ndash265 httppagemifu-berlinde~hundelshpublications

Y2005_RobotLocalizationThroughRegionTrackingRobotLocalizationpdf

[Jack 1993] Jack Keith Video Demystified Llh Technology Pub 1993 ndash ISBN 1ndash878707ndash09ndash4

[Kohonen 2001] Kohonen Teuvo Self-Organizing Maps Springer 2001 ndash ISBN 3ndash540ndash67921ndash9

[lizenzcecill 2007] CeCILL-C Lizenz httpwwwcecillinfolicencesLicence_

CeCILL-C_V1-entxt Version 2007 Abruf 18032007

[Massachusetts Institute of Technology ] Massachusetts Institute of TechnologyMIT Lizenz httpwwwopensourceorglicensesmit-licensephp Abruf18032007

[Meisel 2006] Meisel Andreas Merkmalsextraktion httpswwwinformatik

haw-hamburgdecmsuploadsmediaRV07_01pdf Version 2006 Abruf18032007

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 70: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Literaturverzeichnis 62

[Miglino u a 1995] Miglino Orazio Lund Henrik H Nolfi Stefano Evolving MobileRobots in Simulated and Real Environments In Artificial Life 2 (1995) Nr 4 S417ndash434

[Oesterreich 2006] Oesterreich Bernd Analyse und Design mit UML 21 OldenbourgWissenschaftsverlag GmbH 2006 ndash ISBN 3ndash486ndash57926ndash6

[Pierce 2005] Pierce Eric HSV Cone httpcommonswikimediaorgwikiImageHSV_conejpg Version 2005 Abruf 18032007

[Revout 2003] Revout Ilia Design und Realisierung eines Frameworks fur Bildverarbei-tung Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit 2003 httpusersinformatikhaw-hamburgde~kvlrevoutdiplomarbeitpdf Abruf18032007

[Rickens 2005] Rickens Helge Ein Zigbee-Funkmodul zur Kommunikation unterautonomen Robotern Hochschule fur Angewandte Wissenschaften Hamburg Di-plomarbeit 2005 httpusersinformatikhaw-hamburgde~kvlrickens

Diplomarbeit_Rickenspdf Abruf 18032007

[Robocup ] Robocup httpwwwrobocupde Abruf 18032007

[Schmidt 2005] Schmidt Oliver Entwicklung und Aufbau eines Kamera-Service basiert aufrdquonetrdquo-Technologie Hochschule fur Angewandte Wissenschaften Hamburg Diplomarbeit2005 httpusersinformatikhaw-hamburgde~kvlschmidtdiplompdfAbruf 18032007

[Sony Corporation 2001] Sony Corporation Technical Manual for Sony DFW-V500 andDFW-VL500 2001

[Srisabye u a 2006] Srisabye Jirat Parkpien Napat Kongniratsiakul Poom HoonsuwanPhachachon Bowarnkitiwong Saran Archawananthakul Marut DumnernkittikulRatchai Chongkaonar Santi Ratanaparadorn Anuchit Keawpromman Chayaporn Limnirunkul Varut Tipsuwan Yodyium Skuba 2007 Team Description KasetsartUniversity Team Description 2006 httpimlcpekuacthskubaarchive

SkubaTDP2007pdf Abruf 18032007

[Tannenbaum 2003] Tannenbaum Andrew S Moderne Betriebssysteme Pearson Studium2003 ndash ISBN 3ndash8273ndash7019ndash1

[Tschumperle 2007] Tschumperle David CImg httpcimgsourceforgenetVersion 2007 Abruf 18032007

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis
Page 71: Bachelorarbeit im Fachbereich Elektrotechnik & Informatik ...users.informatik.haw-hamburg.de/~kvl/burka/bachelor.pdf · ”Roboter-Fußball ist eine Herausforderung f¨ur die Robotik

Versicherung uber Selbststandigkeit

Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Prufungsordnung nachsect24(5) ohne fremde Hilfe selbststandig verfasst und nur die angegebenen Hilfsmittel benutzthabe

Hamburg 21 Marz 2007Ort Datum Unterschrift

  • Abbildungsverzeichnis
  • 1 Einfuumlhrung
    • 11 Motivation
    • 12 Zielsetzung
    • 13 Gliederung
      • 2 Analyse
        • 21 Anforderungen
        • 22 Farbmodelle
          • 221 RGB
          • 222 CMYK
          • 223 HSV
          • 224 YUV
            • 23 Rahmenbedingungen
              • 231 Spielfeld
              • 232 Kamera
              • 233 Roboter
              • 234 Funk
              • 235 Computer
                • 24 Algorithmen
                  • 241 Farbsegmentierung
                  • 242 Objekterkennung
                  • 243 Nebenlaumlufigkeit
                    • 25 Verwandte Arbeiten
                      • 3 Design
                        • 31 Systemarchitektur
                        • 32 Programmablauf
                        • 33 Farbkonfiguration
                        • 34 Klassendiagramme
                          • 341 Uumlbersicht
                          • 342 Bildquelle
                          • 343 Farbsegmentierung
                          • 344 Objekterkennung
                          • 345 Ausgabefilter
                          • 346 Ergebnisausgabe
                          • 347 Bild
                          • 348 Ringpuffer
                            • 35 Farbmodell
                              • 4 Realisierung
                                • 41 Programmiersprache
                                • 42 Entwicklungsumgebung
                                • 43 Bibliotheken
                                  • 431 Libdc1394
                                  • 432 CMVision
                                  • 433 GEOS
                                  • 434 CPPUnit
                                  • 435 ConfigFile
                                  • 436 CImg
                                    • 44 Nebenlaumlufigkeit
                                    • 45 Komponenten
                                      • 451 Farbsegmentierung
                                      • 452 Objekterkennung
                                      • 453 Ausgabefilter
                                      • 454 Objekt-Wiederverwendung
                                      • 455 Bild
                                        • 46 Optimierung
                                          • 461 Profiling
                                          • 462 Speicherlecks
                                              • 5 Fazit
                                                • 51 Ergebnisse
                                                • 52 Problemloumlsungen
                                                • 53 Ausblick
                                                • 54 Resuumlmee
                                                  • Literaturverzeichnis