3D Object Tracking and Position Estimation with multiple USB Cameras

3D Object Tracking and Position Estimation with multiple USB Cameras Abschlussbericht Katja Gu ¨tlein, Lars Kreutz, Christian Bernst Lehrstuhl fu ¨r ...
Author: Linus Fuchs
0 downloads 2 Views 5MB Size
3D Object Tracking and Position Estimation with multiple USB Cameras Abschlussbericht Katja Gu ¨tlein, Lars Kreutz, Christian Bernst

Lehrstuhl fu ¨r STEUERUNGS- und REGELUNGSTECHNIK Technische Universit¨at Mu ¨nchen

Univ.-Prof. Dr.-Ing./Univ. Tokio Martin Buss Univ.-Prof. Dr.-Ing. Sandra Hirche

Betreuer: Prof. J¨org Conrad Beginn: 27.10.2009 Abgabe: 29.01.2010

3

INHALTSVERZEICHNIS

Inhaltsverzeichnis 1 Einleitung

5

2 Vorarbeit 2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Kameraevaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Bestimmung des Tracking-Gebietes . . . . . . . . . . . . . . . . . . .

7 7 7 8

3 Entwurf eines zu trackenden Objektes 11 3.1 Objektauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Objektaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Bildverarbeitung 4.1 Einf¨ uhrung und Aufgabenstellung an die Bildverarbeitung 4.2 Verwendete Umgebung und Libraries . . . . . . . . . . . . 4.3 Programmrelevante Fragestellungen . . . . . . . . . . . . . 4.4 Wichtige Funktionen zur Programmausf¨ uhrung . . . . . . 4.5 Programmmeilensteine und deren Evaluation . . . . . . . . 4.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Positionsbestimmung 5.1 Definition neuronales Netz . . . . . . . . . . . . . 5.1.1 Feedforward-Netz . . . . . . . . . . . . . . 5.1.2 Lernen durch Fehler-R¨ uckw¨artsausbreitung 5.2 Erstellung von Trainingsdaten . . . . . . . . . . . 5.3 Implementierung in C . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

15 15 16 16 18 20 24

. . . . .

25 25 26 28 29 31

6 Ausgabe 35 6.1 Protokolldatei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.2 Grafische Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3 Socket-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7 Zusammenfassung

37

Abbildungsverzeichnis

39

4 Literaturverzeichnis

INHALTSVERZEICHNIS

41

5

Kapitel 1 Einleitung Kommerziell erwerbliche Trackingsysteme sind sehr kostspielig, da sie eine hohe Aufl¨osung haben und einen großen Funktionsumfang bieten. Au¨serdem fehlt ihnen die Mobilit¨at, da sie einen komplexen Aufbau haben. Da die meisten wissenschaftlichen Experimente keien hohe Aufl¨osung ben¨otigen, aber ein einfacher und schneller Aufbau große Vorteile bietet, wollen wir ein vereinfachtes Trackingsystem mittels USB Kameras entwickeln. Somit gliedert sich unser Projekt in die Arbeitsschritte ein zu trackendes Objekt zu entwickeln, dieses mittels herk¨omlichen USB Kameras zu erkennen, einen Rechenalgorithmus zur Positionsbestimmung zu implementieren und die ermittelte Position auszugeben. Dabei gibt es f¨ ur jeden dieser Arbeitsschritte bestimmte Anforderungen. Das zu trackende Objekt sollte eindeutig und fehlerfrei von den USB Kameras erkannt werden, aber auch nicht zu komplex in der Herstellung und Montage sein. Die Bildverarbeitung sollte m¨oglichst schnell, hochaufl¨osend und genau arbeiten. Daf¨ ur ist die synchrone Zusammenarbeit beider Kameras von N¨oten, was wiederum bestimmte Anspr¨ uche an die zu verwendende Hardware stellt. Die Anforderungen an den zu entwickelnden Rechenalgorithmus ergeben sich daraus, dass er effizient arbeiten muss. Das heißt der Rechenalgorithmus sollte eine m¨oglichst exakte Position des Objekts liefern, daf¨ ur aber geringe Rechenzeit ben¨otigen. Die errechnete Position des Objekts soll abschließend in einer Protokolldatei gespeichert werden. Desweiteren w¨are eine grafische Ausgabe der Positionen und eine anbindung an andere Programme w¨ unschenswert.

6

KAPITEL 1. EINLEITUNG

7

Kapitel 2 Vorarbeit 2.1

Hardware

Die Grundlage unseres System bildet die Hardware, bestehend aus einem Computer und zwei USB Kameras. Auf Grund der Anforderung, die Bildverarbeitung so schnell wie m¨oglich zu machen, spielt die eingesetzte Hardware eine große Rolle. Aus diesem Grund kommt ein PC mit Linux Betriebssystem zum Einsatz. Dies hat den Vorteil, dass sich unter Linux die ben¨otigten “C Libraries“ besser einbinden lassen und sich eine h¨ohere Performanz erzielen l¨asst. Da am Anfang Probleme mit dem bestehenden Betriebssystem auftraten, wurde eine lokale Version des Betriebssystems auf dem PC installiert. Dies erm¨oglichte anschließend, zwei Kameras an einem PC gleichzeit zu betreiben. Außerdem ist es nicht n¨otig Treiber f¨ ur die Kameras zu installieren, da die universal einsetzbaren “USB Video Class (UVC)“ Treiber benutzt werden. Dies hat den Vorteil, dass das System nicht von den benutzen Kameras abh¨angig ist und sich jede beliebige Kamera einsetzen l¨asst.

2.2

Kameraevaluierung

Die Auswahl der Kameras, die das Objekt tracken, ist von großer Bedeutung, denn die Kameras liefern die grundlegenden Daten, auf denen das gesamte Tracking Projekt beruht. Deswegen wurde einige Zeit darauf verwendet unterschiedliche Kameras zu evaluieren und die Vor- und Nachteile der verschiedenen Modelle herauszuarbeiten. Es wurden die folgenden drei Kameramodelle betrachtet. Aufl¨ osung Name Creative Live! Cam Socialize HD Webcam 800x600 Philips SPC2050NC 800x600 eCom Webcam 5,0 MP 800x600

FPS Bildwinkel 30 60° 20 70° 15 50°

8

KAPITEL 2. VORARBEIT

Die Philipskamera hat einen sehr guten Bildwinkel und w¨ urde so einen großen Teil des zu trackenden Raumes abdecken. Die Bildwiederholungsrate dieser Kamera bewegt sich im mittleren Bereich und w¨ urde auch annehmbare Daten liefern. Aber die Philipskamera hat einen Autofukus hardwareseitig integriert, der nicht zu deaktivieren war. Dieser Umstand macht die USB Kamera f¨ ur unsere Zwecke unbrauchbar, denn durch das automatische Fokussieren w¨ urde sich das Bild laufend ¨andern. Die Creativekamera hat einen festen Fokus, durch den das Bild kontinuierlich gleich bleibt. Sie hat einen relativ guten Bildwinkel von 60°. Mit diesem Winkel kann noch ein annehmbarer Teil des Raumes abgedeckt werden. Außerdem hat diese Kamera eine sehr gute Bildwiederholungsrate von 30fps. Die eComkamera hat eine etwas geringere Aufl¨osung und einen relativ geringen Bildwinkel von 50°. Ihre Bildwiederholungsrate von 15fps ist im Vergleich zu den anderen Kameras schlechter. Aber sie hat einen neuen Chip integriert, der das Farbrauschen mindert. Das Trackingsystem ermittelt u ¨ber die Farbwerte des Objekts die Pixelposition in den Frames, die die Kameras liefern. Da sich das System nicht in einem idealen Raum befindet, der gr¨oßtenteil reinweiß ist, sondern viele Gegenst¨ande beinhaltet, hat man sehr starkes Farbrauschen. Dieses Rauschen verf¨alscht die Position des Mittelpunktes des Objektes. Dieser Mittelpunkt ist aber die Grundlage zur Koordinatenberechnung. Deshalb soll er so genau wie m¨oglich sein. Aus diesem Grund wird die eComkamera verwendet, die das st¨orende Farbrauschen vermindert. Dadurch verliert man zwar etwas an der Aufl¨osung, hat aber einen exakteren Pixelwert des Objekts.

