Upload
buithuy
View
220
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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