Schriftliche Ausarbeitung herunterladen
Schriftliche Ausarbeitung herunterladen
Schriftliche Ausarbeitung herunterladen
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Institut für Visualisierung und Interaktive Systeme<br />
Universität Stuttgart<br />
Universitätsstraße 38<br />
D–70569 Stuttgart<br />
Diplomarbeit Nr. 2325<br />
Bildbasierte Positionserkennung<br />
und Aktualisierung von<br />
modellierten Objekten in Gebäuden<br />
Tim Hartter<br />
Studiengang: Informatik<br />
Prüfer: Prof. Dr. Thomas Ertl<br />
Betreuer: Dr. Andreas Hub<br />
begonnen am: 20. April 2005<br />
beendet am: 20. Oktober 2005<br />
CR-Klassifikation: H.5.2, I.2.10, I.3.7, I.4.1, I.4.3, I.4.6, I.4.7,<br />
I.4.8, I.6.8, K.3.1, K.4.2
Ich danke meinem Betreuer, Dr. Andreas Hub, für seine Unterstützung<br />
bei der Verfassung dieser Arbeit.<br />
Bedanken möchte ich mich auch bei Reinhard Lafrenz für die<br />
zahlreichen Tipps in Fragen der Bildanalyse und des Bildverstehens.<br />
Zudem möchte ich mich bei meiner Mutter für die Hilfe bei der<br />
Korrektur der schriftlichen <strong>Ausarbeitung</strong> herzlich bedanken.
Inhaltsverzeichnis<br />
1 Einleitung 1<br />
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
2 Grundlagen 3<br />
2.1 Grundlagen der Bildverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2.1.1 Featurepunkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2.1.2 Kalibrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.1.3 Rektifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.1.4 Stereodisparität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.1.5 Linienerkennung durch Hough-Transformation . . . . . . . . . . . . . . . . . . 8<br />
2.1.6 Farbmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.1.7 Regiongrowing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
2.2 Stand der Forschung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
2.3 Vorarbeiten und verwendete APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.3.1 Farbklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.3.2 Navigation Assistance System (NAS) . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.3.3 Stereo Vision based Object Distance Estimation in 3D Environment Models . . . 14<br />
2.3.4 Rapid Object Detection using Haar-like Features . . . . . . . . . . . . . . . . . 14<br />
2.3.5 Lucas-Kanade Optical Flow in Pyramids . . . . . . . . . . . . . . . . . . . . . 15<br />
2.3.6 Microsoft DirectX 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
2.3.7 NI-IMAQ for IEEE 1394 Cameras . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
2.3.8 Intel Open Source Computer Vision Library (OpenCV) . . . . . . . . . . . . . . 15<br />
2.3.9 OpenSceneGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
2.3.10 Microsoft Foundation Classes (MFC) . . . . . . . . . . . . . . . . . . . . . . . 16<br />
3 Lösungsentwurf 17<br />
3.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
3.2 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.2.1 Aufbau des Sensormoduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.2.2 Positionsbestimmung der Kamera . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.2.3 Auswahl geeigneter Messpunkte . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.2.4 Detektion von verschiebbaren, modellierten Objekten . . . . . . . . . . . . . . . 28<br />
3.2.5 Aktualisierung des Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
I
II INHALTSVERZEICHNIS<br />
4 Implementierung 35<br />
4.1 Sensordatenerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
4.1.1 Ansteuerung der Kameras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
4.1.2 Berechnung der Stereodisparitätsbilder . . . . . . . . . . . . . . . . . . . . . . 37<br />
4.1.3 Verwendung eines selbstsynchronisierenden Stereokameramoduls . . . . . . . . 41<br />
4.1.4 Verfahren zur Berechnung der Stereobilder . . . . . . . . . . . . . . . . . . . . 42<br />
4.1.5 Ansteuerung des Xsens Motion Trackers . . . . . . . . . . . . . . . . . . . . . 43<br />
4.2 Bereitstellung der Modelldaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
4.2.1 Erstellung des Gebäudemodells mit 3D Studio Max . . . . . . . . . . . . . . . . 44<br />
4.2.2 Darstellung des Gebäudemodells . . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
4.3 Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
4.3.1 Bestimmung geeigneter Messpunkte . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
4.3.2 Positionsbestimmung der virtuellen Kamera . . . . . . . . . . . . . . . . . . . . 50<br />
4.4 Erkennung von verschiebbaren, modellierten Objekten . . . . . . . . . . . . . . . . . . 50<br />
4.5 Aktualisierung des 3D-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
5 Ergebnisse 53<br />
5.1 Hardwarekomponenten des Navigationsassistenten . . . . . . . . . . . . . . . . . . . . 53<br />
5.2 Distanzmessung über Stereokamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
5.3 Selbstlokalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
5.4 Lokalisierung von verschiebbaren Objekten . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
5.5 Performancemessung der Navigationssoftware . . . . . . . . . . . . . . . . . . . . . . . 61<br />
6 Diskussion 63<br />
6.1 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64<br />
7 Zusammenfassung 65<br />
A Bedienungsanleitungen 67<br />
A.1 Kalibrierungs-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67<br />
A.2 Rektifizierungs-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
A.3 Navigationssoftware - Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69<br />
A.3.1 Lernen einer Objektbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
Literaturverzeichnis 73<br />
Abbildungsverzeichnis 77
Kapitel 1<br />
Einleitung<br />
1.1 Motivation<br />
Die Navigation in unbekannten Gebäuden stellt für Blinde eine große Herausforderung dar. Hier fehlt<br />
ihnen die Kenntnis der genauen Gebäudespezifikationen, über die sie sich üblicherweise in einer bekannten<br />
Umgebung orientieren. Da Informationen, die über gängige Hilfsmittel wie den Blindenstock<br />
erfasst werden können sehr begrenzt sind, wird heutzutage versucht, über elektronische Navigationshilfen<br />
weitere Gebäudedetails zur Verfügung zu stellen. Diese sollen durch die Angabe kontextbezogener<br />
Gebäudeinformationen helfen, auch schwierige Aufgaben wie das Finden eines bestimmten Raumes<br />
ohne fremde Hilfe zu bewältigen.<br />
Am Institut für Visualisierung und Interaktive Systeme werden zu diesem Zweck im Rahmen des Sonderforschungsbereiches<br />
Nr. 627 (Nexus Projekt) im Teilprojekt D2 Orientierungsassistenten für Blinde<br />
entwickelt. Ein Teilziel dieses Projektes ist es, den Aufenthaltsort einer blinden Person zu ermitteln. Die<br />
genaue Bestimmung der Position eines portablen Sensormoduls in Innenräumen kann genutzt werden,<br />
um die Navigation des Blinden zu unterstützen, und die Erkennung von Objekten durch Vergleiche mit<br />
einem 3D-Gebäudemodell ermöglichen.<br />
Die hier vorgestellte Arbeit zeigt, wie unter Zuhilfenahme einer Stereokamera und eines Intertialsensors<br />
(Orientierungssensor) die eigene Position bestimmt und die Abstände zu modellierten, verschiebbaren<br />
Objekten berechnet werden können um so den Blinden bei der Navigation durch das Gebäude zu unterstützen.<br />
1.2 Voraussetzungen<br />
Der vorgestellte Ansatz beschränkt sich auf die Navigation in Gebäuden. Diese müssen als 3D-Gebäudemodell<br />
vorhanden sein und alle festen und verschiebbaren Einrichtungsgegenstände des Gebäudes enthalten.<br />
Zudem wird vorausgesetzt, dass der aktuelle Aufenhaltsraum des Benutzers bekannt ist und die vom<br />
Inertialsensor abgefragte Orientierung korrekt ist.<br />
1
2 KAPITEL 1. EINLEITUNG<br />
1.3 Gliederung<br />
Diese Diplomarbeit gliedert sich wie folgt. Kapitel 2 beschreibt die Grundlagen und Vorarbeiten, die<br />
als Ressourcen für diese Arbeit herangezogen wurden. Kapitel 3 stellt die Problemstellung und den<br />
verwendeten Lösungsansatz vor. In der Implementierung (Kapitel 4) werden die zur Lösung der Aufgabe<br />
implementierten Methoden näher beschrieben. Kapitel 5 stellt die Ergebnisse einiger Selbst- und<br />
Objektlokalisierungstests dar. Diese werden in Kapitel 6 diskutiert und ein Ausblick auf mögliche Verbesserungen<br />
gegeben. Die Arbeit schließt mit einer kurzen Zusammenfassung der gewählten Methoden<br />
und Ergebnisse in Kapitel 7.
Kapitel 2<br />
Grundlagen<br />
Dieses Kapitel befasst sich mit den Grundlagen und Vorarbeiten, die als Basis für die hier vorgestellte<br />
Arbeit verwendet wurden. Es beschreibt den Stand der Forschung und die zur Lösung der Aufgabenstellung<br />
in Frage kommenden Verfahren. Diese sind zur Lösung von einzelnen Teilproblemen der<br />
Aufgabenstellung (nach Anpassung an das Projekt) geeignet. Im folgenden Kapitel wird ein Entwurf<br />
vorgestellt, der eine mögliche Kombination der Teillösungen vorschlägt und die Struktur des zu implementierenden<br />
Verfahrens vorstellt.<br />
2.1 Grundlagen der Bildverarbeitung<br />
Zum Verständnis dieser Arbeit, welche die Entwicklung eines bildbasierten Navigationsassistenten beschreibt,<br />
ist die Kenntnis der in den nächsten Abschnitten erklärten Grundlagen der Bildverarbeitung<br />
erforderlich.<br />
2.1.1 Featurepunkte<br />
Als Featurepunkte werden in der Bildverarbeitung Stellen im Bild bezeichnet, welche besondere Merkmale<br />
aufweisen. Besonders geeignete Bildmerkmale sind Ecken und Kanten im Graustufenbild. Diese<br />
sind kaum von Farbverzerrungen bei der Bilderfassung abhängig und können für die unterschiedlichsten<br />
Aufgaben in der Bildverarbeitung eingesetzt werden, wie zum Beispiel<br />
• Ausrichtung von Bildern<br />
• 3D Rekonstruktion<br />
• Verfolgung von Bewegungen<br />
• Objekterkennung<br />
• Roboternavigation<br />
• Suche in Bilddatenbanken<br />
3
4 KAPITEL 2. GRUNDLAGEN<br />
Harris und Stephens stellen in [1] ein Verfahren zur Erkennung von Kanten und Ecken vor, in dem die<br />
Hessematrix in einer Nachbarschaftsumgebung um jeden Bildpunkt berechnet wird.<br />
⎡<br />
⎢<br />
⎣<br />
∑<br />
Nachbarscha ft<br />
∑<br />
Nachbarscha ft<br />
� �2 δI<br />
δx<br />
� �<br />
δ2I δxδy<br />
� �<br />
δ2I ∑ δxδy<br />
Nachbarscha ft<br />
∑<br />
Nachbarscha ft<br />
� δI<br />
δy<br />
� 2<br />
⎤<br />
⎥<br />
⎦ , Intensität I (2.1)<br />
Aus dieser ergeben sich die Eigenwerte λ1,λ2 für jeden Bildpunkt. Bildpunkte an Kanten zeichnen<br />
sich durch einen großen Eigenwert λ1 oder λ2 aus. An diesen Stellen ändert sich in einer Richtung<br />
die Helligkeit sehr stark. Ecken im Bild zeichnen sich hingegen durch starke Änderungen in beiden<br />
Dimensionen aus. Die zugehörigen Eigenwerte sind näherungsweise gleich groß.<br />
� 2<br />
� 1<br />
Nachbarschaft<br />
a) Eigenwerte an Kanten λ2 >> λ1<br />
� 2<br />
� 1<br />
b) Eigenwerte an Ecken λ1 ≈ λ2<br />
Abbildung 2.1: Verhältnis von Eigenwerten an Kanten und Ecken, (a) zeigt die Eigenwerte an einer<br />
Bildkante, diese beschreiben aufgrund ihrer unterschiedlichen Größe eine Ellipse. In<br />
(b) sind die Eigenwerte einer Ecke dargestellt, diese sind näherungsweise gleich groß<br />
und bilden somit einen rotationsinvarianten Kreis.<br />
Aufgrund der Rotationsinvarianz ihrer Eigenwerte stellen sich Ecken im Graustufenbild als besonders<br />
gut zu verfolgende Merkmale heraus. Diese können durch eine „Nicht-Maxima-Unterdrückung“ (nonmaxima-suppression)<br />
anhand eines Grenzwertes λ gefiltert werden (min(λ1,λ2) > λ) und ergeben so die<br />
zur Weiterverfolgung am besten geeigneten Featurepunkte des Bildes. Eine ausführlichere Beschreibung<br />
des „Harris Edge Detectors“ findet sich unter [2].<br />
2.1.2 Kalibrierung<br />
Bei jeder Kamera entstehen durch die zur Abbildung verwendete Linse Verzerrungen im aufgenommenen<br />
Kamerabild (sphärische Aberration). Durch diesen Effekt erscheinen Geraden im Kamerabild nicht<br />
mehr als Geraden, sondern weisen eine starke konzentrische Krümmung auf. Die Stärke der Verzerrung<br />
hängt hauptsächlich vom Öffnungswinkel der verwendeten Kamera ab und ist in Abbildung 2.2 für eine<br />
Kamera mit starkem Weitwinkelobjektiv abgebildet.
2.1. GRUNDLAGEN DER BILDVERARBEITUNG 5<br />
Unter der Kalibrierung einer Kamera versteht man die Berechnung einer Entzerrungsmatrix aus den<br />
für die Verzerrungen verantwortlichen Kameraparametern. Über diese kann das verzerrte Bild korrigiert<br />
werden. Die Kameraparameter gliedern sich in die kameraspezifischen, intrinsischen Parameter:<br />
• Fokale Länge ( fx, fy), Abstand zwischen Linse und Bildebene in X-/Y-Richtung)<br />
• Position des Bildmittelpunktes in Pixelkoordinaten (cx,cy)<br />
und die räumlichen Zusammenhänge zwischen Kamera und Weltkoordinaten, den extrinsischen Parametern:<br />
• Rotationsmatrix (R)<br />
• Translationsvektor (�t)<br />
Für die Abbildung der Koordinaten eines Punktes M im Raum auf die Bildkoordinaten m gilt nach [3]<br />
folgende Vorschrift:<br />
m = A[R�t]M (2.2)<br />
wobei sich A aus den intrinsischen Parametern der Kamera wie folgt zusammensetzt:<br />
⎡<br />
A = ⎣<br />
fx 0 cx<br />
0 fy cy<br />
0 0 1<br />
⎤<br />
⎦ (2.3)<br />
Zur Berechnung der gesuchten Parameter kann der von Zhang vorgestellte Algorithmus [4] verwendet<br />
werden, der über die Präsentation eines bekannten Musters aus verschiedenen Positionen (Abbildung<br />
2.2 (a)-(c)) alle für die Entzerrung des Bildes notwendigen Daten berechnet, indem die intrinsischen<br />
und extrinsischen Parameter so lange variiert werden, bis der Fehler zwischen realer und optimaler<br />
Abbildung des Musters (d) minimal ist.<br />
a) b) c) d)<br />
Abbildung 2.2: Kamerakalibrierung über Schachbrettmuster nach Zhang. Die Kamera nimmt ein<br />
Schachbrettmuster aus unterscheidlichen Positionen (a)-(c) auf. Dieses wird mit der<br />
optimalen Abbildung des Musters (d) verglichen um die Kameraparameter zu berechnen.
6 KAPITEL 2. GRUNDLAGEN<br />
2.1.3 Rektifizierung<br />
Nach der im letzten Abschnitt beschriebenen Kalibrierung der Kamera erscheinen ursprüngliche Geraden<br />
in den entzerrten Bildern wieder als solche. Für die Abbildung eines Punktes M im Raum auf<br />
den CCD-Chip einer Kamera, wie sie in Abbildung 2.3 (a) dargestellt ist, gilt Gleichung 2.2. Bei Verwendung<br />
einer Stereokamera gilt diese Abbildungsvorschrift für beide Kameras. Zur Vereinfachung der<br />
Berechnung eines Stereodisparitätsbildes aus den beiden Einzelbildern der Kameras sorgt man durch die<br />
Rektifizierungstransformation dafür, dass die beiden Abbildungen des Punktes M, wie in Abbildung 2.3<br />
(b) gezeigt, auf einer Geraden, der sogenannten Epipolarlinie zu liegen kommen. Diese Linie ist über<br />
den Bildpunkt m und die nach Gleichung 2.2 in die Bildebene projizierte Position der jeweils anderen<br />
Kamera festgelegt. Durch Angabe einiger korrespondierender Punkte beider Kamerabilder kann die zur<br />
Rektifizierung notwendige Rektifizierungstransformation für jede Kamera berechnet werden. Diese entspricht<br />
einer Rotation beider Kameras, bis die Blickrichtungen parallel sind und die Epipolarlinien, wie<br />
in Abbildung 2.3 (c) gezeigt, aufeinander liegen. Eine ausführliche Beschreibung dieser Berechnung<br />
findet sich in [5].<br />
a) b)<br />
c)<br />
⇓ Rektifizierung ⇓<br />
Abbildung 2.3: Epipolarlinien nach [6]. Durch die Rektifizierungstransformation werden die beiden<br />
Kameras aus (b) so ausgerichtet, dass ihre Blickrichtungen parallel sind und zugehörige<br />
Scanlines der Kamerabilder aufeinander liegen. Bild (c) zeigt die Bildebenen nach der<br />
Rektifizierung.
2.1. GRUNDLAGEN DER BILDVERARBEITUNG 7<br />
2.1.4 Stereodisparität<br />
Die Stereodisparität ist ein Maß für den Abstand eines Punktes M von einer Stereokamera. Sie entspricht<br />
dem Abstand d zwischen den zueinander gehörigen Projektionen (m,m ′ ) des Punktes M aus Abbildung<br />
2.3 (c) und berechnet sich über die Formel:<br />
d = |mm ′ | (2.4)<br />
Nach Li [7] gilt hierbei, dass weit entfernte Punkte einen kleinen, und nahe Punkte einen großen Disparitätswert<br />
ergeben. Die Abbildungen der Punkte rücken auseinander, je näher dieser an der Stereokamera<br />
liegt.<br />
Die Stereodisparität wird dazu verwendet, ein Tiefenbild aus den zwei Einzelbildern einer Stereokamera<br />
zu berechnen, indem Featurepunkte des linken Bildes denselben Features im rechten Bild zugeordnet<br />
werden. Dies wird durch die vorangehende Rektifizierung der Kamerabilder vereinfacht, da sichergestellt<br />
ist, dass sich zueinander gehörige Merkmale auf derselben Scanline im Bild befinden. Somit muss<br />
nur in einer Dimension nach dem zugehörigen Bildpunkt gesucht werden. Berechnungslücken im Disparitätsbild<br />
können durch homogene Flächen entstehen, da diese keine Featurpunkte enhalten. Für die<br />
Disparitätsberechnung müssen die Einzelbilder möglichst zeitgleich aufgenommen werden, da sonst<br />
bei Bewegungen ein zusätzlicher Versatz zwischen den Bildern entstehen kann, der den Disparitätswert<br />
verfälscht. Die Begrenzung der Suche auf diskrete Abstandsstufen (Disparitätsstufen) kann den Rechenaufwand<br />
begrenzen.<br />
Linke Kamera Rechte Kamera Disparitätsbild<br />
mit 16 Stufen<br />
Abbildung 2.4: Durch Vergleiche der Abstände korrespondierender Features im linken und rechten Kamerabild<br />
kann für diese ein Disparitätswert berechnet und im Disparitätsbild dargestellt<br />
werden. Hierbei werden nahe Objekte hell und entfernte dunkel dargestellt.<br />
Aus der fokalen Länge f und dem Abstand B zwischen den Mittelpunkten der Kameras lässt sich folgender<br />
Zusammenhang zwischen Disparitätswert d und dem Abstand Z zu einem Objekt in der Szene<br />
anhand Abbildung 2.4 (c) über den Strahlensatz herleiten:<br />
d f<br />
=<br />
B Z<br />
Somit gilt für die Distanz eines Bildpunktes mit Disparitätswert d<br />
(2.5)
8 KAPITEL 2. GRUNDLAGEN<br />
Z =<br />
f B<br />
d<br />
X = (xc − x)Z<br />
f<br />
Y = (yc − y)Z<br />
f<br />
wobei (xc,yc) die Koordinaten des Bildmittelpunktes sind. Aus den drei Raumkoordinaten berechnet<br />
sich der Abstand zu einem Punkt P(X,Y,Z) im Raum als Länge z des Ortsvektors �p.<br />
2.1.5 Linienerkennung durch Hough-Transformation<br />
(2.6)<br />
(2.7)<br />
(2.8)<br />
z = |�p| =<br />
�<br />
X 2 +Y 2 + Z2 (2.9)<br />
Die Linienerkennung wird in der Bildanalyse oft eingesetzt, um grobe Strukturen aus Bildern zu extrahieren.<br />
Bevor in einem Bild Linien gesucht werden, wird üblicherweise zunächst ein Kantenbild<br />
berechnet. Als sehr geeignetes Verfahren steht hier der Canny Edge Detector [8] zur Verfügung. Andere<br />
Verfahren wie der Sobel Operator oder die Laplace Transformation führen ebenfalls zu guten Ergebnissen.<br />
Die Hough-Transformation ermöglicht eine Erkennung kollinearer Punkte im berechneten Kantenbild,<br />
indem die Geradengleichung y = mx + c nach c aufgelöst wird. Somit beschreibt jeder Punkt (x,y) im<br />
Bild eine Gerade im Hough-Raum (m,c) über:<br />
c = −mx + y (2.10)<br />
Es lässt sich zeigen, dass alle Hough-Geraden, die sich in einem Punkt (xi,yi) schneiden, im Bild auf<br />
einer Geraden liegen. Gleichung 2.10 lässt allerdings keine Darstellung senkrechter Geraden zu, da hier<br />
m = ±∞ wäre. Um diese Geraden ebenfalls darstellen zu können, werden die Hough-Geraden über<br />
folgende Parametrisierung als Punkte im (r,θ) Raum dargestellt.<br />
r = x ∗ cos(θ) + y ∗ sin(θ) (2.11)<br />
Hierbei ist�r der Normalenvektor auf die darzustellende Gerade mit Abstand r vom Ursprung und dem<br />
Winkel θ zur m-Achse (siehe Abbildung 2.5). Auf diese Weise können auch senkrechte Geraden (θ =<br />
±180 ◦ ) dargestellt werden.<br />
Durch die Transformation aller Punkte des Kantenbildes in den Hough-Raum ist es nun möglich, Geraden<br />
im Bild zu erkennen. Diese stellen sich, wie in [9] näher beschrieben wird, als häufige Treffer<br />
desselben Punktes in der (θ,r)-Ebene dar.
2.1. GRUNDLAGEN DER BILDVERARBEITUNG 9<br />
c<br />
r 0<br />
Θ 0<br />
g<br />
m<br />
a) Gerade im Hough-Raum b) Gerade als Punkt in der (θ,r)-Ebene<br />
Abbildung 2.5: Gerade-zu-Punkt-Transformation zur Darstellung von vertikalen Geraden. Diese Transformation<br />
wird eingesetzt, um Geraden im Hough-Raum als Punkte darzustellen. Die<br />
Erkennung von Geraden im Bild nutzt die Tatsache, dass in Hough-Geraden transformierte<br />
Bildpunkte, welche auf einer Geraden liegen, durch denselben Punkt in der<br />
(θ,r)-Ebene repräsentiert werden.<br />
2.1.6 Farbmodelle<br />
Üblicherweise werden Bilder im Computer als Folge von Rot, Grün und Blau (RGB) Werten gespeichert,<br />
da diese Repräsentation mit den Farbkanälen des Ausgabemediums (Bildschirm) übereinstimmt.<br />
Da sich Helligkeitsunterschiede auf alle drei Farbkanäle auswirken, empfiehlt sich, zur späteren Selektion<br />
eines bestimmten Farbbereichs, eine Konvertierung in einen Farbraum, der die Helligkeitsinformationen<br />
von den Sättigungs- und Farbtonwerten trennt und somit die Selektion eines bestimmten<br />
Farbbereichs zulässt.<br />
HSV Farbraum<br />
Im HSV Farbmodell werden Farben durch Helligkeit (Value), Sättigung (Saturation) und Farbton (Hue)<br />
beschrieben. Dies entspricht dem Blick entlang der Diagonalen in Abbildung 2.6 (a) von Schwarz nach<br />
Weiß und ergibt die sogenannte HSV-Farbpyramide (b).<br />
Lab Farbraum<br />
Der Lab-Farbraum (auch L*a*b-Farbraum) ist ein von der Commission Internationale d’Eclairage (CIE)<br />
1976 entwickeltes Farbmodell. Neben dem HSV-Modell eignet sich der Lab-Farbraum besonders gut zur<br />
wahrnehmungsorientierten Selektion von Farben, da er an die menschliche Farbwahrnehmung angepasst<br />
und geräteunabhängig ist. Im Lab-Raum werden die drei Farbkanäle (RGB) auf einen Helligkeitswert<br />
(L), einen rot-grün Wert (a) und einen blau-gelb Anteil (b), wie in [10] näher beschrieben wird, aufgeteilt.<br />
Abbildung 2.7 zeigt die Farbanteile bei unterschiedlichen Luminanzwerten.<br />
r 0<br />
r<br />
Θ 0<br />
Θ
10 KAPITEL 2. GRUNDLAGEN<br />
a) RGB Farbwürfel b) HSV-Farbpyramide<br />
Abbildung 2.6: RGB-Würfel und HSV-Farbmodell. Das HSV-Modell ergibt sich aus dem Blick entlang<br />
der Diagonalen von Schwarz nach Weiß im RGB-Würfel und eignet sich besonders<br />
zur wahrnehmungsorientierten Selektion von Farbtönen in Bildern, da hierfür nur ein<br />
bestimmter Winkelbereich H betrachtet werden muss.<br />
25 % Luminanz 50 % Luminanz 75 % Luminanz<br />
Abbildung 2.7: Lab-Farben für verschiedene Luminanzwerte. Die Farben erscheinen für gleiche Luminanzwerte<br />
in guter Näherung gleich hell. Luminanz Null entspricht Schwarz, eine<br />
Luminanz von 100 Prozent entspricht Weiß.
2.2. STAND DER FORSCHUNG 11<br />
2.1.7 Regiongrowing<br />
Als „Regiongrowing“ wird ein Verfahren bezeichnet, bei dem der Bereich um einen Startpunkt solange<br />
vergrößert wird, bis die Farbwerte größer als ein vorgegebener Schwellwert sind. Über dieses Verfahren<br />
ist es möglich, ausgehend von einem zufällig gewählten Startpunkt, Regionen ähnlicher Farbe im Bild<br />
zu finden und für die spätere Weiterverarbeitung zu markieren.<br />
Abbildung 2.8 (a) zeigt ein Beispielbild, für das in (b) ein Regiongrowing-Algorithmus verwendet wurde,<br />
um ausgehend vom Zentrum des Objektes das Objekt zu segmentieren.<br />
a) Beispielszene b) Markierung von Objekten durch Selektion<br />
Abbildung 2.8: Regiongrowing-Algorithmus zur farbtonbasierten Selektion. Die Objekte im Bild (a)<br />
werden von einem Startpunkt aus mit Farbe gefüllt, indem solange der Bereich um<br />
den Startpunkt mit einbezogen wird, bis sich die Farbwerte zu stark von denen des<br />
Startpunktes unterscheiden. Bild (b) zeigt die so segmentierten Bildbereiche.<br />
2.2 Stand der Forschung<br />
Die bisher veröffentlichten Verfahren zur Unterstützung von Blinden bei der Navigation konzentrieren<br />
sich auf die Lösung folgender Aufgaben.<br />
• Bestimmung der eigenen Position<br />
• Erkennung von Objekten in der Umgebung<br />
• Erkennung von Hindernissen / Gefahren<br />
• Navigation<br />
Häufig wird nur einer dieser Aspekte durch bestehende Lösungen abgedeckt. Die folgenden Abschnitte<br />
beschreiben den Stand der Forschung in diesen Bereichen und machen die Notwendigkeit der Verbindung<br />
aller Teilgebiete zur Lösung der hier behandelten Aufgabe deutlich.
12 KAPITEL 2. GRUNDLAGEN<br />
Erkennung von Hindernissen<br />
Der von Ulrich et al. vorgestellte GuideCane [11] ermöglicht es Hindernissen auszuweichen, aber nicht<br />
die zielgerichtete Leitung des Blinden zu einem gesuchten Raum im Gebäude, da die Information über<br />
die eigene Position fehlt und nur auf Objekte im direkten Umfeld des Benutzers reagiert wird. Da diese<br />
Objekte nur als Hindernisse erkannt werden, bleiben Informationen wie der Zustand von Türen unberücksichtigt.<br />
Erkennung der eigenen Position<br />
Projekte wie das Signpost-Projekt von Studierstube [12], welches die Positionsbestimmung ebenfalls<br />
über Stereokamera und Inertialsensor realisiert, sowie das von Chaitanya et al. in [13] vorgestellte System<br />
zur Navigation anhand von RFID-Tags verwenden Landmarken zur Selbstlokalisation. Sie setzen<br />
deshalb eine mit Markierungen präparierte Umgebung voraus, auf die in diesem Ansatz komplett verzichtet<br />
werden sollte. Die Lösungen aus der Robotik kommen oft auch ohne diese Präparationen aus,<br />
verwenden aber Ultraschall- oder Lasermessgeräte, um ihre eigene Position im Raum zu bestimmen.<br />
Diese sind mit diversen Problemen behaftet. Laserlicht wird von bestimmten Materialien stark gestreut<br />
oder nicht reflektiert. Bei Ultraschall ist die Interpretation reflektierter Signale häufig vieldeutig.<br />
Kombrink stellt in seiner Diplomarbeit [14] einen Ansatz vor über den die Position eines Inertialsensors<br />
durch die Messung von Beschleunigungen, welche bei der Bewegung auftreten, berechnet werden kann.<br />
Dieser Ansatz setzt keine Marker in der Umgebung voraus, ist aber anfällig für magnetischen Störungen,<br />
da diese aufgrund fehlender weiterer Sensoren kaum kompensiert werden können.<br />
Erkennung von Objekten in der Umgebung<br />
In der Umgebung von Blinden kommen häufig auch verschiebbare Objekte (wie zum Beispiel Stühle) als<br />
Hindernisse vor, deren Position im Modell nicht immer aktuell gehalten werden kann. Um die Position<br />
erkannter Objekte im Modell zu aktualisieren, wird die in der Robotik oft angewandte Erkennung anhand<br />
von Farbe und Form in diesem Ansatz mit einigen Erweiterungen weiterverwendet.<br />
Fazit<br />
Der hier vorgestellte Prototyp versucht, die Teillösungen der beschriebenen Ansätze zu kombinieren und<br />
durch „geschickt gewählte“ Vergleiche mit Modelldaten, allein aus Stereobild und Richtungssensor die<br />
eigene Position und die Beschaffenheit seiner Umgebung zu bestimmen. Dies ermöglicht dem blinden<br />
Benutzer die Navigation durch unbekannte Gebäude, ohne auf fremde Hilfe, schwere Sensorhardware<br />
oder eine speziell präparierte Umgebung angewiesen zu sein. In den nächsten Abschnitten werden Vorarbeiten<br />
und Application Programming Interfaces (APIs) beschrieben. In Kapitel 4 wird ihre Eignung<br />
zur Implementierung des Navigationsassistenten untersucht. Entsprechend ihrer Eignung werden sie zur<br />
Lösung einiger Teilaufgaben eingesetzt.
2.3. VORARBEITEN UND VERWENDETE APIS 13<br />
2.3 Vorarbeiten und verwendete APIs<br />
Dieser Abschnitt beschreibt die Vorarbeiten, die zur Lösung einiger Teilprobleme verwendet wurden<br />
und verweist auf die zur Implementierung eingesetzten Bibliotheken und APIs.<br />
2.3.1 Farbklassifizierung<br />
Hub und Teufel stellen in [15] ein Modell zur Klassifikation von Farben entsprechend der menschlichen<br />
Farbwahrnehmung vor. Dieses Modell basiert auf psychophysischen Experimenten zum simultanen<br />
Farbkonstrast und zur Farbbenennung und trägt dem Einfluss benachbarter Farben auf die wahrgenommene<br />
Farbe Rechnung. Es lässt sich auf reale Szenen anwenden, um die wahrgenommene Farbe<br />
einer Bildregion unabhängig vom Hintergrund zu bestimmen und lässt sich somit zur Suche nach Objekten<br />
mit bekannter Farbe in der Bildanalyse einsetzen.<br />
2.3.2 Navigation Assistance System (NAS)<br />
Hub et al. stellen in [16] den Prototyp eines Navigationsassistenten vor (siehe Abbildung 2.9). Dieser<br />
unterstützt Blinde bei der Navigation in Gebäuden und ermöglicht die Identifikation von Objekten durch<br />
Vergleiche mit einem 3D-Gebäudemodell. Die Positionsbestimmung im Gebäude ist in diesem Navigationsassistenten<br />
über ein Wireless-LAN (WLAN) Positionierungssystem realisiert. Anhand der Position<br />
des Benutzers können aus dem verwendeten Gebäudemodell Navigationshinweise abgeleitet und über<br />
eine Sprachausgabe an den blinden Benutzer weitergegeben werden. Die hier vorgestellte Diplomarbeit<br />
setzt auf diesem Prototyp auf und versucht, durch Einsatz einer selbstsynchronisierenden Stereokamera<br />
die Positionsbestimmung weiter zu verbessern.<br />
Abbildung 2.9: Prototyp eines Navigationsassistenten mit integrierter Kamera und Inertialsensor. Das<br />
Handgerät kann an einem Blindenstock befestigt werden. Die Bestimmung der eigenen<br />
Position wird bisher über das im angeschlossenen Laptop integrierte WLAN-Modul<br />
gelöst.
14 KAPITEL 2. GRUNDLAGEN<br />
Rogler stellt in ihrer Diplomarbeit [17] eine Designstudie vor, die den mobilen Navigationsassistenten<br />
komplett in einen Blindenstockgriff integriert (siehe Abbildung 2.10). Sie zeigt in ihrer Arbeit die Anforderungen<br />
auf, die zukünftige Navigationsassistenten erfüllen sollten, um Blinde möglichst unauffällig<br />
bei der Navigation zu unterstützen.<br />
Abbildung 2.10: Navigation Assistant System - Die Designstudie zeigt, wie in Zukunft die Sensoren in<br />
einen unauffälligen Blindenstockgriff integriert werden könnten.<br />
2.3.3 Stereo Vision based Object Distance Estimation in 3D Environment Models<br />
Li stellt in ihrer Studienarbeit [7] ein Verfahren zur Bestimmung von Objektdistanzen über die Stereodisparität<br />
in 3D-Modellen vor. Hierfür wird die Szene aus zwei kollinearen Kamerapositionen gerendert<br />
und auf diese Weise ein virtuelles Stereobildpaar erzeugt. Aus diesem kann über einen Stereoalgorithmus<br />
die Distanz zu Objekten in der Szene bestimmt werden. Der von Li verwendete Stereoalgorithmus<br />
basiert teilweise auf einer Implementierung der Carnegie Mellon Universität und benötigt auf dem verwendeten<br />
Testsystem bis zu zwei Sekunden für die Berechnung des Disparitätsbildes.<br />
2.3.4 Rapid Object Detection using Haar-like Features<br />
Lienhart et al. stellen in [18] ein Verfahren zur schnellen Erkennung von Objekten in Bildern vor (Rapid<br />
Object Detection). Sie erweitern hierfür die von Viola et al. in [19] zur Objekterkennung eingesetzte<br />
Menge der „Haar-Features“, um den Erkennungsprozess weiter zu beschleunigen. Obwohl Lienhart<br />
die Objektklassifizierung speziell zur Detektion von Gesichtern einsetzt, kann die auf dieser Arbeit<br />
aufbauende Implementierung in der OpenCV Bibliothek über die Vorlage von Beispielbildern, wie sie<br />
in [20] beschrieben wird, auch auf die Erkennung anderer Objekte trainiert werden. Auf diese Weise ist<br />
es möglich, viele Objekte im Bild über charakteristische Helligkeitsmerkmale zu erkennen.
2.3. VORARBEITEN UND VERWENDETE APIS 15<br />
2.3.5 Lucas-Kanade Optical Flow in Pyramids<br />
Es existieren diverse Verfahren zur Verfolgung des optischen Flusses (optical flow) in Bildern. Diese<br />
Arbeit verwendet das von Bouguet in [21] eingesetzte und in der OpenCV Bibliothek implementierte<br />
Verfahren zur Verfolgung von Featurepunkten über mehrere Bilder. Es wird eine iterative Anwendung<br />
des Lucas-Kanade Algorithmus [22] mit verschiedenen Suchfenstergrößen eingesetzt, um eine robuste<br />
Verfolgung der Features bei unterschiedlichen Flussgeschwindigkeiten zu realisieren.<br />
Die nächsten Abschnitte beschreiben die zur Implementierung herangezogenen APIs und begründen<br />
kurz ihre Eignung zur Entwicklung des Navigationsprototyps.<br />
2.3.6 Microsoft DirectX 9.0<br />
DirectX 9.0 ist eine von Microsoft zusammengestellte Sammlung von Application Programming Interfaces<br />
(APIs). Es wird zur Spieleprogrammierung und Entwicklung von Multimedia-Anwendungen<br />
eingesetzt. Neben der Unterstützung bei der Darstellung von 2D- und 3D-Grafik enthält DirectX die für<br />
diese Arbeit interessante DirectShow-API. Über diese können unter anderem Digitalkameras angesteuert<br />
und verwaltet werden.<br />
2.3.7 NI-IMAQ for IEEE 1394 Cameras<br />
National Instruments (NI) bietet als Zusatz zu Labview ein Bildverarbeitungsmodul zur Bildakquisition<br />
(image acquisition = imaq) und eine leicht bedienbare API für IEEE 1394 (Firewire) Digitalkameras<br />
an. Über die Integration der zugehörigen Treibersoftware in den Measurement & Automation Explorer<br />
bietet NI die Möglichkeit einer einfachen Treiberinstallation und Konfiguration der Kameras. Dank<br />
guter Beispielprogramme ist es über diese API sehr einfach, nicht nur Labview Programme, sondern<br />
auch C/C++ Applikationen zu schreiben, die eine Firewire Digitalkamera ansteuern.<br />
2.3.8 Intel Open Source Computer Vision Library (OpenCV)<br />
Die „Open Source Computer Vision Library“ (OpenCV) von Intel ist eine Sammlung von Algorithmen<br />
und Beispielprogrammen zu einer Vielzahl von Standardproblemen in der Bildverarbeitung. Diese<br />
Bibliothek eignet sich besonders zur Erstellung von Realtime-Anwendungen im Bereich der Bildanalyse<br />
und stellt die Implementierung einiger Lösungsansätze zur Objektidentifikation, Farbsegmentierung,<br />
Gesichtserkennung, Bewegungserfassung und Berechnung von Featurepunkten im Bild bereit.<br />
Die aktuelle Version 5b sowie die in dieser Arbeit eingesetzte Version 4b finden sich im SourceForge-<br />
Downloadbereich unter [23].<br />
2.3.9 OpenSceneGraph<br />
OpenSceneGraph ist ein plattformunabhängiges OpenSource Grafik-Toolkit zur Entwicklung hochperformanter<br />
Grafikanwendungen wie Flugsimulatoren, Spiele, Virtual Reality Simulationen und kann für
16 KAPITEL 2. GRUNDLAGEN<br />
wissenschaftliche Visualisierungen eingesetzt werden [24]. OpenSceneGraph basiert auf dem Szenengraphen-Konzept<br />
und bietet ein objektorientiertes Framework, welches den Programmierer von der Implementierung<br />
und Optimierung hardwarenaher Grafikbefehle befreit, indem es die Darstellung über<br />
die OpenGL-API vollständig übernimmt. Zudem bietet es viele zusätzliche Funktionen wie Kollisionserkennung<br />
und Schnittpunktberechnungen, welche dem Programmierer die Entwicklung von Grafikanwendungen<br />
erleichtern und so eine schnelle Implementierung unterstützen.<br />
Ein Szenengraph beschreibt den Aufbau von Szenen durch eine Baumstruktur. Diese wird von der Wurzel<br />
aus durch das Anhängen spezieller Knoten (Gruppierungs-, Transformations-, Farb-, Texturknoten)<br />
und Blättern (Geometrieknoten) hierarchisch aufgebaut und enthält alle Elemente der Szene. Er beschreibt<br />
auf diese Weise die räumliche Beziehung zwischen einzelnen Elementen und ihre Lage in der<br />
Szene. Aufgrund des hierarchischen Aufbaus ist eine schnelle Berechnung der im Viewing-Frustum liegenden<br />
Knoten und Blätter des Baumes und somit eine performante Darstellung der Szene möglich.<br />
Zudem können komplexe Objekte durch die Transformation ihres Vaterknotens auf einfache Weise verändert<br />
werden.<br />
2.3.10 Microsoft Foundation Classes (MFC)<br />
Die Microsoft Foundation Classes (MFC) sind eine Sammlung objektorientierter Klassenbibliotheken,<br />
die von Microsoft für das Betriebssystem Windows zur Programmierung windowsbasierter Anwendungen<br />
mit C++ entwickelt wurden.<br />
Die MFC dienen als Schnittstelle zu den nicht objektorientierten API-Funktionen des Betriebssystems<br />
und sollen den Umgang mit den vom Betriebssystem zur Verfügung gestellten Ressourcen erheblich<br />
vereinfachen. Ein Großteil der für Windows geschriebenen Programme nutzen die MFC zum Beispiel<br />
zur Darstellung von graphischen Oberflächen, wie sie auch in dieser Arbeit zur Implementierung der<br />
Kamerakalibrierungstools eingesetzt werden. Diese Oberfächen können in Microsofts Visual Studio<br />
.NET 2003 bequem über den Ressourcen-Editor gestaltet werden.
Kapitel 3<br />
Lösungsentwurf<br />
Dieses Kapitel beschreibt die Probleme, die gelöst werden müssen, um einen bildbasierten Navigationsassistenten<br />
auf Basis einer Stereokamera zu entwickeln. Es werden die Anforderungen an das System<br />
beschrieben und ein Lösungsansatz erarbeitet. Dieser ermöglicht die bildbasierte Positionsbestimmung<br />
und die Erkennung von Objekten auf aktueller, portabler Hardware. Auf die Implementierung der zur<br />
Lösung eingesetzten Klassen und Programme wird in Kapitel 4 näher eingegangen.<br />
3.1 Problembeschreibung<br />
Durch die Auswertung der über eine Sensoreinheit aufgenommenen Stereobild- und Richtungsdaten<br />
sollen blinde Benutzer genau an der Stelle unterstützt werden, an der sie durch ihre visuelle Beeinträchtigung<br />
bei der Navigation durch Gebäude gegenüber sehenden Menschen benachteiligt sind.<br />
Die Stereodisparität der Augen unterstützt sehende Menschen bei der Gewinnung von Informationen<br />
über Objektpositionen, Formen, Größenverhältnisse und Entfernungen. Zusätzlich kann über die farbempfindlichen<br />
Zapfen der Retina die Farbe der Objekte bestimmt werden. Diese Informationsgewinnung<br />
soll von einem tragbaren Navigationsassistenten übernommen werden, um die eigene Position im Gebäude<br />
und die Beschaffenheit der Umgebung an den blinden Benutzer weitergeben zu können, um ihm<br />
auf diese Weise die Navigation durch ein unbekanntes Gebäude zu erleichtern. Die Positionsbestimmung<br />
muss hierbei ohne eine spezielle Markierung der Umgebung auskommen und robust gegenüber<br />
starken Änderungen in der Beschaffenheit der Inneneinrichtung sein. Auf die Verwendung von Karten<br />
mit für spezielle Positionen aufgenommenen Messergebnissen, die dann mit den Sensordaten verglichen<br />
werden könnten, soll ebenfalls verzichtet werden. Die gewonnenen Positionsinformationen und Navigationshinweise<br />
sollen so aufbereitet sein, dass sie in kommenden Projekten dem Blinden auf möglichst<br />
einfache Weise über eine passende Schnittstelle (wie ein taktiles Display oder eine Audioschnittstelle)<br />
weitergegeben werden können.<br />
17
18 KAPITEL 3. LÖSUNGSENTWURF<br />
3.2 Lösungsansatz<br />
Dieser Ansatz versucht über die Möglichkeiten der bisher vorgestellten Arbeiten (siehe Abschnitt 2.3)<br />
hinauszugehen, indem er einige Ideen der Vorarbeiten kombiniert. Eine starke Verknüpfung zwischen<br />
Sensordaten und Modell stellt hierbei die Grundlage für die später an den Benutzer weitergegebenen<br />
Navigationsinformationen dar. Die zur Navigation des blinden Benutzers notwendige Bestimmung der<br />
eigenen Position im Raum sowie die Erkennung von Hindernissen löst dieser Ansatz durch eine kontinuierliche<br />
Anpassung einer virtuellen Umgebung an real gemessene Daten. Zur Messung der notwendigen<br />
Daten wird ein Sensormodul eingesetzt, das im folgenden Abschnitt beschrieben wird.<br />
3.2.1 Aufbau des Sensormoduls<br />
Dieser Abschnitt stellt den zur Lösung der Aufgabe eingesetzten Aufbau des Sensormoduls und die<br />
verwendete Hardware vor. Gründe für die Auswahl dieser Hardwarekomponenten werden in Abschnitt<br />
4.1 ausführlicher beschrieben.<br />
Die Entscheidung, das Sensormodul nicht wie in der in Abschnitt 2.3.2 vorgestellten Designstudie in den<br />
Blindenstock zu integrieren und darum den zugehörigen ersten Prototyp nicht zu verwenden, begründet<br />
sich in der Tatsache, dass sich die zur Selbstlokalisation in Räumen notwendigen Abstandsinformationen<br />
auf gebäudespezifische, invariante Daten wie Abstände zu Wänden und Türen beschränken. Bei allen<br />
anderen Einrichtungsgegenständen muss davon ausgegangen werden, dass sich deren Position ändern<br />
kann oder sie nicht ins Modell integriert sind. Um sicherzustellen, dass diese Informationen möglichst<br />
oft auf den Stereobildern vorhanden sind, wurde die Stereokamera, wie in Abbildung 3.1 gezeigt, auf<br />
einem Fahrradhelm montiert und bildet so, bei natürlicher Kopfhaltung, die beste Ausgangssituation für<br />
den Vergleich mit den Modelldaten.<br />
Abbildung 3.1: Aufbau des Sensormoduls. Die zur Abstandsmessung eingesetzte Stereokamera ist auf<br />
einen Fahrradhelm montiert. Zur Bestimmung der Blickrichtung ist direkt hinter der<br />
Kamera ein Inertialsensor angebracht. Dieser Aufbau ist für den hier verfolgten Lösungsansatz<br />
sehr gut geeignet und zeichnet sich durch einen vergleichsweise hohen<br />
Tragekomfort aus.
3.2. LÖSUNGSANSATZ 19<br />
Direkt hinter der Stereokamera ist ein Inertialsensor montiert. Dieser Aufbau ermöglicht es auf die<br />
bildbasierte Berechnung der Blickrichtung zu verzichten. Somit verbleibt ausreichend CPU-Leistung,<br />
um die zur Positionsbestimmung notwendigen Stereodisparitätsbilder „echtzeitnahe“ zu berechnen und<br />
diese mit dem 3D-Modell zu vergleichen. In den folgenden Abschnitten wird eine Methode vorgestellt,<br />
mit deren Hilfe die Position des Sensormoduls aus den Modell- und Sensordaten berechnet werden kann.<br />
3.2.2 Positionsbestimmung der Kamera<br />
Der hier verfolgte Lösungsansatz ermöglicht die Positionsbestimmung und Unterstützung bei der Navigation<br />
durch das Angleichen einer simulierten Umgebung an real gemessenen Daten. Zu diesem Zweck<br />
wird das im OpenSceneGraph-Format [24] vorliegende Gebäudemodell um eine virtuelle Kamera erweitert<br />
und diese solange im Modell verschoben, bis die simulierten Messungen mit den realen Daten<br />
übereinstimmen. Zu diesem Zweck durchläuft der Navigationsassistent die in den folgenden Absätzen<br />
beschriebenen Schritte.<br />
Ausrichtung der virtuellen Kamera<br />
Unter der Voraussetzung, dass der Startpunkt in Form von 3D-Ortskoordinaten oder eines Raumnamens<br />
gegeben ist, wird die virtuelle Kamera, wie in Abbildung 3.2 (a) gezeigt, im 3D-Modell am vorgegebenen<br />
Startpunkt positioniert. Die Angabe des Startpunktes muss bisher durch den Benutzer erfolgen,<br />
soll aber zukünftig durch ein gerade in der Erprobung befindliches WLAN Positionierungssystem (siehe<br />
Abschnitt ??) automatisiert werden. Der Abstand der Kamera zum virtuellen Boden wird entsprechend<br />
der vorgegebenen Größe des Benutzers angepasst.<br />
Über den hinter der Stereokamera angebrachten Inertialsensor kann die Orientierung der Sensoreinheit<br />
abgefragt und so die Blickrichtung der virtuellen Kamera an die reale Blickrichtung angeglichen werden<br />
(Abbildung 3.2 b). Der Vorteil dieser Art der Orientierungsberechnung gegenüber einer bildbasierten<br />
Blickrichtungsanalyse ist die Robustheit gegenüber Unterschieden zwischen 3D-Modell und Realität,<br />
die sonst nur durch eine ständige Aktualisierung des Gebäudemodells möglich wäre.<br />
a) Initiale Kameraposition b) Ausgerichtete Kamera<br />
Abbildung 3.2: Positionierung und Ausrichtung der virtuellen Kamera. Bild (a) zeigt die initiale Kameraposition,<br />
in (b) ist die anhand des Richtungssensors ausgerichtete Kamera dargestellt.
20 KAPITEL 3. LÖSUNGSENTWURF<br />
Generierung von Positionsvarianten<br />
Unter der Annahme, dass sich die Position der Kamera zwischen zwei aufgenommenen Stereobildern<br />
nur gering ändert, werden vier Positionsvarianten zusätzlich zur aktuellen Position�s im Modell berechnet<br />
(siehe Abbildung 3.3). Für die Positionen der Varianten eins bis vier gilt unter Berücksichtigung der<br />
aktuellen Blickrichtungsrotation R der Kamera und der Schrittweite w:<br />
⎛<br />
⎜<br />
�si = �s ∗ ⎜<br />
⎝<br />
1 0 0 0<br />
0 1 0 0<br />
0 0 1 0<br />
vx vy vz 1<br />
⎞<br />
⎟<br />
⎠<br />
mit �v = �vi und i = 1..4,<br />
�v1,2 = � 0 ±w 0 � T ∗ R, (3.1)<br />
�v3,4 = � ±w 0 0 � T ∗ R<br />
Die 3D-Szene wird an diesen Positionen aus Sicht der virtuellen Kamera gerendert. Hierbei wird das<br />
Tiefenbild der Stereokamera an geeigneten Messpunkten (Kreise in Bild 3.3 a) mit den Abstandsinformationen<br />
im Modell (Bild 3.3 b) verglichen und die Variante mit der geringsten Abweichung als neue<br />
Position der virtuellen Kamera ausgewählt. Wie die Tests des Navigationsassistenten in Kapitel 5 zeigen,<br />
ist schon über die ersten zwei Varianten eine Positionsbestimmung möglich. In diesem Falle muss<br />
der Benutzer gelegentlich den Kopf drehen, um Fehler in der Positionsbestimmung zu minimieren.<br />
a) Reale Szene<br />
b) Virtuelle Szene an Position 0 c) Mögliche Positionsvarianten 1-4<br />
Abbildung 3.3: Berechnung der besten Positionsvariante durch Vergleiche zwischen real und virtuell<br />
gemessenen Abständen. Abbildung (a) zeigt die reale Szene, welche mit der gerenderten<br />
Szene (b) verglichen werden soll. Bild (c) zeigt die möglichen Positionsvarianten<br />
der virtuellen Kamera.
3.2. LÖSUNGSANSATZ 21<br />
Abbildung 3.4: Abstandsmessung im Modell. Über den Vektor �s und den Abstand d des Fokuspunkts<br />
von der Bildebene, der von Φ bestimmt wird, kann der Ortsvektor zum Fokuspunkt �f<br />
berechnet werden. Die xy-Koordinaten des Durchstoßpunktes legen die Richtung des<br />
Strahls�l fest. Die Länge des Vektors von �f zum ersten Schnittpunkt des Strahls mit der<br />
Szene Sp ist der gesuchte Abstand.<br />
Vergleich der realen Distanzen mit dem Modell<br />
Es gibt verschiedene Möglichkeiten aus der gerenderten 3D-Ansicht die Abstandsinformationen zu gewinnen.<br />
Die Distanzmessung wird hier nicht über die Verwendung des Tiefenpuffers oder den simulierten<br />
Tiefenbildern einer virtuellen Stereokamera gelöst. Stattdessen wird anhand der xy-Position der<br />
realen Messpunkte im Kamerabild ein Strahl durch die virtuelle Szene berechnet. Durch diese Maßnahme<br />
kann später auf ein Grafikausgabemedium komplett verzichtet werden. Die Distanz vom CCD-Chip<br />
der virtuellen Kamera zum ersten Schnittpunkt mit der Szene entspricht dann dem simulierten Abstand<br />
im Modell.<br />
Zunächst wird aus der bekannten Position der Bildebene der virtuellen Kamera die Position des virtuellen<br />
Fokuspunktes, anhand des bekannten Öffnungswinkels Φ berechnet. Für die Distanz zwischen<br />
Bildebene und Fokuspunkt gilt Gleichung 3.2.
22 KAPITEL 3. LÖSUNGSENTWURF<br />
d = arctan Φ<br />
; (3.2)<br />
2<br />
Es ergibt sich, über den Ortsvektor�s zum Zentrum der Bildebene, der Vektor �f zum Fokuspunkt.<br />
�f =�s −�v ∗ d, �v : Blickrichtung (3.3)<br />
Die Zusammenhänge zwischen den Abständen und Vektoren, welche zur Berechnung eines Strahls<br />
durch die Szene verwendet werden, sind in Abbildung 3.4 dargestellt. Für den Richtungsvektor �l, der<br />
die Strahlrichtung vom Fokuspunkt zum Durchstoßpunkt in der Bildebene bei den Koordinaten (x,y)<br />
angibt, lässt sich folgender Zusammenhang herleiten:<br />
�l =�v ∗ d +�r ∗ x +�u ∗ y, �r,�u : Right/U p −Vektor der Kamera (3.4)<br />
Die Verlängerung der so gewonnenen Richtung �l ergibt einen Strahl durch die Szene, dessen erster<br />
Schnittpunkt �sp mit der gerenderten Szene den zu messenden Abstand bestimmt.<br />
zvirtuell = |�sp − �f | (3.5)<br />
Anhand der in Absatz 2.1.4 vorgestellten Gleichung 2.9 lässt sich die Distanz zreal eines Punktes im<br />
Kamerabild aus dem Disparitätswert des Tiefenbildes berechnen. Diese kann mit der Distanz im Modell<br />
zvirtuell verglichen werden. Um die Positionsvarianten effizient miteinander vergleichen zu können, wird<br />
die Summe der Abstandsdifferenzen zwischen Messpunkten in Modell und Realität für jede Variante i<br />
in einem Differenzvektor gespeichert:<br />
�di = ∑ j<br />
|zreal − zvirtuell|, j : 1..Anzahl der Messpunkte (3.6)<br />
Für Fälle, in denen die virtuelle Kamera direkt vor einer Tür positioniert ist, werden alle virtuellen<br />
Distanzen zusätzlich für eine offene Tür berechnet und der kleinere Differenzvektor ausgewählt.<br />
Aktualisierung der Position<br />
Durch den Vergleich der Differenzvektoren �di aller Varianten i ergibt sich die beste Positionsvariante<br />
als die Variante mit den kleinsten Differenzen. Für die in Abbildung 3.3 (c) dargestellte Situation<br />
stellt Position 1 die beste Lösung dar. Anhand dieser Information wird die Kameraposition im Modell<br />
aktualisiert.<br />
Über eine Translation wird die virtuelle Kamera in Richtung der besten Positionsvariante verschoben.<br />
Hierbei muss nicht zwingend derselbe Abstand verwendet werden, wie er zur Berechnung der Varianten<br />
angenommen wurde. Dieser kann, abhängig von der Größe des Fehlers, dynamisch bestimmt werden,<br />
um die Positionsfindung bei großen Differenzen zu beschleunigen und bei kleinen zu verfeinern. Auf<br />
diese Weise führt das Verfahren auch bei größeren Positionsabweichungen nach wenigen Schritten zu<br />
guten Ergebnissen.
3.2. LÖSUNGSANSATZ 23<br />
Zur Aktualisierung der Kameraposition muss zuerst der Verschiebungsvektor �vs in Richtung der besten<br />
Positionsvariante berechnet werden. Dieser ergibt sich wie in Gleichung 3.1 aus der gewählten<br />
Verschiebungsdistanz und der aktuellen Blickrichtung. Für die neue Position �s der Kamera gilt dann<br />
entsprechend:<br />
⎛<br />
⎜<br />
�s =�s ∗ ⎜<br />
⎝<br />
1 0 0 0<br />
0 1 0 0<br />
0 0 1 0<br />
vx vy vz 1<br />
⎞<br />
⎟<br />
⎛<br />
⎠ , mit �vs = ⎝<br />
vx<br />
vy<br />
vz<br />
⎞<br />
⎠ (3.7)<br />
Neben der Berechnung der besten Positionsvariante kann durch den Vergleich der X-Koordinaten korrespondierender<br />
Featurepunkte aufeinander folgender Frames eine Rotation der Sensoreinheit oder eine<br />
Translation in X-Richtung erkannt werden. Zur Bestimmung zusammengehöriger Featurepunkte kann<br />
das in Abschnitt 2.3.5 beschriebene Tracking-Verfahren eingesetzt werden. Für die Bewegungserkennung<br />
müssen die Bilddaten mit den Richtungsinformationen des Inertialsensors verglichen werden. Folgende<br />
simple Logik liefert dann Aufschluss über die aktuelle Bewegung:<br />
Alle Featurepunkte streben in eine Richtung ∧<br />
Kompass meldet Bewegung → Rotation<br />
Alle Featurepunkte streben in eine Richtung ∧<br />
Kompass meldet keine Bewegung → Translation in XRichtung<br />
Eine zusätzliche Betrachtung der Tiefeninformation aller Messpunkte ermöglicht es Z-Translationen zu<br />
erkennen, wenn die Tiefenänderung ebenfalls einen Schwellwert überschreitet.<br />
Durch eine Kollisionserkennung auf dem Szenengraphen wird verhindert, dass die Kamera bei Messfehlern<br />
durch Objekte hindurch geschoben wird. Eine solche Verschiebung wird nur zugelassen, wenn<br />
es sich bei dem betreffenden Objekt um eine Türe im Modell handelt. Ein Raumwechsel ist auf diese<br />
Weise für die virtuelle Kamera nur an Türen möglich.<br />
Erste Tests mit festen Messpunkten zeigten, dass die Qualität der Positionsbestimmung in verschiedenen<br />
Räumen wesentlich von der Wahl der Messpunkte abhängt und diese somit entscheidend für eine gute<br />
Navigationsunterstützung des blinden Benutzers ist. Der nächste Absatz vergleicht verschiedene Ansätze<br />
zur Suche nach geeigneten Messpunkten und begründet die Auswahl der im Prototyp eingesetzten<br />
Verfahren.<br />
3.2.3 Auswahl geeigneter Messpunkte<br />
Durch Fenster, Messfehler und Schwächen im Stereoalgorithmus können alle Entfernungen zwischen<br />
Unendlich und Null im realen Tiefenbild vorhanden sein. Der triviale Ansatz zu versuchen, die Punkte<br />
mit größter Tiefe als Messpunkte zu wählen, führt nicht zum gewünschten Ergebnis. Um dennoch ohne<br />
großen Rechenaufwand Punkte auf den Wänden zu finden wurden die folgenden Kriterien auf ihre<br />
Eignung als Suchkriterium für Wandpunkte verglichen:
24 KAPITEL 3. LÖSUNGSENTWURF<br />
• Farbe und Form<br />
• Helligkeitsmuster<br />
• Charakteristische Linien<br />
• Featurepunkte mit Wandabstand<br />
Farbe und Form<br />
Wie Abschnitt 2.1.7 näher beschreibt, kann über einen Regiongrowing-Algorithmus eine gleichmäßig<br />
gefärbte Fläche gefunden werden. Über das in Absatz 2.3.1 vorgestellte Verfahren kann dann die wahrgenommene<br />
Farbe der Region bestimmt werden. Die Versuche, über diesen Ansatz graue Wände zu<br />
finden, machen deutlich, dass die Festlegung der Farbe zuviele Objekte wie Boden, Decke und Computermonitore<br />
ebenfalls mit einschließt. Sie ist deshalb als Auswahlkriterium zu schwach. Die zusätzliche<br />
Vorgabe einer bestimmten Form würde die Suche zwar weiter einschränken, da sich aber keine allgemeine<br />
Form einer Wand angeben lässt, ist dieser Ansatz in großen Gebäuden nicht geeignet.<br />
Helligkeitsmuster<br />
In Abschnitt 2.3.4 wird ein Verfahren vorgestellt, das es ermöglicht, Helligkeitsmuster in einem Bild<br />
wiederzufinden. Diese Muster können dem „Rapid Object Detection“ genannten Verfahren über mehrere<br />
hundert Beispielbilder und Markierung der gewünschten Objekte antrainiert werden und dann für<br />
die Suche nach Objekten wie Türgriffen, Fenstergriffen oder Fensterecken, welche üblicherweise an<br />
Wänden zu finden sind, verwendet werden. Die nacheinander aufgenommenen Bilder in Abbildung 3.5<br />
zeigen die Ergebnisse des nach Abschnitt 2.3.4 implementierten Verfahrens. Aufgrund zu großer Helligkeitsunterschiede<br />
und der geringen Größe der Fenstergriffe wurden hier nur die Fensterecken erkannt.<br />
Diese sind aber bei natürlicher Kopfhaltung in kleineren Räumen üblicherweise nicht im Bild zu sehen.<br />
Deshalb eignen sich Fensterecken nicht allein als Suchkriterium für Punkte auf Wänden. Es wird deutlich,<br />
dass aufgrund der fehlenden Stabilität der Objekterkennung dieses Verfahren ebenfalls nicht zur<br />
Bestimmung der Messpunkte geeignet ist.<br />
Abbildung 3.5: Messpunktauswahl anhand von erkannten Objekten. Die Abbildungen zeigen die durch<br />
rote Quadrate markierten gefundenen Objekte einer Bildsequenz. Der Mittelpunkt der<br />
Quadrate könnte als Messpunkt verwendet werden.
3.2. LÖSUNGSANSATZ 25<br />
Charakteristische Linien<br />
Wie in der Aufgabenstellung beschrieben, sollte ein Algorithmus getestet werden, der es ermöglicht,<br />
allein über die Zuordnung von erkannten Linien im Kamerabild zu Kanten im Modell, die genaue Position<br />
im Raum zu bestimmen. Die dafür nötigen Linien müssen zunächst in einem Kantenbild, wie es<br />
in Abbildung 3.6 (b) dargestellt ist, erkannt und den Modellkanten (in Bild 3.6 blau, grün und gelb dargestellt)<br />
zugeordnet werden. Der Algorithmus berechnet dann über ein Näherungsverfahren die Transformationsmatrix,<br />
die notwendig ist, um die Kanten des Modells auf die gegebenen Linien abzubilden.<br />
Hieraus ließe sich die Position der Kamera zurückrechnen. Dieser Ansatz setzt allerdings voraus, dass<br />
die erkannten Linien des Kamerabildes vorher den Kanten im Modell zugeordnet werden. Harald Sanftmann<br />
löst dieses Problem der Zuordnung in seiner Diplomarbeit [25], indem er die erkannten Kanten mit<br />
Orientierungsvarianten des Modells vergleicht und die ähnlichste Orientierung auswählt. Dieser Ansatz<br />
setzt aber ein speziell vorbereitetes 3D Modell voraus, in dem keine „falschen“ Kanten (in Abbildung<br />
3.6 (d) türkis markiert) vorhanden sind. Da ein solches Modell für diese Arbeit nicht zur Verfügung<br />
stand und der Vergleich mit Modellvarianten bei komplexen Objekten zuviele Lösungen ergeben würde,<br />
kommt dieses Verfahren aufgrund der begrenzten Rechenleistung hier ebenfalls nicht zum Einsatz.<br />
a) Kamerabild b) Extrahierte Kanten des Kamerabildes<br />
c) gerendertes Modell d) Wireframe Darstellung des gerenderten Modells<br />
Abbildung 3.6: Zuordnung von erkannten Linien zu Modellkanten. Bild (a) zeigt einen typischen Gang<br />
im Gebäude. Die aus dem Kantenbild extrahierten Geraden sind in (b) dargestellt. Bild<br />
(c) zeigt die gerenderte Szene und (d) die zugehörigen Kanten im Wireframe-Modell.
26 KAPITEL 3. LÖSUNGSENTWURF<br />
Trotz der rechenaufwändigen Extraktion der Bildkanten, können diese besonders gut zur Ermittlung<br />
eines „Fluchtpunkts“ am Gangende, über den Schnittpunkt der blauen und grünen Linien aus Abbildung<br />
3.7 (e) berechnet werden. Dies ermöglicht die Positionierung der Abstandsmesspunkte auf die in Gängen<br />
entscheidenden Messpunkte am Ende des Ganges (gelber Kreis), da sich alle anderen Abstände, wie in<br />
den roten Linien in Abbildung 3.7 (f) gezeigt, für verschiedene Kamerapositionen kaum unterscheiden.<br />
e) Fluchtpunktabschätzung f) Signifikante Abstände im Gang<br />
Abbildung 3.7: Schnittpunkt von Diagonalen in langen Gängen. Bild (e) zeigt, dass der Schnittpunkt<br />
von Diagonalen im Bild in Richtung des Gangendes liegt. Dieser markiert den einzigen<br />
signifikanten Abstand zum Sensormodul.<br />
Ein Vergleich der Position des Fluchtpunktes in realem und gerendertem Kamerabild kann zusätzlich<br />
zur Detektion von Abweichungen zwischen realer und virtueller Blickrichtung eingesetzt werden. Aus<br />
der Distanz z zum Fluchtpunkt und dem Unterschied der X-Koordinaten der Fluchtpunkte dx kann der<br />
Offset der virtuellen Kamera über Gleichung 3.8 für kleinere Abweichungen berechnet und korrigiert<br />
werden. Bei zu großen Abweichungen muss der Offset bei diesem Verfahren vom Benutzer manuell<br />
nachgestellt werden.<br />
Featurepunkte mit Wandabstand<br />
θO f f set = arctan( dx<br />
) (3.8)<br />
z<br />
Aufgrund der hohen Rechenzeit der vorangegangenen Verfahren wurde eine Methode entwickelt, bei<br />
der die Tiefeninformationen an geeigneten Featurepunkten (siehe Abschnitt 2.1.1) mit einem „Wandabstandsschätzwert“<br />
verglichen werden. Dieser Schätzwert wird nach dem in Abschnitt 4.3.1 implementierten<br />
Verfahren ermittelt und ermöglicht die Filterung der gefundenen Featurepunkte.<br />
Abbildung 3.8 (a) zeigt das Ergebnis einer solchen Filterung und stellt Featurepunkte mit zu kleinem Abstand<br />
weiß, Punkte mit zu großem Abstand rot und die Features mit Wandabstand gelb dar. Dieser Ansatz<br />
zeichnet sich durch seine hohe Geschwindigkeit und eine große Robustheit gegenüber Störungen aus.<br />
Er liefert über mehrere Bilder stabile Messpunkte (Abbildung 3.8 b), die mit hoher Wahrscheinlichkeit<br />
auf der Wand zu liegen kommen. Da sich das Verfahren zur Wandabstandsschätzung nur für annähernd
3.2. LÖSUNGSANSATZ 27<br />
a) b)<br />
Abbildung 3.8: Die Featurepunkte in (a) und (b) sind entsprechend ihrer Einstufung anhand eines<br />
Wandabstandsschätzwertes in drei Farben kodiert. Weiße Punkte sind zu nahe, gelbe<br />
haben ungefähr Wandabstand und rote Punkte sind zu weit entfernt um auf der Wand<br />
zu liegen.<br />
quadratische Räume eignet, muss bei langen Gängen auf das zuvor vorgestellte Fluchtpunkt-Verfahren<br />
zurückgegriffen werden.<br />
Abbildung 3.9 fasst die Geschwindigkeitsunterschiede der vorgestellten Verfahren in einem Diagramm<br />
zusammen. Das schnellste Verfahren wird als 100 Prozent Marke angenommen. Es zeigt sich, dass<br />
das zuletzt vorgestellte Verfahren bis zu drei mal schneller ist als die vorangegangenen Ansätze. Dies<br />
begründet sich hauptsächlich durch die schnelle Berechnung des Abstandsschätzwertes und der Featurepunkte,<br />
da für diese Berechnungen kein Kantenbild berechnet werden muss.<br />
Wiederverwendung der Messpunkte über mehrere Bilder<br />
Durch den Einsatz eines Verfahrens zur Verfolgung der gewählten Messpunkte über mehrere Bilder,<br />
wie es Lucas und Kanade 1981 vorgestellt haben (siehe Abschnitt 2.3.5), muss die „teure“ Berechnung<br />
der Messpunkte nur durchgeführt werden, wenn diese nicht mehr im Bild gefunden werden. Um die<br />
Messpunkte möglichst gleichmäßig über das aufgenommene Bild zu verteilen, wird es wie in Abbildung<br />
3.3 (a) gezeigt, in neun Quadranten eingeteilt.<br />
Zur Selbstlokalisation werden nur die oberen sechs Quadranten eingesetzt. Dies begründet sich mit<br />
dem Aufbau des Sensormoduls, da bei natürlicher Kopfhaltung üblicherweise im unteren Drittel des<br />
Bildes nur Einrichtungsgegenstände oder der Boden zu sehen sind. Verlässt einer der Messpunkte den<br />
ihm zugeordneten Quadranten, wird nur für diesen Teil des Bildes ein neuer Messpunkt auf der Wand<br />
berechnet. Für diese Neuberechnung werden, abhängig von der Form des aktuellen Aufenthaltsraums,<br />
entweder Featurepunkte auf der Wand gesucht oder Messpunkte am Gangende festgelegt. Dies ermöglicht<br />
eine gute Positionsbestimmung in vielen unterschiedlichen Räumen bei vergleichsweise hohen<br />
Frameraten.
28 KAPITEL 3. LÖSUNGSENTWURF<br />
Abbildung 3.9: Geschwindigkeitsvergleich zw. Messpunkt-Such-Verfahren. Das schnellste Verfahren<br />
wurde als Referenz mit 100 Prozent angenommen. Es wird deutlich, dass alle anderen<br />
Verfahren wesentlich langsamer arbeiten und sich das neu entwickelte Verfahren somit<br />
am besten zur Positionsbestimmung in Räumen eignet.<br />
3.2.4 Detektion von verschiebbaren, modellierten Objekten<br />
Der hier vorgestellte Ansatz zur Erkennung von Objekten nutzt die Kombination der Farb- und Tiefeninformationen<br />
des Kamerabildes, um Objekte im Bild anhand einer Objektbeschreibung wieder zu<br />
erkennen. Hierzu werden einige der Vorarbeiten dieses Gebietes kombiniert und um die Informationen<br />
aus dem Disparitätsbild erweitert. Die Erkennung der Orientierung von Hindernissen wird von Sanftmann<br />
für rechteckig modellierte Objekte beschrieben [25].<br />
In dieser Arbeit werden die folgenden drei Schritte sukzessive angewandt, um zu entscheiden, ob ein<br />
Bereich im Bild das gesuchte Objekt enthält.<br />
1. Suche nach gleichfarbigen Regionen<br />
2. Vergleich der Farbe<br />
3. Vergleich der Form
3.2. LÖSUNGSANSATZ 29<br />
1. Suche nach gleichfarbigen Regionen<br />
Die Suche nach homogenen Regionen im Bild nutzt das in der OpenCV Bibliothek implementierte<br />
Regiongrowing-Verfahren (siehe Abschnitt 2.1.7) um ähnlichfarbige Regionen im Bild zu finden. Hierfür<br />
wird das Verfahren an verschiedenen, über das Bild verteilten Startpunkten aufgerufen. Abbildung<br />
3.11 zeigt die so segmentierten Farbregionen im Kamerabild.<br />
a) Kamerabild b) Markierung der homogenen Farbregionen<br />
Abbildung 3.10: Farbsegmentierung über Regiongrowing. Homogene Flächen im Bild (a) werden zur<br />
Segmentierung mit Farbe gefüllt. Bild (b) zeigt die so gefundenen Regionen.<br />
Wird der Szene ein weiterer Stuhl hinzugefügt, färbt der Standard-Regiongrowing-Algorithmus diesen<br />
mit derselben Farbe ein, wenn dieser zu nahe an einem gleichfarbigen Stuhl positioniert ist (siehe Abbildung<br />
3.11 (a) linker und mittlerer Stuhl). Um diesen Effekt zu verringern wurde das Regiongrowing-<br />
Verfahren so erweitert, dass es zusätzlich die Unterschiede im Tiefenbild berücksichtigt und bei zu<br />
starker Änderung der Tiefe die Expansion der Region beendet. Das Ergebnis dieser Methode ist in Abbildung<br />
3.11 (b) dargestellt. In diesem Falle wird der mittlere Stuhl nicht in die Region des linken Stuhls<br />
mit einbezogen, sondern als eigenständiger Bereich betrachtet und mit einer anderen Farbe gefüllt.<br />
a) Ohne Tiefenbild, zwei segmentierte Stühle b) Mit Tiefenbild, drei segmentierte Stühle<br />
Abbildung 3.11: Regiongrowing mit und ohne Berücksichtung der Tiefenunterschiede. Wird die Tiefe<br />
mit einbezogen, können die Objekte besser unterschieden werden.
30 KAPITEL 3. LÖSUNGSENTWURF<br />
Für die Entscheidung, ob der gefüllte Bereich das gesuchte, modellierte Objekt enthält, wird die Farbe<br />
und Form der gefundenen Region mit einer Modellbeschreibung verglichen. Die Modellbeschreibung<br />
enthält für diesen Zweck drei Informationen über den zu suchenden Gegenstand:<br />
1. Name der Farbe<br />
2. Histogrammwerte der Farbe<br />
3. Form-Muster<br />
Diese sind in die Modellbeschreibungsdateien _description_i.txt und ein Form-Muster Bild<br />
kodiert, wobei die Art des Objektes und i die Nummer der Beschreibung bezeichnet. Für<br />
Stühle kann eine solche Modellbeschreibung folgendermaßen aussehen:<br />
rot<br />
chair_tpl_0.bmp<br />
0 255.0<br />
1 0.0<br />
...<br />
14 0.0<br />
15 78.0<br />
a) Beschreibungsdatei b) Histogrammbild aus 16 c) Form-Muster<br />
vorgegebenen Farbtönen (chair_tpl_0.bmp)<br />
Abbildung 3.12: Modellbeschreibung für einen roten Stuhl bestehend aus Modellbeschreibung mit Histogrammwerten<br />
wie sie in (b) dargestellt sind und einem Form-Muster für die Stuhllehne<br />
(c).<br />
Anhang A.3.1 beschreibt, wie eine solche Beschreibung durch simples Betrachten der Objekte erzeugt<br />
und abgespeichert werden kann. Es empfiehlt sich, für ein Objekt mehrere Beschreibungsdateien aus<br />
verschiedenen Blickwinkeln und mit unterschiedlicher Beleuchtung anzufertigen, um das gesuchte Objekt<br />
in möglichst vielen Situationen wiederzufinden.<br />
Vergleich der Farbe<br />
Anhand des im Abschnitt 2.3.1 vorgestellten Farbklassifikationsverfahrens von Hub und Teufel kann<br />
die wahrgenommene Farbe einer gefundenen Region bestimmt und mit dem Farbnamen in der Modellbeschreibung<br />
verglichen werden. Dies ermöglicht es zu entscheiden, ob der gefüllte Bildbereich das<br />
gesuchte, modellierte Objekt enthalten könnte. Ist dieser „Farbnamentest“ positiv, werden zusätzlich die<br />
in 16 Farbtöne (siehe Abbildung 3.13) eingeteilten Histogrammwerte der Bildregion im HSV Raum berechnet.<br />
Diese werden dann mit den vorgegebenen Farbwerten der Modellbeschreibung verglichen. Die<br />
hier verwendete Farbeinteilung in 16 Stufen wird auch im CamShift („Continuously Adaptive Mean-<br />
SHIFT“) Algorithmus von OpenCV [26] eingesetzt um Objekte mit speziellen Farben zu verfolgen.
3.2. LÖSUNGSANSATZ 31<br />
Abbildung 3.13: Farbtöne des Histogramms. Für den Vergleich zwischen Modell und Realität werden<br />
im HSV-Raum die Werte von 16 Farbtönen in der segmentierten Region berechnet.<br />
Vergleich der Form<br />
Ergibt die Farbklassifizierung den in der Beschreibung angegebenen Farbnamen und ähnliche Histogrammwerte,<br />
wird zusätzlich die Form der Region verglichen um sicherzustellen, dass die getestete<br />
Region wirklich das gesuchte Objekt und nicht nur einen ähnlichfarbigen Gegenstand enthält. Für diesen<br />
Vergleich stellt die OpenCV Bibliothek ein Verfahren zum Vergleich der HuMomente (HuMoments)<br />
[27] in Bildern bereit. Diese setzen sich aus sieben speziellen Richtungsableitungen des Bildes zusammen<br />
von denen bewiesen ist, dass sie unabhängig von Rotation und Skalierung des Bildes sind.<br />
Besteht eine Region alle drei Tests, wird die Mitte ihrer Oberkante zur Berechnung der Distanz zob j zum<br />
Betrachter aus dem Disparitätsbild eingesetzt.<br />
Positionsbestimmung der Objekte<br />
Anhand des Ortsvektors zur eigenen Position �f im Raum, wie sie nach Abschnitt 4.3 berechnet wurde,<br />
und der gemessenen Distanz zob j zu einem gefundenen, modellierten Objekt kann die Position �pob j<br />
des Objektes über Gleichung 3.10 berechnet werden. Diese leitet sich direkt von der in Abschnitt 3.2.2<br />
gezeigten Gleichung 3.4 für einen Strahl durch die Bildebene an der Position (x,y) ab. Für die Richtung<br />
des Strahles gilt wieder:<br />
�l =�v ∗ d +�r ∗ x +�u ∗ y, �r,�u : Right − /U p −Vektor (3.9)<br />
wobei d die nach Gleichung 3.2 bestimmte Distanz vom Fokuspunkt zur Bildebene und �v die aktuelle<br />
Blickrichtung der virtuellen Kamera ist. Für die Position des gefundenen, modellierten Objektes gilt<br />
dann:<br />
3.2.5 Aktualisierung des Modells<br />
�pob j = �f + �l<br />
|�l| ∗ zob j<br />
(3.10)<br />
Dieser Abschnitt beschreibt die Nutzung der ermittelten Positionsinformationen zur Unterstützung blinder<br />
Benutzer bei der Navigation durch ein unbekanntes Gebäude.<br />
Zunächst werden die Positionen der verschiebbaren, modellierten Objekte, welche nach dem im letzten<br />
Abschnitt beschriebenen Verfahren gefunden wurden, genutzt, um verschobene Hindernisse im Modell<br />
zu aktualisieren. Dies wird durch die Berechnung von Änderungstransformationen ermöglicht, welche<br />
die gefundenen Objekte in der virtuellen Szene an ihre neue Position verschieben. Hierfür ist die Suche
32 KAPITEL 3. LÖSUNGSENTWURF<br />
des gefundenen Objekts im Szenengraphen-Ast des aktuellen Aufenthaltsraumes erforderlich. Enthält<br />
dieser mehrere gleiche, verschiebbare Objekte, werden diese ohne Berücksichtigung ihrer vorherigen<br />
Position neu positioniert, indem ihnen im Szenengraphen ein neuer Transformationsknoten angehängt<br />
wird. Dieser transformiert die Objekte von ihrer ursprünglichen Position an die nach Gleichung 3.10<br />
bestimmte neue Position. Auf diese Art entsteht ein neues 3D-Modell mit aktualisierten Positionen aller<br />
modellierter Hindernisse. Das so gewonnene 3D-Modell kann nun verwendet werden, um den Benutzer<br />
bei der Navigation durch ein unbekanntes Gebäude zu unterstützen.<br />
Visuelle Darstellung der Navigationshinweise für den blinden Benutzer<br />
a) Aktueller Aufenthaltsraum und Abstand zum b) Warnung vor Hindernissen<br />
Objekt im Bildzentrum<br />
c) Information über den Zustand einer Tür d) Tür im Kamerabild (ist offen)<br />
Abbildung 3.14: Nach akustischer Umsetzung können visuelle Navigationshinweisen dem blinden Benutzer<br />
Aufschluss über den aktuellen Aufenthaltsraum und den Abstand zu modellierten<br />
Objekten geben, oder vor Gefahren warnen. Bild (a) zeigt den aktuellen Aufenthaltsraum<br />
und den Abstand zum Objekt in der Mitte des Blickfeldes an. Bild (b) zeigt<br />
eine Warnung vor einem Hindernis. Bild (c) zeigt eine als offen erkannte Tür.
3.2. LÖSUNGSANSATZ 33<br />
Die Selbstlokalisation des Navigationsassistenten über Stereokamera und Richtungssensor gibt dem<br />
blinden Benutzer Auskunft über seinen aktuellen Aufenthaltsraum. Ein Abtaststrahl im Zentrum des virtuellen<br />
Blickfeldes ermöglicht ihm zudem die Erforschung der Umgebung durch einfaches „Umsehen“.<br />
Die Namen und die Distanzen der vom virtuellen Abtaststrahl getroffenen Objekte (siehe Abbildung<br />
3.14 (a) orange markiert) können Aufschluss über die Beschaffenheit der Umgebung geben. Durch die<br />
Extrapolation der augenblicklichen Bewegung kann über eine modellbasierte Kollisionserkennung vor<br />
Hindernissen gewarnt werden (siehe Abbildung 3.14 (b)). Der Vergleich zwischen realen und virtuellen<br />
Abständen ermöglicht zudem einen Hinweis auf den Zustand von Türen (Abbildung 3.14 (c-d)).<br />
Der Blinde erhält vom Navigationsassistenten somit zusätzliche Informationen über seine Umgebung,<br />
welche ihm die Navigation durch das fremde Gebäude erleichtern können.<br />
Die in diesem Kapitel beschriebenen Schritte, die zur Realisierung einer Navigationsunterstützung notwendig<br />
sind, wurden im Diagramm 3.15 als Designentwurf des zu implementierenden Prototyps zusammengefasst.<br />
Die Eingabedaten sind durch Rechtecke und die zur Navigationsunterstützung notwendigen<br />
Berechnungen als Ellipsen dargestellt. Das nächste Kapitel beschreibt die Implementierung der zur Ansteuerung<br />
der Sensoren notwendigen Klassen. Es stellt zudem die zur Generierung des 3D-Modells im<br />
OpenScneneGraph-Format eingesetzte Software vor und geht auf einige Implementierungsdetails des<br />
im Lösungsansatz beschriebenen Navigationsassistenten ein.<br />
Realität vs<br />
Modell<br />
Neuberechnung auf Anfrage<br />
Farbbild<br />
Tiefenbild<br />
Objekterkennung<br />
Objektbeschreibung<br />
2D Bildpositionen<br />
Sensordaten Modelldaten<br />
Tiefenbild<br />
Richtung<br />
Positionsbestimmung<br />
Szenengraph<br />
Kontinuierliche Neuberechnung<br />
3D Raumpositionen<br />
Berechnung der<br />
Änderungstransformationen<br />
Aktualisierung des<br />
3D-Modells<br />
Abbildung 3.15: Systemdesign des Navigationsassistenten. Die rechteckig markierten Eingabedaten<br />
aus Realität und Modell werden in drei Schritten ausgewertet, um die eigene Position<br />
zu bestimmen und das 3D-Modell zu aktualisieren. Eigene Position und Bewegungsrichtung<br />
können verwendet werden, um dem Benutzer Informationen über seine<br />
Umgebung bereit zu stellen und ihn vor Hindernissen zu warnen.
Kapitel 4<br />
Implementierung<br />
Dieses Kapitel beschreibt die Umsetzung des in Abschnitt 3.2 vorgestellten Lösungsansatzes und die<br />
zur Lösung der einzelnen Teilaufgaben implementierten Klassen. Die Struktur des implementierten Navigationsprogramms<br />
folgt dem in Abbildung 3.15 dargestellten Systemdesign.<br />
Zunächst müssen die Sensordaten erfasst und entsprechend aufbereitet werden, um diese dann mit den<br />
Modelldaten vergleichen zu können. Der nächste Abschnitt beschreibt die Auswahl und Ansteuerung<br />
der hierfür notwendigen Sensorhardware, die schließlich im Prototyp (siehe Abschnitt 3.2.1) eingesetzt<br />
wurde.<br />
4.1 Sensordatenerfassung<br />
Über das Nexus-Teilprojekt D2 standen eine Vielzahl an IEEE-1394 (Firewire) Digitalkameras und anderen<br />
Sensoren zur Verfügung. Diese wurden zu Beginn dieser Arbeit vor dem Erwerb einer „Bumblebee“-<br />
Kamera, in den ersten Monaten der Arbeit, auf ihre Eignung zur Gewinnung der Disparitätsbilder getestet.<br />
Folgende drei als Stereokamera konzipierten Module standen zur Verfügung:<br />
a) Unibrain Fire-i Digitalkameras b) Hand-geführtes Modul c) Brillenmodul<br />
Abbildung 4.1: Kamera-Module zur Erfassung von Stereobildern<br />
Unibrain Fire-i Kamera: Die in Abbildung 4.1 (a) gezeigten Unibrain Fire-i Kameras wurden in 8,5<br />
Zentimeter Abstand auf einer Aluschiene befestigt und bilden den ersten Testkandidaten.<br />
35
36 KAPITEL 4. IMPLEMENTIERUNG<br />
NAS Prototyp: In der in Abschnitt 2.3.2 vorgestellten Forschungsarbeit von Hub wird der Navigationsassistent<br />
als Handgerät umgesetzt. In diesem sind, neben anderen Sensoren, zwei Point Grey Firefly<br />
Kameras in einen Blindenstockgriff mit Steuerungstastatur integriert.<br />
Brillenmodul mit Point Grey Fireflys: Um den Vergleich mit den Modelldaten für die Positionsbestimmung<br />
zu vereinfachen, wurden in diesem Testkandidaten zwei Point Grey Firefly Kameras auf<br />
einer Brille befestigt. Aufgrund der im Vergleich zum Blindenstock eher ruhigen Haltung des Kopfes<br />
wird durch diesen Aufbau ein stabileres Kamerabild erreicht.<br />
Die drei Stereokameras wurden kalibriert und auf ihre Eignung für den zu entwerfenden Navigationsassistenten<br />
geprüft. Hierfür musste zunächst ein Konzept zur einheitlichen Ansteuerung aller Kameras<br />
erstellt und ein Programm zur Kalibrierung implementiert werden.<br />
4.1.1 Ansteuerung der Kameras<br />
Aufgrund der bisherigen Verwendung von Windows in diesem Nexus-Teilprojekt und der vergleichsweise<br />
einfachen Möglichkeit, unterschiedlichste Hardware mit diversen Treibern an verschiedenen Schnittstellen<br />
zu testen, setzt die hier vorgestellte Arbeit ebenfalls auf den Einsatz des Redmonder Betriebssystems.<br />
Hier stehen zur Ansteuerung von Firewire-Kameras diverse Application Programming Interfaces<br />
(APIs) und Bibliotheken zur Verfügung. Unter den bekanntesten in Industrie und Forschung finden sich:<br />
• Microsofts DirectShow (siehe Abschnitt 2.3.6)<br />
• National Instruments Image Aquisition (IMAQ) for IEEE 1394 Cameras (siehe Abschnitt 2.3.7)<br />
• Intels OpenCV (siehe Abschnitt 2.3.8)<br />
Der nächste Abschnitt beschreibt die zu Beginn der Arbeit getesteten APIs und bewertet ihre Eignung<br />
zur Ansteuerung der Kameras. Die synchrone Bildaufnahme zweier baugleicher Kameras ist hierbei ein<br />
besonderes Kriterium, da dies für die Berechnung von Stereodisparitätsbildern, wie sie im Abschnitt<br />
4.1.2 beschrieben wird, bei bewegter Kamera unerlässlich ist.<br />
Test verschiedener APIs<br />
Microsoft stellt über das in DirectX 9.0 (siehe Abschnitt 2.3.6) integrierte DirectShow API die Möglichkeit<br />
zur Ansteuerung von Firewire-Kameras über die Identifikationsnummer (ID) zur Verfügung.<br />
Hierfür müssen die entsprechenden Windows-Treiber für die Kameras installiert werden, welche für<br />
die verschiedenen Kameras in unterschiedlich stabilen Versionen zur Verfügung standen. Das niedrige<br />
Abstraktionsniveau der DirectShow-API ermöglicht zwar die hardwarenahe Ansteuerung der Kameras,<br />
das Senden eines Synchronisationsimpulses (Trigger Impuls) ist aber dennoch nicht vorgesehen. Eine<br />
synchrone Ansteuerung der Kamera muss deshalb über den DirectX Synch-Filter implementiert werden.<br />
Da diese Möglichkeit der Synchronisation bereits in der CvCam Klasse von OpenCV eingesetzt wird,<br />
wurde dieser Ansatz nicht nochmals implementiert.
4.1. SENSORDATENERFASSUNG 37<br />
Das von National Instruments (NI) als Zusatz zu Labview zur Verfügung gestellte IMAQ API (siehe<br />
Abschnitt 2.3.7) bietet durch eine hohe Abstraktion von der Hardware eine komfortable Möglichkeit,<br />
über wenige Befehle Firewire-Kameras anzusteuern. Es setzt hierfür allerdings den Einsatz der NI eigenen<br />
IMAQ Firewire-Treiber voraus. Diese können über den Measurement & Automation Explorer von<br />
NI komfortabel installiert und getestet werden. Der Vorteil der IMAQ API liegt in der Möglichkeit, der<br />
Kamera Triggerimpulse zu senden. Es stellte sich allerdings heraus, dass keine der getesteten Kameras<br />
diese Impulse berücksichtigt und somit nur eine asynchrone Ansteuerung der Kameras möglich war.<br />
Die Open Computer Vision Library (OpenCV) aus Abschnitt 2.3.8 beinhaltet neben vielen anderen<br />
Funktionen zwei Wege um Digitalkameras anzusteuern. Der Standardweg führt über die CvCapture-<br />
Funktionen, welche aber bei der zu Beginn der Arbeit vorliegenden OpenCV Version 4b noch nicht zur<br />
parallelen Ansteuerung mehrerer Kameras vorgesehen waren. Der andere Weg führt über die Verwendung<br />
der kaum dokumentierten und offensichtlich noch in einer sehr frühen Entwicklungsphase befindlichen<br />
Klasse CvCam. Diese verwendet zur Synchronisation der Kameras den SyncFilter von OpenCV<br />
und bietet so einen vielversprechenden Ansatz zur Lösung des Synchronistionsproblems. Geschwindigkeitsvergleiche<br />
zwischen CvCapture und CvCam zeigten zudem einen erheblichen Geschwindigkeitszuwachs<br />
und führte so zur Entscheidung, die CvCam Klasse so zu erweitern, dass sie für die Bilderfassung<br />
des Navigationsassistenten verwendet werden kann.<br />
CCam - Eine Klasse zur Ansteuerung der Kameras: Die CCam genannte Wrapper-Klasse wurde<br />
geschrieben um die Möglichkeit der NI-API Triggerimpulse an die Kamera zu senden für zukünftige<br />
Hardware bereitzustellen. Sie vereint die NI-API mit der CvCam Klasse. Über das Setzen eines Kompilerflags<br />
ist es möglich, die gewünschte API auszuwählen, ohne dass der Programmcode, welcher die<br />
CCam-Klasse verwendet, geändert werden muss.<br />
4.1.2 Berechnung der Stereodisparitätsbilder<br />
Nach der Lösung des Ansteuerungsproblems ist, zur Berechnung des Stereodisparitätsbildes aus den<br />
erfassten Einzelbildern, die Kalibrierung und Rektifizierung der Kamerabilder erforderlich (siehe Absatz<br />
2.1.4).<br />
Kamerakalibrierung<br />
Unter der Kalibrierung einer Kamera versteht man die Bestimmung der durch den optischen Aufbau<br />
der Kamera auftretenden Verzerrungen. Diese können, wie in Abschnitt 2.1.2 beschrieben, über das<br />
von Zhang vorgestellte Verfahren [4] ermittelt werden und ergeben alle kameraspezifischen Parameter,<br />
die zur Berechnung einer Entzerrungsmatrix nötig sind. Diese ermöglicht es, gerade Linien wieder in<br />
Geraden zu überführen, um so ein unverzerrtes Abbild der realen Szene im Computer weiterverarbeiten<br />
zu können.<br />
Um diesen Schritt möglichst einfach für alle zur Verfügung stehenden Kameras durchführen zu können,<br />
wurde eine MFC Oberfläche geschrieben, welche die zu kalibrierende Kamera über die in der Implementierung<br />
(Kapitel 4, Abschnitt 4.1.1) vorgestellte CCam-Klasse ansteuert. Nach der Angabe der Anzahl<br />
von Zeilen und Spalten des verwendeten Schachbrettmusters werden dessen innere Ecken automatisch<br />
gefunden. Es müssen mindestens fünf Ansichten des Schachbretts mit gefundenen inneren Ecken abge-
38 KAPITEL 4. IMPLEMENTIERUNG<br />
speichert werden, bevor das Programm über den nach Zhang implementierten Kalibrierungsalgorithmus<br />
cvCalibrateCamera() alle zur Kalibrierung der Kamera notwendigen Daten berechnen kann. Sobald<br />
genügend Ansichten abgespeichert sind, wird die Entzerrungsmatrix berechnet und das entzerrte Kamerabild<br />
dargestellt. Eine ausführliche Bedienungsanleitung des „Cam Calibrator“ findet sich im Anhang<br />
A.1.<br />
Abbildung 4.2: Screenshot des entwickelten MFC-Programms zur Kalibrierung von Firewire-Kameras<br />
Rektifizierung der Kamerabilder<br />
Nach der Kalibrierung erscheinen Abbildungen von parallelen Geraden wieder parallel, allerdings ist<br />
aufgrund der Verwendung zweier Kameramodule nicht sichergestellt, dass die Scanlines beider Bilder<br />
aufeinander liegen und die Blickrichtung beider Kameras parallel ist. Um den Versatz zwischen den<br />
Kameras zu korrigieren, muss daher die in Abschnitt 2.1.3 beschriebene Rektifizierungstransformation<br />
berechnet werden, welche die Scanlines beider Bilder so ausrichtet, dass eine einfache Berechnung des<br />
Stereodisparitätsbildes möglich ist.<br />
Abbildung 4.3: MFC Programm zur Kalibrierung und Rektifizierung der Kameras<br />
Zur Berechnung der für die Rektifizierung notwendigen Daten, wurde der „Cam Calibrator“ des letzten<br />
Abschnitts mit Hilfe des undokumentierten, aber in den OpenCV-Quellen enthaltenen Calib-Filters<br />
erweitert. Dieser nutzt die gefundenen Eckpunktpositionen des Schachbrettmusters aus linkem und rech-
4.1. SENSORDATENERFASSUNG 39<br />
tem Kamerabild, um die zur Rektifizierung der Bilder notwendigen Transformationsmatrizen zu berechnen.<br />
Diese können zusammen mit den zur Kalibrierung nötigen Daten im File „cameras.txt“ abgespeichert<br />
werden. Dies ermöglicht es, nach einmaliger Berechnung der Kameraspezifikationen, diese in<br />
anderen Anwendungen zu laden und erspart so die Neukalibrierung der Kameras bei jedem Programmstart.<br />
Eine ausführliche Bedienungsanleitung für den „StereoCam Calibrator“ findet sich in Anhang A.2.<br />
Nach der Entzerrung der Kamerabilder kann über den „Show/Hide“ Button im Bereich „Disparity<br />
Image“ ein Tiefenbild angezeigt werden, welches über den OpenCV Algorithmus berechnet wird (Abschnitt<br />
4.1.4). Es zeigt sich, dass selbst kleine Rotationsbewegungen der Kamera zu großen Fehlern im<br />
Stereobild führen. Die Vermutung, dass dies mit einer unzureichenden Synchronisierung der Kameras<br />
zusammenhängt, wurde über den im folgenden Abschnitt beschriebenen Synchronitätstest bestätigt.<br />
Synchronität<br />
Die Messung der Synchronität beider Kameras ist durch einen einfachen Versuchsaufbau realisierbar.<br />
Hierfür wird ein Fadenpendel, wie in Abbildung 4.4 gezeigt, aufgebaut und die Stereokamera so vor<br />
dem Pendel positioniert, dass die Bewegungsrichtung des Pendels senkrecht auf der Kameraachse steht.<br />
Abbildung 4.4: Versuchsaufbau für Synchronitätstests. Die Stereokamera wird auf der Seite liegend vor<br />
einem Fadenpendel positioniert. Über eine Skala hinter dem Pendel kann der Versatz<br />
zwischen linkem und rechten Einzelbild abgelesen werden.
40 KAPITEL 4. IMPLEMENTIERUNG<br />
Die Starthöhe des Pendels kann über die Energieerhaltungsgleichung<br />
E = mgh = 1<br />
2 mv2<br />
h = 1<br />
2g v2 =<br />
1<br />
2 ∗ 9.81 (5/3.6)2<br />
� m 2 s 2<br />
m s 2<br />
�<br />
= 0.1[m] (4.1)<br />
so gewählt werden, dass es mit einer Geschwindigkeit von 5 km m<br />
h (≈ 1.4 s ) an der Kamera vorbei schwingt.<br />
Dies entspricht der anzunehmenden Laufgeschwindigkeit des Benutzers. Über die hinter dem Pendel<br />
angebrachte Skala kann der Zeitversatz zwischen den Bildern aus der Geschwindigkeit des Pendels<br />
berechnet werden. Die Zeit pro Skaleneinheit (0.01Meter) ergibt sich aus:<br />
s = vt<br />
t = 0.01<br />
1.4<br />
�<br />
m s<br />
�<br />
= 7.1[ms] (4.2)<br />
m<br />
Abbildung 4.5 vergleicht die Ergebnisse des Pendelversuchs für verschiedene Kameras bei Verwendung<br />
der CvCam-Klasse von OpenCV und der IMAQ-API. Es wird deutlich, dass in diesem Fall die Verwendung<br />
einer asynchronen, sequentiellen Ansteuerung der Kameras mit circa 40 ms Versatz synchroner ist,<br />
als die Verwendung der über den DirectX Sync-Filter synchronisierten CvCam-Klasse mit (≈ 48 ms).<br />
Abbildung 4.5: Zeitversatz zwischen linken und rechten Einzelbildern bei unterschiedlichen Kameras<br />
und APIs. Es zeigt sich eine etwas geringere Zeitdifferenz beim Einsatz der IMAQ-API.<br />
Der insgesamt hohe Versatz erklärt die Fehler im Disparitätsbild bei bewegter Kamera.<br />
Zum Vergleich ist der Versatz der Bumblebee (125 µs) ebenfalls abgebildet.
4.1. SENSORDATENERFASSUNG 41<br />
Die Versuche, durch die Verwendung paralleler Threads oder eines Bildpuffers zeitgleiche Bilder zu<br />
erhalten, führen leider zu ähnlich schlechten Ergebnissen. Wie an der Abbildung zu erkennen ist, erlaubt<br />
der Zeitversatz zwischen den Kameras nur sehr langsame Bewegungungen.<br />
Dieses erklärt die großen Fehler im Stereobild bei Rotationen, die in Abschnitt 4.1.2 beschrieben wurden,<br />
und disqualifiziert jedes der vorhandenen Testmodule für den Einsatz im Navigationsassistenten<br />
bei nicht statischer Anwendung, da selbst bei langsamen Bewegungen Ungenauigkeiten im Tiefenbild<br />
auftreten und der zu entwickelnde Navigationsassistent den Benutzer nicht zu unnatürlich langsamen<br />
Bewegungen zwingen sollte.<br />
4.1.3 Verwendung eines selbstsynchronisierenden Stereokameramoduls<br />
Nach den im letzten Abschnitt beschriebenen Synchronitätstests kommt keine der vorhandenen Kamerasysteme<br />
zur Lösung der hier behandelten Navigationsaufgabe in Frage, da diese nicht ausreichend gut<br />
synchronisiert werden können (Latenzzeit zwischen den Kameras von 40 ms) und somit die Berechnung<br />
eines Disparitätsbildes bei bewegter Kamera zu ungenau ist. Aus diesem Grund wurde entschieden, ein<br />
Stereokameramodul zu erwerben, welches sich am Firewire-Bus automatisch synchronisiert und so die<br />
Berechnung des Tiefenbildes aus den Einzelbildern auch bei Bewegungen ermöglicht.<br />
Point Grey Bumblebee<br />
Von Point Grey [28] wurde das Bumblebee Stereokameramodul entwickelt, welches die Berechnung<br />
eines Disparitätsbildes, dank einer Latenzzeit von maximal 125 µs zwischen linkem und rechtem Kamerabild,<br />
auch bei schnellen Bewegungen ermöglicht. Aufgrund der Vorkalibrierung ab Werk und des<br />
vergleichsweise geringen Gewichts wurde das Kameramodul zur Entwicklung des Navigationsassistenten<br />
eingesetzt.<br />
Abbildung 4.6: Point Grey bietet mit der Bumblebee eine vorkalibrierte Stereokamera an. Durch automatische<br />
Synchronisierung am Firewire-Bus ist der Zeitversatz zwischen Stereobildpaaren<br />
minimal.
42 KAPITEL 4. IMPLEMENTIERUNG<br />
Ansteuerung der Stereokamera<br />
Zur Ansteuerung der Bumblebee stehen unter [29] das Digiclops- und Triclops-API von Point Grey zur<br />
Verfügung. Beide können in C/C++ Programme eingebunden werden und ermöglichen eine weitgehend<br />
komfortable, jedoch recht hardwarenahe Abfrage der Kamera beziehungsweise des zur Positionsbestimmung<br />
notwendigen Tiefenbildes. Das Digiclops API dient zur Ansteuerung der Kameras und Abfrage<br />
der Einzelbilder. Das Triclops SDK enthält Funktionen zur schnellen Messung von Distanzen zu Pixeln<br />
im Bild und unterstützt die Generierung von Disparitätsbildern aus linkem und rechtem Bild der<br />
Stereokamera.<br />
CBumblebee - Eine Klasse zur Ansteuerung der Bumblebee: Aufgrund der Hardwarenähe der<br />
APIs wurden die Aufrufe zur Ansteuerung der Kamera und Abfrage der Tiefeninformationen in einer<br />
Wrapper-Klasse zusammengefasst. Neben der in den meisten Beispielen verwendeten Methode,<br />
zunächst über triclopsGetImage16() das Disparitätsbild zu extrahieren und daraus durch Aufrufe von<br />
triclopsRCDToXYZ() für jeden Pixel einen Tiefenwert zu berechnen, steht zusätzlich die Funktion triclopsExtractImage3d()<br />
zur Verfügung. Diese fasst die Schritte zusammen und liefert direkt die benötigten<br />
Tiefeninformationen. Aufgrund vergleichbarer Performance beider Methoden und der leichteren Handhabung,<br />
wurde die zweite in der CBumblebee-Klasse verwendet, um die Abstandsinformationen für den<br />
späteren Vergleich mit der realen Szene zu berechnen.<br />
4.1.4 Verfahren zur Berechnung der Stereobilder<br />
Die automatische Synchronisation der Kameras im Bumblebee Stereokameramodul ermöglicht eine<br />
selbst für schnelle Kamerabewegungen ausreichend synchrone Akquisition von Stereobildpaaren. Diese<br />
können dank interner Entzerrung und Rektifizierung direkt über einen Stereoalgorithmus in ein Disparitätsbild<br />
umgerechnet werden. Es standen drei Implementierungen zur Berechnung des Stereodisparitätsbildes<br />
zur Verfügung, die in den folgenden Absätzen kurz vorgestellt werden.<br />
1. Die in Abschnitt 2.3.3 beschriebene Studienarbeit verwendet zur Berechnung der Stereodisparität<br />
einen an der Carnegie Mellon University implementierten Stereoalgorithmus. Da dieser allerdings<br />
zur Berechnung des Disparitätsbildes mehrere Sekunden benötigt, eignet er sich nicht zum Einsatz in<br />
Echtzeit-Anwendungen.<br />
2. In der OpenCV Dokumentation [26] findet sich über den Link „Experimental Functionality“ die Beschreibung<br />
einiger Funktionen, die nicht in der offiziellen Dokumentation des OpenCV Pakets enthalten<br />
sind. Hier wird unter anderem die Funktion cvFindStereoCorrespondence() erwähnt, welche es ermöglicht,<br />
aus zwei rektifizierten Grauwertbildern anhand des nach Birchfield et al. [30] implementierten<br />
Stereoalgorithmus ein Tiefenbild der Szene zu berechnen.<br />
3. Über die Triclops-API von Point Grey steht ebenfalls eine Implementierung zur Berechnung des<br />
Tiefenbilds aus den linken und rechten Einzelbildern der Bumblebee zur Verfügung. Diese wird über<br />
die CBumblebee-Klasse bereitgestellt und ermöglicht eine schnelle Abfrage des gewünschten Disparitätsbildes.
4.1. SENSORDATENERFASSUNG 43<br />
Geschwindigkeitsvergleich zwischen den Berechnungsverfahren<br />
Um die Geschwindigkeiten der OpenCV und Point Grey Implementierungen vergleichen zu können,<br />
wurde ein Programm geschrieben, welches die Distanzmessung anhand von Disparitätsbildern unter<br />
Verwendung der Bumblebee ermöglicht und zwischen den beiden Implementierungen umschalten kann.<br />
Abbildung 4.7 vergleicht die auf einem 1.6 GHz Centrino Laptop gemessene Geschwindigkeit beider<br />
APIs für unterschiedliche Anzahlen von Disparitätsstufen. Es ergibt sich, dass die Triclops-API bei<br />
allen Stufen schneller arbeitet als OpenCV. Sie wird deshalb zur Generierung der Disparitätsbilder im<br />
Navigationsassistent eingesetzt.<br />
Abbildung 4.7: Geschwindigkeitsvergleich zwischen OpenCV und Point Grey API, gemessen auf einem<br />
1.6 GHz Centrino Laptop. Es zeigt sich ein deutlicher Performancevorsprung der<br />
Point Grey API.<br />
4.1.5 Ansteuerung des Xsens Motion Trackers<br />
Über den von Hub entwickelten Prototyp (Abbildung 4.1 (b)) steht mit dem integrierten Motion Tracker<br />
von Xsens ein Miniatur-Inertialsensor mit Beschleunigungs-, Gyro- und Magnetfeldsensoren zur Verfügung.<br />
Die Magnetfeldsensoren können, wie im Lösungsansatz vorgestellt, zur Vorgabe der Blickrichtung<br />
der simulierten Kamera verwendet werden. Dieses ermöglicht einen einfachen und robusten Vergleich<br />
zwischen Realität und Modell. Der Sensor ist, wie in Abbildung 3.1 (b) gezeigt, direkt am Gehäuse der<br />
Stereokamera befestigt. Die im nächsten Absatz beschriebene Client-Server Lösung ermöglicht es, die<br />
benötigten Richtungsdaten vom Sensor abzufragen, ohne den Sensor zu blockieren.
44 KAPITEL 4. IMPLEMENTIERUNG<br />
Client-Server Lösung zur Kommunikation mit dem Motion Tracker<br />
Die Verwendung einer Client-Server Lösung ermöglicht es, von der eingesetzten Hardware unabhängig<br />
zu bleiben und den Sensor nicht zu blockieren, sodass er gleichzeitig für andere Berechnungen zur<br />
Verfügung steht.<br />
Es wurde ein Server-Thread auf Basis von Windows Sockets implementiert, der Verbindungen zum Port<br />
7000 zulässt und über das folgende einfache Protokoll die Abfrage der benötigten Richtungsinformationen<br />
des Inertialsensors ermöglicht:<br />
Befehl Funktion<br />
mt_server_get_data erfragt die Richtungsdaten vom Server<br />
mt_server_quit beendet den Server<br />
Tabelle 4.1: Xsens Server Protokoll zur Abfrage der Richtungsdaten<br />
Zur Übertragung der Richtungsdaten wird das folgende Strukt verwendet, welches je nach Einstellung<br />
des Motion Tracker Servers die Orientierung des Sensors als Raumwinkel oder als Rotationsmatrix an<br />
den Client liefern kann:<br />
typedef struct _mtOrientation{<br />
float phi, theta, psi;<br />
float matrix[9];<br />
}mtOrientation;<br />
4.2 Bereitstellung der Modelldaten<br />
Wie der Lösungsansatz beschreibt, soll durch die Angleichung einer simulierten Umgebung an real<br />
gemessene Daten die Position des Sensormoduls im Raum approximiert werden. Nachdem nun die<br />
Hardware zur Messung der realen Daten vorliegt, muss für den effizienten Vergleich zwischen Modell<br />
und Realität ein möglichst genaues 3D-Modell des Gebäudes vorhanden sein.<br />
4.2.1 Erstellung des Gebäudemodells mit 3D Studio Max<br />
Über die von Architekten üblicherweise zur Planung öffentlicher Gebäude angefertigeten CAD-Zeichnungen<br />
steht oft ein detailliertes Grundgerüst eines 3D-Modells zur Verfügung. Dieses kann in ein gängiges<br />
3D-Animationsprogramm wie zum Beispiel Discreets 3D Studio Max 6.0 importiert und dort<br />
über die Integration von Flächen als Wände und Böden, Fenster, Türen, etc. vervollständigt werden.<br />
Um später Blinde bei ihrer Navigation durch das Gebäude unterstützen zu können, muss zusätzlich die<br />
Inneneinrichtung der Räume nachmodelliert werden. Hierbei sollten alle festen und verschiebbaren Objekte,<br />
die bei der Navigation durch das Gebäude Hindernisse darstellen könnten, beachtet werden. Für<br />
einen Teil des Informatikgebäudes der Universität Stuttgart wurde ein solches Modell von Alexander<br />
Kobus im Rahmen des Nexus-Projektes bereits erstellt. Abbildung 4.8 zeigt den vollständig modellierten<br />
Gebäudeabschnitt, der zur Simulation der Umgebung bei dieser Arbeit eingesetzt wird.
4.2. BEREITSTELLUNG DER MODELLDATEN 45<br />
Abbildung 4.8: Zur Navigationsunterstützung eingesetzter, modellierter Gebäudeabschnitt<br />
Einteilung in Hierarchiestufen<br />
Die Einteilung des Gebäudes in verschiedene Hierarchiestufen (sogenannte Gruppen) ermöglicht es,<br />
relevante Teile des Modells selektieren oder ausblenden zu können. Dies erleichtert die Positionsbestimmung<br />
und Änderung von Objekten im Modell.<br />
Folgende Namenskonvention wurde zur Benennung der Gruppen festgelegt, um die in Abschnitt 3.2.2<br />
beschriebene Selektion des Startraumes zu vereinfachen.<br />
Räume : raum_ < Raumnummer ><br />
Gänge und Flure : f lur_ < Flurname ><br />
Treppenhäuser : treppenhaus_ < Treppenhausname ><br />
Der Flur- beziehungsweise Treppenhausname ist frei wählbar und besteht in den meisten Fällen aus<br />
einer Kombination aus Stockwerk und Himmelsrichtung im Gebäude.
46 KAPITEL 4. IMPLEMENTIERUNG<br />
Rohbau-Modell Mit statischen Mit statischen und<br />
Objekten verschiebbaren Objekten<br />
Abbildung 4.9: Anzeige verschiedener Hierarchiestufen des Gebäudes. Die Einteilung in Gruppen ermöglicht<br />
es, zwischen festen und verschiebbaren Hindernissen zu unterscheiden.<br />
Export des Modells ins OpenSceneGraph Format<br />
Das um verschiebbare Hindernisse erweiterte 3D-Modell wird über das OSGExp-Plugin [31] mit den in<br />
Abbildung 4.10 gezeigten Einstellungen ins OpenSceneGraph (.osg) Format exportiert. Dieses Format<br />
wurde gewählt, da es sich beim OpenSceneGraph-Format um eine einfach zu parsende, hierarchische<br />
Modellbeschreibungssprache handelt. Diese Format wird auch von anderen Nexus-Projekten zur Repräsentation<br />
von 3D-Modellen eingesetzt. OpenSceneGraph unterstützt außerdem Formate wie Alias Wavefront<br />
(.obj), 3D Studio Max (.3ds), VRML 1.0 (.wrl) und viele andere, die aber nicht die gewünschten<br />
strukturellen Eigenschaften besitzen.<br />
Abbildung 4.10: Osg Export Einstellungen des OSGExp Plugins für 3D Studio Max
4.2. BEREITSTELLUNG DER MODELLDATEN 47<br />
4.2.2 Darstellung des Gebäudemodells<br />
Die Darstellung komplexer 3D-Modelle wird üblicherweise durch den Einsatz einer ausgereiften 3D-<br />
Rendering-Engine übernommen. Diese setzen häufig einen Szenengraphen ein um die Szene möglichst<br />
effizient zu rendern. Verdeckung, „View-Frustum-Culling“, „Level-Of-Detail“ und viele andere Berechnungen<br />
werden vorab direkt auf dem Szenengraphen ausgeführt, damit nur die minimal nötige Anzahl an<br />
Vertices von der Grafikkarte dargestellt werden muss. Zudem wird eine schnelle Berechnung von Kollisionen<br />
und Schnittpunkten von Geraden mit der Szene ermöglicht. Das in Abschnitt 2.3.9 vorgestellte<br />
OpenSceneGraph-Toolkit stellt eine Opensource-Implementierung einer hochperformaten Rendering-<br />
Engine zur Verfügung. Diese wird in der hier vorgestellten Arbeit zur Simulation der Umgebung eingesetzt<br />
indem der in den OpenSceneGraph-Quellen enthaltene Viewer so erweitert wird, dass er die<br />
Distanzmessung des Sensormoduls im 3D-Gebäudemodell simuliert. Dies ermöglicht den Vergleich mit<br />
den real gemessenen Sensordaten. Die Locator genannte Implementierung der Navigationsassistenz-<br />
Software rendert die Szene zur grafischen Visualisierung der Positionsbestimmung aus Sicht einer virtuellen<br />
Kamera. Abbildung 4.11 (a) zeigt einen Raum im Informatikgebäude aus Sicht der simulierten<br />
Kamera. Zur besseren Informationsvisualisierung der Positionsbestimmungn, wird zudem eine Außenansicht<br />
der Szene gerendert, wie sie in Abbildung 4.11 (b) dargestellt ist. Diese zeigt die Position der<br />
virtuellen Kamera im Gebäude.<br />
Der Locator verbindet die in den folgenden Abschnitten beschriebenen Implementierungen zur Selbstlokalisation<br />
und Erkennung von modellierten Hindernissen und gibt das Feedback an den Benutzer grafisch<br />
zurück. Später soll auf eine grafische Ausgabe verzichtet werden und alle Berechnungen direkt auf<br />
dem Szenengraphen ausgeführt werden können. Die dargestellten Navigationshinweise könnten dann<br />
über eine Text-zu-Sprache Software wiedergegeben werden. Eine ausführliche Bedienungsanleitung mit<br />
allen Tastaturkürzeln findet sich in Anhang A.3.<br />
a) Aus Sicht der virtuellen Kamera b) Außenansicht der gerenderten Szene<br />
gerendertes 3D-Modell<br />
Abbildung 4.11: Darstellung des gerenderten 3D-Modells. Abbildung (a) zeigt die Szene aus Sicht der<br />
virtuellen Kamera, Bild (b) zeigt eine Außenansicht der gerenderten Szene.
48 KAPITEL 4. IMPLEMENTIERUNG<br />
4.3 Positionsbestimmung<br />
Ausgehend von den Modell- und Sensordaten wird in diesem Abschnitt auf die relevanten Berechnungsschritte<br />
des Navigationsprogramms eingegangen. Die zentralen Bestandteile sind die Objekterkennung,<br />
die Bestimmung der eigenen Position und der erkannten Objekte, sowie die Aktualisierung des Modells<br />
(Abbildung 4.12 (b))<br />
Realität vs<br />
Modell<br />
Neuberechnung auf Anfrage<br />
Farbbild<br />
Tiefenbild<br />
Objekterkennung<br />
Objektbeschreibung<br />
2D Bildpositionen<br />
Sensordaten Modelldaten<br />
Tiefenbild<br />
Richtung<br />
Positionsbestimmung<br />
Szenengraph<br />
Kontinuierliche Neuberechnung<br />
3D Raumpositionen<br />
Berechnung der<br />
Änderungstransformationen<br />
Aktualisierung des<br />
3D-Modells<br />
Objekterkennung<br />
2D Bildpositionen<br />
Positionsbestimmung<br />
3D Raumpositionen<br />
Berechnung der<br />
Änderungstransformationen<br />
a) Systemdesign b) Berechnungsschritte des<br />
Navigationsprogramms<br />
Abbildung 4.12: Berechnungsschritte zur Positionsbestimmung. Bild (a) zeigt nochmals das im Lösungsansatz<br />
entwickelte Systemdesign. Bild (b) zeigt die Berechnungsschritte, welche<br />
das Programm zur Navigationsunterstützung durchführen muss.<br />
Das im Lösungsentwurf vorgestellte Verfahren zur Bestimmung der eigenen Position verschiebt die<br />
virtuelle Kamera solange, bis der Unterschied zwischen Simulation und Realität minimal wird. Der Locator<br />
setzt für den Vergleich zwischen Realität und Modell ein Verfahren zur Verfolgung von geeigneten<br />
Messpunkten ein. Die Art der Auswahl der Messpunkte wird dabei dynamisch vom Programm gesteuert.<br />
4.3.1 Bestimmung geeigneter Messpunkte<br />
Wie im Lösungsansatz bereits erwähnt wurde, eignen sich für annähernd quadratische Räume Featurepunkte<br />
auf Wänden als Messpunkte. In langen Gängen ist ein Punkt am Ende des Ganges aussagekräftiger.<br />
Die Berechnung des Wandabstandsschätzwertes beziehungsweise des Gangendes zur Kategorisierung<br />
und Auswahl der über cvGoodFeaturesToTrack() gefundenen Featurepunkte ist in der tvCalcPos-<br />
Klasse implementiert.
4.3. POSITIONSBESTIMMUNG 49<br />
Schätzung des Wandabstandes<br />
Die Schätzung des Wandabstandes beruht auf der Annahme, dass sich in der oberen Hälfte des Bildes üblicherweise<br />
keine Gegenstände befinden. In Abbildung 4.13 (a) sind die vier verwendeten Höhen durch<br />
farbige Linien dargestellt. Bild (b) zeigt die über die Stereokamera ermittelten Tiefen in den verschiedenen<br />
Höhen. Die obere (rote) Linie zeigt deutlich die extremen Tiefenunterschiede an Fenstern. Diese<br />
sind an den roten „Zacken“ zu erkennen. Durch die Mittelung aller gemessenen Tiefen und die Auswahl<br />
des größten Mittelwertes, nach Elemination der „Zacken“, kann der Wandabstand abgeschätzt werden.<br />
Abbildung 4.13 zeigt die gemäß Absatz 3.2.3 anhand des Abstands kategorisierten Featurepunkte des<br />
Bildes. Als Messpunkte geeignete Featurepunkte sind gelb eingefärbt.<br />
a) Eingesetzte Messhöhen b) Ermittelte Tiefen c) Kategorisierte Featurepunkte<br />
Abbildung 4.13: Schätzung des Wandabstandes durch Tiefensampling in verschiedenen Höhen. Abbildung<br />
(a) zeigt in verschiedenen Farben kodierte Messhöhen. Die an den Messhöhen<br />
ermittelten Tiefen sind in (b) dargestellt. Bild (c) zeigt die kategorisierten Featurepunkte.<br />
Bestimmung des Fluchtpunktes<br />
Als Fluchtpunkt wird der Punkt im Bild bezeichnet, in dem sich die meisten diagonalen Kanten eines<br />
Kantenbildes schneiden. Für lange Gänge lässt sich dieser Schnittpunkt über die in Abbildung 3.6 (e)<br />
dargestellten Hough-Linien im Bild berechnen. Zu diesem Zweck werden in der tvCalcPos-Klasse über<br />
einen Aufruf cvHoughLines2() alle Hough-Linien (siehe Abschnitt 2.1.5) extrahiert und ihre Richtung<br />
anhand des Hough-Winkels bestimmt. Den gesuchten Schnittpunkt P1 jeweils zweier Diagonalen g und<br />
n, mit den Steigungswinkeln α1 und α2, wie sie in Abbildung 4.14 dargestellt sind, berechnet tvCalc-<br />
Pos::getVanisingPoint().<br />
Abbildung 4.14: Schnittpunkt zweier Geraden im 2D-Raum, Quelle [32]
50 KAPITEL 4. IMPLEMENTIERUNG<br />
Nach dieser Berechnung werden die Featurepunkte im Bild weiterverwendet, welche dem gefundenen<br />
„Fluchtpunkt“ am nächsten liegen.<br />
Weiterer Programmablauf: Unabhängig vom Berechnungsverfahren werden die gefundenen Featurepunkte<br />
solange im Bild verfolgt, bis diese nicht mehr gefunden werden oder sie ihren Quadranten<br />
verlassen haben (siehe Abschnitt 3.2.3, Wiederverwendung der Messpunkte). Auf diese Weise muss<br />
die rechenintensive Auswahl der Messpunkte nicht in jedem Durchlauf durchgeführt werden. So bleibt<br />
trotz kontinuierlicher Neuberechnung der eigenen Position noch Rechenleistung, um andere Objekte,<br />
wie verschiebbare Hindernisse, im Raum zu erkennen. Für diesen Zweck ist zunächst der aktuelle Aufenthaltsraum<br />
der virtuellen Kamera im Modell zu bestimmen.<br />
4.3.2 Positionsbestimmung der virtuellen Kamera<br />
Wechselt der blinde Benutzer seinen Aufenthaltsraum, so wird diese Raumänderung auch im Modell<br />
nachvollzogen. Eine einfache Möglichkeit zu bestimmen, in welchem Raum sich die virtuelle Kamera<br />
befindet, ist über ein Picking-ähnliches Verfahren implementiert. Die tvRoomFinder-Klasse berechnet<br />
die Schnittpunkte eines vom Mittelpunkt der Kamera senkrecht nach unten gehenden Strahls mit der<br />
Szene. Das erste getroffene Objekt liefert gemäß der Namenskonvention (raum_*, flur_* oder treppenhaus_*)<br />
(siehe Abschnitt 4.2.1) den Namen des aktuellen Aufenthaltsraumes. Der entsprechende<br />
Szenengraph Knoten wird zurückgegeben und ermöglicht die Extraktion des Raumnamens und der im<br />
Raum enthaltenen Geometrie.<br />
4.4 Erkennung von verschiebbaren, modellierten Objekten<br />
Neben der kontinuierlichen Neuberechnung der eigenen Position kann über den Locator nach verschiebbaren,<br />
modellierten Objekten im Bild gesucht werden. Auf diese Weise ist es möglich, das Modell<br />
anhand der gefundenen Objektpositionen aktuell zu halten. Die tvObjectDetector-Klasse implementiert<br />
den in Abschnitt 3.2.4 vorgestellten Ansatz zur farb- und formbasierten Erkennung von Objekten. Durch<br />
Vererbung kann dieses allgemeine Objekterkennungsverfahren auf die Detektion spezieller Objekte wie<br />
zum Beispiel Stühle zugeschnitten werden.<br />
Der ObjektDetector segmentiert in einem ersten Schritt Regionen im Bild. Die cvFloodFill() Funktion<br />
wird hierfür in diskreten Abständen im unteren Drittel des Bildes aufgerufen. Eine gefüllte Region<br />
wird dann als Binärbild zurückgegeben. Die Beschränkung auf das untere Bilddrittel ist in diesem Fall<br />
möglich, da nur nach Objekten am Boden gesucht werden soll. Sie reduziert den Aufwand der Suche<br />
auf diese Weise um zwei Drittel. Zur Bestimmung der Farbe wird das Kamerabild in den Lab-Farbraum<br />
konvertiert und der Farbwert des gefundenen Bereichs gemittelt. Dieser wird zusammen mit dem gemittelten<br />
Lab-Farbwert der Umgebung an den nach Hub [15] implementierten Farbklassifizierungsalgorithmus<br />
(colorClassifier()) übergeben. Der Name der ermittelten, wahrgenommenen Farbe kann dann mit<br />
dem Farbnamen der in Abschnitt 3.2.4 entworfenen Modellbeschreibung verglichen werden.<br />
Stimmt der aus dem Kamerabild ermittelte Farbname mit dem Farbnamen der Modellbeschreibung überein,<br />
so wird nach der Maskierung des Farbbildes über den logischen Und-Operator mit dem Binärbild<br />
der gefüllten Region, das Histogramm berechnet. In OpenCV steht für den Vergleich zweier Histogram-
4.5. AKTUALISIERUNG DES 3D-MODELLS 51<br />
me die cvCompareHist() Funktion zur Verfügung. Über diese wird das berechnete Histogram mit den in<br />
der Modellbeschreibung gespeicherten Histogrammwerten des zu suchenden Objektes verglichen.<br />
Waren beide Farbtests erfolgreich, wird zuletzt der Unterschied zwischen gefundener Region und dem<br />
Form-Muster der Beschreibung berechnet. Der ObjektDetector setzt hierfür die ebenfalls in der OpenCV<br />
Bibliothek enthaltene cvMatchShapes() Funktion ein. Das Ergebnis dieses Aufrufs gibt den Unterschied<br />
der verglichenen Form zurück.<br />
Wird das gesuchte Objekt in der gefüllten Region wiedererkannt, speichert der ObjektDetector die räumlichen<br />
Koordinaten (x,y,z) des Mittelpunktes der gefundenen Region und ruft die Fülloperation für einen<br />
weiteren Startpunkt im Bild auf. Auf diese Weise können alle in der Objektbeschreibung vorhandenen<br />
Objekte gesucht und gefunden werden. Über die in Gleichung 3.10 entwickelte Positionsbestimmung<br />
der Objekte im Raum ist eine Aktualisierung der Objektpositionen im 3D-Modell möglich.<br />
Der hohe Rechenaufwand, der zur Segmentierung der Bildbereiche notwendig ist, erlaubt bisher keine<br />
Berechnung der Objektpositionen in Echtzeit. Aus diesem Grund wird die Objektsuche nicht kontinuierlich<br />
durchgeführt, sondern muss vom Benutzer bei Bedarf manuell gestartet werden. Auf diese Weise<br />
kann zum Beispiel beim Betreten eines neuen Raumes die Lage der verschiebbaren Objekte aktualisiert<br />
werden.<br />
4.5 Aktualisierung des 3D-Modells<br />
Die Bestimmung des aktuellen Aufenthaltsraumes der virtuellen Kamera, wie sie in Absatz 4.3.2 beschrieben<br />
ist, ermöglicht eine schnelle Abfrage der enthaltenen Geometrie über den Szenengraphen.<br />
Die Beispiel-Klasse zur Suche nach Stühlen implementiert die Suche nach allen Stühlen im aktuellen<br />
Aufenthaltsraum. Zeiger auf die entsprechenden Szenengraphen-Knoten ermöglichen es, bei Erkennung<br />
einer geänderten Position, den Translationsknoten eines Stuhles zu aktualisieren, um ihn auf diese Weise<br />
an seine neue Position zu verschieben. Um sicherzustellen, dass die Objekte weiterhin auf dem Boden<br />
stehen, werden nur die X- und Y-Koordinaten der gefunden Objekte neu berechnet.<br />
Nach der Aktualisierung des Gebäudemodells kann dieses über die im OpenSceneGraph-Paket enthaltenen<br />
Funktionen wieder als OSG-Datei abgespeichert werden.<br />
Das aktualisierte Modell ermöglicht es blinde Benutzer bei der Erforschung ihrer Umgebung zu unterstützen.<br />
Über einen Abtaststrahl im Modell können Informationen wie Abstand und Art von betrachteten<br />
Objekten an den Benutzer zurückgegeben werden. Zudem ist die Warnung vor Hindernissen über Kollisionserkennung<br />
im Modell möglich.
Kapitel 5<br />
Ergebnisse<br />
Dieses Kapitel stellt die Ergebnisse der Selbstlokalisation und Positionserkennung von verschiebbaren,<br />
modellierten Objekten vor. Es beschreibt kurz die Testbedingungen unter welchen die Ergebnisse gemessen<br />
wurden. Alle Tests wurden auf der im nächsten Absatz beschriebenen Hardware durchgeführt.<br />
5.1 Hardwarekomponenten des Navigationsassistenten<br />
Als Entwicklungsplattform diente in dieser Arbeit ein Samsung x20 Laptop mit 1.6 GHz Pentium CPU<br />
(siehe Abbildung 5.1 (a)). Dieses verfügt über einen sechspoligen Firewire-Anschluss und eignet sich<br />
deshalb besonders gut zur Ansteuerung der Stereokamera, da keine zusätzliche Stromquelle benötigt<br />
wird. Das Laptop wurde aus diesem Grund auch zur Messung der Ergebnisse eingesetzt. Zur Positionsbestimmung<br />
sind die in Bild (b) gezeigte Stereokamera und der Inertialsensor (Bild (c)) aus den im<br />
Lösungsansatz beschriebenen Gründen auf einen Fahrradhelm montiert.<br />
a) Samsung x20 Centrino Laptop b) Point Grey Bumblebee c) Xsens MT9-B<br />
mit 1.6 GHz Stereokamera Inertialsensor<br />
Abbildung 5.1: Navigationsassistent bestehend aus Samsung x20 und Sensormodul. Bild (a) zeigt das<br />
eingesetzte Laptop im Betrieb, Bild (b) die Stereokamera und (c) den Inertialsensor.<br />
53
54 KAPITEL 5. ERGEBNISSE<br />
5.2 Distanzmessung über Stereokamera<br />
Vor dem Einsatz im Navigationsassistenten wurde zunächst die Abstandsmessung über die Stereokamera<br />
getestet. Die aus dem Disparitätsbild ermittelten Abstände wurden mit den gemessenen Abständen<br />
eines Laserentfernungsmessers (Leica Disto pro 4 a) verglichen. In einem großen Raum des Gebäudes<br />
wurden hierfür in bestimmten Entfernungen Markierungen an Einrichtungsgegenständen und Wänden<br />
angebracht und die Abstände zur Kamera gemessen. Abbildung 5.2 zeigt die Abweichung der Entfernungsmessung<br />
über die Bumblebee vom exakten Wert. Im Nahbereich (bis sechs Meter) ergibt sich eine<br />
Abweichung im Dezimeterbereich. Für Distanzen über neun Metern ist mit einem Messfehler von über<br />
einem Meter zu rechnen. Der Fehler steigt dabei exponentiell mit wachsendem Abstand.<br />
Abbildung 5.2: Abweichung der Abstandsmessung über Stereobilder der Bumblebee<br />
5.3 Selbstlokalisierung<br />
Zur Bestimmung der Qualität der Selbstlokalisierung wurden in verschiedenen Räumen Markierungen<br />
am Boden angebracht. Die Position der Markierungen wurde mit dem Laserentfernungsmesser bestimmt<br />
und in einer Karte eingetragen (siehe Abbildung 5.3 - grüne Markierungen).<br />
Testparcours 1: VIS-GS-Pool im Informatikgebäude<br />
Als erster Testparcours diente der VIS-GS-Pool im Informatikgebäude. Die Messpunkte wurden mit<br />
dem Navigationsassistenten abgelaufen und die Position der virtuellen Kamera an diesen Punkten abgespeichert.<br />
Durchgeführt wurden vier Messungen. Die Ergebnisse der ersten Testläufe sind in Abbildung<br />
5.3 (a) dargestellt. In diesen wurden vom Navigationsassistenten kontinuierlich alle Positionsvarianten<br />
berechnet. Tabelle 5.1 zeigt die zugrundeliegenden Messdaten. In Abbildung 5.3 (b) und Tabelle 5.2 sind<br />
die Ergebnisse der Selbstlokalisierung bei Beschränkung auf die Berechnung zweier Positionsvarianten<br />
(vor und zurück) abgebildet.
5.3. SELBSTLOKALISIERUNG 55<br />
a) Selbstlokalisierung durch Berechnung aller Positionsvarianten<br />
b) Selbstlokalisierung bei Beschränkung auf zwei Varianten<br />
Abbildung 5.3: Ergebnisse der Positionsbestimmung im VIS-GS-Pool. Abbildung (a) zeigt die Markerpositionen<br />
(grün) und die Positionen der virtuellen Kamera des Navigationsassistenten<br />
bei Berechnung aller Positionsvarianten (rot bzw. blau). Bild (b) stellt die Selbstlokalisierung<br />
bei Beschränkung der Berechnung auf zwei Varianten dar. Für annähernd<br />
quadratische Räume (Raum 1 und Raum 2) zeigt sich eine durchschnittliche Abweichung<br />
im Meterbereich. In langen Gängen weichen die Positionen über zwei Meter von<br />
den exakten Werten ab. Türdurchgänge, an denen vom Benutzer nachgeholfen werden<br />
musste, sind gelb markiert.
56 KAPITEL 5. ERGEBNISSE<br />
Messpunkte Messung 1 Messung 2<br />
X Y x y |∆x| |∆y| x y |∆x| |∆y|<br />
Raum 1 66,71 -53,61 66,19 -54,09 0,51 0,48 66,28 -53,41 0,42 0,19<br />
(7,25m x 9,49m) 63,92 -53,56 64,23 -55,18 0,31 1,62 63,65 -54,59 0,26 1,03<br />
61,45 -53,46 62,09 -55,05 0,64 1,59 61,93 -54,22 0,48 0,76<br />
61,45 -57,31 63,85 -56,98 2,40 0,32 64,25 -57,32 2,80 0,01<br />
63,85 -57,46 62,93 -57,11 0,91 0,34 62,71 -54,19 1,13 3,26<br />
66,72 -57,51 65,56 -57,52 1,15 0,01 65,98 -54,92 0,73 2,58<br />
66,75 -61,05 64,61 -60,96 2,13 0,08 65,96 -60,77 0,78 0,27<br />
63,85 -61,41 63,46 -59,33 0,38 2,07 64,26 -60,39 0,41 1,01<br />
61,45 -61,09 61,79 -60,57 0,34 0,51 62,32 -59,87 0,87 1,21<br />
Abweichung Ø 0,32 0,29 0,35 0,12<br />
Raum 2 58,22 -61,1 59,77 -61,95 1,55 0,85 59,80 -60,49 1,58 0,60<br />
(7,25m x 9,49m) 58,23 -57,64 57,74 -59,24 0,48 1,60 57,41 -59,37 0,81 1,73<br />
58,18 -53,82 59,06 -55,23 0,88 1,41 59,30 -55,71 1,12 1,89<br />
58,23 -57,64 58,55 -57,61 0,32 0,02 57,66 -57,08 0,56 0,55<br />
58,22 -61,1 58,05 -60,98 0,16 0,11 58,41 -60,65 0,19 0,44<br />
58,17 -64,12 58,43 -64,02 0,26 0,09 58,05 -63,99 0,11 0,12<br />
58,13 -66,35 58,02 -65,25 0,10 1,09 57,48 -65,42 0,64 0,92<br />
56,25 -66,43 57,16 -66,48 0,91 0,05 57,85 -66,40 1,60 0,02<br />
Abweichung Ø 0,67 0,09 0,54 0,13<br />
Raum 3 56,22 -68,39 56,73 -67,54 0,51 0,84 58,25 -68,94 2,03 0,55<br />
(26,56m x 2,15m) 50,92 -68,38 54,74 -68,35 3,82 0,02 51,20 -69,56 0,28 1,18<br />
41,86 -68,4 41,83 -68,75 0,02 0,35 48,65 -68,70 6,79 0,30<br />
50,92 -68,38 51,44 -69,54 0,52 1,16 49,82 -68,24 1,09 0,13<br />
56,22 -68,39 59,79 -67,99 3,57 0,39 57,41 -68,54 1,19 0,15<br />
61,02 -68,31 61,94 -68,31 0,92 0,00 59,96 -68,48 1,05 0,17<br />
66,42 -68,42 65,67 -69,27 0,74 0,85 66,30 -67,91 0,11 0,50<br />
Abweichung Ø 0,11 0,37 0,21 0,56<br />
Tabelle 5.1: Positionen der virtuellen Kamera bei Berechnung aller vier Positionsvarianten. |∆x| und<br />
|∆y| geben den Betrag der Abweichung in X- und Y-Richtung an. Es ergibt sich für die in<br />
Abbildung 5.3 (a) markierten Räume eine durchschnittliche Abweichung im Meterbereich.<br />
Im Gang mit einfarbigen Wänden fällt diese Abweichung wesentlich größer aus.
5.3. SELBSTLOKALISIERUNG 57<br />
Messpunkte Messung 1 Messung 2<br />
X Y x y |∆x| |∆y| x y |∆x| |∆y|<br />
Raum 1 66,71 -53,61 66,12 -53,96 0,59 0,35 66,37 -53,86 0,34 0,25<br />
(7,25m x 9,49m) 63,92 -53,56 64,10 -54,16 0,18 0,60 63,67 -54,30 0,25 0,74<br />
61,45 -53,46 60,21 -53,53 1,24 0,07 61,64 -53,85 0,19 0,39<br />
61,45 -57,31 60,80 -56,97 0,65 0,34 61,18 -57,01 0,27 0,30<br />
63,85 -57,46 63,44 -58,50 0,41 1,04 63,50 -57,80 0,35 0,34<br />
66,72 -57,51 65,92 -58,72 0,80 1,21 65,62 -58,26 1,10 0,75<br />
66,75 -61,05 66,62 -61,24 0,13 0,19 66,10 -60,78 0,65 0,27<br />
63,85 -61,41 63,10 -60,45 0,75 0,96 63,60 -61,10 0,25 0,31<br />
61,45 -61,09 62,15 -61,26 0,70 0,17 62,23 -61,32 0,78 0,23<br />
Abweichung Ø 0,60 0,56 0,47 0,40<br />
Raum 2 58,22 -61,10 56,55 -61,30 1,67 0,20 59,68 -61,47 1,46 0,37<br />
(3.26m x 14,38m) 58,23 -57,64 57,44 -57,44 0,79 0,20 58,42 -57,32 0,19 0,32<br />
58,18 -53,82 57,68 -54,59 0,50 0,77 58,52 -55,07 0,34 1,25<br />
58,23 -57,64 57,79 -57,97 0,44 0,33 58,34 -56,88 0,11 0,76<br />
58,22 -61,10 57,64 -63,98 0,58 2,88 57,93 -60,93 0,29 0,17<br />
58,17 -64,12 57,58 -65,97 0,59 1,85 57,89 -63,90 0,28 0,22<br />
58,13 -66,35 57,70 -66,53 0,43 0,18 58,11 -65,77 0,02 0,58<br />
56,25 -66,43 55,86 -68,07 0,40 1,64 57,90 -66,14 1,65 0,29<br />
Abweichung Ø 0,67 1,01 0,54 0,50<br />
Raum 3 56,22 -68,39 55,13 -68,33 1,09 0,06 56,07 -68,13 0,15 0,26<br />
(26,56m x 2,15m) 50,92 -68,38 51,52 -68,06 0,60 0,32 55,82 -68,07 4,90 0,31<br />
41,86 -68,40 42,94 -68,32 1,08 0,08 46,51 -68,71 4,65 0,31<br />
50,92 -68,38 46,14 -68,52 4,78 0,14 47,64 -68,90 3,28 0,52<br />
56,22 -68,39 58,69 -68,69 2,47 0,30 58,48 -68,04 2,26 0,35<br />
61,02 -68,31 61,94 -68,54 0,92 0,23 60,35 -68,44 0,67 0,13<br />
66,42 -68,42 65,79 -68,66 0,63 0,24 64,01 -68,75 2,41 0,33<br />
Abweichung Ø 1,65 0,19 2,62 0,31<br />
Tabelle 5.2: Positionswerte der virtuellen Kamera für Abbildung 5.3 (b) bei Beschränkung der Berechnung<br />
auf zwei Positionsvarianten. |∆x| und |∆y| geben wieder den Betrag der Abweichung<br />
in X- und Y-Richtung an. Es zeigt sich, dass durch Beschränkung eine genauere Positionsbestimmung<br />
in Räumen möglich ist (vergleiche Abbildung 5.3 (b). In Gängen erzielt die<br />
Beschränkung keine besseren Ergebnisse, ist aber aufgrund des niedrigeren Berechnungsaufwands<br />
zu bevorzugen.
58 KAPITEL 5. ERGEBNISSE<br />
Testparcours 2: Wohnräume<br />
Aufgrund starker magnetischer Störungen im ersten Testparcours musste die Orientierung der virtuellen<br />
Kamera bei den Tests gelegentlich von Hand nachjustiert werden. Zudem stellen die vielen homogenen<br />
Flächen im Informatikgebäude ein „Worst Case Szenario“ für die Berechnung des Disparitätsbildes dar.<br />
Aus diesem Grund wurde ein zweiter Testparcours in einem Wohnhaus aufgebaut. Abbildung 5.4 und<br />
Tabelle 5.3 zeigen die hier gemessenen Ergebnisse.<br />
Abbildung 5.4: Ergebnisse der Positionsbestimmung in Wohnräumen. Aufgrund geringer magnetischer<br />
Störungen und besserer Texturen auf den Wänden, kann die eigene Position wesentlich<br />
exakter bestimmt werden.<br />
Ergebnis der Selbstlokalisierung<br />
Tabelle 5.1 und 5.2 zeigen die Ergebnisse der Positionsbestimmung des Sensormoduls bei unterschiedlichen<br />
Einstellungen der Navigationssoftware. Für annähernd quadratische Räume ergibt sich eine durchschnittliche<br />
Abweichung von der exakten Position von circa einem Meter. In langen Gängen ist mit<br />
einer durchschnittlichen Abweichung längs des Ganges von zwei Metern zu rechnen. Der Vergleich mit<br />
den Messergebnissen in Räumen, die weniger magnetische Störungen und wenige homogene Flächen<br />
aufweisen zeigt, dass dort eine Positionsbestimmung im Bereich weniger Dezimeter möglich ist. Die<br />
starke Positionsabweichung in langen Gängen entsteht zum einen durch die Schwierigkeit, geeignete<br />
Messpunkte zu finden (einfarbige Wände und wenige Texturen auf den Wänden), zum anderen aus der<br />
für große Entfernungen ungenauen Abstandsmessung der Bumblebee. Dieser Effekt ist in Abbildung<br />
5.2 dargestellt.
5.3. SELBSTLOKALISIERUNG 59<br />
Messpunkte Messung 1 Messung 2<br />
X Y x y |∆x| |∆y| x y |∆x| |∆y|<br />
Raum 1 1,00 0,70 1,55 0,18 0,55 0,52 1,34 0,35 0,34 0,35<br />
2,30 0,75 2,65 0,29 0,35 0,46 2,53 0,46 0,23 0,29<br />
4,00 0,70 4,16 0,32 0,16 0,38 3,92 0,52 0,08 0,18<br />
4,00 2,30 4,10 2,74 0,10 0,44 4,05 2,24 0,05 0,06<br />
2,30 2,30 2,63 2,36 0,33 0,06 2,78 2,30 0,48 0,00<br />
1,00 2,30 1,20 2,62 0,20 0,32 0,08 2,30 0,92 0,00<br />
1,00 3,50 1,59 3,29 0,59 0,21 1,17 3,40 0,17 0,10<br />
2,30 3,50 2,44 3,34 0,14 0,16 2,48 3,36 0,18 0,14<br />
4,00 3,50 3,60 3,41 0,40 0,09 3,27 3,48 0,73 0,02<br />
Abweichung Ø 1,65 0,19 2,62 0,31<br />
Gang 4,66 5,11 4,58 4,95 0,08 0,16 3,83 4,90 0,83 0,21<br />
6,66 5,11 6,26 4,97 0,40 0,14 6,92 5,00 0,26 0,11<br />
8,00 5,11 7,45 5,11 0,55 0,00 7,53 4,98 0,47 0,13<br />
9,50 5,11 7,86 5,03 1,64 0,08 8,91 5,18 0,59 0,07<br />
Abweichung Ø 1,65 0,19 2,62 0,31<br />
Raum 2 9,50 7,00 9,41 7,49 0,09 0,49 9,15 7,90 0,35 0,90<br />
9,50 8,50 9,47 8,38 0,03 0,12 9,22 8,50 0,28 0,00<br />
9,50 9,78 9,56 9,46 0,06 0,32 9,31 9,29 0,19 0,49<br />
7,74 9,78 8,07 9,74 0,33 0,04 8,09 9,63 0,35 0,15<br />
7,74 8,50 7,62 7,72 0,12 0,78 7,72 7,30 0,02 1,20<br />
7,74 7,00 7,68 6,52 0,06 0,48 7,69 6,39 0,05 0,61<br />
7,74 7,00 7,6787 6,52 0,06 0,48 7,69 6,39 0,05 0,61<br />
Abweichung Ø 1,65 0,19 2,62 0,31<br />
Tabelle 5.3: Positionswerte der virtuellen Kamera zu Abbildung 5.4. Es wird deutlich, dass in Räumen<br />
mit besseren Wandtexturen und geringen magnetischen Störungen eine bessere Positionsbestimmung<br />
erzielt werden kann. Die durchschnittliche Abweichung liegt hier im Bereich<br />
weniger Dezimeter.
60 KAPITEL 5. ERGEBNISSE<br />
5.4 Lokalisierung von verschiebbaren Objekten<br />
Anhand einer Modellbeschreibung für modellierte, verschiebbare Objekte ist es möglich, diese über<br />
ein bildbasiertes Verfahren in der Szene zu lokalisieren. Um das entwickelte Suchverfahren zu testen,<br />
wurden Modellbeschreibungen für mehrere Ansichten verschiedener Stühle erstellt und diese in unterschiedlichen<br />
Abständen vor der Kamera positioniert. Die exakten Abstände zu den Objekten und die<br />
über die Stereokamera ermittelten Distanzen sind in Abbildung 5.5 zusammengefasst. Aufgrund der<br />
Eigenschaften des eingesetzten Lokalisierungsverfahrens konnten nicht in jedem Durchgang alle Stühle<br />
gefunden werden (fehlende orange Balken im Bild). Vor allem dunkelblaue Stühle heben sich bei<br />
zu schwacher Beleuchtung zu wenig von ihrer grauen Umgebung ab und können deshalb schlechter<br />
gefunden werden.<br />
Abbildung 5.5: Distanzen zu lokalisierten Objekten. Für Abstände von bis zu 4,5 Metern können Objekte<br />
im Stereobild lokalisiert werden. Ob ein gesuchtes Objekt gefunden werden kann,<br />
ist von der Beleuchtung und dem Farbkontrast zur Umgebung abhängig.<br />
Ergebnisse der Objektlokalisierung<br />
Für die Bestimmung der Position erkannter Objekte lässt sich, aus den Schaubild 5.5 zugrundeliegenden<br />
Daten, eine durchschnittliche Abweichung von 0,2 Metern ermitteln. Aufgrund der Einschränkung des<br />
Verfahrens auf eine bestimmte Objektgröße werden Objekte ab einer Entfernung von circa viereinhalb<br />
Metern nicht mehr gefunden. Dies ist für eine Hindernis-Erkennung für Blinde noch annehmbar, da<br />
innerhalb dieser Distanz noch Gelegenheit besteht, Hindernisse zu erkennen und zu umgehen.
5.5. PERFORMANCEMESSUNG DER NAVIGATIONSSOFTWARE 61<br />
5.5 Performancemessung der Navigationssoftware<br />
Zur Bestimmung der Geschwindigkeit der Navigationssoftware wurde die Anzahl der verarbeiteten Bilder<br />
pro Sekunde (Fps) gemessen. Abhängig von der Komplexität der Szene kann diese mit bis zu 230<br />
Fps dargestellt werden. Wird zusätzlich das Disparitätsbild der Stereokamera angezeigt, sinkt die Geschwindigkeit<br />
auf 16 Fps. Dies entspricht circa zehn Prozent der von der Grafikhardware möglichen<br />
Leistung. Abbildung 5.6 zeigt die Berechnungsgeschwindigkeiten mit und ohne Stereokamera und bei<br />
Zuschaltung der entwickelten Verfahren zur Selbstlokalisierung und Suche nach verschiebbaren Objekten.<br />
Abbildung 5.6: Performancemessung der Navigationssoftware. Aufgrund der zeitaufwändigen Berechnung<br />
sinkt die Anzahl der verarbeiteten Bilder der Software bei Anzeige des Disparitätsbildes<br />
um circa 90 Prozent.
Kapitel 6<br />
Diskussion<br />
Dieses Kapitel diskutiert die im letzten Kapitel gemessenen Ergebnisse. Es geht auf die Bedeutung der<br />
ermittelten Positionsdaten und die errechnete Abweichung vom mit Laser vermessenen, exakten Wert<br />
ein und gibt einen Ausblick auf die Maßnahmen, die zur weiteren Verbesserung der Positionsbestimmung<br />
führen könnten.<br />
6.1 Bewertung der Ergebnisse<br />
Die Ergebnisse der Selbstlokalisation des Sensormoduls zeigen, dass eine deutliche Verbesserung der<br />
Positionsbestimmung gegenüber dem bisher eingesetzten WLAN-Positionierungssystem, welches die<br />
eigene Position nur auf Raumgenauigkeit bestimmt, erreicht werden kann. Je nach Beschaffenheit der<br />
Räume ist es möglich, die Position des Benutzers auf einen Bereich von einem halben Meter bis maximal<br />
zwei Meter einzugrenzen. Der Blinde ist damit einerseits weiterhin auf den Blindenstock zur<br />
Erforschung seiner direkten Umgebung angewiesen, andererseits können erweiterte Informationen aus<br />
dem Modell die Navigation zusätzlich erleichtern.<br />
Durch das in Abschnitt 3.2.3 vorgestellte Verfahren ist es möglich, die Selbstlokalisation echtzeitnahe<br />
durchzuführen. Der Einsatz geeigneter Bildpunkte zur Abstandsbestimmung ist robust gegenüber Störungen<br />
und somit in vielen Umgebungen einsetzbar. Tests mit unterschiedlichen Anzahlen berechneter<br />
Positionsvarianten im Modell zeigen, dass es im Allgemeinen ausreicht, die ersten zwei Varianten (vor<br />
und zurück) zusätzlich zur aktuellen Position mit der Realität zu vergleichen. In diesem Fall sollte der<br />
Benutzer gelegentlich den Kopf um 90 Grad drehen, um durch Abweichungen des Kompasses entstandene<br />
Fehler zu korrigieren.<br />
Die Performancemessung in Abschnitt 5.5 macht deutlich, dass eine kontinuierliche Suche nach modellierten,<br />
verschiebbaren Hindernissen, bei gleichzeitiger Erfassung des Stereobildes, den Programmablauf<br />
zu stark verzögert (0,62 Bilder pro Sekunde). Diese Berechnung muss deshalb vom System oder<br />
vom Benutzer bei Bedarf aufgerufen werden. Die Ergebnisse der Objektlokalisierung zeigen, dass das<br />
zur Detektion der Objekte entworfene Verfahren (siehe Abschnitt 3.2.4) Hindernisse mit Dezimetergenauigkeit<br />
lokalisieren kann, sofern diese nicht zu weit entfernt oder von anderen Objekten verdeckt sind.<br />
Durch Vergleiche mit dem Modell können genauere Informationen über die Art und Lage von Objek-<br />
63
64 KAPITEL 6. DISKUSSION<br />
ten in der Umgebung des Benutzers bereitgestellt werden, als das über bisherige Verfahren möglich ist<br />
(Abschnitt 2.2).<br />
6.2 Ausblick<br />
Im Verlauf dieser Arbeit wurde deutlich, dass viele der eingesetzten Verfahren durch die Wahl geeigneter<br />
Parameter oder durch die Kombination mit anderen Methoden und Sensordaten verbessert werden<br />
können. Der implementierte Prototyp zeigt, dass das entworfene Konzept zur Selbstlokalisation und<br />
Detektion geeignet ist und durch Beschleunigung der eingesetzten Verfahren und schnellere Hardware<br />
schon bald eine Navigationsunterstützung für Blinde echtzeitnahe möglich ist.<br />
Die Geschwindigkeitsmessung der Software zeigt, dass bis zu 90 Prozent der Rechenzeit für die Berechnung<br />
des Tiefenbildes benötigt werden. Da diese Berechnung komplett auf der CPU stattfindet bleibt<br />
nur wenig Zeit für die zur Positionsbestimmung notwendigen Verfahren. Eine GPU-basierte Berechnung<br />
des Disparitätsbildes könnte die CPU stark entlasten und auf diese Weise die Suche nach verschiebbaren<br />
Objekten beschleunigen.<br />
Die Ende Oktober 2005 erscheinende Umsetzung eines Embedded Systems zur Berechnung der Stereobilder<br />
von Videre Design [33] stellt ebenfalls eine interessante Möglichkeit zur Beschleunigung des<br />
Systems dar. Der auf einem kleinen FPGA (2x3 cm) synthetisierte Stereoalgorithmus soll die CPU von<br />
allen Berechnungen befreien, die zur Ermittlung der Abstände aus dem Tiefenbild notwendig sind und<br />
ausreichende Bildfrequenzen liefern.<br />
Prinzipbedingt ist ein Raumwechsel über die Stereokamera oft nicht zu erkennen. In diesen Fällen wird<br />
die Kamera aufgrund ungleicher Distanzen im Modell rückwärts bewegt, obwohl sie in der Realität<br />
vorwärts bewegt wird. Dieser Effekt könnte durch die zusätzliche Nutzung der Beschleunigungssensoren<br />
des Inertialsensors oder durch eine Fusion der Positionsbestimmung mit anderen Verfahren, wie zum<br />
Beispiel dem von Kombrink [14] verbessert werden.<br />
Neue Erkenntnisse aus der Psychophysik könnten zudem helfen, die Suche nach verschobenen Objekten<br />
zu verbessern und die Segmentierung der Bildregionen zu beschleunigen. Eine geeignete Wahl von<br />
wenigen Startpunkten, von deren Position aus die Regionen segmentiert werden, würde das eingesetzte<br />
Suchverfahren erheblich beschleunigen.<br />
Die zunehmende Miniaturisierung von Kamerasensoren macht eine Integration der Sensorhardware in<br />
eine Brille denkbar. Das immer häufiger verfügbare WLAN-Netz könnte in diesem Fall genutzt werden<br />
um aufwändige Berechnungen vom Navigationsassistenten auf einen externen Server zu verlagern und<br />
so den blinden Benutzer, bezüglich der zu tragenden Hardware, weiter zu entlasten.<br />
Über die von Hub et al. in [34] vorgestellte Methode zur Sprachausgabe oder ein taktiles Display können<br />
die über den Navigationsassistenten gewonnenen Informationen an den blinden Benutzer weitergegeben<br />
werden.
Kapitel 7<br />
Zusammenfassung<br />
Ziel dieser Arbeit war die Optimierung eines elektronischen Navigationsassistenten für Blinde, der auf<br />
der Kombination lokaler Sensorik mit 3D-Gebäudemodellen basiert. Zum einen sollte die Position des<br />
Benutzers und die von modellierten Objekten, unter Verwendung einer Stereokamera und eines Inertialsensors,<br />
bestimmt werden. Des Weiteren sollten veränderte Positionen von verschiebbaren Objekten<br />
erkannt und das Gebäudemodell entsprechend aktualisiert werden.<br />
Nach der Auswahl und Kalibrierung geeigneter Sensorhardware wurden Verfahren evaluiert, über die<br />
Daten aus dem virtuellen Modell mit realen Messungen verglichen werden können. Aufgrund der langen<br />
Rechenzeit vorhandener Verfahren, wurde eine neue Methode zur Auswahl von geeigneten Messpunkten<br />
entwickelt und implementiert. Als geeignet stellen sich Bildpunkte heraus, die einen starken<br />
Helligkeitskontrast bezüglich ihrer Umgebung aufweisen. Diese können über richtungsbasierte Gradientverfahren<br />
gefunden werden. An diesen Stellen kann die Tiefe über die Stereodisparität zuverlässig<br />
berechnet werden. Parameterbereiche zur Auswahl der Messpunkte wurden über Tests in verschiedenen<br />
Umgebungen ermittelt. Durch den Vergleich von Messdaten mit einer simulierten Umgebung kann die<br />
Selbstlokalisation gegenüber bisher verwendeten Verfahren erheblich verbessert werden. Die Messfehler<br />
liegen in Umgebungen mit einfarbigen Wänden im Bereich von ein bis zwei Metern. In kontrastreichen<br />
Umgebungen liegt der Fehler im Bereich weniger Dezimeter.<br />
Zur bildbasierten Detektion verschobener Objekte wurden charakteristische Objekteigenschaften ermittelt<br />
und in einer Modellbeschreibung zusammengefasst. Diese umfasst Farbnamen, Farbtonwerte und<br />
Forminformationen. Durch die Kombination bestehender Verfahren aus der farbbasierten Bildsegmentierung<br />
und deren Erweiterung um die Nutzung der Tiefeninformationen, können Regionen im Bild segmentiert<br />
und mit der Modellbeschreibung verglichen werden. Der zusätzliche Vergleich der Form und<br />
die Optimierung der Erkennungsparameter können dabei beleuchtungsbedingte Störungen der Farbsegmentierung<br />
kompensieren. Verschiebbare, modellierte Objekte können auf diese Weise lokalisiert und<br />
das Modell ohne ständiges Eingreifen eines 3D-Designers aktuell gehalten werden.<br />
Über die im Rahmen dieser Arbeit entwickelten Methoden können Blinde ihre Position innerhalb einzelner<br />
Räume bis auf eine ertastbare Abweichung bestimmen. Die Verwendung eines 3D-Gebäudemodells<br />
ermöglicht es, auf zusätzliche Infrastruktur im Gebäude weitgehend zu verzichten. Durch Ausgabe von<br />
Objektnamen, Distanzmessungen zu modellierten Objekten und Kollisionserkennung im Modell kann<br />
der blinde Benutzer neuartige Informationen erhalten und vor Hindernissen gewarnt werden. Für Blinde<br />
ist somit eine Basis für eine sichere und unabhängige Navigation in unbekannten Gebäuden gegeben.<br />
65
Anhang A<br />
Bedienungsanleitungen<br />
A.1 Kalibrierungs-Tool<br />
Zur Kalibrierung von Kameras wurde das Programm CamCalibrator entwickelt. Es ermöglicht die Kalibrierung<br />
von Kameras über die Aufnahme eines Schachbrettmusters aus verschiedenen Positionen.<br />
a) CamCalibrator-GUI b) Kamerabild mit gefundenen Ecken<br />
Abbildung A.1: CamCalibrator zur Kalibrierung von Kameras. Bild (a) zeigt die GUI zur Steuerung<br />
der Kalibrierung, (b) zeigt die gefundenen inneren Ecken des Schachbrettmusters als<br />
farbige Punkte.<br />
Nach Programmstart muss die Kamera über den „Start Cam“-Button gestartet werden. Sofern die Kamera<br />
dies unterstützt, wird ein Video Device Konfigurationsfenster geöffnet. In diesem sollte die maximale<br />
Auflösung und RGB als Farbspektrum gewählt werden. Die Anzahl der Zeilen und Spalten des verwen-<br />
67
68 ANHANG A. BEDIENUNGSANLEITUNGEN<br />
deten Schachbrettmusters muss in die Felder „Rows, Cols“ eingetragen werden. Das Programm sucht<br />
nach dieser Angabe automatisch die inneren Ecken des Schachbrettmusters. Der „Save Image“-Button<br />
wird erst freigegeben, wenn alle Ecken gefunden wurden. Im „Num Images“-Feld kann die Anzahl der<br />
zur Kalibrierung verwendeten Bilder angegeben werden. Für die Bestimmung der Verzerrungen sind<br />
mindestens drei Bilder des Musters aus unterschiedlichen Betrachtungswinkeln notwendig. Nachdem<br />
die notwendige Anzahl an Bildern abgespeichert wurde, erlaubt der Knopf „Get Calibration Parameters“<br />
die Berechnung der gesuchten Kalibrierungsdaten. Diese können über den „Save“-Button abgespeichert<br />
und später in anderen Programmen geladen werden.<br />
Über den „Verbose“ Schalter kann eine grafische Darstellung der Suche nach den inneren Ecken zugeschaltet<br />
werden. „Flip Image“ ermöglicht das Spiegeln der Bilder an der Horizontalen, falls die Kamerabilder<br />
auf dem Kopf stehen sollten.<br />
Nach der Berechnung der Parameter kann die Kamera gestoppt und über den „Quit“-Knopf die Anwendung<br />
beendet werden.<br />
A.2 Rektifizierungs-Tool<br />
Die mit StereoCam bezeichnete Anwendung erweitert den CamCalibrator um die Ansteuerung einer<br />
zweiten Kamera und die Möglichkeit neben den Kalibrierungsdaten gleichzeitig die zur Rektifizierung<br />
notwendigen Parameter mitzuberechnen.<br />
a) StereoCam-GUI b) linkes Kamerabild c) rechtes Kamerabild<br />
Abbildung A.2: StereoCam zur Kalibrierung und Rektifizierung von Kameras. Bild (a) zeigt die StereoCam<br />
Oberfläche, in Bild (b) und (c) sind die Kamerabilder mit gefundenen Schachbrettecken<br />
dargestellt.
A.3. NAVIGATIONSSOFTWARE - LOCATOR 69<br />
Der Ablauf des Programms ist dem CamCalibrator nachempfunden. Nach dem Start der Anwendung<br />
muss zunächst die Auflösung und das Farbspektrum beider Kameras eingestellt werden. Farbe und Helligkeit<br />
der Kameras sind über die „Left, Right“-Knöpfe im „Cam Settings“-Bereich einstellbar. Die<br />
Anzahl der Spalten und Zeilen des verwendeten Schachbrettmusters muss wieder in die „Rows-, Cols“-<br />
Felder eingetragen werden. Nach Drücken des „Calibrate“-Buttons sucht das Programm im linken und<br />
rechten Kamerabild die inneren Ecken des Musters und markiert diese mit farbkodierten Punkten. Bei<br />
Positionsänderungen des Musters muss darauf geachtet werden, dass das Schachbrett immer in beiden<br />
Kamerabildern zu sehen ist. Durch die Betätigung des „Snap“-Knopfes wird die aktuelle Ansicht gespeichert.<br />
Zur Rektifizierung sind mindestens fünf Ansichten aus verschiedenen Winkeln notwendig. Die<br />
gewünschte Anzahl kann in „Num Images“ eingestellt werden, sollte aber nicht zu hoch angesetzt werden,<br />
da sonst die Berechnung der Kalibrations- und Rektifizierungsdaten unnötig lange dauert. Der „Sort<br />
Points“-Schalter wurde eingefügt, da sich die Reihenfolge der linken und rechten Schachbrettecken unterscheiden<br />
kann (erkennbar durch unterschiedliche Farbkodierung der Punkte in den Kamerabildern).<br />
Ist der Schalter aktiviert, werden die Ecken automatisch sortiert. Dies führte in allen Tests zu besseren<br />
Ergebnissen. Steht dem Programm eine ausreichende Anzahl an Bildpaaren zur Verfügung, werden<br />
die Kalibrierungs- und Rektifizierungsdaten automatisch berechnet. Diese können über die „Save“- und<br />
„Load“-Knöpfe abgespeichert und später wieder geladen werden.<br />
Über den „Show/Hide“-Button kann das berechnete Stereobild ein- und ausgeblendet werden. Das Ausund<br />
Einschalten der „Undistort“- und „Rectify“-Schalter macht den Einfluss von Kalibrierung und Rektifizierung<br />
auf das Disparitätsbild deutlich. Der „Steps“-Regler steuert die Anzahl der verwendeten Disparitätsstufen.<br />
Die Anwendung kann nach dem Anhalten der Kameras über den „Quit“-Knopf verlassen<br />
werden.<br />
A.3 Navigationssoftware - Locator<br />
Locator ist die implementierte Software des Navigationsassistenten. Sie bestimmt die Position des Sensormoduls<br />
durch Vergleiche zwischen real gemessenen und simulierten Abstandsdaten in Gebäuden. Für<br />
den Vergleich zwischen Realität und Modell wird ein OpenSceneGraph-Modell des Gebäudes verwendet.<br />
Aus diesem Grund baut der Locator auf dem OpenSceneGraph-Viewer auf und erbt das Konzept<br />
zur Mausinteraktion mit der Szene und einige Tastaturkürzel.<br />
Bevor der Viewer, welcher die aktuelle Position und Navigationshilfen anzeigt, gestartet wird, fragt eine<br />
MFC-Oberfläche den aktuellen Aufenthaltsraum ab.<br />
Abbildung A.3: Raum-Auswahl-Dialog. Über diesen Dialog muss beim Programmstart der aktuelle<br />
Aufenthaltsraum angegeben werden.
70 ANHANG A. BEDIENUNGSANLEITUNGEN<br />
Nach der Angabe des Startraumes zeigt der Locator im Hauptfenster die virtuelle Szene mit der aktuellen<br />
Position und Orientierung der Kamera an (siehe Abbildung A.4 (a)). Nebenfenster Right zeigt das Bild<br />
der realen Kamera mit den Messpunkten in den oberen sechs Quadranten. Im Nebenfenster Disp wird<br />
das aus der Stereodisparität berechnete Tiefenbild und ebenfalls die Position der Messpunkte angezeigt.<br />
Über die Schieberegler im Right-Fenster kann das Rot-Blau-Verhältnis der Kamera und die Anzahl der<br />
berechneten Varianten eingestellt werden. Die Zahlen entsprechen folgenden Varianten:<br />
Variants Berechnete Varianten<br />
0 keine<br />
1 aktuelle Position<br />
2, 3 aktuelle Position, vor, zurück<br />
3, 4 aktuelle Position, vor, zurück, links, rechts (alle)<br />
Tabelle A.1: Einfluss des Reglers „Variants“ auf die Anzahl der berechneten Varianten<br />
Über die s-Taste kann die Selbstlokalisation gestartet werden. Sollte die Orientierung der virtuellen<br />
Kamera nicht mit der realen Blickrichtung übereinstimmen kann dies über die r- / l-Tasten korrigiert<br />
werden. Die Suche nach modellierten Objekten steht über die f-Taste bereit. Tabelle A.2 fasst alle Tastaturkürzel<br />
zusammen, die zur Steuerung des Locators notwendig sind. Diese können im laufenden<br />
Programm über die h-Taste im Locator-Fenster eingeblendet werden. Die i-Taste ermöglicht zudem das<br />
Anzeigen der Navigationshinweise in einem HUD. Dieses gibt Auskunft über den aktuellen Aufenthaltsraum<br />
und zeigt den Namen und Abstand des Objekts im Zentrum des Kamerabildes an. Errechnet<br />
die Bewegungsextrapolation Kollisionen im Modell wird hier auch eine entsprechende Warnung ausgegeben.<br />
Zur besseren Visualisierung der aktuellen Position wird im oberen Teil des 3D-Modell-Fensters<br />
die Szene von außen angezeigt. Über die linke Maustaste kann die Szene rotiert werden. Die rechte<br />
Maustaste erlaubt das Hinein- und Herauszoomen. Werden beide Tasten gedrückt, ist zudem das Verschieben<br />
der betrachteten Szene möglich.<br />
Taste Locator-Funktion<br />
h Anzeige der Hilfe im Viewer<br />
i HUD anzeigen / ausblenden<br />
s Start / Stop der Positionsbestimmung<br />
← ↑ ↓ → Verschiebung der virtuellen Kamera<br />
l, r Rotation der virtuellen Kamera nach links, rechts<br />
u, d Translation der virtuellen Kamera nach unten, oben<br />
f Einmalige Suche nach Objekten<br />
t Trainieren einer neuen Objektbeschreibung<br />
w Modellbeschreibung speichern<br />
o Aktualisiertes 3D-Modell abspeichern<br />
ESC Programmende<br />
SPACE Rücksetzen der Außenansicht<br />
Tabelle A.2: Tastaturkürzel zur Steuerung des Navigationsassistenten
A.3. NAVIGATIONSSOFTWARE - LOCATOR 71<br />
a)<br />
Abbildung A.4: Locator Programmoberfläche. Das Hauptfenster (a) zeigt die Position der virtuellen<br />
Kamera, welche aus den Messdaten der Stereokamera berechnet wurde. Über dieses<br />
Fenster kann die Navigationssoftware gesteuert und die Position und Orientierung der<br />
Kamera nach Programmstart korrigiert werden. Bild (b) zeigt die Position der augenblicklich<br />
verwendeten Messpunkte in den Quadranten. Schieberegler ermöglichen die<br />
Begrenzung der berechneten Varianten und die Einstellung der Kamerafarben. In Bild<br />
(c) wird das Disparitätsbild und ebenfalls die Messpunkte angezeigt.<br />
b)<br />
c)
72 ANHANG A. BEDIENUNGSANLEITUNGEN<br />
A.3.1 Lernen einer Objektbeschreibung<br />
Über den Locator besteht die Möglichkeit neue Objektbeschreibungen für verschiebbare Objekte zu<br />
erzeugen. Bisher ist diese Funktion allerdings nur für das Objekt „Stuhl“ implementiert. Wird das zu<br />
erlernende Objekt wie in Abbildung A.5 (a) im Zentrum des Kamerabildes positioniert, kann über die<br />
t-Taste die Objekt-Trainings-Funktion gestartet werden. Wurde eine ausreichend große und charakteristische<br />
Region des Objekts markiert (siehe Abbildung A.5 (b)) kann die zugehörige Modellbeschreibung<br />
über die w-Taste abgespeichert werden.<br />
a) b)<br />
Abbildung A.5: Trainieren eines verschiebbaren Objekts im Locator. Bild (a) zeigt das zu trainierende<br />
Objekt im Zentrum des Bildes. In (b) ist die gefundene Region Weiß markiert.<br />
Die im Locator-Verzeichnis unter data/ abgelegte Modellbeschreibung enthält den Namen der wahrgenommenen<br />
Farbe des Objekts und die zur Erkennung notwendigen Histogrammwerte (siehe Abbildung<br />
A.6 (a). Das in Bild (b) gezeigte Form-Muster wird ebenfalls abgespeichert.<br />
a) b)<br />
Abbildung A.6: Histogramm und Forminformationen der Modellbeschreibung. In (a) sind die Histogrammwerte<br />
des gefundenen Stuhls dargestellt, Bild (b) zeigt das aus der gefüllten<br />
Region abgeleitete Form-Muster.
Literaturverzeichnis<br />
[1] Harris, C.; Stephens, M.: A Combined Corner and Edge Detector. In: M.M. Matthews, (eds.): 4th<br />
ALVEY vision conference, 147–151. University of Manchester, England, September, 1988<br />
[2] Matching with Invariant Features, 19. Oktober, 2005.<br />
Internetseite: http://www.wisdom.weizmann.ac.il/ deniss/vision_spring04/files/InvariantFeatures.ppt<br />
[3] Intel Corporation: Open Source Computer Vision Library, Reference Manual, 19. Oktober, 2001.<br />
Internetseite: http://www710.univ-lyon1.fr/ ameyer/devel/opencv/docs/opencvman_old.pdf<br />
[4] Zhang, Z.: Flexible Camera Calibration by Viewing a Plane from Unknown Orientations. In:<br />
ICCV, 666–673. 1999<br />
[5] Owens, R.: Epipolar geometry, 19. Oktober, 2005.<br />
Internetseite: http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/OWENS/LECT10/<br />
node3.html<br />
[6] Bougnoux, S.: Learning Epipolar Geometry, 19. Oktober, 2005.<br />
Internetseite: http://www-sop.inria.fr/robotvis/personnel/sbougnou/Meta3DViewer/EpipolarGeo.html<br />
[7] Li, X.: Stereo Vision based Object Distance Estimation in 3D Environment Models. Diplomarbeit,<br />
Universität Stuttgart, 2005<br />
[8] Canny, J. Finding Edges and Lines in Images. Technical report, Cambridge, MA, USA, 1983<br />
[9] Fermüller, C.: Edge detection, 19. Oktober, 2005.<br />
Internetseite: http://www.cfar.umd.edu/ fer/cmsc426/lectures/edge1.ppt<br />
[10] Wyszecki, G.; Stiles, W. S.: Color Science. John Wiley & Sons, 1982<br />
[11] Ulrich, I.; Borenstein, J.: The GuideCane-applying mobile robot technologies to assist the visually<br />
impaired. IEEE Transactions on Systems, Man, and Cybernetics, Part A Vol. 31.2, 131–136 , 2001<br />
[12] Kalkusch, M. (eds.). Structured Visual Markers for Indoor Pathfinding, 2002<br />
[13] Chaitanya, V. K.: A Robotic Wayfinding System for the Visually Impaired<br />
[14] Kombrink, S.: Positionsbestimmung in Gebäuden auf der Basis von Sensordaten und Umgebungsinformationen.<br />
Diplomarbeit, Universität Stuttgart, 2005<br />
73
74 LITERATURVERZEICHNIS<br />
[15] Hub, A. und Teufel, H. in Jamal, R. and Jaschinski, H.,: Virtuelle Instrumente in der Praxis. Hüthig<br />
2003<br />
[16] Hub, A.; Diepstraten, J.; Ertl, T.: Augmented Indoor Modeling for Navigation Support for the Blind.<br />
In: International Conference on Computers for People with Special Needs, 54–59. Las Vegas, NV,<br />
USA, 2005<br />
[17] Rogler, U.: NAS Navigation Assistance System - Orientierungshilfe für Blinde. Diplomarbeit,<br />
Hochschule für Gestaltung Offenbach am Main, 2005<br />
[18] Lienhart, R.; Maydt, J.: An Extended Set of Haar-like Features for Rapid Object Detection. IEEE<br />
ICIP Vol. 1, 900–903 , 2002<br />
[19] Viola, P.; Jones, M. J.: Rapid Object Detection using a Boosted Cascade of Simple Features. IEEE<br />
CVPR Vol. 1, 511–518 , 2001<br />
[20] Adolf, F.: OpenCV´s Rapid Object Detection, 19. Oktober, 2005.<br />
Internetseite: http://terasu.cntl.kyutech.ac.jp/ nishida/opencv/OpenCV_ObjectDetection_HowTo.pdf<br />
[21] Bouguet, J.-Y. Pyramidal Implementation of the Lucas Kanade Feature Tracker Description of the<br />
Algorithm. Intel Corporation, Microprocessor Research Labs, 1999<br />
[22] Lucas, B. D.; Kanade, T.: An Iterative Image Registration Technique with an Application to Stereo<br />
Vision (IJCAI). In: Proceedings of the 7th International Joint Conference on Artificial Intelligence<br />
(IJCAI ’81), 674–679. April, 1981<br />
[23] Open Computer Vision Library, 19. Oktober, 2005.<br />
Internetseite: http://sourceforge.net/project/showfiles.php?group_id=22870&package_id=16937<br />
[24] Open Scene Graph, 19. Oktober, 2005.<br />
Internetseite: http://www.openscenegraph.org<br />
[25] Sanftmann, H.: Objekt Registrierung für AR-Anwendungen. Diplomarbeit, Universität Stuttgart,<br />
2005<br />
[26] OpenCV Library Documentation, 19. Oktober, 2005.<br />
Internetseite: http://www.cs.bham.ac.uk/resources/courses/robotics/doc/index.php<br />
[27] Hu, M.-K.: Visual pattern recognition by moment invariants. IEEE Trans. Inform. Theory Vol. 8,<br />
179–187 , 1962<br />
[28] Point Grey Research, 19. Oktober, 2005.<br />
Internetseite: http://www.ptgrey.com<br />
[29] Point Grey Customer Support Login, 19. Oktober, 2005.<br />
Internetseite: http://www.ptgrey.com/support/downloads/ps-downloads.html<br />
[30] Birchfield, S.; Tomasi, C.: Depth Discontinuities by Pixel-to-Pixel Stereo. Int. J. Comput. Vision<br />
Vol. 35.3, 269–293 , 1999<br />
[31] Schmidt Jensen, R.: Open source exporter from 3ds max to openscenegraph, 19. Oktober, 2005.<br />
Internetseite: http://osgexp.vr-c.dk/
LITERATURVERZEICHNIS 75<br />
[32] Hinterseher, M.: Schnittpunkt zweier Gerden, 19. Oktober, 2005.<br />
Internetseite: http://www.hinterseher.de/Diplomarbeit/GeometrischeFunktionen.html<br />
[33] Videre Design, 19. Oktober, 2005.<br />
Internetseite: http://www.videredesign.com/stereo_on_a_chip.htm<br />
[34] Hub, A.; Diepstraten, J.; Ertl, T.: Design of an Object Identification and Orientation Assistant for<br />
the Deafblind. In: 6th DbI European Conference On Deafblindness. Presov, Slovakia, 2005
Abbildungsverzeichnis<br />
2.1 Verhältnis von Eigenwerten an Kanten und Ecken . . . . . . . . . . . . . . . . . . . . . 4<br />
2.2 Kamerakalibrierung über Schachbrettmuster . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
2.3 Epipolarlinien nach [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.4 Disparitätsbild aus rektifizierten Einzelbildern . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.5 Gerade-zu-Punkt-Transformation zur Darstellung von vertikalen Geraden . . . . . . . . 9<br />
2.6 RGB-Würfel und HSV-Farbmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
2.7 Lab-Farben für verschiedene Luminanzwerte . . . . . . . . . . . . . . . . . . . . . . . 10<br />
2.8 Regiongrowing-Algorithmus zur farbtonbasierten Selektion . . . . . . . . . . . . . . . . 11<br />
2.9 Prototyp eines Navigationsassistenten mit integrierter Kamera und Inertialsensor . . . . 13<br />
2.10 Navigation Assistant System - Designstudie . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
3.1 Aufbau des Sensormoduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.2 Positionierung und Ausrichtung der virtuellen Kamera . . . . . . . . . . . . . . . . . . 19<br />
3.3 Berechnung der besten Positionsvariante . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
3.4 Abstandsmessung im Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.5 Messpunktauswahl anhand von erkannten Objekten . . . . . . . . . . . . . . . . . . . . 24<br />
3.6 Zuordnung von erkannten Linien zu Modellkanten . . . . . . . . . . . . . . . . . . . . 25<br />
3.7 Schnittpunkt von Diagonalen in langen Gängen . . . . . . . . . . . . . . . . . . . . . . 26<br />
3.8 Featurepunkte mit Wandabstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
3.9 Geschwindigkeitsvergleich zw. Messpunkt-Such-Verfahren . . . . . . . . . . . . . . . . 28<br />
3.10 Farbsegmentierung über Regiongrowing . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
3.11 Regiongrowing mit und ohne Berücksichtung der Tiefenunterschiede . . . . . . . . . . . 29<br />
3.12 Modellbeschreibung für einen roten Stuhl . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
3.13 Farbtöne des Histogramms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
3.14 Visuelle Ausgabe von Navigationshinweisen . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
3.15 Systemdesign des Navigationsassistenten . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
77
78 ABBILDUNGSVERZEICHNIS<br />
4.1 Testaufbauten zur Erfassung von Stereobildern . . . . . . . . . . . . . . . . . . . . . . 35<br />
4.2 Screenshot des entwickelten MFC-Programms zur Kalibrierung von Firewire-Kameras . 38<br />
4.3 MFC Programm zur Kalibrierung und Rektifizierung der Kameras . . . . . . . . . . . . 38<br />
4.4 Versuchsaufbau für Synchronitätstests . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.5 Zeitversatz zwischen Einzelbildern bei unterschiedlichen Kameras und APIs . . . . . . . 40<br />
4.6 Point Grey Bumblebee Stereokamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.7 Geschwindigkeitsvergleich zwischen OpenCV und Point Grey API . . . . . . . . . . . . 43<br />
4.8 Zur Navigationsunterstützung eingesetzter, modellierter Gebäudeabschnitt . . . . . . . . 45<br />
4.9 Anzeige verschiedener Hierarchiestufen des Gebäudes . . . . . . . . . . . . . . . . . . 46<br />
4.10 Osg Export Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
4.11 Darstellung des gerenderten 3D-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
4.12 Berechnungsschritte zur Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . 48<br />
4.13 Ermittlung des Wandabstandsschätzwertes . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
4.14 Schnittpunkt zweier Geraden im 2D-Raum, Quelle [32] . . . . . . . . . . . . . . . . . . 49<br />
5.1 Navigationsassistent bestehend aus Samsung x20 und Sensormodul . . . . . . . . . . . 53<br />
5.2 Abweichung der Abstandsmessung über Stereobilder der Bumblebee . . . . . . . . . . . 54<br />
5.3 Ergebnisse der Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
5.4 Ergebnisse der Positionsbestimmung in Wohnräumen . . . . . . . . . . . . . . . . . . . 58<br />
5.5 Distanzen zu lokalisierten Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
5.6 Performancemessung der Navigationssoftware . . . . . . . . . . . . . . . . . . . . . . . 61<br />
A.1 CamCalibrator - Programm zur Kalibrierung von Kameras . . . . . . . . . . . . . . . . 67<br />
A.2 StereoCam - Programm zur Kalibrierung und Rektifizierung von Kameras . . . . . . . . 68<br />
A.3 Raum-Auswahl-Diealog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69<br />
A.4 Locator Programmoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71<br />
A.5 Trainieren eines verschiebbaren Objekts im Locator . . . . . . . . . . . . . . . . . . . . 72<br />
A.6 Histogramm und Forminformationen der Modellbeschreibung . . . . . . . . . . . . . . 72
Erklärung<br />
Hiermit versichere ich, diese Arbeit<br />
selbständig verfaßt und nur die<br />
angegebenen Quellen benutzt zu haben.<br />
(Tim Hartter)