2.3

Bestimmung des Tracking-Gebietes

Die Wahl des Tracking-Gebietes wurde stark eingeschr¨ankt, da f¨ ur dieses Projekt eine Fl¨ache im CoTeSys (Cognition for Technical Systems) gew¨ahlt werden sollte. Die Entscheidung fiel auf eine freie Fl¨ache im vierten Stock des Geb¨audes. Wie im voherigen Kapitel erl¨autert, hat die verwendete eComkamera einen Blickwinkel von 50°. Dadurch ist der Raum, den beide Kameras abdecken stark eingeschr¨ankt. Hier wurde ein Rechteck mit folgenden Abmessungen verwirklicht

x-Wert: y-Wert: z-Wert:

333cm 215cm 43cm

In Abbildung (2.1) ist dieses Gebiet dargestellt. Um diese Abmessungen zu gew¨ahrleisten m¨ ussen die Kameras in einem großen Abstand zum Tracking-Gebiet befestigt werden. Die erste Kamera hat in negativer x-Richtung einen Abstand von 301cm zum Nullpunkt und in positiver y-Richtung

2.3. BESTIMMUNG DES TRACKING-GEBIETES

9

Abbildung 2.1: Tracking-Gebiet 91cm zum Nullpunkt. Sie ist in einer H¨ohe von 257 cm angebracht. Die zweite Kamera hat einen Abstand von 105cm in positiver x-Richtung zum Nullpunkt und 787cm in positiver y-Richtung. Sie ist in einer H¨ohe von 228cm angebracht.

10

KAPITEL 2. VORARBEIT

11

Kapitel 3 Entwurf eines zu trackenden Objektes Das Trackingsystem soll sp¨ater einen K¨orper erkennen und dessen Position im Raum verfolgen. Um den K¨orper zu erkennen muss ein Objekt entwickelt und auf dem K¨orper befestigt werden. Das Objekt muss von den Kameras eindeutig erkannt werden, um so die richtigen Pixelwerten an den Rechenalgorithmus zu u ¨bergeben.

3.1

Objektauswahl

Als erstes muss die Form des zu trackenden Objektes bestimmt werden. Hier wird eine Kugel gew¨ahlt, da diese aus allen Perspektiven zur Kamera die gleichen Abmessungen hat. Das erleichtert sp¨ater die Bildverarbeitung, da das Objekt in allen Ausrichtungen die gleiche Form hat und somit nicht f¨ ur jede Perspektive ein eigener Sonderfall beachtet werden muss. Daraufhin muss die Farbe der Kugel definiert werden. Am besten w¨aren einzigartige Farben, die nicht h¨aufiger in normalen B¨ uror¨aumen vorkommen. Als erster Ansatz werden Neonfarben gew¨ahlt. Diese werden mit Hilfe von einigen Testbildern evaluiert. Wie in Abbildung (3.1) erkennbar, haben alle farben a¨hnliche RGB-Werte. Sie unterscheiden sich zwar im Einzelvergleich ein wenig, haben aber keine signifikant hohen oder niedrigen Werte. Diese Farbwerte kommen in der Trackingumgebung zu oft vor, sodass das Objekt nicht fehlerfrei erkannt werden kann. Außerdem wurden die B¨alle per Hand bemalt und haben dadurch einen nicht gleichm¨aßigen Farbverlauf. Somit m¨ usste auf sehr große Farbintervalle getestet werden. Deshalb wurde als n¨achstes ein gekaufter orangefarbener Tischtennisball verwendet, dessen gesamte Fl¨ache die gleiche Farbe hat. Um diese Farbwerte einwandfrei zu erkennen, werden in der Bildverarbeitung nicht die RGB- sondern die HSV-Werte verwendet. Bei den HSV-Farben werden die Farbwerte, die S¨attigung und die Helligkeit eines Pixels bestimmt. Dadurch k¨onnen Farbwerte besser und eindeutiger erkannt werden, weil man die Helligkeit und S¨attigung herausfiltert, womit die Wahrschein-

12

KAPITEL 3. ENTWURF EINES ZU TRACKENDEN OBJEKTES

Abbildung 3.1: Testbild der neonfarbenen B¨alle

lichkeit sinkt, dass ein falsches Objekt getrackt wird. Damit sich der Ball noch mehr von seiner Umgebung abhebt wird er von innen beleuchtet. Daf¨ ur wird der Ball aufgeschnitten und im Inneren eine weiße 360°LED befestigt. Somit leuchtet der Ball in allen Richtungen. Dadurch entstehen wieder keine Probleme wenn sich die Orientierung des Balles ¨andert und somit die Kamera aus einem anderen Blickwinkel das Objekt erfasst. In Abbildung (3.2) sind alle Pixel die die Farbwerte des erleuchteten Balles aufweisen schwarz eingef¨arbt. Man kann deutlich erkennen, dass einige Dinge in der Umgebung die selben Farbwerte aufweisen und somit die Position des Objektes verf¨alscht wird.

Das Objekt sollte außerdem gr¨oßer als ein Tischtennisball sein, da die Kameras etwas entfernt von dem zu trackenden Raum stehen, weil der Bildwinkel der Kameras nur 50 betr¨agt und somit der abgedeckte Raum sehr klein wird, wenn die Kameras n¨aher angebracht werden. Durch die Entfernung der Kameras besteht ein Tischtennisbal nur noch aus sehr wenigen Pixel und ist so viel anf¨alliger f¨ ur das Farbrauschen. Deshalb wurde ein roter Ball mit einem Durchmesser von 20cm gew¨ahlt. In Abbildung (3.3) werden die passenden Pixel weiß eingef¨arbt und der Mittelwert dieser Pixel durch ein Kreuz dargestellt. Hier ist deutlich erkennbar, dass das Objekt sehr gut erkannt wird.

13

3.1. OBJEKTAUSWAHL

Abbildung 3.2: HSV-Bild des erleuchtenden Balles

Abbildung 3.3: HSV-Bild des roten Balles

14

3.2

KAPITEL 3. ENTWURF EINES ZU TRACKENDEN OBJEKTES

Objektaufbau

Im entwickelten Trackingsystem wird nicht der beleuchtete Ball verwendet. Da dieser aber einige Zeit der Evaluation in Anspruch genommen hat und die Beleuchtung selbst entwickelt wurde, wird im Folgenden der Aufbau n¨aher erl¨autert. Um den Ball zu beleuchten wird eine LED mit folgenden technischen Daten benutzt Weiß 360° typ. 80mA typ. 3.4V 8mm

Farbe: Abstrahlwinkel: IF : UF : Geh¨ause:

Um diese LED in Betrieb zu nehmen, wird sie in einer einfachen Schaltung verarbeitet. Diese besteht aus einem Vorwiderstand von 33Ω, der mit der LED in Reihe geschalten ist. Um den hohen Betriebsstrom (IF ) vom 80 mA aufzubringen, wird die Schaltung mit einer Gleichspannungsquelle von 6 V betrieben. Diese wird mit vier AA Mignonbatterien realisiert. Die gr¨oße des Widerstands ließ sich dabei durch das Ohmsche Gesetz ermitteln: R=

U I

(3.1)

Die LED-Schaltung wird mit dem in Abbildung (3.4) skizzierten Schaltplan realisiert.

Abbildung 3.4: Schaltplan der LED Schaltung

15

Kapitel 4 Bildverarbeitung 4.1

Einfu ¨ hrung und Aufgabenstellung an die Bildverarbeitung

Da dieses Projekt von Grund auf eine Neuentwicklung darstellt und bei den Gruppenteilnehmern wenige bis gar keine Grundkenntnisse vorhanden waren musste umfangreiches Einarbeiten und Recherchieren einer Projektrealisierung voraus gehen. Zu Beginn erfolgte eine Analyse der Projektanforderungen an die Bildverarbeitung. Folgende Projektanforderungen waren an die Bildverarbeitung zu stellen: ˆ Tracking eines Objektes in Echtzeit mit zwei handels¨ ublichen USB Webcams ˆ Einlesen jedes einzelnen Kameraframes zur Berechnung ˆ Ermitteln der genauen Position des getrackten Objekts in jedem einzelnen Frame ˆ Errechnung des Objektmittelpunktes und Weitergabe dieses Wertes an das neuronale Netz

Entsprechend der Aufgabenstellung stellte sich die Frage, wie die Objekterkennung zu bew¨altigen ist. Um sich dieser Frage anzunehmen erfolgte eine entsprechende Internetrecherche mit folgenden Kriterien:

1. Schneller und problemloser Zugriff auf die Kameradaten durch einen selbst geschaffenen Programmcode. Dabei wurde nach bekannten L¨osungswegen gesucht. 2. Entsprechend der gew¨ahlten L¨osungswege aus Punkt 1 muß dann die entsprechende Wahl der Programmiersprache und des Betriebßystems erfolgen.

16

KAPITEL 4. BILDVERARBEITUNG

3. Kombinierter Einsatz der Kameraanbindung und der Objekterkennung. 4. Finanziell g¨ unstige Realisierung (R¨ uckgriff auf Open Source Produkten) Die entsprechende Internetrecherche ergab, das eine speziell von Intel entwickelte Open Source Programmierbibliothek zur Bildeinbindung und Bilderkennung existiert, die von Willo Garage gepflegt wird. Diese Bibliothek mit dem Namen OpenCV l¨aßt sich in die Programmiersprachen C, C++ und Phyton einbinden. Da bei mir keine Kenntniße in in C++ und Phyton vorhanden waren, wurde hier entsprechend C als Programmiersprache in Kombination mit der OpenCV Libary gew¨ahlt.

4.2

Verwendete Umgebung und Libraries

OpenCV ist eine quelloffene Programmbibliothek unter BSD-Lizenz. Sie enth¨alt Algorithmen f¨ ur die Bildverarbeitung und maschinelles Sehen. Das CV im Namen steht f¨ ur “Computer Vision“. Im September 2006 wurde die Version 1.0 herausgegeben, Ende September 2009 folgte nach l¨angerer Pause die Version 2.0.0, welche in diesem Projekt auch Verwendung findet. Die St¨arke von OpenCV liegt in ihrer Geschwindigkeit und in der großen Menge der Algorithmen aus neusten Forschungsergebnissen. Die Bibliothek umfasst unter anderem Algorithmen f¨ ur Gesichtsdetektion, 3D-Funktionalit¨at, Haar-Klassifikatoren, verschiedene sehr schnelle Filter (Sobel, Canny, Gauß) und Funktionen f¨ ur die Kamerakalibrierung. Die Wahl von Linux erfolgte ebenso aus mehreren Gr¨ unden. Zum einen war hier das Ansprechen unterschiedlicher Webcams problemlos ohne Treiber und Herstellersoftware m¨oglich, da entsprechend notwendige Hardwareschnittstellen bereits im ne¨ um LINUX Kernel enthalten waren. Des weitern waren entsprechende kostenlose Compiler und Entwicklungsumgebungen bereits vorhanden und konnten relativ einfach verwendet werden. Als letzten entscheidenden Punkt wurde die Stabilit¨at des Betriebsystems gesehen.

4.3

Programmrelevante Fragestellungen

Als entscheidende programmrelevante Fragestellung ist die Art des Bildes, deren Farbeigenschaften und der “Datenaufbau“ wichtig. Hierzu ist es wichtig zu wissen, wie ein Bild im allgemeinen aufgebaut ist und welche Attribute es hat. Die Ausgangsbilder unserer Webcams waren mit RGB Farben aufgebaut, mit drei getrennten Farbkan¨alen und der jeweiligen Farbtiefe von 8 Bit. Den Aufbau dieses Farbarreys kann man sich wie in 4.1 dargestellt vorstellen. Erst wird ein Rotwert der Farbtiefe 8 Bit [0 . . 255] als Integer abgelegt, danach der zweite Kanal (Gelb)

4.3. PROGRAMMRELEVANTE FRAGESTELLUNGEN

17

und der letztlich der dritte Kanal (Blau). Alle Kan¨ale zusammen bilden einen Pixel.

Abbildung 4.1: Aufbau eines Frames in RGB-Farben

Das Problem an einer RGB Darstellung ist, dass die drei Farbkan¨ale in ihren Werten entsprechend der Helligkeit und S¨attigung unterschiedlich schwanken, was das genaue Erkennen einer konkreten Farbe fast unm¨oglich macht. Aufgrund dieser Tatsache mussten wir einen entsprechenden Farbraum w¨ahlen der eine genaue Erkennung einer Farbe erm¨oglicht. Die Wahl fiel hierbei auf den HSV Farbraum, in den man mit OpenCV auch leicht ein RGB Bild u uhren konnte. ¨berf¨ Der HSV-Farbraum ist in seinem Datenaufbau ¨ahnlich dem RGB-Farbraum aufgebaut, mit dem entscheidenden Unterschied, dass sich die drei Kan¨ale hier nicht in 3 Farben aufteilen sondern in den Farbton H, die S¨attigung S und die Dunkelstufe V. In 4.2 ist der Aufbau eines Bildes in HSV-Farben verdeutlicht.

Abbildung 4.2: Aufbau eines Frames in HSV-Farben

Nachdem hier jede Farbe unabh¨angig von deren S¨attigung und Beleuchtung betrachtet werden kann bleibt ihr Farbwert konstant und kann im ganzen Bild identifiziert werden. Das diese in der praktischen Anwendung auf Grund des relativ großen Pixelrauschens der einfachen Webcams trotzdem in einem bestimmten Bereich schwanken l¨asst sich nicht vermeiden. Erw¨ahnenswert ist noch das es sich beim Farbton um eine Kreis gem¨aß 4.3 handelt, was heißt, dass die Werte 255 und 0 nahezu identisch sind.

18

KAPITEL 4. BILDVERARBEITUNG

Abbildung 4.3: HSV-Farbraum

4.4

Wichtige Funktionen zur Programmausfu ¨ hrung

F¨ ur die Programmausf¨ uhrung war es notwendig auf einige wichtige Funktionen von OpenCV zur¨ uckzugreifen. Diese werden im Folgenden kurz erl¨autert, da die Auseinandersetzung mit ihnen einen großen Teil des Projektes ausmacht.

IplImage* img; Der Type IplImage* erzeugt einen Imagepointer mit dem es m¨oglich ist auf Bilddaten zuzugreifen die im Speicher hinterlegt sind. cvNamedWindow ( “Webcam 1“, CV WINDOW AUTOSIZE ); Mit dieser Funktion l¨asst sich auf einfachem Weg ein Fenster erzeugen. Das erste Argument ist der Name des Fensters, das zweite die Gr¨oße. cvResizeWindow( “Befehle“, 435, 137); Mit diesem Befehl kann man direkt die Gr¨oße des Fensters in Pixel ¨andern. Hier wird das Fenster “Befehle“ auf eine Gr¨oße von 435 x 137 festgelegt. cvMoveWindow( “Befehle“, 0, 600); Mit diesem Befehl ist es m¨oglich ein Fenster entsprechend zu positionieren. Hier wird der linke obere Punkt des Fensters beim x Wert 0 und beim y-Wert 600 gesetzt.

¨ 4.4. WICHTIGE FUNKTIONEN ZUR PROGRAMMAUSFUHRUNG

19

cvShowImage( “Befehle“, img ); Mit diesem Befehl ist es m¨oglich im Fenster “Befehle“ die Bilddaten, die an der Stelle des Imagepointers img hinterlegt sind, anzuzeigen. CvCapture* capture10 = cvCaptureFromCAM(0); Mit diesem wichtigem Befehl ist es m¨oglich einen Viedeostream von einer Kamera zu holen und deren Position im Speicher u ¨ber einen Capturepointer anzusprechen. cvReleaseCapture(&capture10); Mit dieser Funktion kann man den Wert des Capturepointers zur¨ ucksetzen. img2 = cvQu ¨ ryFrame( capture10 ); Hierbei handelt es sich ebenfalls um eine f¨ ur unsere Aufgaben unersetzliche Funktion. Sie holt aus dem bei capture10 hinterlegten Videostream nur das akt¨ ulle frame und macht es u ur weitere Operationen zug¨anglich. ¨ber den img2 pointer f¨ channels = img2-¿nChannels; Der Pointer vom Type Ipl *img2 enth¨alt weiterhin nicht nur die Position der Bilddaten sondern es werden auch eine Reihe von wichtigen Bildeigenschaften des Bildes mit abgespeichert. Hier als Beispiel die Anzahl der Farbkan¨ale. Insgesammt k¨onnen 22 Eigenschaften abgerufen werden, z.B. auch die Aufl¨osung, das Farbmodell oder die Kanalreinfolge. Diese kann ich einfach abrufen und ausgeben. hsv2 = cvCreateImage( cvGetSize(img2), 8, 3 ); Dieser Funktionsaufruf erzeugt ein ne¨ us Bild was an der Stelle hsv2 abgelegt wird. Das erste Argument legt die Gr¨oße des Bildes fest, das zweite die Farbtiefe pro Element und das dritte die Anzahl der Farbkan¨ale. cvCvtColor( img2, hsv2, CV RGB2HSV ); Mit diesem Funktionsaufruf wird auf einfache Weise ein gegebenes RGB Bild (img2) in ein HSV Bild umgewandelt und an der Stell img2 abgelegt. cvSmooth ( hsv2 , hsv2 norm , CV GAUßIAN , 13 , 13, 0, 0); Mit diesem Funktionsaufruf ist es m¨oglich, ein gegebenes Bild mit einen Gaußfilter zu normalisieren und entsprechend an der Stelle hsv2 norm abzulegen. uchar* ptr = (uchar*) (hsv2 norm->imageData + i * hsv2 norm->widthStep); Diese ebenso sehr wichtige Zeiger erzeugt einen Pointer ptr der entsprechend unserer Bilddaten durch die als Array angelegten Daten laufen kann, so daß auf einzelne Farbpixelwerte zugegriffen werden kann.

20

KAPITEL 4. BILDVERARBEITUNG

cvRectangle(hsv2 norm,cvPoint((int)x1+50,(int)y1-50),cvPoint((int)x1-50,(int)y1+50),CV Diese Funktion malt ein Rechteck in das Bild, welches an der Stelle hsv2 norm hinterlegt ist. Hierbei muss man als zweites und drittes Argument jeweils zwei gegen¨ uberliegende Punkte mit deren entsprechenden x und y Koordinaten angeben und in dem vierten und f¨ unften Argument die Farbe und die Dicke der Linie angeben.

cvLine(hsv2 norm,cvPoint((int)x1,(int)y1+10),cvPoint((int)x1,(int)y1-10),CV RGB(255,25 Hier wird analog eine Linie zwischen zwei x Koordinaten mit der Farbe weiß und der dicke 2 gemalt. cvDestroyWindow( “Befehle“ ); Diese Funktion schließt ein Fenster.

4.5

Programmmeilensteine und deren Evaluation

Die meisten Programme in der Entwicklungsphase wurden mit der Bezeichnung getvid und einer laufenden Nummer versehen, z.B. getvid4. Jedes Programm baute auf dem vorherigem auf und entstand wenn Ver¨anderungen oder Erg¨anzungen erfolgten. Erg¨anzend gab es zwei Programme mit dem Namen pointertest und pointertest2. Letztendlich existierte noch das Finale Programm ObjectTracking. Das erste Programm getvid1 hatte den Zweck das Ansprechen von zwei Webcams u ¨ber einen C Code bei Verwendung von OpenCV zu testen. Hierzu konnte auf die oben beschriebenen relativ einfache Funktionen, die ich im weitern CV Calls (CVC) nenne, zur¨ uckgegriffen werden. u ¨ber einen programminternen CVC Capturepointer war es m¨oglich den Videostream beider Kameras abzurufen. Zwei weitere CVC erzeugten entsprechende Fenster zur Ausgabe und zeigten das Bild der Kameras entsprechend an. Insgesammt waren daf¨ ur nur 24 Codezeilen n¨otig, wobei hierbei auch Ressourcenabfragen enthalten waren. Wenn also eine Kamera nicht angeschlossen war, so wurde eine entsprechende Fehlermeldung ausgegeben. Damit war der erste und einfachste Meilenstein, paralleler Kamerazugriff und Bildausgabe erreicht. Dieser erfolgte noch mit zwei unterschiedlichen Webcams, da die Auswahl der Kameras noch nicht abgeschlossen war. Problematisch zeigte sich hier jedoch, dass die Ausgabefenster nicht geordnet angezeigt wurden sondern an einer festen Position u ¨bereinander. Um den Fehler des ersten Programms auszugleichen wurde in getvid2 entsprechend u ¨ber einen CVC eine Fensterpositionierung vorgenommen. Dies war auch mit entsprechend 2 Codzeilen problemlos m¨oglich. Des weiteren wurde zur weiteren Funktionalit¨at ein drittes Fenster mit entsprechend m¨oglichen Tastenbefehlen angezeigt. Somit konnte der Nutzer bei Programmaufruf sofort beide Webcams ˆaeinsehenˆa und das Programm u ¨ber die Taste Esc wieder beenden. In den Programmen getvid3 und getvid4 wurde ein weiterer Meilenstein erreicht.

4.5. PROGRAMMMEILENSTEINE UND DEREN EVALUATION

21

Hier wurde zum ersten mal von einer Webcam einzelne Frames geholt und wieder ausgegeben. Mit der Funktionalit¨at einzelne Frames zu erhalten wurde die n¨otige Grundlage zur Farb- und Objekterkennung gelegt. Im n¨achsten Schritt (getvid5) wurde diese Funktionalit¨at auf zwei Webcams erweitert. Nachdem die Voraussetzung zum Zugriff auf einzelne Bilddaten pro Frame gelegt ¨ waren wurde zun¨achst Uberlegungen angestellt wie man das Einzelbild entsprechend durchsuchen k¨onnte. Da das einer der entscheidenden Schl¨ usselpunkte ist wird im folgenden darauf genauer eingegangen. Der Code stellte sich wie folgt dar: { for (i=0; i hsv2->height; i++){ uchar* ptr = (uchar*) (hsv2->imageData + i * hsv2->widthStep); for (j=0; jwidth; j++){ if ((ptr[3*j] >= 108) && (ptr[3*j] widthStep);“} (siehe 4.) innerhalb des Bildes jedes Pixel durchliefen. Die Variable i stellt dabei die Zeilen dar und die Variable j die Spalten. Mit diesen Beiden Laufvariablen war es m¨oglich, jeden Pixel gem¨aß 4.1 oder 4.2 zu lokalisieren. Mit dem Pointerzugriff ptr[3*j] konnte man dann auf den ersten Kanal (Rot in RGB oder Farbwert H in HSV) zugreifen, diesen vergleichen oder ¨andern. Entsprechend war es auch u ¨ber ptr[3*j+1] m¨oglich auf den zweiten Kanal zuzugreifen. Mit diesen Code wurde zun¨achst in getvid6 die zwei Webcambilder im RGB Bereich invertiert und sp¨ater in pointertest und pointertest2 im HSV Bereich umfangreich getestet. In den letzten beiden erfolgte auch ein “einf¨arben“ gefundener Pixel mit der Farbe Weiß. Diese Idee die urspr¨ unglich nur zum testen diente wurde auch ins Endprogramm u ¨bernommen. Nachdem in getvid7 die HSV Umwandlung implementiert wurde ging es nun darum, im n¨achsten Programm(getvid8 und 9) gefunden Pixel in eine Protokolldatei auszugeben. Nachdem bis zu diesem Zeitpunkt zwei verschieden Webcams verwendet wurden ging es nun darum den Code mit zwei gleichen Webcams zu testen (getvid10). Dieser Test scheiterte zun¨achst mit der LINUX Fehlermeldung, aˆno space left on deviceˆa. Nach umfangreichen Recherchen stellte sich heraus das es nicht m¨oglich war an ein und dem selben USB Hub zwei gleiche Kameras parallel zu betreiben. Dementsprechend wurde eine zweite PCI USB Karte beschafft und integriert, die das Problem l¨oste. Nun wurde im n¨achsten Programm(getvid11) zun¨achst in allen Kan¨alen gesucht bevor im Programm getvid12 nur noch der gew¨ unschte Farbwert H untersucht wurde und ein Mittelpunkt u ¨ber alle gefunden Pinxel je Zeile und Spalte ermittelt wurde.

22

KAPITEL 4. BILDVERARBEITUNG

Dieser war unbedingt notwendig um den Mittelpunkt des zu trackenden Objektes zu ermitteln. Diese Zweidimensionalen Pixelkoordinaten wurden sp¨ater unbedingt f¨ ur das neuronale Netz ben¨otigt. Es sei hier noch erw¨ahnt, dass nat¨ urlich jedes gefundene Pixel außerhalb des Trackingobjektes den Mittelpunkt verf¨alschte. Nach dem dies evaluiert war, wurde ein gr¨oßeres Objekt mit einer markanteren Farbe gew¨ahlt. Einen besonderen Stellenwert kommt letztlich den letzten beiden Programmen getvid13 und 14 zu. In ihnen wurde ein kleiner Bereich im Bild zur Farbermittlung eingef¨ ugt. Hielt man das zu trackende Objekt hinter diesen Bereich so erhielt man als Konsohlenausgabe die HSV Werte des entsprechenden Objektes. Mit dieser Untersuchungsmethode war es m¨oglich, den Farbwert verschiedener Objekte zu untersuchen und das fertige Programm entsprechend einzustellen.

Abbildung 4.4: Testprogramm zur Farbauswahl Erg¨anzend dazu wurde im letzten Testprogramm eine Fadenkreuz mit Umgebungsrechteck in das Bild gemalt um die Position des gefundenen Mittelpunktes sichtbar zu machen. Des weiteren wurde ein Gaußfilter zur Normalisierung getestet, jedoch wurde bei diesem keine signifikante Verbesserung des Trackingergebnisses erreicht, weswegen er keine Verwendung im endg¨ ultigen Programm fand (vgl. Abbildung 4.5).

4.5. PROGRAMMMEILENSTEINE UND DEREN EVALUATION

23

Die Ergebnisse der letzten beiden Testprogramme f¨ uhrte auch dazu, daß ein weiteres Mal unsere Kameras austauschten. Das starke Pixelrauschen der hochaufl¨osenden Kameras sorgten f¨ ur eine solche Verschlechterung des Trackings das wir auf die einfacheren Kameras zur¨ uckgriffen die unser Objekt relativ zielgenau fanden.

Abbildung 4.5: Testbild mit Gaußfilter Als letzter Schritt wurden die aus den diversen Testprogrammen gewonnen Erkenntnisse in das Hauptprogramm implementiert. Danach verf¨ ugte das endg¨ ultige Programm u ¨ber folgende Funktionalit¨at: ˆ Suche nach dem f¨ ur unseres Trackingobjekt markanten Farbwert in jedem Frame von zwei Webcams in Echtzeit ˆ gefundene Farbwerte weiß einf¨ arben ˆ den Mittelpunkt des Objektes ermitteln und diesen mit Fadenkreuz und Umgebungsrechteck kenntlich machen ˆ die Mittelpunktkoordinaten x1, y1 der ersten und x2, y2 der zweiten Kamera an das neuronale Netzwerk u ¨bergeben ˆ Ausgabe der akt¨ ullen Bilder beider Kameras zur Verifizierung

Wie man hier erkennen kann erf¨ ullt dieser Code die unter Punkt 1 geforderten Anforderungen. Entsprechend sah das Programm dann wie in Abbildung (4.6) dargestellt aus.

24

KAPITEL 4. BILDVERARBEITUNG

Abbildung 4.6: Finale Version der Objekterkennung

4.6

Fazit

Abschliessend l¨aßt sich zusammenfassen, dass das Tracking eines Objektes im HSV aˆ Bildraum unter bestimmten Umst¨anden sehr genau m¨oglich ist. Zum einen verf¨alschen hochaufl¨osende Webcams durch ihr Pixelrauschen das Tracking zum anderen ist mit niedrigaufl¨osenden Webcams, wie der letztendlich verwendeten, der Blickwickel und die Genauigkeit (weniger Pixel) sehr eingeschr¨ankt. Dieser Nachteil wiederum ist jedoch akzeptabler als ein extrem springendes ungenaus Tracking. Das Pixelrauschen ist ein unkalkulierbares Risiko was bei vermeintlich guten Kameras dazu f¨ uhrt, das diese nicht zum Tracking verwendet werden k¨onnen.

25

Kapitel 5 Positionsbestimmung Um aus den Kameradaten die Objektposition in Weltkoordinaten zu bestimmen, ¨ gibt es mehrere M¨oglichkeiten. Ublicherweise werden bei Trackingsystemen komplizierte mathematische Berechnungen verwendet. Da die Kameranzahl bei diesem Projekt auf zwei beschr¨ankt ist und das System m¨oglichst einfach und effizient arbeiten soll, wird zur Positionbestimmung ein neuronales Netz verwendet.

5.1

Definition neuronales Netz

Ein neuronales Netz ist ein System das Informationen mit Hilfe von miteinander verbundenen Neuronen verarbeitet. Es gibt zwei Arten von neuronalen Netzen, biologische und k¨ unstliche neuronale Netze. Bei biologischen neuronalen Netzen handelt es sich bei den Neuronen um Nervenzellen. Sie verarbeiten biologische Informationen. Bei k¨ unstlichen neuronalen Netzen sind die Neuronen mathematische Modelle mit mehreren Ein- und Ausg¨angen. Ein neuronales Netz erh¨alt ein Eingangsmuster, dass es verarbeitet und dann ein Ausgangsmuster ausgibt. Dieses Prinzip wird in Abbildung (5.1) verdeutlicht.

Abbildung 5.1: Neuronales Netz Die Neuronen lassen sich in drei Schichten aufteilen. Neuronen die direkt mit den Eingangswerten verbunden sind geh¨oren der Input Layer an. Neuronen, die nur mit

26

KAPITEL 5. POSITIONSBESTIMMUNG

anderen Neuronen verbunden sind, befinden sich in der Hidden Layer. Neuronen, die das Ausgangsmuster ausgeben bilden die Output Layer. In der Informationsverarbeitung eines neuronalen Netzwerk erzeugt ein Neuron eus seinem Eingangssignal ein Ausgangssignal. Dies Ausg¨ange werden wiederrum die Eing¨ange der n¨achsten Neuronenschicht. Auf diese Weise wird das Ausgangsmster erzeugt. Die Verbindungen der einzelnen Neuronen werden Gewichte genannt und tragen unterschiedliche Werte, mit denen die Ausg¨ange der Neuronen multipliziert werden um den neuen Eingang der darunterliegenden Schicht zu bestimmen. Ein neuronales Netz besteht somit aus mindestens zwei Schichten, einer bestimmten Anzahl an Neuronen und die gewichteten Verbindungen, welche in einer Gewichtsmatrix dargestellt werden k¨onnen. Die Eingangsdaten werden durch eine komplexe, ¨ nichtlineare Ubertragungsfunktion, die durch mehrere Parameter bestimmt wird, in die Ausgangsdaten gewandelt. Bei neuronalen Netzen wird untersucht, wie die ¨ Parameter gew¨ahlt werden m¨ ussen um ein bestimmtes Ubertragungsverhalten zu realisieren. Hierf¨ ur liefert man dem Netz einige Beispielmuster, auch Trainingsmuster genannt, u ber die man mit einem Optimierungsverfahren die Gewichte des Net¨ ¨ zes, der Ubertragungsfunktion entsprechend, bestimmt. Dieses Verfahren bezeichnet man bei neuronalen Netzen als Lernphase. In dieser Phase werden die Gewichte so gew¨ahlt, das die Beispielmuster richtig verarbeitet werden. Nach der Lernphase folgt die Testphase des neuronalen Netzes. In dieser testet man das Netz mit neuen Beispielen. Man vergleicht die Ergebnisse, die das Netz liefert, mit den realen Werten. Wenn Abweichungen existieren, werden die Gewichtungen entsprechend angepasst. Sobald sie auf die entsprechenden Anforderungen trainiert ist, kann mit ihnen gesprochene oder geschriebene Sprache verarbeiten, Bilder, Muster oder Signale verarbeiten, Probleme in der adaptiven Steuerung und Regelung l¨osen oder wie hier das Netz f¨ ur Trackingsysteme verwenden.

5.1.1

Feedforward-Netz

Um ein neuronales Netz zu implementieren, muss man sich zun¨achst f¨ ur eine grundlegende Netzarchitektur entscheiden. Bei dem hier entwickelten Netz wird ein FeedforwardNetz verwendet. Bei einer Feedforeward-Architektur existieren zwischen den Neuronen nur Verbindungen in eine Richtung. Die Neuronen einer Schicht sind nur mit den Neuronen der n¨achst h¨oheren Schicht verbunden, wobei hier mit h¨oher n¨aher an der Ausgangsschicht gemeint ist. Dabei existieren keine Verbindungen zwischen den Neuronen einer Schicht. Zudem f¨ uhren Feedforward-Netze keine Iteration aus, sondern jede Schicht wird nur einmal aktiviert. In Abbildung (5.2) ist das neuronale Netz abgebildet, das hier die Positionsbestimmung im Trackingsystem u ¨bernimmt. Bei den Eingangsdaten, die dem Netz u ¨bergeben werden, handelt es sich um die Bildpunkte des Objekts in x- und y-Richtung. Es werden die Werte von beiden Kameras u ¨bergeben. Das Netzt verarbeitet diese Informationen in zwei Hidden Layers. Die erste Hidden Layer besteht aus sieben Neuronen, die zweite aus sechs. Dadurch

5.1. DEFINITION NEURONALES NETZ

Abbildung 5.2: Verwendetes Feedforward Netz

27

28

KAPITEL 5. POSITIONSBESTIMMUNG

wird die reale Position in Weltkoordinaten ermittelt und als x-, y- und z-Wert ausgeben. Um zu entscheiden wieviele Neuronen in den jeweiligen Hidden Layers implementiert werden, wurden einige Kombinationen evaluiert. Dabei wurde der quadratische Fehler im Verh¨altnis zur Neuronenanzahl ermittelt.

Abbildung 5.3: Abh¨angigkeit des quadratischen Fehlers von der Neuronenanzahl Wie in Abbildung (5.3) ersichtlich wird ist der quadratische Fehler bei einem neuronalen Netz mit sieben Neuronen in der ersten Hidden Layer und sechs in der zweiten am kleinsten. Somit arbeitet dieses Netz am genauesten und wurde in diesem Trackingsystem als Grundlage gew¨ahlt.

5.1.2

Lernen durch Fehler-Ru artsausbreitung ¨ ckw¨

Da das Netz aus mehreren Schichten besteht und sich deshalb die Gewichte der Verkn¨ upfungen nicht “von Hand” ermitteln lassen, muss die Gewichtsmatrix durch einen Lernprozess ermittelt werden. Dabei kommt bei dem verwendeten Netz die Lernmethode des “¨ uberwachten Lernens” zum Einsatz. Dieser l¨asst sich so beschreiben, das ein Eingabemuster vorgegeben wird und sich durch Vorw¨artsausbreitung das Ausgabemuster berechnen l¨asst. Dieses wird mit einem gew¨ unschtem Ausgabemuster, auch Trainingsmuster oder -vektor genannt, verglichen. Die Gewichte werden dabei dann nach einer bestimmten Lernregel um einen kleinen Betrag korrigiert. Diesen Vorgang wiederholt man dann so lange, bis der Abstand zwischen tats¨achlicher und gew¨ unschter Ausgabe kleiner einer Toleranz, auch maximaler Fehler genannt, ist. Wie dieser Delta-Wert berechnet und implementiert wird, wird unter “Implementierung in C” beschrieben. Das Problem liegt nun darin, dass der Ausgangswert der versteckten Einheiten nicht bekannt ist. Um trotzdem die Gewichte zwischen den Schichten ¨andern zu k¨onnen ben¨otigen wir deshalb das Prinzip der “FehlerR¨ uckw¨artsausbreitung”, auch “Backpropagation-Algorithmus” genannt.

29

5.2. ERSTELLUNG VON TRAININGSDATEN

Dieses besagt, dass die Korrektur der Gewichte der auf eine bestimmte versteckte Einheit zulaufenden Verbindung proportional zu einem Delta ist, welches sich aber nun aus der gewichteten Summe aller der Deltas ermittelt, welche bei den Einheiten entstanden sind, mit denen die versteckten Einheiten ihrerseits nach vorne verbunden ist. [Schmitter]

5.2

Erstellung von Trainingsdaten

Um das Netz w¨ahrend der Entwicklungsphase mit Test- und Trainingsdaten versorgen zu k¨onnen musste zun¨achst ein Programm geschrieben werden, welches Datens¨atze erzeugen kann. Der hierf¨ ur entwickelte Algorithmus generiert zun¨achst Zufallszahlen f¨ ur die reellen X- Y- und Z- Koordinaten. Der Wertebereich liegt dabei f¨ ur die X- und Y- Koordinate zwischen 0 und 400 und bei der Z-Koordinate bei 0 bis 200. Diese Werte sollen die Raumabmessungen, in denen sich das Objekt befinden kann, in Zentimeter widerspiegeln. Um jetzt die dazugeh¨origen Bildpunkte zu berechenen, wird ein Idealisiertes Modell, wie in Abbildung (5.4) gezeigt, verwendet. Dieses setzt Voraus, dass zwei Kameras mit einem Bildwinkel von 90 so positioniert werden, dass sie auf der selben H¨ohe sind, somit also die selbe Z-Achse besitzen, und den gesamten Raum abdecken. Aus der Trigonometrie l¨asst sich dann der Winkel αx1 f¨ ur die erste Kamera mit der Gleichung tan αx1 =

x y

(5.1)

zu x y

(5.2)

400 − x y

(5.3)

αx1 = arctan berechnen. F¨ ur die zweite Kamera gilt: αx2 = arctan

Um daraus die Bildpunkte x1 , und x2 der beiden Kamerabilder zu berechnen teilt man α durch den maximalen Bildwinkel, also durch 90 bzw. π2 , um den Wertebereich zwischen 0 und 1 festzulegen. Um dann auf einen Wert innerhalb der Bildaufl¨osung zu kommen, multipliziert man das Ergebnis mit xmax . Bei einer Aufl¨osung von 800x600 errechnen sich die Bildpunkte x1 und x2 dann zu x1 = x2 =

αx1 ∗ 800 π 2

αx2 ∗ 800 π 2

(5.4) (5.5)

30

KAPITEL 5. POSITIONSBESTIMMUNG

Um die Y-Koordinaten y1 und y2 der Bilder zu errechnen multipliziert man den YWert mit ymax , teilt ihn durch 400 und addiert 300. Somit passt man den zuf¨alligen Y-Wert (welcher zwischen 0 und 200 liegt) dem Wertebereich der Aufl¨osung von 800x600 an. y1,2 =

y ∗ 600 + 300 400

(5.6)

Da beide Kameras die selbe H¨ohe besitzen ergibt sich f¨ ur beide Bilder den selbe Y-Wert. Nachdem die Daten erzeugt und berechnet wurden, werden sie pro Datensatz zeilenweise in eine Datei geschrieben, damit sie sp¨ater als Trainings- und Testdaten vom neuronalen Netz einlesbar sind.

Abbildung 5.4: Idealisiertes Modell der Trackingumgebung

5.3. IMPLEMENTIERUNG IN C

5.3

31

Implementierung in C

Einer der Hauptaufgaben des Projekts besteht darin, die Positionsbestimmung mit Hilfe eines neuronalen Netzes zu realisieren. Dazu wurde die zu Anfang gelernte Theorie u ¨ber neuronale Netze mittels C Code in die Praxis umgesetzt. Nachdem das Programm gestartet wurde, hat der Benutzer die Auswahl, die Trainingsphase zu starten oder die Position, nach Eingabe von Bildkoordinaten in Weltkoordinaten auszugeben. Nachdem man die Kameras in der Trackingumgebung aufgebaut und mit dem PC verbunden hat kann man mit der Trainingsphase beginnen, indem man das Programm startet und den Men¨ upunkt “Trainingsphase“ ausw¨ahlt. In der n¨achsten Men¨ uauswahl kann der Benutzer dann w¨ahlen, ob die Trainingsdaten aus einer Datei ausgelesen werden oder ob sie manuell eingegeben werden. Bei der Auswahl, die Trainingsdaten per Datei einzulesen muss sich die Datei “zufall.dat” im selben Verzeichnis befinden, in dem sich auch die kompilierten Daten befinden. Ansonsten wird eine Fehlermeldung angezeigt und das Programm beendet. Im folgenden Schritt wird der Benutzer aufgefordert, nacheinander die Netzparameter einzugeben. Der erste Parameter ist die Anzahl der zu lernenden Assoziationen, diese wird als Integer Zahl in einem Array namens “PNUM“ gespeichert. Aus programmiertechnischen Gr¨ unden ist die gr¨oße des Arrays hartcodiert, die Anzahl an zu lernenden Assoziationen ist dadurch nach oben hin beschr¨ankt. Der zweite einzugebende Parameter ist die Steilheit der Aktivierungsfunktion. Dieser Parameter erm¨oglicht es, den Wertebereich der Aktivierungsfunktion einzustellen. Umso kleiner dieser Wert ist, desto fr¨ uher wird der S¨attigungsbereich erreicht. F¨ ur das eingesetzte Netz hat sich ein Wert von 0.1 bis 0.2 als tauglich erwiesen. Darauf folgt die Eingabe der Lernrate η, welche f¨ ur die Delta-Lernregel ben¨otigt wird. Der n¨achste Parameter ist die Anzahl an Iterationen. Umso mehr Iterationen gemacht werden, desto geringer wird der quadratische Fehler. Der letzte Parameter, der eingegeben werden muss ist der zu unterschreitende maximale Fehler. Dieser gibt an, ab wann die Iterationsschleife abgebrochen werden soll. Nach der Eingabe des letzten Parameters wird eine Funktion aufgerufen, die das Netz mit Zufallsgewichtungen initialisiert. Diese liegen im Wertebereich von -0.2 bis 0.2. Daraufhin wird erneut ein Auswahlbildschrim angezeigt. Dort kann der Benutzer den Trainingsalgorithmus starten, sich die Gewichtungen anzeigen lassen, die Parameter erneut eingeben, Zufallsdaten erzeugen (siehe Erstellung von Trainingsdaten) oder das Programm beenden. Wie bereits beschrieben werden beim Trainieren des Netzes die Gewichte zwischen den einzelnen Schichten so angepasst, dass die Differenz zwischen Trainingsvektor und Ausgabevektor kleiner als der quadratische Fehler ist oder die Anzahl an Iterationen erreicht ist. Vor der Berechnung des Ausgabevektors werden zuerst die Eingabevektoren manuell oder aus einer Datei eingelesen und in einem Array der gr¨oße PNUM*EINGANG gespeichert, wobei EINGANG die Anzahl der Eingangs-

32

KAPITEL 5. POSITIONSBESTIMMUNG

neuronen ist. Danach beginnt die eigentliche Lernphase. Dazu m¨ ussen die Trainingsdaten zur weiteren Berechnung so umgewandelt werden, dass sie dem Wertebereich der Aktivierungsfunktion entsprechen. Als Aktivierungsfunktion selber kommt bei dem benutzen Netz die sogenannte Sigmoidfunktion zum Einsatz: f (x) =

1 1 + e−x

(5.7)

Wie man in Abbildung (5.5) erkennen kann bedeutet dies, dass die Eingangswerte x1 , y1 , x2 und y2 im Wertebereich von -1 und +1 liegen m¨ ussen. Dies geschieht durch eine Funktion, welche nach der Eingabe der Trainingseingangsvektoren aufgerufen wird und folgende mathematische Gleichungen ausf¨ uhrt:

inputxneu =

inputx −1 400

(5.8)

inputyneu =

inputy −1 300

(5.9)

Die Werte der Trainingsausgangsvektoren m¨ ussen hingegen dem Wertebereich des Ausgangs der Aktivierungsfunktion entsprechen. Mit Hilfe der Gleichungen outputxneu =

outputx 400

(5.10)

outputyneu =

outputy 400

(5.11)

outputz (5.12) 200 werden diese Werte dann in den Augangswertebereich der Aktivierungsfunktion (5.5), n¨amlich 0 bis 1, transformtiert. Um nun aus den transformierten Eingangsvektoren die Ausgangsvektoren berechnen zu k¨onnen m¨ ussen die Eingangswerte mit der Gewichtsmatrix, die zu Anfang mit Zufallswerten generiert wurde, multipliziert werden. Dies wird in C mit zwei ineinander verschachtelten for-Schleifen realisiert, welche die Indizes der Vektoren bzw. der Matrixelemente hochz¨ahlt und Schicht f¨ ur Schicht die einzelnen Neuronen berechnet. Um nun die richtigen Gewichte setzen, und somit das Netz Trainieren lassen zu k¨onnen, muss der Backpropagation-Algorithmus in den bisherigen Quellcode implementiert werden. Wie bereits beschrieben kommt daf¨ ur die erweiterte outputzneu =

5.3. IMPLEMENTIERUNG IN C

33

Abbildung 5.5: Aktivierungsfunktion in Form der Sigmoidfunktion Delta-Lernregel zur Anwendung. F¨ ur jede der n Ausgabeeinheiten (bei dem hier besprochenen Netz 3) wird dabei delta nach folgender Gleichung berechnet: δw[i][j] = η ∗ (tp[i] − out[i]) ∗ in[j] ∗ out[i] ∗ (1 − out[i])

(5.13)

Die Variable w[i][j] ist hierbei der Wert des Gewichtes zwischen den jeweiligen Schichten und Neuronen, tp[i] den Trainingsvektor, out[i] den Ausgangsvektor und in[j] den Eingangsvektor darstellt. Daraufhin werden die Korrekturen f¨ ur die Gewichtungen und Skalenverschiebungen proportional zur Lernrate η gesetzt indem, beim Ausgangsvektor angefangen, von hinten nach vorne die Neuronen mit dem jeweiligen δ der einzelnen Schichten multipliziert werden. Der dadurch entwickelte Lernalgorithmus hat die Vorteile, dass das Netz durch die variablen Parametereingabe sehr genau angepasst werden kann. Außerdem erfordert der Quellcode keine zus¨atzlichen C Libraries und kann somit flexibel an jedem PC mit Linux Betriebssystem ohne weiteres ausgef¨ uhrt werden. ¨ Um einen besseren Uberblick u ¨ber die einzelnen Werte des Netzes und den summierten quadratischen Fehler wurde in einzelnen Funktionen eine Konsolenausgabe implementiert. Diese zeigt dem Benutzer w¨ahrend der Trainingsphase bei jedem zehnten Iterationsschritt die Summe des quadratischen Fehlers an. Zus¨atzlich werden nach dem Training die Gewichte und die Skalenverschiebung zwischen den einzelnen Neuronen angezeigt. Zu Testzwecken wurde der Benutzer nach der Lernphase gefragt, ob er das Netz mit manuell eingegebenen Daten testen will. Diese Funktion wurde sp¨ater entfernt, da das Netz die Bildpunkte direkt aus den Bildern u ¨bernimmt. Um die Gewichten speichern zu k¨onnen verf¨ ugt das Netz zudem u ¨ber die M¨oglichkeit, die berechnete Gewichtsmatrix in einer Datei abzuspeichern und bei einem erneuten Programmstart zu laden. Dies ist deshalb wichtig, da nach dem Beenden des Programmes die Werte der Gewichtsmatrix nicht mehr vorhanden sind und man jedes mal, wenn man das Programm startet, die Trainingsphase wiederholen m¨ usste. Eine weitere Aufgabe, die es zu bew¨altigen gab bestand darin, die Schnittstelle zwi-

34

KAPITEL 5. POSITIONSBESTIMMUNG

schen Objekterkennung und neuronalen Netz zu implementieren. Eine M¨oglichkeit ist es, die Bildpunkte des Objektes in eine Datei zu schreiben und diese dann in das Netz einzulesen. Diese Methode hat aber den gravierenden Nachteil, dass die Operation, in eine Datei schreiben und aus einer Datei lesen relativ lange dauert. Aus diesem Grund wurde der gesamten Code des Netzes in den Code der Bildverarbeitung einzubauen. Die Bildpunkte k¨onnen so dann durch das Aufrufen einer Funktion dem neuronalen Netz u ¨bergeben werden. Dieses zeigt dann kontinuierlich die Position des Objektes in einer Konsole an.

35

Kapitel 6 Ausgabe Um nach der efolgreichen Berechnung der Weltkoordinaten mit diesen arbeiten zu k¨onnen, m¨ ussen sie ausgegeben werden. Zuerst werden die Koordinaten mittels Konsole auf dem PC ausgegeben. Eines der Schwierigkeiten dabei war, die Position so schnell wie m¨oglich ausgeben zu lassen. Die Zeit, zwischen aktueller Position und ausgegebener Position ist durch mehrere Faktoren bestimmt. Zum einen hat man eine (sehr geringe) Verz¨ogerung, die es dauert, die Kamerabilder aus dem Kamerastream abzugreifen. Also spielt die Auswahl der Kameras eine Rolle. Die gr¨oßte Verz¨ogerung entsteht bei der Suche nach dem Objekt, da die Bilder Pixel f¨ ur Pixel nach dem Objekt abgesucht werden m¨ ussen. Den letzten Anteil an der Gesamt¨ verz¨ogerung bildet die Ubergabe der Daten an das neuronale Netz, die Berechnung und Ausgabe. Es gibt noch weitere Methoden die koordinaten auszugeben, die im weiteren beschrieben sind.

6.1

Protokolldatei

Eine M¨oglichkeit, die Koordinaten des Objektes auszugeben besteht darin, diese in einer Protokolldatei festzuhalten. Dadurch sind sie gespeicher und k¨onnen sp¨ater noch verwendet und analysiert werden. Hier wird die Protokolldatei mit dem erneuten starten des Programmes mit den aktuellen Daten u ur eine dauerhafte Speicherung muss ¨berschrieben. Das bedeutet f¨ die Protokolldatei kopiert werden.

6.2

Grafische Ausgabe

Um die Bewegung des Objektes leichter nachzuvollziehen, werden die Trajektorien der gespeicherten Koordinaten gezeichnet. Dies wird mit MATLAB realisiert. Hierf¨ ur werden die Daten aus der Protokolldatei eingelesen. Dann werden die x-, y- und z-Koordinaten in einzelnen Vektoren gespeichert und diese mit Hilfe eines

36

KAPITEL 6. AUSGABE

einfachen Plot-Befehls gezeichnet. In Abbildung (6.1) ist eine beispielhafte Bewegung des Objekts dargestellt.

Abbildung 6.1: Trajektorie des Objektes im Raum Hier wird ersichtlich wie sich das Objekt im Raum bewegt hat.

6.3

Socket-Interface

Um die Koordinaten des Objektes nicht nur als Information zu bekommen, sondern mit diesen auch arbeiten zu k¨onnen, muss die M¨oglichkeit besthen diese an andere Programme zu u ¨bergeben. Dazu bedient man sich eines Socket-Interfaces, welches die Ausgabe des neuronalen Netzes mit anderen Programmen verbindet. Da es aus Zeitgr¨ unden nicht m¨oglich war ein eigenes Socket-Interface zu program¨ mieren und dieses bei der Ubergabe an verschiedene Programme unterschiedliche Schnittstellen ben¨otigt, muss man hier auf ein eigenes Socket-Interface zur¨ uckgreifen.

37

Kapitel 7 Zusammenfassung Zusammenfassend l¨asst sich sagen, dass das Ziel, ein Tracking-System mit USB Kameras zu realisieren, erreicht wurde. Doch musste teilweise von den vorausgesetzten Spezifikationen abgewichen werden. Vor allem die zur Zeit auf dem Markt erh¨altlichen Kameras schr¨anken das System in seiner Genauigkeit ein. USB Kameras haben ein großes Farbrauschen, dass das Trackingergebnis des Objektes verf¨alscht. Außerdem wurde der Raum, in dem sich das Objekt bewegt, von dem geringen Bildwinkel der eComkameras eingeschr¨ankt. So konnte im Laufe des Praktikums ein Raum mit den Abmessungen von 333cmx215cmx43cm agbedeckt werden. F¨ ur die Entwicklung des Systems und f¨ ur die ersten Tests war dies aber ausreichend. Aber auch auf die Gr¨oße des Objektes hat die gew¨ahlte Kamera Einfluss. Diese mussten n¨amlich weit von dem abgedeckten Raum entfernt positioniert werden, weshalb ein relativ großes Objekt gew¨ahlt wurde. Durch eine andere Wahl des Raumes und der Raumgr¨oße kann auch der Umfang des Objektes verkleinert werden. H¨ohere Genauigkeit kann außerdem durch Erh¨ohen der Aufl¨osung der Kameras erzielt werden. Da sich aber ohne gr¨oßeren Aufwand die Eigenschaften des Videostreams nicht ¨andern lassen wurde mit einer Aufl¨osung von 640x480 gearbeitet. Durch Programmieren eines Treibers f¨ ur die Kamera w¨ urde sich dieses Problem aber l¨osen lassen, wobei man dadurch aber mit Einbußen in der Bildwiederholungsrate rechnen muss. Die Positionsbestimmung mittels eines neuronalen Netzes konnte ebenfalls erfolgreich implementiert werden. Um Trainingsdaten aufzunehmen wurden dabei Punkte innerhalb des Raumes abgemessen, das Objekt auf diese Punkte gelegt und die Bildpunkte der Kamerabilder abgelesen. So konnten f¨ ur den verwendeten Raum w¨ahrend des Praktikums 360 Punkte aufgenommen werden. Da dieses Verfahren sehr aufwendig ist, w¨aren hier ebenfalls Verbesserungen sinnvoll. Diese k¨onnten darin bestehen gleichzeitig mehrere Bildpunkte aufzunehmen, indem man mehrere Objekte mit gleichem Abstand verwendet. Mit den oben erw¨ahnten Netzparametern konnte in der Lernphase der quadratische Fehler nach 5000 Iterations- schritten auf 1.28 verringert werden. Durch die relativ geringe Anzahl an Trainingsdaten kam es zum Abschluss des Projekts zwischen

38

KAPITEL 7. ZUSAMMENFASSUNG

errechneter und realer Position zu einer Abweichung von f¨ unf bis zehn Zentimeter. Durch die Ver¨anderung dieser Parameter kann ebenfalls die Genauigkeit des Netzes beeinflussen. Durch die Positionberechnungen wird Rechenzeit in Anspruch genommen, die zu einer Verz¨ogerung von 0.96% in der Zeit f¨ uhrt.

39

ABBILDUNGSVERZEICHNIS

Abbildungsverzeichnis 2.1

Tracking-Gebiet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.1 3.2 3.3 3.4

Testbild der neonfarbenen B¨ alle . HSV-Bild des erleuchtenden Balles HSV-Bild des roten Balles . . . . Schaltplan der LED Schaltung . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

12 13 13 14

4.1 4.2 4.3 4.4 4.5 4.6

Aufbau eines Frames in RGB-Farben Aufbau eines Frames in HSV-Farben HSV-Farbraum . . . . . . . . . . . Testprogramm zur Farbauswahl . . . Testbild mit Gaußfilter . . . . . . . Finale Version der Objekterkennung

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

17 17 18 22 23 24

5.1 5.2 5.3 5.4 5.5

Neuronales Netz . . . . . . . . . . . . . . . . . . . . . . . . Verwendetes Feedforward Netz . . . . . . . . . . . . . . . . . Abh¨ angigkeit des quadratischen Fehlers von der Neuronenanzahl Idealisiertes Modell der Trackingumgebung . . . . . . . . . . . Aktivierungsfunktion in Form der Sigmoidfunktion . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

25 27 28 30 33

6.1

Trajektorie des Objektes im Raum . . . . . . . . . . . . . . . . . . . . . 36

40

ABBILDUNGSVERZEICHNIS

LITERATURVERZEICHNIS

41

Literaturverzeichnis [Schmitter]

E.D. Schmitter. Neuronale Netze. Einf¨ uhrung, Programmierbeispiele, praktische Anwendungen. , 1. Auflage 1991

[Rigoll]

Gerhard Rigoll. Neuronale Netze. Eine Einf¨ uhrung f¨ ur Ingenieure, Infomratiker und Naturwissenschaftler. , 1994

[natur-struktur.ch] http://www.natur-struktur.ch/ai/images/200pxNeural network.png

Suggest Documents