Schriftliche Ausarbeitung herunterladen

Institut für Visualisierung und Interaktive Systeme 

Universität Stuttgart 

Universitätsstraße 38 

D–70569 Stuttgart 

Diplomarbeit Nr. 2325 

Bildbasierte Positionserkennung 

und Aktualisierung von 

modellierten Objekten in Gebäuden 

Tim Hartter 

Studiengang: Informatik 

Prüfer: Prof. Dr. Thomas Ertl 

Betreuer: Dr. Andreas Hub 

begonnen am: 20. April 2005 

beendet am: 20. Oktober 2005 

CR-Klassifikation: H.5.2, I.2.10, I.3.7, I.4.1, I.4.3, I.4.6, I.4.7, 

I.4.8, I.6.8, K.3.1, K.4.2

Ich danke meinem Betreuer, Dr. Andreas Hub, für seine Unterstützung 

bei der Verfassung dieser Arbeit. 

Bedanken möchte ich mich auch bei Reinhard Lafrenz für die 

zahlreichen Tipps in Fragen der Bildanalyse und des Bildverstehens. 

Zudem möchte ich mich bei meiner Mutter für die Hilfe bei der 

Korrektur der schriftlichen Ausarbeitung herzlich bedanken.

Inhaltsverzeichnis 

1 Einleitung 1 

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2 Grundlagen 3 

2.1 Grundlagen der Bildverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2.1.1 Featurepunkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2.1.2 Kalibrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.1.3 Rektifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.1.4 Stereodisparität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.1.5 Linienerkennung durch Hough-Transformation . . . . . . . . . . . . . . . . . . 8 

2.1.6 Farbmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.1.7 Regiongrowing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.2 Stand der Forschung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.3 Vorarbeiten und verwendete APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.3.1 Farbklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.3.2 Navigation Assistance System (NAS) . . . . . . . . . . . . . . . . . . . . . . . 13 

2.3.3 Stereo Vision based Object Distance Estimation in 3D Environment Models . . . 14 

2.3.4 Rapid Object Detection using Haar-like Features . . . . . . . . . . . . . . . . . 14 

2.3.5 Lucas-Kanade Optical Flow in Pyramids . . . . . . . . . . . . . . . . . . . . . 15 

2.3.6 Microsoft DirectX 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.3.7 NI-IMAQ for IEEE 1394 Cameras . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.3.8 Intel Open Source Computer Vision Library (OpenCV) . . . . . . . . . . . . . . 15 

2.3.9 OpenSceneGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.3.10 Microsoft Foundation Classes (MFC) . . . . . . . . . . . . . . . . . . . . . . . 16 

3 Lösungsentwurf 17 

3.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.2 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

3.2.1 Aufbau des Sensormoduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

3.2.2 Positionsbestimmung der Kamera . . . . . . . . . . . . . . . . . . . . . . . . . 19 

3.2.3 Auswahl geeigneter Messpunkte . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

3.2.4 Detektion von verschiebbaren, modellierten Objekten . . . . . . . . . . . . . . . 28 

3.2.5 Aktualisierung des Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

I

II INHALTSVERZEICHNIS 

4 Implementierung 35 

4.1 Sensordatenerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

4.1.1 Ansteuerung der Kameras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

4.1.2 Berechnung der Stereodisparitätsbilder . . . . . . . . . . . . . . . . . . . . . . 37 

4.1.3 Verwendung eines selbstsynchronisierenden Stereokameramoduls . . . . . . . . 41 

4.1.4 Verfahren zur Berechnung der Stereobilder . . . . . . . . . . . . . . . . . . . . 42 

4.1.5 Ansteuerung des Xsens Motion Trackers . . . . . . . . . . . . . . . . . . . . . 43 

4.2 Bereitstellung der Modelldaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

4.2.1 Erstellung des Gebäudemodells mit 3D Studio Max . . . . . . . . . . . . . . . . 44 

4.2.2 Darstellung des Gebäudemodells . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.3 Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

4.3.1 Bestimmung geeigneter Messpunkte . . . . . . . . . . . . . . . . . . . . . . . . 48 

4.3.2 Positionsbestimmung der virtuellen Kamera . . . . . . . . . . . . . . . . . . . . 50 

4.4 Erkennung von verschiebbaren, modellierten Objekten . . . . . . . . . . . . . . . . . . 50 

4.5 Aktualisierung des 3D-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

5 Ergebnisse 53 

5.1 Hardwarekomponenten des Navigationsassistenten . . . . . . . . . . . . . . . . . . . . 53 

5.2 Distanzmessung über Stereokamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

5.3 Selbstlokalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

5.4 Lokalisierung von verschiebbaren Objekten . . . . . . . . . . . . . . . . . . . . . . . . 60 

5.5 Performancemessung der Navigationssoftware . . . . . . . . . . . . . . . . . . . . . . . 61 

6 Diskussion 63 

6.1 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

7 Zusammenfassung 65 

A Bedienungsanleitungen 67 

A.1 Kalibrierungs-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

A.2 Rektifizierungs-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

A.3 Navigationssoftware - Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

A.3.1 Lernen einer Objektbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Literaturverzeichnis 73 

Abbildungsverzeichnis 77

Kapitel 1 

Einleitung 

1.1 Motivation 

Die Navigation in unbekannten Gebäuden stellt für Blinde eine große Herausforderung dar. Hier fehlt 

ihnen die Kenntnis der genauen Gebäudespezifikationen, über die sie sich üblicherweise in einer bekannten 

Umgebung orientieren. Da Informationen, die über gängige Hilfsmittel wie den Blindenstock 

erfasst werden können sehr begrenzt sind, wird heutzutage versucht, über elektronische Navigationshilfen 

weitere Gebäudedetails zur Verfügung zu stellen. Diese sollen durch die Angabe kontextbezogener 

Gebäudeinformationen helfen, auch schwierige Aufgaben wie das Finden eines bestimmten Raumes 

ohne fremde Hilfe zu bewältigen. 

Am Institut für Visualisierung und Interaktive Systeme werden zu diesem Zweck im Rahmen des Sonderforschungsbereiches 

Nr. 627 (Nexus Projekt) im Teilprojekt D2 Orientierungsassistenten für Blinde 

entwickelt. Ein Teilziel dieses Projektes ist es, den Aufenthaltsort einer blinden Person zu ermitteln. Die 

genaue Bestimmung der Position eines portablen Sensormoduls in Innenräumen kann genutzt werden, 

um die Navigation des Blinden zu unterstützen, und die Erkennung von Objekten durch Vergleiche mit 

einem 3D-Gebäudemodell ermöglichen. 

Die hier vorgestellte Arbeit zeigt, wie unter Zuhilfenahme einer Stereokamera und eines Intertialsensors 

(Orientierungssensor) die eigene Position bestimmt und die Abstände zu modellierten, verschiebbaren 

Objekten berechnet werden können um so den Blinden bei der Navigation durch das Gebäude zu unterstützen. 

1.2 Voraussetzungen 

Der vorgestellte Ansatz beschränkt sich auf die Navigation in Gebäuden. Diese müssen als 3D-Gebäudemodell 

vorhanden sein und alle festen und verschiebbaren Einrichtungsgegenstände des Gebäudes enthalten. 

Zudem wird vorausgesetzt, dass der aktuelle Aufenhaltsraum des Benutzers bekannt ist und die vom 

Inertialsensor abgefragte Orientierung korrekt ist. 

1

2 KAPITEL 1. EINLEITUNG 

1.3 Gliederung 

Diese Diplomarbeit gliedert sich wie folgt. Kapitel 2 beschreibt die Grundlagen und Vorarbeiten, die 

als Ressourcen für diese Arbeit herangezogen wurden. Kapitel 3 stellt die Problemstellung und den 

verwendeten Lösungsansatz vor. In der Implementierung (Kapitel 4) werden die zur Lösung der Aufgabe 

implementierten Methoden näher beschrieben. Kapitel 5 stellt die Ergebnisse einiger Selbst- und 

Objektlokalisierungstests dar. Diese werden in Kapitel 6 diskutiert und ein Ausblick auf mögliche Verbesserungen 

gegeben. Die Arbeit schließt mit einer kurzen Zusammenfassung der gewählten Methoden 

und Ergebnisse in Kapitel 7.

Kapitel 2 

Grundlagen 

Dieses Kapitel befasst sich mit den Grundlagen und Vorarbeiten, die als Basis für die hier vorgestellte 

Arbeit verwendet wurden. Es beschreibt den Stand der Forschung und die zur Lösung der Aufgabenstellung 

in Frage kommenden Verfahren. Diese sind zur Lösung von einzelnen Teilproblemen der 

Aufgabenstellung (nach Anpassung an das Projekt) geeignet. Im folgenden Kapitel wird ein Entwurf 

vorgestellt, der eine mögliche Kombination der Teillösungen vorschlägt und die Struktur des zu implementierenden 

Verfahrens vorstellt. 

2.1 Grundlagen der Bildverarbeitung 

Zum Verständnis dieser Arbeit, welche die Entwicklung eines bildbasierten Navigationsassistenten beschreibt, 

ist die Kenntnis der in den nächsten Abschnitten erklärten Grundlagen der Bildverarbeitung 

erforderlich. 

2.1.1 Featurepunkte 

Als Featurepunkte werden in der Bildverarbeitung Stellen im Bild bezeichnet, welche besondere Merkmale 

aufweisen. Besonders geeignete Bildmerkmale sind Ecken und Kanten im Graustufenbild. Diese 

sind kaum von Farbverzerrungen bei der Bilderfassung abhängig und können für die unterschiedlichsten 

Aufgaben in der Bildverarbeitung eingesetzt werden, wie zum Beispiel 

• Ausrichtung von Bildern 

• 3D Rekonstruktion 

• Verfolgung von Bewegungen 

• Objekterkennung 

• Roboternavigation 

• Suche in Bilddatenbanken 

3

4 KAPITEL 2. GRUNDLAGEN 

Harris und Stephens stellen in [1] ein Verfahren zur Erkennung von Kanten und Ecken vor, in dem die 

Hessematrix in einer Nachbarschaftsumgebung um jeden Bildpunkt berechnet wird. 

⎡ 

⎢ 

⎣ 

∑ 

Nachbarscha ft 

∑ 


� �2 δI 

δx 

� � 

δ2I δxδy 

� � 

δ2I ∑ δxδy 


∑ 


� δI 

δy 

� 2 

⎤ 

⎥ 

⎦ , Intensität I (2.1) 

Aus dieser ergeben sich die Eigenwerte λ1,λ2 für jeden Bildpunkt. Bildpunkte an Kanten zeichnen 

sich durch einen großen Eigenwert λ1 oder λ2 aus. An diesen Stellen ändert sich in einer Richtung 

die Helligkeit sehr stark. Ecken im Bild zeichnen sich hingegen durch starke Änderungen in beiden 

Dimensionen aus. Die zugehörigen Eigenwerte sind näherungsweise gleich groß. 

� 2 

� 1 

Nachbarschaft 

a) Eigenwerte an Kanten λ2 >> λ1 

� 2 

� 1 

b) Eigenwerte an Ecken λ1 ≈ λ2 

Abbildung 2.1: Verhältnis von Eigenwerten an Kanten und Ecken, (a) zeigt die Eigenwerte an einer 

Bildkante, diese beschreiben aufgrund ihrer unterschiedlichen Größe eine Ellipse. In 

(b) sind die Eigenwerte einer Ecke dargestellt, diese sind näherungsweise gleich groß 

und bilden somit einen rotationsinvarianten Kreis. 

Aufgrund der Rotationsinvarianz ihrer Eigenwerte stellen sich Ecken im Graustufenbild als besonders 

gut zu verfolgende Merkmale heraus. Diese können durch eine „Nicht-Maxima-Unterdrückung“ (nonmaxima-suppression) 

anhand eines Grenzwertes λ gefiltert werden (min(λ1,λ2) > λ) und ergeben so die 

zur Weiterverfolgung am besten geeigneten Featurepunkte des Bildes. Eine ausführlichere Beschreibung 

des „Harris Edge Detectors“ findet sich unter [2]. 

2.1.2 Kalibrierung 

Bei jeder Kamera entstehen durch die zur Abbildung verwendete Linse Verzerrungen im aufgenommenen 

Kamerabild (sphärische Aberration). Durch diesen Effekt erscheinen Geraden im Kamerabild nicht 

mehr als Geraden, sondern weisen eine starke konzentrische Krümmung auf. Die Stärke der Verzerrung 

hängt hauptsächlich vom Öffnungswinkel der verwendeten Kamera ab und ist in Abbildung 2.2 für eine 

Kamera mit starkem Weitwinkelobjektiv abgebildet.

2.1. GRUNDLAGEN DER BILDVERARBEITUNG 5 

Unter der Kalibrierung einer Kamera versteht man die Berechnung einer Entzerrungsmatrix aus den 

für die Verzerrungen verantwortlichen Kameraparametern. Über diese kann das verzerrte Bild korrigiert 

werden. Die Kameraparameter gliedern sich in die kameraspezifischen, intrinsischen Parameter: 

• Fokale Länge ( fx, fy), Abstand zwischen Linse und Bildebene in X-/Y-Richtung) 

• Position des Bildmittelpunktes in Pixelkoordinaten (cx,cy) 

und die räumlichen Zusammenhänge zwischen Kamera und Weltkoordinaten, den extrinsischen Parametern: 

• Rotationsmatrix (R) 

• Translationsvektor (�t) 

Für die Abbildung der Koordinaten eines Punktes M im Raum auf die Bildkoordinaten m gilt nach [3] 

folgende Vorschrift: 

m = A[R�t]M (2.2) 

wobei sich A aus den intrinsischen Parametern der Kamera wie folgt zusammensetzt: 

⎡ 

A = ⎣ 

fx 0 cx 

0 fy cy 

0 0 1 

⎤ 

⎦ (2.3) 

Zur Berechnung der gesuchten Parameter kann der von Zhang vorgestellte Algorithmus [4] verwendet 

werden, der über die Präsentation eines bekannten Musters aus verschiedenen Positionen (Abbildung 

2.2 (a)-(c)) alle für die Entzerrung des Bildes notwendigen Daten berechnet, indem die intrinsischen 

und extrinsischen Parameter so lange variiert werden, bis der Fehler zwischen realer und optimaler 

Abbildung des Musters (d) minimal ist. 

a) b) c) d) 

Abbildung 2.2: Kamerakalibrierung über Schachbrettmuster nach Zhang. Die Kamera nimmt ein 

Schachbrettmuster aus unterscheidlichen Positionen (a)-(c) auf. Dieses wird mit der 

optimalen Abbildung des Musters (d) verglichen um die Kameraparameter zu berechnen.


2.1.3 Rektifizierung 

Nach der im letzten Abschnitt beschriebenen Kalibrierung der Kamera erscheinen ursprüngliche Geraden 

in den entzerrten Bildern wieder als solche. Für die Abbildung eines Punktes M im Raum auf 

den CCD-Chip einer Kamera, wie sie in Abbildung 2.3 (a) dargestellt ist, gilt Gleichung 2.2. Bei Verwendung 

einer Stereokamera gilt diese Abbildungsvorschrift für beide Kameras. Zur Vereinfachung der 

Berechnung eines Stereodisparitätsbildes aus den beiden Einzelbildern der Kameras sorgt man durch die 

Rektifizierungstransformation dafür, dass die beiden Abbildungen des Punktes M, wie in Abbildung 2.3 

(b) gezeigt, auf einer Geraden, der sogenannten Epipolarlinie zu liegen kommen. Diese Linie ist über 

den Bildpunkt m und die nach Gleichung 2.2 in die Bildebene projizierte Position der jeweils anderen 

Kamera festgelegt. Durch Angabe einiger korrespondierender Punkte beider Kamerabilder kann die zur 

Rektifizierung notwendige Rektifizierungstransformation für jede Kamera berechnet werden. Diese entspricht 

einer Rotation beider Kameras, bis die Blickrichtungen parallel sind und die Epipolarlinien, wie 

in Abbildung 2.3 (c) gezeigt, aufeinander liegen. Eine ausführliche Beschreibung dieser Berechnung 

findet sich in [5]. 

a) b) 

c) 

⇓ Rektifizierung ⇓ 

Abbildung 2.3: Epipolarlinien nach [6]. Durch die Rektifizierungstransformation werden die beiden 

Kameras aus (b) so ausgerichtet, dass ihre Blickrichtungen parallel sind und zugehörige 

Scanlines der Kamerabilder aufeinander liegen. Bild (c) zeigt die Bildebenen nach der 

Rektifizierung.


2.1.4 Stereodisparität 

Die Stereodisparität ist ein Maß für den Abstand eines Punktes M von einer Stereokamera. Sie entspricht 

dem Abstand d zwischen den zueinander gehörigen Projektionen (m,m ′ ) des Punktes M aus Abbildung 

2.3 (c) und berechnet sich über die Formel: 

d = |mm ′ | (2.4) 

Nach Li [7] gilt hierbei, dass weit entfernte Punkte einen kleinen, und nahe Punkte einen großen Disparitätswert 

ergeben. Die Abbildungen der Punkte rücken auseinander, je näher dieser an der Stereokamera 

liegt. 

Die Stereodisparität wird dazu verwendet, ein Tiefenbild aus den zwei Einzelbildern einer Stereokamera 

zu berechnen, indem Featurepunkte des linken Bildes denselben Features im rechten Bild zugeordnet 

werden. Dies wird durch die vorangehende Rektifizierung der Kamerabilder vereinfacht, da sichergestellt 

ist, dass sich zueinander gehörige Merkmale auf derselben Scanline im Bild befinden. Somit muss 

nur in einer Dimension nach dem zugehörigen Bildpunkt gesucht werden. Berechnungslücken im Disparitätsbild 

können durch homogene Flächen entstehen, da diese keine Featurpunkte enhalten. Für die 

Disparitätsberechnung müssen die Einzelbilder möglichst zeitgleich aufgenommen werden, da sonst 

bei Bewegungen ein zusätzlicher Versatz zwischen den Bildern entstehen kann, der den Disparitätswert 

verfälscht. Die Begrenzung der Suche auf diskrete Abstandsstufen (Disparitätsstufen) kann den Rechenaufwand 

begrenzen. 

Linke Kamera Rechte Kamera Disparitätsbild 

mit 16 Stufen 

Abbildung 2.4: Durch Vergleiche der Abstände korrespondierender Features im linken und rechten Kamerabild 

kann für diese ein Disparitätswert berechnet und im Disparitätsbild dargestellt 

werden. Hierbei werden nahe Objekte hell und entfernte dunkel dargestellt. 

Aus der fokalen Länge f und dem Abstand B zwischen den Mittelpunkten der Kameras lässt sich folgender 

Zusammenhang zwischen Disparitätswert d und dem Abstand Z zu einem Objekt in der Szene 

anhand Abbildung 2.4 (c) über den Strahlensatz herleiten: 

d f 

= 

B Z 

Somit gilt für die Distanz eines Bildpunktes mit Disparitätswert d 

(2.5)


Z = 

f B 

d 

X = (xc − x)Z 

f 

Y = (yc − y)Z 

f 

wobei (xc,yc) die Koordinaten des Bildmittelpunktes sind. Aus den drei Raumkoordinaten berechnet 

sich der Abstand zu einem Punkt P(X,Y,Z) im Raum als Länge z des Ortsvektors �p. 

2.1.5 Linienerkennung durch Hough-Transformation 

(2.6) 

(2.7) 

(2.8) 

z = |�p| = 

� 

X 2 +Y 2 + Z2 (2.9) 

Die Linienerkennung wird in der Bildanalyse oft eingesetzt, um grobe Strukturen aus Bildern zu extrahieren. 

Bevor in einem Bild Linien gesucht werden, wird üblicherweise zunächst ein Kantenbild 

berechnet. Als sehr geeignetes Verfahren steht hier der Canny Edge Detector [8] zur Verfügung. Andere 

Verfahren wie der Sobel Operator oder die Laplace Transformation führen ebenfalls zu guten Ergebnissen. 

Die Hough-Transformation ermöglicht eine Erkennung kollinearer Punkte im berechneten Kantenbild, 

indem die Geradengleichung y = mx + c nach c aufgelöst wird. Somit beschreibt jeder Punkt (x,y) im 

Bild eine Gerade im Hough-Raum (m,c) über: 

c = −mx + y (2.10) 

Es lässt sich zeigen, dass alle Hough-Geraden, die sich in einem Punkt (xi,yi) schneiden, im Bild auf 

einer Geraden liegen. Gleichung 2.10 lässt allerdings keine Darstellung senkrechter Geraden zu, da hier 

m = ±∞ wäre. Um diese Geraden ebenfalls darstellen zu können, werden die Hough-Geraden über 

folgende Parametrisierung als Punkte im (r,θ) Raum dargestellt. 

r = x ∗ cos(θ) + y ∗ sin(θ) (2.11) 

Hierbei ist�r der Normalenvektor auf die darzustellende Gerade mit Abstand r vom Ursprung und dem 

Winkel θ zur m-Achse (siehe Abbildung 2.5). Auf diese Weise können auch senkrechte Geraden (θ = 

±180 ◦ ) dargestellt werden. 

Durch die Transformation aller Punkte des Kantenbildes in den Hough-Raum ist es nun möglich, Geraden 

im Bild zu erkennen. Diese stellen sich, wie in [9] näher beschrieben wird, als häufige Treffer 

desselben Punktes in der (θ,r)-Ebene dar.


c 

r 0 

Θ 0 

g 

m 

a) Gerade im Hough-Raum b) Gerade als Punkt in der (θ,r)-Ebene 

Abbildung 2.5: Gerade-zu-Punkt-Transformation zur Darstellung von vertikalen Geraden. Diese Transformation 

wird eingesetzt, um Geraden im Hough-Raum als Punkte darzustellen. Die 

Erkennung von Geraden im Bild nutzt die Tatsache, dass in Hough-Geraden transformierte 

Bildpunkte, welche auf einer Geraden liegen, durch denselben Punkt in der 

(θ,r)-Ebene repräsentiert werden. 

2.1.6 Farbmodelle 

Üblicherweise werden Bilder im Computer als Folge von Rot, Grün und Blau (RGB) Werten gespeichert, 

da diese Repräsentation mit den Farbkanälen des Ausgabemediums (Bildschirm) übereinstimmt. 

Da sich Helligkeitsunterschiede auf alle drei Farbkanäle auswirken, empfiehlt sich, zur späteren Selektion 

eines bestimmten Farbbereichs, eine Konvertierung in einen Farbraum, der die Helligkeitsinformationen 

von den Sättigungs- und Farbtonwerten trennt und somit die Selektion eines bestimmten 

Farbbereichs zulässt. 

HSV Farbraum 

Im HSV Farbmodell werden Farben durch Helligkeit (Value), Sättigung (Saturation) und Farbton (Hue) 

beschrieben. Dies entspricht dem Blick entlang der Diagonalen in Abbildung 2.6 (a) von Schwarz nach 

Weiß und ergibt die sogenannte HSV-Farbpyramide (b). 

Lab Farbraum 

Der Lab-Farbraum (auch L*a*b-Farbraum) ist ein von der Commission Internationale d’Eclairage (CIE) 

1976 entwickeltes Farbmodell. Neben dem HSV-Modell eignet sich der Lab-Farbraum besonders gut zur 

wahrnehmungsorientierten Selektion von Farben, da er an die menschliche Farbwahrnehmung angepasst 

und geräteunabhängig ist. Im Lab-Raum werden die drei Farbkanäle (RGB) auf einen Helligkeitswert 

(L), einen rot-grün Wert (a) und einen blau-gelb Anteil (b), wie in [10] näher beschrieben wird, aufgeteilt. 

Abbildung 2.7 zeigt die Farbanteile bei unterschiedlichen Luminanzwerten. 

r 0 

r 

Θ 0 

Θ


a) RGB Farbwürfel b) HSV-Farbpyramide 

Abbildung 2.6: RGB-Würfel und HSV-Farbmodell. Das HSV-Modell ergibt sich aus dem Blick entlang 

der Diagonalen von Schwarz nach Weiß im RGB-Würfel und eignet sich besonders 

zur wahrnehmungsorientierten Selektion von Farbtönen in Bildern, da hierfür nur ein 

bestimmter Winkelbereich H betrachtet werden muss. 

25 % Luminanz 50 % Luminanz 75 % Luminanz 

Abbildung 2.7: Lab-Farben für verschiedene Luminanzwerte. Die Farben erscheinen für gleiche Luminanzwerte 

in guter Näherung gleich hell. Luminanz Null entspricht Schwarz, eine 

Luminanz von 100 Prozent entspricht Weiß.

2.2. STAND DER FORSCHUNG 11 

2.1.7 Regiongrowing 

Als „Regiongrowing“ wird ein Verfahren bezeichnet, bei dem der Bereich um einen Startpunkt solange 

vergrößert wird, bis die Farbwerte größer als ein vorgegebener Schwellwert sind. Über dieses Verfahren 

ist es möglich, ausgehend von einem zufällig gewählten Startpunkt, Regionen ähnlicher Farbe im Bild 

zu finden und für die spätere Weiterverarbeitung zu markieren. 

Abbildung 2.8 (a) zeigt ein Beispielbild, für das in (b) ein Regiongrowing-Algorithmus verwendet wurde, 

um ausgehend vom Zentrum des Objektes das Objekt zu segmentieren. 

a) Beispielszene b) Markierung von Objekten durch Selektion 

Abbildung 2.8: Regiongrowing-Algorithmus zur farbtonbasierten Selektion. Die Objekte im Bild (a) 

werden von einem Startpunkt aus mit Farbe gefüllt, indem solange der Bereich um 

den Startpunkt mit einbezogen wird, bis sich die Farbwerte zu stark von denen des 

Startpunktes unterscheiden. Bild (b) zeigt die so segmentierten Bildbereiche. 

2.2 Stand der Forschung 

Die bisher veröffentlichten Verfahren zur Unterstützung von Blinden bei der Navigation konzentrieren 

sich auf die Lösung folgender Aufgaben. 

• Bestimmung der eigenen Position 

• Erkennung von Objekten in der Umgebung 

• Erkennung von Hindernissen / Gefahren 

• Navigation 

Häufig wird nur einer dieser Aspekte durch bestehende Lösungen abgedeckt. Die folgenden Abschnitte 

beschreiben den Stand der Forschung in diesen Bereichen und machen die Notwendigkeit der Verbindung 

aller Teilgebiete zur Lösung der hier behandelten Aufgabe deutlich.


Erkennung von Hindernissen 

Der von Ulrich et al. vorgestellte GuideCane [11] ermöglicht es Hindernissen auszuweichen, aber nicht 

die zielgerichtete Leitung des Blinden zu einem gesuchten Raum im Gebäude, da die Information über 

die eigene Position fehlt und nur auf Objekte im direkten Umfeld des Benutzers reagiert wird. Da diese 

Objekte nur als Hindernisse erkannt werden, bleiben Informationen wie der Zustand von Türen unberücksichtigt. 

Erkennung der eigenen Position 

Projekte wie das Signpost-Projekt von Studierstube [12], welches die Positionsbestimmung ebenfalls 

über Stereokamera und Inertialsensor realisiert, sowie das von Chaitanya et al. in [13] vorgestellte System 

zur Navigation anhand von RFID-Tags verwenden Landmarken zur Selbstlokalisation. Sie setzen 

deshalb eine mit Markierungen präparierte Umgebung voraus, auf die in diesem Ansatz komplett verzichtet 

werden sollte. Die Lösungen aus der Robotik kommen oft auch ohne diese Präparationen aus, 

verwenden aber Ultraschall- oder Lasermessgeräte, um ihre eigene Position im Raum zu bestimmen. 

Diese sind mit diversen Problemen behaftet. Laserlicht wird von bestimmten Materialien stark gestreut 

oder nicht reflektiert. Bei Ultraschall ist die Interpretation reflektierter Signale häufig vieldeutig. 

Kombrink stellt in seiner Diplomarbeit [14] einen Ansatz vor über den die Position eines Inertialsensors 

durch die Messung von Beschleunigungen, welche bei der Bewegung auftreten, berechnet werden kann. 

Dieser Ansatz setzt keine Marker in der Umgebung voraus, ist aber anfällig für magnetischen Störungen, 

da diese aufgrund fehlender weiterer Sensoren kaum kompensiert werden können. 

Erkennung von Objekten in der Umgebung 

In der Umgebung von Blinden kommen häufig auch verschiebbare Objekte (wie zum Beispiel Stühle) als 

Hindernisse vor, deren Position im Modell nicht immer aktuell gehalten werden kann. Um die Position 

erkannter Objekte im Modell zu aktualisieren, wird die in der Robotik oft angewandte Erkennung anhand 

von Farbe und Form in diesem Ansatz mit einigen Erweiterungen weiterverwendet. 

Fazit 

Der hier vorgestellte Prototyp versucht, die Teillösungen der beschriebenen Ansätze zu kombinieren und 

durch „geschickt gewählte“ Vergleiche mit Modelldaten, allein aus Stereobild und Richtungssensor die 

eigene Position und die Beschaffenheit seiner Umgebung zu bestimmen. Dies ermöglicht dem blinden 

Benutzer die Navigation durch unbekannte Gebäude, ohne auf fremde Hilfe, schwere Sensorhardware 

oder eine speziell präparierte Umgebung angewiesen zu sein. In den nächsten Abschnitten werden Vorarbeiten 

und Application Programming Interfaces (APIs) beschrieben. In Kapitel 4 wird ihre Eignung 

zur Implementierung des Navigationsassistenten untersucht. Entsprechend ihrer Eignung werden sie zur 

Lösung einiger Teilaufgaben eingesetzt.

2.3. VORARBEITEN UND VERWENDETE APIS 13 

2.3 Vorarbeiten und verwendete APIs 

Dieser Abschnitt beschreibt die Vorarbeiten, die zur Lösung einiger Teilprobleme verwendet wurden 

und verweist auf die zur Implementierung eingesetzten Bibliotheken und APIs. 

2.3.1 Farbklassifizierung 

Hub und Teufel stellen in [15] ein Modell zur Klassifikation von Farben entsprechend der menschlichen 

Farbwahrnehmung vor. Dieses Modell basiert auf psychophysischen Experimenten zum simultanen 

Farbkonstrast und zur Farbbenennung und trägt dem Einfluss benachbarter Farben auf die wahrgenommene 

Farbe Rechnung. Es lässt sich auf reale Szenen anwenden, um die wahrgenommene Farbe 

einer Bildregion unabhängig vom Hintergrund zu bestimmen und lässt sich somit zur Suche nach Objekten 

mit bekannter Farbe in der Bildanalyse einsetzen. 

2.3.2 Navigation Assistance System (NAS) 

Hub et al. stellen in [16] den Prototyp eines Navigationsassistenten vor (siehe Abbildung 2.9). Dieser 

unterstützt Blinde bei der Navigation in Gebäuden und ermöglicht die Identifikation von Objekten durch 

Vergleiche mit einem 3D-Gebäudemodell. Die Positionsbestimmung im Gebäude ist in diesem Navigationsassistenten 

über ein Wireless-LAN (WLAN) Positionierungssystem realisiert. Anhand der Position 

des Benutzers können aus dem verwendeten Gebäudemodell Navigationshinweise abgeleitet und über 

eine Sprachausgabe an den blinden Benutzer weitergegeben werden. Die hier vorgestellte Diplomarbeit 

setzt auf diesem Prototyp auf und versucht, durch Einsatz einer selbstsynchronisierenden Stereokamera 

die Positionsbestimmung weiter zu verbessern. 

Abbildung 2.9: Prototyp eines Navigationsassistenten mit integrierter Kamera und Inertialsensor. Das 

Handgerät kann an einem Blindenstock befestigt werden. Die Bestimmung der eigenen 

Position wird bisher über das im angeschlossenen Laptop integrierte WLAN-Modul 

gelöst.


Rogler stellt in ihrer Diplomarbeit [17] eine Designstudie vor, die den mobilen Navigationsassistenten 

komplett in einen Blindenstockgriff integriert (siehe Abbildung 2.10). Sie zeigt in ihrer Arbeit die Anforderungen 

auf, die zukünftige Navigationsassistenten erfüllen sollten, um Blinde möglichst unauffällig 

bei der Navigation zu unterstützen. 

Abbildung 2.10: Navigation Assistant System - Die Designstudie zeigt, wie in Zukunft die Sensoren in 

einen unauffälligen Blindenstockgriff integriert werden könnten. 

2.3.3 Stereo Vision based Object Distance Estimation in 3D Environment Models 

Li stellt in ihrer Studienarbeit [7] ein Verfahren zur Bestimmung von Objektdistanzen über die Stereodisparität 

in 3D-Modellen vor. Hierfür wird die Szene aus zwei kollinearen Kamerapositionen gerendert 

und auf diese Weise ein virtuelles Stereobildpaar erzeugt. Aus diesem kann über einen Stereoalgorithmus 

die Distanz zu Objekten in der Szene bestimmt werden. Der von Li verwendete Stereoalgorithmus 

basiert teilweise auf einer Implementierung der Carnegie Mellon Universität und benötigt auf dem verwendeten 

Testsystem bis zu zwei Sekunden für die Berechnung des Disparitätsbildes. 

2.3.4 Rapid Object Detection using Haar-like Features 

Lienhart et al. stellen in [18] ein Verfahren zur schnellen Erkennung von Objekten in Bildern vor (Rapid 

Object Detection). Sie erweitern hierfür die von Viola et al. in [19] zur Objekterkennung eingesetzte 

Menge der „Haar-Features“, um den Erkennungsprozess weiter zu beschleunigen. Obwohl Lienhart 

die Objektklassifizierung speziell zur Detektion von Gesichtern einsetzt, kann die auf dieser Arbeit 

aufbauende Implementierung in der OpenCV Bibliothek über die Vorlage von Beispielbildern, wie sie 

in [20] beschrieben wird, auch auf die Erkennung anderer Objekte trainiert werden. Auf diese Weise ist 

es möglich, viele Objekte im Bild über charakteristische Helligkeitsmerkmale zu erkennen.

2.3. VORARBEITEN UND VERWENDETE APIS 15 

2.3.5 Lucas-Kanade Optical Flow in Pyramids 

Es existieren diverse Verfahren zur Verfolgung des optischen Flusses (optical flow) in Bildern. Diese 

Arbeit verwendet das von Bouguet in [21] eingesetzte und in der OpenCV Bibliothek implementierte 

Verfahren zur Verfolgung von Featurepunkten über mehrere Bilder. Es wird eine iterative Anwendung 

des Lucas-Kanade Algorithmus [22] mit verschiedenen Suchfenstergrößen eingesetzt, um eine robuste 

Verfolgung der Features bei unterschiedlichen Flussgeschwindigkeiten zu realisieren. 

Die nächsten Abschnitte beschreiben die zur Implementierung herangezogenen APIs und begründen 

kurz ihre Eignung zur Entwicklung des Navigationsprototyps. 

2.3.6 Microsoft DirectX 9.0 

DirectX 9.0 ist eine von Microsoft zusammengestellte Sammlung von Application Programming Interfaces 

(APIs). Es wird zur Spieleprogrammierung und Entwicklung von Multimedia-Anwendungen 

eingesetzt. Neben der Unterstützung bei der Darstellung von 2D- und 3D-Grafik enthält DirectX die für 

diese Arbeit interessante DirectShow-API. Über diese können unter anderem Digitalkameras angesteuert 

und verwaltet werden. 

2.3.7 NI-IMAQ for IEEE 1394 Cameras 

National Instruments (NI) bietet als Zusatz zu Labview ein Bildverarbeitungsmodul zur Bildakquisition 

(image acquisition = imaq) und eine leicht bedienbare API für IEEE 1394 (Firewire) Digitalkameras 

an. Über die Integration der zugehörigen Treibersoftware in den Measurement & Automation Explorer 

bietet NI die Möglichkeit einer einfachen Treiberinstallation und Konfiguration der Kameras. Dank 

guter Beispielprogramme ist es über diese API sehr einfach, nicht nur Labview Programme, sondern 

auch C/C++ Applikationen zu schreiben, die eine Firewire Digitalkamera ansteuern. 

2.3.8 Intel Open Source Computer Vision Library (OpenCV) 

Die „Open Source Computer Vision Library“ (OpenCV) von Intel ist eine Sammlung von Algorithmen 

und Beispielprogrammen zu einer Vielzahl von Standardproblemen in der Bildverarbeitung. Diese 

Bibliothek eignet sich besonders zur Erstellung von Realtime-Anwendungen im Bereich der Bildanalyse 

und stellt die Implementierung einiger Lösungsansätze zur Objektidentifikation, Farbsegmentierung, 

Gesichtserkennung, Bewegungserfassung und Berechnung von Featurepunkten im Bild bereit. 

Die aktuelle Version 5b sowie die in dieser Arbeit eingesetzte Version 4b finden sich im SourceForge- 

Downloadbereich unter [23]. 

2.3.9 OpenSceneGraph 

OpenSceneGraph ist ein plattformunabhängiges OpenSource Grafik-Toolkit zur Entwicklung hochperformanter 

Grafikanwendungen wie Flugsimulatoren, Spiele, Virtual Reality Simulationen und kann für


wissenschaftliche Visualisierungen eingesetzt werden [24]. OpenSceneGraph basiert auf dem Szenengraphen-Konzept 

und bietet ein objektorientiertes Framework, welches den Programmierer von der Implementierung 

und Optimierung hardwarenaher Grafikbefehle befreit, indem es die Darstellung über 

die OpenGL-API vollständig übernimmt. Zudem bietet es viele zusätzliche Funktionen wie Kollisionserkennung 

und Schnittpunktberechnungen, welche dem Programmierer die Entwicklung von Grafikanwendungen 

erleichtern und so eine schnelle Implementierung unterstützen. 

Ein Szenengraph beschreibt den Aufbau von Szenen durch eine Baumstruktur. Diese wird von der Wurzel 

aus durch das Anhängen spezieller Knoten (Gruppierungs-, Transformations-, Farb-, Texturknoten) 

und Blättern (Geometrieknoten) hierarchisch aufgebaut und enthält alle Elemente der Szene. Er beschreibt 

auf diese Weise die räumliche Beziehung zwischen einzelnen Elementen und ihre Lage in der 

Szene. Aufgrund des hierarchischen Aufbaus ist eine schnelle Berechnung der im Viewing-Frustum liegenden 

Knoten und Blätter des Baumes und somit eine performante Darstellung der Szene möglich. 

Zudem können komplexe Objekte durch die Transformation ihres Vaterknotens auf einfache Weise verändert 

werden. 

2.3.10 Microsoft Foundation Classes (MFC) 

Die Microsoft Foundation Classes (MFC) sind eine Sammlung objektorientierter Klassenbibliotheken, 

die von Microsoft für das Betriebssystem Windows zur Programmierung windowsbasierter Anwendungen 

mit C++ entwickelt wurden. 

Die MFC dienen als Schnittstelle zu den nicht objektorientierten API-Funktionen des Betriebssystems 

und sollen den Umgang mit den vom Betriebssystem zur Verfügung gestellten Ressourcen erheblich 

vereinfachen. Ein Großteil der für Windows geschriebenen Programme nutzen die MFC zum Beispiel 

zur Darstellung von graphischen Oberflächen, wie sie auch in dieser Arbeit zur Implementierung der 

Kamerakalibrierungstools eingesetzt werden. Diese Oberfächen können in Microsofts Visual Studio 

.NET 2003 bequem über den Ressourcen-Editor gestaltet werden.

Kapitel 3 

Lösungsentwurf 

Dieses Kapitel beschreibt die Probleme, die gelöst werden müssen, um einen bildbasierten Navigationsassistenten 

auf Basis einer Stereokamera zu entwickeln. Es werden die Anforderungen an das System 

beschrieben und ein Lösungsansatz erarbeitet. Dieser ermöglicht die bildbasierte Positionsbestimmung 

und die Erkennung von Objekten auf aktueller, portabler Hardware. Auf die Implementierung der zur 

Lösung eingesetzten Klassen und Programme wird in Kapitel 4 näher eingegangen. 

3.1 Problembeschreibung 

Durch die Auswertung der über eine Sensoreinheit aufgenommenen Stereobild- und Richtungsdaten 

sollen blinde Benutzer genau an der Stelle unterstützt werden, an der sie durch ihre visuelle Beeinträchtigung 

bei der Navigation durch Gebäude gegenüber sehenden Menschen benachteiligt sind. 

Die Stereodisparität der Augen unterstützt sehende Menschen bei der Gewinnung von Informationen 

über Objektpositionen, Formen, Größenverhältnisse und Entfernungen. Zusätzlich kann über die farbempfindlichen 

Zapfen der Retina die Farbe der Objekte bestimmt werden. Diese Informationsgewinnung 

soll von einem tragbaren Navigationsassistenten übernommen werden, um die eigene Position im Gebäude 

und die Beschaffenheit der Umgebung an den blinden Benutzer weitergeben zu können, um ihm 

auf diese Weise die Navigation durch ein unbekanntes Gebäude zu erleichtern. Die Positionsbestimmung 

muss hierbei ohne eine spezielle Markierung der Umgebung auskommen und robust gegenüber 

starken Änderungen in der Beschaffenheit der Inneneinrichtung sein. Auf die Verwendung von Karten 

mit für spezielle Positionen aufgenommenen Messergebnissen, die dann mit den Sensordaten verglichen 

werden könnten, soll ebenfalls verzichtet werden. Die gewonnenen Positionsinformationen und Navigationshinweise 

sollen so aufbereitet sein, dass sie in kommenden Projekten dem Blinden auf möglichst 

einfache Weise über eine passende Schnittstelle (wie ein taktiles Display oder eine Audioschnittstelle) 

weitergegeben werden können. 

17

18 KAPITEL 3. LÖSUNGSENTWURF 

3.2 Lösungsansatz 

Dieser Ansatz versucht über die Möglichkeiten der bisher vorgestellten Arbeiten (siehe Abschnitt 2.3) 

hinauszugehen, indem er einige Ideen der Vorarbeiten kombiniert. Eine starke Verknüpfung zwischen 

Sensordaten und Modell stellt hierbei die Grundlage für die später an den Benutzer weitergegebenen 

Navigationsinformationen dar. Die zur Navigation des blinden Benutzers notwendige Bestimmung der 

eigenen Position im Raum sowie die Erkennung von Hindernissen löst dieser Ansatz durch eine kontinuierliche 

Anpassung einer virtuellen Umgebung an real gemessene Daten. Zur Messung der notwendigen 

Daten wird ein Sensormodul eingesetzt, das im folgenden Abschnitt beschrieben wird. 

3.2.1 Aufbau des Sensormoduls 

Dieser Abschnitt stellt den zur Lösung der Aufgabe eingesetzten Aufbau des Sensormoduls und die 

verwendete Hardware vor. Gründe für die Auswahl dieser Hardwarekomponenten werden in Abschnitt 

4.1 ausführlicher beschrieben. 

Die Entscheidung, das Sensormodul nicht wie in der in Abschnitt 2.3.2 vorgestellten Designstudie in den 

Blindenstock zu integrieren und darum den zugehörigen ersten Prototyp nicht zu verwenden, begründet 

sich in der Tatsache, dass sich die zur Selbstlokalisation in Räumen notwendigen Abstandsinformationen 

auf gebäudespezifische, invariante Daten wie Abstände zu Wänden und Türen beschränken. Bei allen 

anderen Einrichtungsgegenständen muss davon ausgegangen werden, dass sich deren Position ändern 

kann oder sie nicht ins Modell integriert sind. Um sicherzustellen, dass diese Informationen möglichst 

oft auf den Stereobildern vorhanden sind, wurde die Stereokamera, wie in Abbildung 3.1 gezeigt, auf 

einem Fahrradhelm montiert und bildet so, bei natürlicher Kopfhaltung, die beste Ausgangssituation für 

den Vergleich mit den Modelldaten. 

Abbildung 3.1: Aufbau des Sensormoduls. Die zur Abstandsmessung eingesetzte Stereokamera ist auf 

einen Fahrradhelm montiert. Zur Bestimmung der Blickrichtung ist direkt hinter der 

Kamera ein Inertialsensor angebracht. Dieser Aufbau ist für den hier verfolgten Lösungsansatz 

sehr gut geeignet und zeichnet sich durch einen vergleichsweise hohen 

Tragekomfort aus.

3.2. LÖSUNGSANSATZ 19 

Direkt hinter der Stereokamera ist ein Inertialsensor montiert. Dieser Aufbau ermöglicht es auf die 

bildbasierte Berechnung der Blickrichtung zu verzichten. Somit verbleibt ausreichend CPU-Leistung, 

um die zur Positionsbestimmung notwendigen Stereodisparitätsbilder „echtzeitnahe“ zu berechnen und 

diese mit dem 3D-Modell zu vergleichen. In den folgenden Abschnitten wird eine Methode vorgestellt, 

mit deren Hilfe die Position des Sensormoduls aus den Modell- und Sensordaten berechnet werden kann. 

3.2.2 Positionsbestimmung der Kamera 

Der hier verfolgte Lösungsansatz ermöglicht die Positionsbestimmung und Unterstützung bei der Navigation 

durch das Angleichen einer simulierten Umgebung an real gemessenen Daten. Zu diesem Zweck 

wird das im OpenSceneGraph-Format [24] vorliegende Gebäudemodell um eine virtuelle Kamera erweitert 

und diese solange im Modell verschoben, bis die simulierten Messungen mit den realen Daten 

übereinstimmen. Zu diesem Zweck durchläuft der Navigationsassistent die in den folgenden Absätzen 

beschriebenen Schritte. 

Ausrichtung der virtuellen Kamera 

Unter der Voraussetzung, dass der Startpunkt in Form von 3D-Ortskoordinaten oder eines Raumnamens 

gegeben ist, wird die virtuelle Kamera, wie in Abbildung 3.2 (a) gezeigt, im 3D-Modell am vorgegebenen 

Startpunkt positioniert. Die Angabe des Startpunktes muss bisher durch den Benutzer erfolgen, 

soll aber zukünftig durch ein gerade in der Erprobung befindliches WLAN Positionierungssystem (siehe 

Abschnitt ??) automatisiert werden. Der Abstand der Kamera zum virtuellen Boden wird entsprechend 

der vorgegebenen Größe des Benutzers angepasst. 

Über den hinter der Stereokamera angebrachten Inertialsensor kann die Orientierung der Sensoreinheit 

abgefragt und so die Blickrichtung der virtuellen Kamera an die reale Blickrichtung angeglichen werden 

(Abbildung 3.2 b). Der Vorteil dieser Art der Orientierungsberechnung gegenüber einer bildbasierten 

Blickrichtungsanalyse ist die Robustheit gegenüber Unterschieden zwischen 3D-Modell und Realität, 

die sonst nur durch eine ständige Aktualisierung des Gebäudemodells möglich wäre. 

a) Initiale Kameraposition b) Ausgerichtete Kamera 

Abbildung 3.2: Positionierung und Ausrichtung der virtuellen Kamera. Bild (a) zeigt die initiale Kameraposition, 

in (b) ist die anhand des Richtungssensors ausgerichtete Kamera dargestellt.


Generierung von Positionsvarianten 

Unter der Annahme, dass sich die Position der Kamera zwischen zwei aufgenommenen Stereobildern 

nur gering ändert, werden vier Positionsvarianten zusätzlich zur aktuellen Position�s im Modell berechnet 

(siehe Abbildung 3.3). Für die Positionen der Varianten eins bis vier gilt unter Berücksichtigung der 

aktuellen Blickrichtungsrotation R der Kamera und der Schrittweite w: 

⎛ 

⎜ 

�si = �s ∗ ⎜ 

⎝ 

1 0 0 0 

0 1 0 0 

0 0 1 0 

vx vy vz 1 

⎞ 

⎟ 

⎠ 

mit �v = �vi und i = 1..4, 

�v1,2 = � 0 ±w 0 � T ∗ R, (3.1) 

�v3,4 = � ±w 0 0 � T ∗ R 

Die 3D-Szene wird an diesen Positionen aus Sicht der virtuellen Kamera gerendert. Hierbei wird das 

Tiefenbild der Stereokamera an geeigneten Messpunkten (Kreise in Bild 3.3 a) mit den Abstandsinformationen 

im Modell (Bild 3.3 b) verglichen und die Variante mit der geringsten Abweichung als neue 

Position der virtuellen Kamera ausgewählt. Wie die Tests des Navigationsassistenten in Kapitel 5 zeigen, 

ist schon über die ersten zwei Varianten eine Positionsbestimmung möglich. In diesem Falle muss 

der Benutzer gelegentlich den Kopf drehen, um Fehler in der Positionsbestimmung zu minimieren. 

a) Reale Szene 

b) Virtuelle Szene an Position 0 c) Mögliche Positionsvarianten 1-4 

Abbildung 3.3: Berechnung der besten Positionsvariante durch Vergleiche zwischen real und virtuell 

gemessenen Abständen. Abbildung (a) zeigt die reale Szene, welche mit der gerenderten 

Szene (b) verglichen werden soll. Bild (c) zeigt die möglichen Positionsvarianten 

der virtuellen Kamera.


Abbildung 3.4: Abstandsmessung im Modell. Über den Vektor �s und den Abstand d des Fokuspunkts 

von der Bildebene, der von Φ bestimmt wird, kann der Ortsvektor zum Fokuspunkt �f 

berechnet werden. Die xy-Koordinaten des Durchstoßpunktes legen die Richtung des 

Strahls�l fest. Die Länge des Vektors von �f zum ersten Schnittpunkt des Strahls mit der 

Szene Sp ist der gesuchte Abstand. 

Vergleich der realen Distanzen mit dem Modell 

Es gibt verschiedene Möglichkeiten aus der gerenderten 3D-Ansicht die Abstandsinformationen zu gewinnen. 

Die Distanzmessung wird hier nicht über die Verwendung des Tiefenpuffers oder den simulierten 

Tiefenbildern einer virtuellen Stereokamera gelöst. Stattdessen wird anhand der xy-Position der 

realen Messpunkte im Kamerabild ein Strahl durch die virtuelle Szene berechnet. Durch diese Maßnahme 

kann später auf ein Grafikausgabemedium komplett verzichtet werden. Die Distanz vom CCD-Chip 

der virtuellen Kamera zum ersten Schnittpunkt mit der Szene entspricht dann dem simulierten Abstand 

im Modell. 

Zunächst wird aus der bekannten Position der Bildebene der virtuellen Kamera die Position des virtuellen 

Fokuspunktes, anhand des bekannten Öffnungswinkels Φ berechnet. Für die Distanz zwischen 

Bildebene und Fokuspunkt gilt Gleichung 3.2.


d = arctan Φ 

; (3.2) 

2 

Es ergibt sich, über den Ortsvektor�s zum Zentrum der Bildebene, der Vektor �f zum Fokuspunkt. 

�f =�s −�v ∗ d, �v : Blickrichtung (3.3) 

Die Zusammenhänge zwischen den Abständen und Vektoren, welche zur Berechnung eines Strahls 

durch die Szene verwendet werden, sind in Abbildung 3.4 dargestellt. Für den Richtungsvektor �l, der 

die Strahlrichtung vom Fokuspunkt zum Durchstoßpunkt in der Bildebene bei den Koordinaten (x,y) 

angibt, lässt sich folgender Zusammenhang herleiten: 

�l =�v ∗ d +�r ∗ x +�u ∗ y, �r,�u : Right/U p −Vektor der Kamera (3.4) 

Die Verlängerung der so gewonnenen Richtung �l ergibt einen Strahl durch die Szene, dessen erster 

Schnittpunkt �sp mit der gerenderten Szene den zu messenden Abstand bestimmt. 

zvirtuell = |�sp − �f | (3.5) 

Anhand der in Absatz 2.1.4 vorgestellten Gleichung 2.9 lässt sich die Distanz zreal eines Punktes im 

Kamerabild aus dem Disparitätswert des Tiefenbildes berechnen. Diese kann mit der Distanz im Modell 

zvirtuell verglichen werden. Um die Positionsvarianten effizient miteinander vergleichen zu können, wird 

die Summe der Abstandsdifferenzen zwischen Messpunkten in Modell und Realität für jede Variante i 

in einem Differenzvektor gespeichert: 

�di = ∑ j 

|zreal − zvirtuell|, j : 1..Anzahl der Messpunkte (3.6) 

Für Fälle, in denen die virtuelle Kamera direkt vor einer Tür positioniert ist, werden alle virtuellen 

Distanzen zusätzlich für eine offene Tür berechnet und der kleinere Differenzvektor ausgewählt. 

Aktualisierung der Position 

Durch den Vergleich der Differenzvektoren �di aller Varianten i ergibt sich die beste Positionsvariante 

als die Variante mit den kleinsten Differenzen. Für die in Abbildung 3.3 (c) dargestellte Situation 

stellt Position 1 die beste Lösung dar. Anhand dieser Information wird die Kameraposition im Modell 

aktualisiert. 

Über eine Translation wird die virtuelle Kamera in Richtung der besten Positionsvariante verschoben. 

Hierbei muss nicht zwingend derselbe Abstand verwendet werden, wie er zur Berechnung der Varianten 

angenommen wurde. Dieser kann, abhängig von der Größe des Fehlers, dynamisch bestimmt werden, 

um die Positionsfindung bei großen Differenzen zu beschleunigen und bei kleinen zu verfeinern. Auf 

diese Weise führt das Verfahren auch bei größeren Positionsabweichungen nach wenigen Schritten zu 

guten Ergebnissen.


Zur Aktualisierung der Kameraposition muss zuerst der Verschiebungsvektor �vs in Richtung der besten 

Positionsvariante berechnet werden. Dieser ergibt sich wie in Gleichung 3.1 aus der gewählten 

Verschiebungsdistanz und der aktuellen Blickrichtung. Für die neue Position �s der Kamera gilt dann 

entsprechend: 

⎛ 

⎜ 

�s =�s ∗ ⎜ 

⎝ 

1 0 0 0 

0 1 0 0 

0 0 1 0 

vx vy vz 1 

⎞ 

⎟ 

⎛ 

⎠ , mit �vs = ⎝ 

vx 

vy 

vz 

⎞ 

⎠ (3.7) 

Neben der Berechnung der besten Positionsvariante kann durch den Vergleich der X-Koordinaten korrespondierender 

Featurepunkte aufeinander folgender Frames eine Rotation der Sensoreinheit oder eine 

Translation in X-Richtung erkannt werden. Zur Bestimmung zusammengehöriger Featurepunkte kann 

das in Abschnitt 2.3.5 beschriebene Tracking-Verfahren eingesetzt werden. Für die Bewegungserkennung 

müssen die Bilddaten mit den Richtungsinformationen des Inertialsensors verglichen werden. Folgende 

simple Logik liefert dann Aufschluss über die aktuelle Bewegung: 

Alle Featurepunkte streben in eine Richtung ∧ 

Kompass meldet Bewegung → Rotation 

Alle Featurepunkte streben in eine Richtung ∧ 

Kompass meldet keine Bewegung → Translation in XRichtung 

Eine zusätzliche Betrachtung der Tiefeninformation aller Messpunkte ermöglicht es Z-Translationen zu 

erkennen, wenn die Tiefenänderung ebenfalls einen Schwellwert überschreitet. 

Durch eine Kollisionserkennung auf dem Szenengraphen wird verhindert, dass die Kamera bei Messfehlern 

durch Objekte hindurch geschoben wird. Eine solche Verschiebung wird nur zugelassen, wenn 

es sich bei dem betreffenden Objekt um eine Türe im Modell handelt. Ein Raumwechsel ist auf diese 

Weise für die virtuelle Kamera nur an Türen möglich. 

Erste Tests mit festen Messpunkten zeigten, dass die Qualität der Positionsbestimmung in verschiedenen 

Räumen wesentlich von der Wahl der Messpunkte abhängt und diese somit entscheidend für eine gute 

Navigationsunterstützung des blinden Benutzers ist. Der nächste Absatz vergleicht verschiedene Ansätze 

zur Suche nach geeigneten Messpunkten und begründet die Auswahl der im Prototyp eingesetzten 

Verfahren. 

3.2.3 Auswahl geeigneter Messpunkte 

Durch Fenster, Messfehler und Schwächen im Stereoalgorithmus können alle Entfernungen zwischen 

Unendlich und Null im realen Tiefenbild vorhanden sein. Der triviale Ansatz zu versuchen, die Punkte 

mit größter Tiefe als Messpunkte zu wählen, führt nicht zum gewünschten Ergebnis. Um dennoch ohne 

großen Rechenaufwand Punkte auf den Wänden zu finden wurden die folgenden Kriterien auf ihre 

Eignung als Suchkriterium für Wandpunkte verglichen:


• Farbe und Form 

• Helligkeitsmuster 

• Charakteristische Linien 

• Featurepunkte mit Wandabstand 

Farbe und Form 

Wie Abschnitt 2.1.7 näher beschreibt, kann über einen Regiongrowing-Algorithmus eine gleichmäßig 

gefärbte Fläche gefunden werden. Über das in Absatz 2.3.1 vorgestellte Verfahren kann dann die wahrgenommene 

Farbe der Region bestimmt werden. Die Versuche, über diesen Ansatz graue Wände zu 

finden, machen deutlich, dass die Festlegung der Farbe zuviele Objekte wie Boden, Decke und Computermonitore 

ebenfalls mit einschließt. Sie ist deshalb als Auswahlkriterium zu schwach. Die zusätzliche 

Vorgabe einer bestimmten Form würde die Suche zwar weiter einschränken, da sich aber keine allgemeine 

Form einer Wand angeben lässt, ist dieser Ansatz in großen Gebäuden nicht geeignet. 

Helligkeitsmuster 

In Abschnitt 2.3.4 wird ein Verfahren vorgestellt, das es ermöglicht, Helligkeitsmuster in einem Bild 

wiederzufinden. Diese Muster können dem „Rapid Object Detection“ genannten Verfahren über mehrere 

hundert Beispielbilder und Markierung der gewünschten Objekte antrainiert werden und dann für 

die Suche nach Objekten wie Türgriffen, Fenstergriffen oder Fensterecken, welche üblicherweise an 

Wänden zu finden sind, verwendet werden. Die nacheinander aufgenommenen Bilder in Abbildung 3.5 

zeigen die Ergebnisse des nach Abschnitt 2.3.4 implementierten Verfahrens. Aufgrund zu großer Helligkeitsunterschiede 

und der geringen Größe der Fenstergriffe wurden hier nur die Fensterecken erkannt. 

Diese sind aber bei natürlicher Kopfhaltung in kleineren Räumen üblicherweise nicht im Bild zu sehen. 

Deshalb eignen sich Fensterecken nicht allein als Suchkriterium für Punkte auf Wänden. Es wird deutlich, 

dass aufgrund der fehlenden Stabilität der Objekterkennung dieses Verfahren ebenfalls nicht zur 

Bestimmung der Messpunkte geeignet ist. 

Abbildung 3.5: Messpunktauswahl anhand von erkannten Objekten. Die Abbildungen zeigen die durch 

rote Quadrate markierten gefundenen Objekte einer Bildsequenz. Der Mittelpunkt der 

Quadrate könnte als Messpunkt verwendet werden.


Charakteristische Linien 

Wie in der Aufgabenstellung beschrieben, sollte ein Algorithmus getestet werden, der es ermöglicht, 

allein über die Zuordnung von erkannten Linien im Kamerabild zu Kanten im Modell, die genaue Position 

im Raum zu bestimmen. Die dafür nötigen Linien müssen zunächst in einem Kantenbild, wie es 

in Abbildung 3.6 (b) dargestellt ist, erkannt und den Modellkanten (in Bild 3.6 blau, grün und gelb dargestellt) 

zugeordnet werden. Der Algorithmus berechnet dann über ein Näherungsverfahren die Transformationsmatrix, 

die notwendig ist, um die Kanten des Modells auf die gegebenen Linien abzubilden. 

Hieraus ließe sich die Position der Kamera zurückrechnen. Dieser Ansatz setzt allerdings voraus, dass 

die erkannten Linien des Kamerabildes vorher den Kanten im Modell zugeordnet werden. Harald Sanftmann 

löst dieses Problem der Zuordnung in seiner Diplomarbeit [25], indem er die erkannten Kanten mit 

Orientierungsvarianten des Modells vergleicht und die ähnlichste Orientierung auswählt. Dieser Ansatz 

setzt aber ein speziell vorbereitetes 3D Modell voraus, in dem keine „falschen“ Kanten (in Abbildung 

3.6 (d) türkis markiert) vorhanden sind. Da ein solches Modell für diese Arbeit nicht zur Verfügung 

stand und der Vergleich mit Modellvarianten bei komplexen Objekten zuviele Lösungen ergeben würde, 

kommt dieses Verfahren aufgrund der begrenzten Rechenleistung hier ebenfalls nicht zum Einsatz. 

a) Kamerabild b) Extrahierte Kanten des Kamerabildes 

c) gerendertes Modell d) Wireframe Darstellung des gerenderten Modells 

Abbildung 3.6: Zuordnung von erkannten Linien zu Modellkanten. Bild (a) zeigt einen typischen Gang 

im Gebäude. Die aus dem Kantenbild extrahierten Geraden sind in (b) dargestellt. Bild 

(c) zeigt die gerenderte Szene und (d) die zugehörigen Kanten im Wireframe-Modell.


Trotz der rechenaufwändigen Extraktion der Bildkanten, können diese besonders gut zur Ermittlung 

eines „Fluchtpunkts“ am Gangende, über den Schnittpunkt der blauen und grünen Linien aus Abbildung 

3.7 (e) berechnet werden. Dies ermöglicht die Positionierung der Abstandsmesspunkte auf die in Gängen 

entscheidenden Messpunkte am Ende des Ganges (gelber Kreis), da sich alle anderen Abstände, wie in 

den roten Linien in Abbildung 3.7 (f) gezeigt, für verschiedene Kamerapositionen kaum unterscheiden. 

e) Fluchtpunktabschätzung f) Signifikante Abstände im Gang 

Abbildung 3.7: Schnittpunkt von Diagonalen in langen Gängen. Bild (e) zeigt, dass der Schnittpunkt 

von Diagonalen im Bild in Richtung des Gangendes liegt. Dieser markiert den einzigen 

signifikanten Abstand zum Sensormodul. 

Ein Vergleich der Position des Fluchtpunktes in realem und gerendertem Kamerabild kann zusätzlich 

zur Detektion von Abweichungen zwischen realer und virtueller Blickrichtung eingesetzt werden. Aus 

der Distanz z zum Fluchtpunkt und dem Unterschied der X-Koordinaten der Fluchtpunkte dx kann der 

Offset der virtuellen Kamera über Gleichung 3.8 für kleinere Abweichungen berechnet und korrigiert 

werden. Bei zu großen Abweichungen muss der Offset bei diesem Verfahren vom Benutzer manuell 

nachgestellt werden. 

Featurepunkte mit Wandabstand 

θO f f set = arctan( dx 

) (3.8) 

z 

Aufgrund der hohen Rechenzeit der vorangegangenen Verfahren wurde eine Methode entwickelt, bei 

der die Tiefeninformationen an geeigneten Featurepunkten (siehe Abschnitt 2.1.1) mit einem „Wandabstandsschätzwert“ 

verglichen werden. Dieser Schätzwert wird nach dem in Abschnitt 4.3.1 implementierten 

Verfahren ermittelt und ermöglicht die Filterung der gefundenen Featurepunkte. 

Abbildung 3.8 (a) zeigt das Ergebnis einer solchen Filterung und stellt Featurepunkte mit zu kleinem Abstand 

weiß, Punkte mit zu großem Abstand rot und die Features mit Wandabstand gelb dar. Dieser Ansatz 

zeichnet sich durch seine hohe Geschwindigkeit und eine große Robustheit gegenüber Störungen aus. 

Er liefert über mehrere Bilder stabile Messpunkte (Abbildung 3.8 b), die mit hoher Wahrscheinlichkeit 

auf der Wand zu liegen kommen. Da sich das Verfahren zur Wandabstandsschätzung nur für annähernd


a) b) 

Abbildung 3.8: Die Featurepunkte in (a) und (b) sind entsprechend ihrer Einstufung anhand eines 

Wandabstandsschätzwertes in drei Farben kodiert. Weiße Punkte sind zu nahe, gelbe 

haben ungefähr Wandabstand und rote Punkte sind zu weit entfernt um auf der Wand 

zu liegen. 

quadratische Räume eignet, muss bei langen Gängen auf das zuvor vorgestellte Fluchtpunkt-Verfahren 

zurückgegriffen werden. 

Abbildung 3.9 fasst die Geschwindigkeitsunterschiede der vorgestellten Verfahren in einem Diagramm 

zusammen. Das schnellste Verfahren wird als 100 Prozent Marke angenommen. Es zeigt sich, dass 

das zuletzt vorgestellte Verfahren bis zu drei mal schneller ist als die vorangegangenen Ansätze. Dies 

begründet sich hauptsächlich durch die schnelle Berechnung des Abstandsschätzwertes und der Featurepunkte, 

da für diese Berechnungen kein Kantenbild berechnet werden muss. 

Wiederverwendung der Messpunkte über mehrere Bilder 

Durch den Einsatz eines Verfahrens zur Verfolgung der gewählten Messpunkte über mehrere Bilder, 

wie es Lucas und Kanade 1981 vorgestellt haben (siehe Abschnitt 2.3.5), muss die „teure“ Berechnung 

der Messpunkte nur durchgeführt werden, wenn diese nicht mehr im Bild gefunden werden. Um die 

Messpunkte möglichst gleichmäßig über das aufgenommene Bild zu verteilen, wird es wie in Abbildung 

3.3 (a) gezeigt, in neun Quadranten eingeteilt. 

Zur Selbstlokalisation werden nur die oberen sechs Quadranten eingesetzt. Dies begründet sich mit 

dem Aufbau des Sensormoduls, da bei natürlicher Kopfhaltung üblicherweise im unteren Drittel des 

Bildes nur Einrichtungsgegenstände oder der Boden zu sehen sind. Verlässt einer der Messpunkte den 

ihm zugeordneten Quadranten, wird nur für diesen Teil des Bildes ein neuer Messpunkt auf der Wand 

berechnet. Für diese Neuberechnung werden, abhängig von der Form des aktuellen Aufenthaltsraums, 

entweder Featurepunkte auf der Wand gesucht oder Messpunkte am Gangende festgelegt. Dies ermöglicht 

eine gute Positionsbestimmung in vielen unterschiedlichen Räumen bei vergleichsweise hohen 

Frameraten.


Abbildung 3.9: Geschwindigkeitsvergleich zw. Messpunkt-Such-Verfahren. Das schnellste Verfahren 

wurde als Referenz mit 100 Prozent angenommen. Es wird deutlich, dass alle anderen 

Verfahren wesentlich langsamer arbeiten und sich das neu entwickelte Verfahren somit 

am besten zur Positionsbestimmung in Räumen eignet. 

3.2.4 Detektion von verschiebbaren, modellierten Objekten 

Der hier vorgestellte Ansatz zur Erkennung von Objekten nutzt die Kombination der Farb- und Tiefeninformationen 

des Kamerabildes, um Objekte im Bild anhand einer Objektbeschreibung wieder zu 

erkennen. Hierzu werden einige der Vorarbeiten dieses Gebietes kombiniert und um die Informationen 

aus dem Disparitätsbild erweitert. Die Erkennung der Orientierung von Hindernissen wird von Sanftmann 

für rechteckig modellierte Objekte beschrieben [25]. 

In dieser Arbeit werden die folgenden drei Schritte sukzessive angewandt, um zu entscheiden, ob ein 

Bereich im Bild das gesuchte Objekt enthält. 

1. Suche nach gleichfarbigen Regionen 

2. Vergleich der Farbe 

3. Vergleich der Form


1. Suche nach gleichfarbigen Regionen 

Die Suche nach homogenen Regionen im Bild nutzt das in der OpenCV Bibliothek implementierte 

Regiongrowing-Verfahren (siehe Abschnitt 2.1.7) um ähnlichfarbige Regionen im Bild zu finden. Hierfür 

wird das Verfahren an verschiedenen, über das Bild verteilten Startpunkten aufgerufen. Abbildung 

3.11 zeigt die so segmentierten Farbregionen im Kamerabild. 

a) Kamerabild b) Markierung der homogenen Farbregionen 

Abbildung 3.10: Farbsegmentierung über Regiongrowing. Homogene Flächen im Bild (a) werden zur 

Segmentierung mit Farbe gefüllt. Bild (b) zeigt die so gefundenen Regionen. 

Wird der Szene ein weiterer Stuhl hinzugefügt, färbt der Standard-Regiongrowing-Algorithmus diesen 

mit derselben Farbe ein, wenn dieser zu nahe an einem gleichfarbigen Stuhl positioniert ist (siehe Abbildung 

3.11 (a) linker und mittlerer Stuhl). Um diesen Effekt zu verringern wurde das Regiongrowing- 

Verfahren so erweitert, dass es zusätzlich die Unterschiede im Tiefenbild berücksichtigt und bei zu 

starker Änderung der Tiefe die Expansion der Region beendet. Das Ergebnis dieser Methode ist in Abbildung 

3.11 (b) dargestellt. In diesem Falle wird der mittlere Stuhl nicht in die Region des linken Stuhls 

mit einbezogen, sondern als eigenständiger Bereich betrachtet und mit einer anderen Farbe gefüllt. 

a) Ohne Tiefenbild, zwei segmentierte Stühle b) Mit Tiefenbild, drei segmentierte Stühle 

Abbildung 3.11: Regiongrowing mit und ohne Berücksichtung der Tiefenunterschiede. Wird die Tiefe 

mit einbezogen, können die Objekte besser unterschieden werden.


Für die Entscheidung, ob der gefüllte Bereich das gesuchte, modellierte Objekt enthält, wird die Farbe 

und Form der gefundenen Region mit einer Modellbeschreibung verglichen. Die Modellbeschreibung 

enthält für diesen Zweck drei Informationen über den zu suchenden Gegenstand: 

1. Name der Farbe 

2. Histogrammwerte der Farbe 

3. Form-Muster 

Diese sind in die Modellbeschreibungsdateien _description_i.txt und ein Form-Muster Bild 

kodiert, wobei die Art des Objektes und i die Nummer der Beschreibung bezeichnet. Für 

Stühle kann eine solche Modellbeschreibung folgendermaßen aussehen: 

rot 

chair_tpl_0.bmp 

0 255.0 

1 0.0 

... 

14 0.0 

15 78.0 

a) Beschreibungsdatei b) Histogrammbild aus 16 c) Form-Muster 

vorgegebenen Farbtönen (chair_tpl_0.bmp) 

Abbildung 3.12: Modellbeschreibung für einen roten Stuhl bestehend aus Modellbeschreibung mit Histogrammwerten 

wie sie in (b) dargestellt sind und einem Form-Muster für die Stuhllehne 

(c). 

Anhang A.3.1 beschreibt, wie eine solche Beschreibung durch simples Betrachten der Objekte erzeugt 

und abgespeichert werden kann. Es empfiehlt sich, für ein Objekt mehrere Beschreibungsdateien aus 

verschiedenen Blickwinkeln und mit unterschiedlicher Beleuchtung anzufertigen, um das gesuchte Objekt 

in möglichst vielen Situationen wiederzufinden. 

Vergleich der Farbe 

Anhand des im Abschnitt 2.3.1 vorgestellten Farbklassifikationsverfahrens von Hub und Teufel kann 

die wahrgenommene Farbe einer gefundenen Region bestimmt und mit dem Farbnamen in der Modellbeschreibung 

verglichen werden. Dies ermöglicht es zu entscheiden, ob der gefüllte Bildbereich das 

gesuchte, modellierte Objekt enthalten könnte. Ist dieser „Farbnamentest“ positiv, werden zusätzlich die 

in 16 Farbtöne (siehe Abbildung 3.13) eingeteilten Histogrammwerte der Bildregion im HSV Raum berechnet. 

Diese werden dann mit den vorgegebenen Farbwerten der Modellbeschreibung verglichen. Die 

hier verwendete Farbeinteilung in 16 Stufen wird auch im CamShift („Continuously Adaptive Mean- 

SHIFT“) Algorithmus von OpenCV [26] eingesetzt um Objekte mit speziellen Farben zu verfolgen.


Abbildung 3.13: Farbtöne des Histogramms. Für den Vergleich zwischen Modell und Realität werden 

im HSV-Raum die Werte von 16 Farbtönen in der segmentierten Region berechnet. 

Vergleich der Form 

Ergibt die Farbklassifizierung den in der Beschreibung angegebenen Farbnamen und ähnliche Histogrammwerte, 

wird zusätzlich die Form der Region verglichen um sicherzustellen, dass die getestete 

Region wirklich das gesuchte Objekt und nicht nur einen ähnlichfarbigen Gegenstand enthält. Für diesen 

Vergleich stellt die OpenCV Bibliothek ein Verfahren zum Vergleich der HuMomente (HuMoments) 

[27] in Bildern bereit. Diese setzen sich aus sieben speziellen Richtungsableitungen des Bildes zusammen 

von denen bewiesen ist, dass sie unabhängig von Rotation und Skalierung des Bildes sind. 

Besteht eine Region alle drei Tests, wird die Mitte ihrer Oberkante zur Berechnung der Distanz zob j zum 

Betrachter aus dem Disparitätsbild eingesetzt. 

Positionsbestimmung der Objekte 

Anhand des Ortsvektors zur eigenen Position �f im Raum, wie sie nach Abschnitt 4.3 berechnet wurde, 

und der gemessenen Distanz zob j zu einem gefundenen, modellierten Objekt kann die Position �pob j 

des Objektes über Gleichung 3.10 berechnet werden. Diese leitet sich direkt von der in Abschnitt 3.2.2 

gezeigten Gleichung 3.4 für einen Strahl durch die Bildebene an der Position (x,y) ab. Für die Richtung 

des Strahles gilt wieder: 

�l =�v ∗ d +�r ∗ x +�u ∗ y, �r,�u : Right − /U p −Vektor (3.9) 

wobei d die nach Gleichung 3.2 bestimmte Distanz vom Fokuspunkt zur Bildebene und �v die aktuelle 

Blickrichtung der virtuellen Kamera ist. Für die Position des gefundenen, modellierten Objektes gilt 

dann: 

3.2.5 Aktualisierung des Modells 

�pob j = �f + �l 

|�l| ∗ zob j 

(3.10) 

Dieser Abschnitt beschreibt die Nutzung der ermittelten Positionsinformationen zur Unterstützung blinder 

Benutzer bei der Navigation durch ein unbekanntes Gebäude. 

Zunächst werden die Positionen der verschiebbaren, modellierten Objekte, welche nach dem im letzten 

Abschnitt beschriebenen Verfahren gefunden wurden, genutzt, um verschobene Hindernisse im Modell 

zu aktualisieren. Dies wird durch die Berechnung von Änderungstransformationen ermöglicht, welche 

die gefundenen Objekte in der virtuellen Szene an ihre neue Position verschieben. Hierfür ist die Suche


des gefundenen Objekts im Szenengraphen-Ast des aktuellen Aufenthaltsraumes erforderlich. Enthält 

dieser mehrere gleiche, verschiebbare Objekte, werden diese ohne Berücksichtigung ihrer vorherigen 

Position neu positioniert, indem ihnen im Szenengraphen ein neuer Transformationsknoten angehängt 

wird. Dieser transformiert die Objekte von ihrer ursprünglichen Position an die nach Gleichung 3.10 

bestimmte neue Position. Auf diese Art entsteht ein neues 3D-Modell mit aktualisierten Positionen aller 

modellierter Hindernisse. Das so gewonnene 3D-Modell kann nun verwendet werden, um den Benutzer 

bei der Navigation durch ein unbekanntes Gebäude zu unterstützen. 

Visuelle Darstellung der Navigationshinweise für den blinden Benutzer 

a) Aktueller Aufenthaltsraum und Abstand zum b) Warnung vor Hindernissen 

Objekt im Bildzentrum 

c) Information über den Zustand einer Tür d) Tür im Kamerabild (ist offen) 

Abbildung 3.14: Nach akustischer Umsetzung können visuelle Navigationshinweisen dem blinden Benutzer 

Aufschluss über den aktuellen Aufenthaltsraum und den Abstand zu modellierten 

Objekten geben, oder vor Gefahren warnen. Bild (a) zeigt den aktuellen Aufenthaltsraum 

und den Abstand zum Objekt in der Mitte des Blickfeldes an. Bild (b) zeigt 

eine Warnung vor einem Hindernis. Bild (c) zeigt eine als offen erkannte Tür.


Die Selbstlokalisation des Navigationsassistenten über Stereokamera und Richtungssensor gibt dem 

blinden Benutzer Auskunft über seinen aktuellen Aufenthaltsraum. Ein Abtaststrahl im Zentrum des virtuellen 

Blickfeldes ermöglicht ihm zudem die Erforschung der Umgebung durch einfaches „Umsehen“. 

Die Namen und die Distanzen der vom virtuellen Abtaststrahl getroffenen Objekte (siehe Abbildung 

3.14 (a) orange markiert) können Aufschluss über die Beschaffenheit der Umgebung geben. Durch die 

Extrapolation der augenblicklichen Bewegung kann über eine modellbasierte Kollisionserkennung vor 

Hindernissen gewarnt werden (siehe Abbildung 3.14 (b)). Der Vergleich zwischen realen und virtuellen 

Abständen ermöglicht zudem einen Hinweis auf den Zustand von Türen (Abbildung 3.14 (c-d)). 

Der Blinde erhält vom Navigationsassistenten somit zusätzliche Informationen über seine Umgebung, 

welche ihm die Navigation durch das fremde Gebäude erleichtern können. 

Die in diesem Kapitel beschriebenen Schritte, die zur Realisierung einer Navigationsunterstützung notwendig 

sind, wurden im Diagramm 3.15 als Designentwurf des zu implementierenden Prototyps zusammengefasst. 

Die Eingabedaten sind durch Rechtecke und die zur Navigationsunterstützung notwendigen 

Berechnungen als Ellipsen dargestellt. Das nächste Kapitel beschreibt die Implementierung der zur Ansteuerung 

der Sensoren notwendigen Klassen. Es stellt zudem die zur Generierung des 3D-Modells im 

OpenScneneGraph-Format eingesetzte Software vor und geht auf einige Implementierungsdetails des 

im Lösungsansatz beschriebenen Navigationsassistenten ein. 

Realität vs 

Modell 

Neuberechnung auf Anfrage 

Farbbild 

Tiefenbild 

Objekterkennung 

Objektbeschreibung 

2D Bildpositionen 

Sensordaten Modelldaten 

Tiefenbild 

Richtung 

Positionsbestimmung 

Szenengraph 

Kontinuierliche Neuberechnung 

3D Raumpositionen 

Berechnung der 

Änderungstransformationen 

Aktualisierung des 

3D-Modells 

Abbildung 3.15: Systemdesign des Navigationsassistenten. Die rechteckig markierten Eingabedaten 

aus Realität und Modell werden in drei Schritten ausgewertet, um die eigene Position 

zu bestimmen und das 3D-Modell zu aktualisieren. Eigene Position und Bewegungsrichtung 

können verwendet werden, um dem Benutzer Informationen über seine 

Umgebung bereit zu stellen und ihn vor Hindernissen zu warnen.

Kapitel 4 

Implementierung 

Dieses Kapitel beschreibt die Umsetzung des in Abschnitt 3.2 vorgestellten Lösungsansatzes und die 

zur Lösung der einzelnen Teilaufgaben implementierten Klassen. Die Struktur des implementierten Navigationsprogramms 

folgt dem in Abbildung 3.15 dargestellten Systemdesign. 

Zunächst müssen die Sensordaten erfasst und entsprechend aufbereitet werden, um diese dann mit den 

Modelldaten vergleichen zu können. Der nächste Abschnitt beschreibt die Auswahl und Ansteuerung 

der hierfür notwendigen Sensorhardware, die schließlich im Prototyp (siehe Abschnitt 3.2.1) eingesetzt 

wurde. 

4.1 Sensordatenerfassung 

Über das Nexus-Teilprojekt D2 standen eine Vielzahl an IEEE-1394 (Firewire) Digitalkameras und anderen 

Sensoren zur Verfügung. Diese wurden zu Beginn dieser Arbeit vor dem Erwerb einer „Bumblebee“- 

Kamera, in den ersten Monaten der Arbeit, auf ihre Eignung zur Gewinnung der Disparitätsbilder getestet. 

Folgende drei als Stereokamera konzipierten Module standen zur Verfügung: 

a) Unibrain Fire-i Digitalkameras b) Hand-geführtes Modul c) Brillenmodul 

Abbildung 4.1: Kamera-Module zur Erfassung von Stereobildern 

Unibrain Fire-i Kamera: Die in Abbildung 4.1 (a) gezeigten Unibrain Fire-i Kameras wurden in 8,5 

Zentimeter Abstand auf einer Aluschiene befestigt und bilden den ersten Testkandidaten. 

35

36 KAPITEL 4. IMPLEMENTIERUNG 

NAS Prototyp: In der in Abschnitt 2.3.2 vorgestellten Forschungsarbeit von Hub wird der Navigationsassistent 

als Handgerät umgesetzt. In diesem sind, neben anderen Sensoren, zwei Point Grey Firefly 

Kameras in einen Blindenstockgriff mit Steuerungstastatur integriert. 

Brillenmodul mit Point Grey Fireflys: Um den Vergleich mit den Modelldaten für die Positionsbestimmung 

zu vereinfachen, wurden in diesem Testkandidaten zwei Point Grey Firefly Kameras auf 

einer Brille befestigt. Aufgrund der im Vergleich zum Blindenstock eher ruhigen Haltung des Kopfes 

wird durch diesen Aufbau ein stabileres Kamerabild erreicht. 

Die drei Stereokameras wurden kalibriert und auf ihre Eignung für den zu entwerfenden Navigationsassistenten 

geprüft. Hierfür musste zunächst ein Konzept zur einheitlichen Ansteuerung aller Kameras 

erstellt und ein Programm zur Kalibrierung implementiert werden. 

4.1.1 Ansteuerung der Kameras 

Aufgrund der bisherigen Verwendung von Windows in diesem Nexus-Teilprojekt und der vergleichsweise 

einfachen Möglichkeit, unterschiedlichste Hardware mit diversen Treibern an verschiedenen Schnittstellen 

zu testen, setzt die hier vorgestellte Arbeit ebenfalls auf den Einsatz des Redmonder Betriebssystems. 

Hier stehen zur Ansteuerung von Firewire-Kameras diverse Application Programming Interfaces 

(APIs) und Bibliotheken zur Verfügung. Unter den bekanntesten in Industrie und Forschung finden sich: 

• Microsofts DirectShow (siehe Abschnitt 2.3.6) 

• National Instruments Image Aquisition (IMAQ) for IEEE 1394 Cameras (siehe Abschnitt 2.3.7) 

• Intels OpenCV (siehe Abschnitt 2.3.8) 

Der nächste Abschnitt beschreibt die zu Beginn der Arbeit getesteten APIs und bewertet ihre Eignung 

zur Ansteuerung der Kameras. Die synchrone Bildaufnahme zweier baugleicher Kameras ist hierbei ein 

besonderes Kriterium, da dies für die Berechnung von Stereodisparitätsbildern, wie sie im Abschnitt 

4.1.2 beschrieben wird, bei bewegter Kamera unerlässlich ist. 

Test verschiedener APIs 

Microsoft stellt über das in DirectX 9.0 (siehe Abschnitt 2.3.6) integrierte DirectShow API die Möglichkeit 

zur Ansteuerung von Firewire-Kameras über die Identifikationsnummer (ID) zur Verfügung. 

Hierfür müssen die entsprechenden Windows-Treiber für die Kameras installiert werden, welche für 

die verschiedenen Kameras in unterschiedlich stabilen Versionen zur Verfügung standen. Das niedrige 

Abstraktionsniveau der DirectShow-API ermöglicht zwar die hardwarenahe Ansteuerung der Kameras, 

das Senden eines Synchronisationsimpulses (Trigger Impuls) ist aber dennoch nicht vorgesehen. Eine 

synchrone Ansteuerung der Kamera muss deshalb über den DirectX Synch-Filter implementiert werden. 

Da diese Möglichkeit der Synchronisation bereits in der CvCam Klasse von OpenCV eingesetzt wird, 

wurde dieser Ansatz nicht nochmals implementiert.

4.1. SENSORDATENERFASSUNG 37 

Das von National Instruments (NI) als Zusatz zu Labview zur Verfügung gestellte IMAQ API (siehe 

Abschnitt 2.3.7) bietet durch eine hohe Abstraktion von der Hardware eine komfortable Möglichkeit, 

über wenige Befehle Firewire-Kameras anzusteuern. Es setzt hierfür allerdings den Einsatz der NI eigenen 

IMAQ Firewire-Treiber voraus. Diese können über den Measurement & Automation Explorer von 

NI komfortabel installiert und getestet werden. Der Vorteil der IMAQ API liegt in der Möglichkeit, der 

Kamera Triggerimpulse zu senden. Es stellte sich allerdings heraus, dass keine der getesteten Kameras 

diese Impulse berücksichtigt und somit nur eine asynchrone Ansteuerung der Kameras möglich war. 

Die Open Computer Vision Library (OpenCV) aus Abschnitt 2.3.8 beinhaltet neben vielen anderen 

Funktionen zwei Wege um Digitalkameras anzusteuern. Der Standardweg führt über die CvCapture- 

Funktionen, welche aber bei der zu Beginn der Arbeit vorliegenden OpenCV Version 4b noch nicht zur 

parallelen Ansteuerung mehrerer Kameras vorgesehen waren. Der andere Weg führt über die Verwendung 

der kaum dokumentierten und offensichtlich noch in einer sehr frühen Entwicklungsphase befindlichen 

Klasse CvCam. Diese verwendet zur Synchronisation der Kameras den SyncFilter von OpenCV 

und bietet so einen vielversprechenden Ansatz zur Lösung des Synchronistionsproblems. Geschwindigkeitsvergleiche 

zwischen CvCapture und CvCam zeigten zudem einen erheblichen Geschwindigkeitszuwachs 

und führte so zur Entscheidung, die CvCam Klasse so zu erweitern, dass sie für die Bilderfassung 

des Navigationsassistenten verwendet werden kann. 

CCam - Eine Klasse zur Ansteuerung der Kameras: Die CCam genannte Wrapper-Klasse wurde 

geschrieben um die Möglichkeit der NI-API Triggerimpulse an die Kamera zu senden für zukünftige 

Hardware bereitzustellen. Sie vereint die NI-API mit der CvCam Klasse. Über das Setzen eines Kompilerflags 

ist es möglich, die gewünschte API auszuwählen, ohne dass der Programmcode, welcher die 

CCam-Klasse verwendet, geändert werden muss. 

4.1.2 Berechnung der Stereodisparitätsbilder 

Nach der Lösung des Ansteuerungsproblems ist, zur Berechnung des Stereodisparitätsbildes aus den 

erfassten Einzelbildern, die Kalibrierung und Rektifizierung der Kamerabilder erforderlich (siehe Absatz 

2.1.4). 

Kamerakalibrierung 

Unter der Kalibrierung einer Kamera versteht man die Bestimmung der durch den optischen Aufbau 

der Kamera auftretenden Verzerrungen. Diese können, wie in Abschnitt 2.1.2 beschrieben, über das 

von Zhang vorgestellte Verfahren [4] ermittelt werden und ergeben alle kameraspezifischen Parameter, 

die zur Berechnung einer Entzerrungsmatrix nötig sind. Diese ermöglicht es, gerade Linien wieder in 

Geraden zu überführen, um so ein unverzerrtes Abbild der realen Szene im Computer weiterverarbeiten 

zu können. 

Um diesen Schritt möglichst einfach für alle zur Verfügung stehenden Kameras durchführen zu können, 

wurde eine MFC Oberfläche geschrieben, welche die zu kalibrierende Kamera über die in der Implementierung 

(Kapitel 4, Abschnitt 4.1.1) vorgestellte CCam-Klasse ansteuert. Nach der Angabe der Anzahl 

von Zeilen und Spalten des verwendeten Schachbrettmusters werden dessen innere Ecken automatisch 

gefunden. Es müssen mindestens fünf Ansichten des Schachbretts mit gefundenen inneren Ecken abge-


speichert werden, bevor das Programm über den nach Zhang implementierten Kalibrierungsalgorithmus 

cvCalibrateCamera() alle zur Kalibrierung der Kamera notwendigen Daten berechnen kann. Sobald 

genügend Ansichten abgespeichert sind, wird die Entzerrungsmatrix berechnet und das entzerrte Kamerabild 

dargestellt. Eine ausführliche Bedienungsanleitung des „Cam Calibrator“ findet sich im Anhang 

A.1. 

Abbildung 4.2: Screenshot des entwickelten MFC-Programms zur Kalibrierung von Firewire-Kameras 

Rektifizierung der Kamerabilder 

Nach der Kalibrierung erscheinen Abbildungen von parallelen Geraden wieder parallel, allerdings ist 

aufgrund der Verwendung zweier Kameramodule nicht sichergestellt, dass die Scanlines beider Bilder 

aufeinander liegen und die Blickrichtung beider Kameras parallel ist. Um den Versatz zwischen den 

Kameras zu korrigieren, muss daher die in Abschnitt 2.1.3 beschriebene Rektifizierungstransformation 

berechnet werden, welche die Scanlines beider Bilder so ausrichtet, dass eine einfache Berechnung des 

Stereodisparitätsbildes möglich ist. 

Abbildung 4.3: MFC Programm zur Kalibrierung und Rektifizierung der Kameras 

Zur Berechnung der für die Rektifizierung notwendigen Daten, wurde der „Cam Calibrator“ des letzten 

Abschnitts mit Hilfe des undokumentierten, aber in den OpenCV-Quellen enthaltenen Calib-Filters 

erweitert. Dieser nutzt die gefundenen Eckpunktpositionen des Schachbrettmusters aus linkem und rech-


tem Kamerabild, um die zur Rektifizierung der Bilder notwendigen Transformationsmatrizen zu berechnen. 

Diese können zusammen mit den zur Kalibrierung nötigen Daten im File „cameras.txt“ abgespeichert 

werden. Dies ermöglicht es, nach einmaliger Berechnung der Kameraspezifikationen, diese in 

anderen Anwendungen zu laden und erspart so die Neukalibrierung der Kameras bei jedem Programmstart. 

Eine ausführliche Bedienungsanleitung für den „StereoCam Calibrator“ findet sich in Anhang A.2. 

Nach der Entzerrung der Kamerabilder kann über den „Show/Hide“ Button im Bereich „Disparity 

Image“ ein Tiefenbild angezeigt werden, welches über den OpenCV Algorithmus berechnet wird (Abschnitt 

4.1.4). Es zeigt sich, dass selbst kleine Rotationsbewegungen der Kamera zu großen Fehlern im 

Stereobild führen. Die Vermutung, dass dies mit einer unzureichenden Synchronisierung der Kameras 

zusammenhängt, wurde über den im folgenden Abschnitt beschriebenen Synchronitätstest bestätigt. 

Synchronität 

Die Messung der Synchronität beider Kameras ist durch einen einfachen Versuchsaufbau realisierbar. 

Hierfür wird ein Fadenpendel, wie in Abbildung 4.4 gezeigt, aufgebaut und die Stereokamera so vor 

dem Pendel positioniert, dass die Bewegungsrichtung des Pendels senkrecht auf der Kameraachse steht. 

Abbildung 4.4: Versuchsaufbau für Synchronitätstests. Die Stereokamera wird auf der Seite liegend vor 

einem Fadenpendel positioniert. Über eine Skala hinter dem Pendel kann der Versatz 

zwischen linkem und rechten Einzelbild abgelesen werden.


Die Starthöhe des Pendels kann über die Energieerhaltungsgleichung 

E = mgh = 1 

2 mv2 

h = 1 

2g v2 = 

1 

2 ∗ 9.81 (5/3.6)2 

� m 2 s 2 

m s 2 

� 

= 0.1[m] (4.1) 

so gewählt werden, dass es mit einer Geschwindigkeit von 5 km m 

h (≈ 1.4 s ) an der Kamera vorbei schwingt. 

Dies entspricht der anzunehmenden Laufgeschwindigkeit des Benutzers. Über die hinter dem Pendel 

angebrachte Skala kann der Zeitversatz zwischen den Bildern aus der Geschwindigkeit des Pendels 

berechnet werden. Die Zeit pro Skaleneinheit (0.01Meter) ergibt sich aus: 

s = vt 

t = 0.01 

1.4 

� 

m s 

� 

= 7.1[ms] (4.2) 

m 

Abbildung 4.5 vergleicht die Ergebnisse des Pendelversuchs für verschiedene Kameras bei Verwendung 

der CvCam-Klasse von OpenCV und der IMAQ-API. Es wird deutlich, dass in diesem Fall die Verwendung 

einer asynchronen, sequentiellen Ansteuerung der Kameras mit circa 40 ms Versatz synchroner ist, 

als die Verwendung der über den DirectX Sync-Filter synchronisierten CvCam-Klasse mit (≈ 48 ms). 

Abbildung 4.5: Zeitversatz zwischen linken und rechten Einzelbildern bei unterschiedlichen Kameras 

und APIs. Es zeigt sich eine etwas geringere Zeitdifferenz beim Einsatz der IMAQ-API. 

Der insgesamt hohe Versatz erklärt die Fehler im Disparitätsbild bei bewegter Kamera. 

Zum Vergleich ist der Versatz der Bumblebee (125 µs) ebenfalls abgebildet.


Die Versuche, durch die Verwendung paralleler Threads oder eines Bildpuffers zeitgleiche Bilder zu 

erhalten, führen leider zu ähnlich schlechten Ergebnissen. Wie an der Abbildung zu erkennen ist, erlaubt 

der Zeitversatz zwischen den Kameras nur sehr langsame Bewegungungen. 

Dieses erklärt die großen Fehler im Stereobild bei Rotationen, die in Abschnitt 4.1.2 beschrieben wurden, 

und disqualifiziert jedes der vorhandenen Testmodule für den Einsatz im Navigationsassistenten 

bei nicht statischer Anwendung, da selbst bei langsamen Bewegungen Ungenauigkeiten im Tiefenbild 

auftreten und der zu entwickelnde Navigationsassistent den Benutzer nicht zu unnatürlich langsamen 

Bewegungen zwingen sollte. 

4.1.3 Verwendung eines selbstsynchronisierenden Stereokameramoduls 

Nach den im letzten Abschnitt beschriebenen Synchronitätstests kommt keine der vorhandenen Kamerasysteme 

zur Lösung der hier behandelten Navigationsaufgabe in Frage, da diese nicht ausreichend gut 

synchronisiert werden können (Latenzzeit zwischen den Kameras von 40 ms) und somit die Berechnung 

eines Disparitätsbildes bei bewegter Kamera zu ungenau ist. Aus diesem Grund wurde entschieden, ein 

Stereokameramodul zu erwerben, welches sich am Firewire-Bus automatisch synchronisiert und so die 

Berechnung des Tiefenbildes aus den Einzelbildern auch bei Bewegungen ermöglicht. 

Point Grey Bumblebee 

Von Point Grey [28] wurde das Bumblebee Stereokameramodul entwickelt, welches die Berechnung 

eines Disparitätsbildes, dank einer Latenzzeit von maximal 125 µs zwischen linkem und rechtem Kamerabild, 

auch bei schnellen Bewegungen ermöglicht. Aufgrund der Vorkalibrierung ab Werk und des 

vergleichsweise geringen Gewichts wurde das Kameramodul zur Entwicklung des Navigationsassistenten 

eingesetzt. 

Abbildung 4.6: Point Grey bietet mit der Bumblebee eine vorkalibrierte Stereokamera an. Durch automatische 

Synchronisierung am Firewire-Bus ist der Zeitversatz zwischen Stereobildpaaren 

minimal.


Ansteuerung der Stereokamera 

Zur Ansteuerung der Bumblebee stehen unter [29] das Digiclops- und Triclops-API von Point Grey zur 

Verfügung. Beide können in C/C++ Programme eingebunden werden und ermöglichen eine weitgehend 

komfortable, jedoch recht hardwarenahe Abfrage der Kamera beziehungsweise des zur Positionsbestimmung 

notwendigen Tiefenbildes. Das Digiclops API dient zur Ansteuerung der Kameras und Abfrage 

der Einzelbilder. Das Triclops SDK enthält Funktionen zur schnellen Messung von Distanzen zu Pixeln 

im Bild und unterstützt die Generierung von Disparitätsbildern aus linkem und rechtem Bild der 

Stereokamera. 

CBumblebee - Eine Klasse zur Ansteuerung der Bumblebee: Aufgrund der Hardwarenähe der 

APIs wurden die Aufrufe zur Ansteuerung der Kamera und Abfrage der Tiefeninformationen in einer 

Wrapper-Klasse zusammengefasst. Neben der in den meisten Beispielen verwendeten Methode, 

zunächst über triclopsGetImage16() das Disparitätsbild zu extrahieren und daraus durch Aufrufe von 

triclopsRCDToXYZ() für jeden Pixel einen Tiefenwert zu berechnen, steht zusätzlich die Funktion triclopsExtractImage3d() 

zur Verfügung. Diese fasst die Schritte zusammen und liefert direkt die benötigten 

Tiefeninformationen. Aufgrund vergleichbarer Performance beider Methoden und der leichteren Handhabung, 

wurde die zweite in der CBumblebee-Klasse verwendet, um die Abstandsinformationen für den 

späteren Vergleich mit der realen Szene zu berechnen. 

4.1.4 Verfahren zur Berechnung der Stereobilder 

Die automatische Synchronisation der Kameras im Bumblebee Stereokameramodul ermöglicht eine 

selbst für schnelle Kamerabewegungen ausreichend synchrone Akquisition von Stereobildpaaren. Diese 

können dank interner Entzerrung und Rektifizierung direkt über einen Stereoalgorithmus in ein Disparitätsbild 

umgerechnet werden. Es standen drei Implementierungen zur Berechnung des Stereodisparitätsbildes 

zur Verfügung, die in den folgenden Absätzen kurz vorgestellt werden. 

1. Die in Abschnitt 2.3.3 beschriebene Studienarbeit verwendet zur Berechnung der Stereodisparität 

einen an der Carnegie Mellon University implementierten Stereoalgorithmus. Da dieser allerdings 

zur Berechnung des Disparitätsbildes mehrere Sekunden benötigt, eignet er sich nicht zum Einsatz in 

Echtzeit-Anwendungen. 

2. In der OpenCV Dokumentation [26] findet sich über den Link „Experimental Functionality“ die Beschreibung 

einiger Funktionen, die nicht in der offiziellen Dokumentation des OpenCV Pakets enthalten 

sind. Hier wird unter anderem die Funktion cvFindStereoCorrespondence() erwähnt, welche es ermöglicht, 

aus zwei rektifizierten Grauwertbildern anhand des nach Birchfield et al. [30] implementierten 

Stereoalgorithmus ein Tiefenbild der Szene zu berechnen. 

3. Über die Triclops-API von Point Grey steht ebenfalls eine Implementierung zur Berechnung des 

Tiefenbilds aus den linken und rechten Einzelbildern der Bumblebee zur Verfügung. Diese wird über 

die CBumblebee-Klasse bereitgestellt und ermöglicht eine schnelle Abfrage des gewünschten Disparitätsbildes.


Geschwindigkeitsvergleich zwischen den Berechnungsverfahren 

Um die Geschwindigkeiten der OpenCV und Point Grey Implementierungen vergleichen zu können, 

wurde ein Programm geschrieben, welches die Distanzmessung anhand von Disparitätsbildern unter 

Verwendung der Bumblebee ermöglicht und zwischen den beiden Implementierungen umschalten kann. 

Abbildung 4.7 vergleicht die auf einem 1.6 GHz Centrino Laptop gemessene Geschwindigkeit beider 

APIs für unterschiedliche Anzahlen von Disparitätsstufen. Es ergibt sich, dass die Triclops-API bei 

allen Stufen schneller arbeitet als OpenCV. Sie wird deshalb zur Generierung der Disparitätsbilder im 

Navigationsassistent eingesetzt. 

Abbildung 4.7: Geschwindigkeitsvergleich zwischen OpenCV und Point Grey API, gemessen auf einem 

1.6 GHz Centrino Laptop. Es zeigt sich ein deutlicher Performancevorsprung der 

Point Grey API. 

4.1.5 Ansteuerung des Xsens Motion Trackers 

Über den von Hub entwickelten Prototyp (Abbildung 4.1 (b)) steht mit dem integrierten Motion Tracker 

von Xsens ein Miniatur-Inertialsensor mit Beschleunigungs-, Gyro- und Magnetfeldsensoren zur Verfügung. 

Die Magnetfeldsensoren können, wie im Lösungsansatz vorgestellt, zur Vorgabe der Blickrichtung 

der simulierten Kamera verwendet werden. Dieses ermöglicht einen einfachen und robusten Vergleich 

zwischen Realität und Modell. Der Sensor ist, wie in Abbildung 3.1 (b) gezeigt, direkt am Gehäuse der 

Stereokamera befestigt. Die im nächsten Absatz beschriebene Client-Server Lösung ermöglicht es, die 

benötigten Richtungsdaten vom Sensor abzufragen, ohne den Sensor zu blockieren.


Client-Server Lösung zur Kommunikation mit dem Motion Tracker 

Die Verwendung einer Client-Server Lösung ermöglicht es, von der eingesetzten Hardware unabhängig 

zu bleiben und den Sensor nicht zu blockieren, sodass er gleichzeitig für andere Berechnungen zur 

Verfügung steht. 

Es wurde ein Server-Thread auf Basis von Windows Sockets implementiert, der Verbindungen zum Port 

7000 zulässt und über das folgende einfache Protokoll die Abfrage der benötigten Richtungsinformationen 

des Inertialsensors ermöglicht: 

Befehl Funktion 

mt_server_get_data erfragt die Richtungsdaten vom Server 

mt_server_quit beendet den Server 

Tabelle 4.1: Xsens Server Protokoll zur Abfrage der Richtungsdaten 

Zur Übertragung der Richtungsdaten wird das folgende Strukt verwendet, welches je nach Einstellung 

des Motion Tracker Servers die Orientierung des Sensors als Raumwinkel oder als Rotationsmatrix an 

den Client liefern kann: 

typedef struct _mtOrientation{ 

float phi, theta, psi; 

float matrix[9]; 

}mtOrientation; 

4.2 Bereitstellung der Modelldaten 

Wie der Lösungsansatz beschreibt, soll durch die Angleichung einer simulierten Umgebung an real 

gemessene Daten die Position des Sensormoduls im Raum approximiert werden. Nachdem nun die 

Hardware zur Messung der realen Daten vorliegt, muss für den effizienten Vergleich zwischen Modell 

und Realität ein möglichst genaues 3D-Modell des Gebäudes vorhanden sein. 

4.2.1 Erstellung des Gebäudemodells mit 3D Studio Max 

Über die von Architekten üblicherweise zur Planung öffentlicher Gebäude angefertigeten CAD-Zeichnungen 

steht oft ein detailliertes Grundgerüst eines 3D-Modells zur Verfügung. Dieses kann in ein gängiges 

3D-Animationsprogramm wie zum Beispiel Discreets 3D Studio Max 6.0 importiert und dort 

über die Integration von Flächen als Wände und Böden, Fenster, Türen, etc. vervollständigt werden. 

Um später Blinde bei ihrer Navigation durch das Gebäude unterstützen zu können, muss zusätzlich die 

Inneneinrichtung der Räume nachmodelliert werden. Hierbei sollten alle festen und verschiebbaren Objekte, 

die bei der Navigation durch das Gebäude Hindernisse darstellen könnten, beachtet werden. Für 

einen Teil des Informatikgebäudes der Universität Stuttgart wurde ein solches Modell von Alexander 

Kobus im Rahmen des Nexus-Projektes bereits erstellt. Abbildung 4.8 zeigt den vollständig modellierten 

Gebäudeabschnitt, der zur Simulation der Umgebung bei dieser Arbeit eingesetzt wird.

4.2. BEREITSTELLUNG DER MODELLDATEN 45 

Abbildung 4.8: Zur Navigationsunterstützung eingesetzter, modellierter Gebäudeabschnitt 

Einteilung in Hierarchiestufen 

Die Einteilung des Gebäudes in verschiedene Hierarchiestufen (sogenannte Gruppen) ermöglicht es, 

relevante Teile des Modells selektieren oder ausblenden zu können. Dies erleichtert die Positionsbestimmung 

und Änderung von Objekten im Modell. 

Folgende Namenskonvention wurde zur Benennung der Gruppen festgelegt, um die in Abschnitt 3.2.2 

beschriebene Selektion des Startraumes zu vereinfachen. 

Räume : raum_ < Raumnummer > 

Gänge und Flure : f lur_ < Flurname > 

Treppenhäuser : treppenhaus_ < Treppenhausname > 

Der Flur- beziehungsweise Treppenhausname ist frei wählbar und besteht in den meisten Fällen aus 

einer Kombination aus Stockwerk und Himmelsrichtung im Gebäude.


Rohbau-Modell Mit statischen Mit statischen und 

Objekten verschiebbaren Objekten 

Abbildung 4.9: Anzeige verschiedener Hierarchiestufen des Gebäudes. Die Einteilung in Gruppen ermöglicht 

es, zwischen festen und verschiebbaren Hindernissen zu unterscheiden. 

Export des Modells ins OpenSceneGraph Format 

Das um verschiebbare Hindernisse erweiterte 3D-Modell wird über das OSGExp-Plugin [31] mit den in 

Abbildung 4.10 gezeigten Einstellungen ins OpenSceneGraph (.osg) Format exportiert. Dieses Format 

wurde gewählt, da es sich beim OpenSceneGraph-Format um eine einfach zu parsende, hierarchische 

Modellbeschreibungssprache handelt. Diese Format wird auch von anderen Nexus-Projekten zur Repräsentation 

von 3D-Modellen eingesetzt. OpenSceneGraph unterstützt außerdem Formate wie Alias Wavefront 

(.obj), 3D Studio Max (.3ds), VRML 1.0 (.wrl) und viele andere, die aber nicht die gewünschten 

strukturellen Eigenschaften besitzen. 

Abbildung 4.10: Osg Export Einstellungen des OSGExp Plugins für 3D Studio Max

4.2. BEREITSTELLUNG DER MODELLDATEN 47 

4.2.2 Darstellung des Gebäudemodells 

Die Darstellung komplexer 3D-Modelle wird üblicherweise durch den Einsatz einer ausgereiften 3D- 

Rendering-Engine übernommen. Diese setzen häufig einen Szenengraphen ein um die Szene möglichst 

effizient zu rendern. Verdeckung, „View-Frustum-Culling“, „Level-Of-Detail“ und viele andere Berechnungen 

werden vorab direkt auf dem Szenengraphen ausgeführt, damit nur die minimal nötige Anzahl an 

Vertices von der Grafikkarte dargestellt werden muss. Zudem wird eine schnelle Berechnung von Kollisionen 

und Schnittpunkten von Geraden mit der Szene ermöglicht. Das in Abschnitt 2.3.9 vorgestellte 

OpenSceneGraph-Toolkit stellt eine Opensource-Implementierung einer hochperformaten Rendering- 

Engine zur Verfügung. Diese wird in der hier vorgestellten Arbeit zur Simulation der Umgebung eingesetzt 

indem der in den OpenSceneGraph-Quellen enthaltene Viewer so erweitert wird, dass er die 

Distanzmessung des Sensormoduls im 3D-Gebäudemodell simuliert. Dies ermöglicht den Vergleich mit 

den real gemessenen Sensordaten. Die Locator genannte Implementierung der Navigationsassistenz- 

Software rendert die Szene zur grafischen Visualisierung der Positionsbestimmung aus Sicht einer virtuellen 

Kamera. Abbildung 4.11 (a) zeigt einen Raum im Informatikgebäude aus Sicht der simulierten 

Kamera. Zur besseren Informationsvisualisierung der Positionsbestimmungn, wird zudem eine Außenansicht 

der Szene gerendert, wie sie in Abbildung 4.11 (b) dargestellt ist. Diese zeigt die Position der 

virtuellen Kamera im Gebäude. 

Der Locator verbindet die in den folgenden Abschnitten beschriebenen Implementierungen zur Selbstlokalisation 

und Erkennung von modellierten Hindernissen und gibt das Feedback an den Benutzer grafisch 

zurück. Später soll auf eine grafische Ausgabe verzichtet werden und alle Berechnungen direkt auf 

dem Szenengraphen ausgeführt werden können. Die dargestellten Navigationshinweise könnten dann 

über eine Text-zu-Sprache Software wiedergegeben werden. Eine ausführliche Bedienungsanleitung mit 

allen Tastaturkürzeln findet sich in Anhang A.3. 

a) Aus Sicht der virtuellen Kamera b) Außenansicht der gerenderten Szene 

gerendertes 3D-Modell 

Abbildung 4.11: Darstellung des gerenderten 3D-Modells. Abbildung (a) zeigt die Szene aus Sicht der 

virtuellen Kamera, Bild (b) zeigt eine Außenansicht der gerenderten Szene.


4.3 Positionsbestimmung 

Ausgehend von den Modell- und Sensordaten wird in diesem Abschnitt auf die relevanten Berechnungsschritte 

des Navigationsprogramms eingegangen. Die zentralen Bestandteile sind die Objekterkennung, 

die Bestimmung der eigenen Position und der erkannten Objekte, sowie die Aktualisierung des Modells 

(Abbildung 4.12 (b)) 

Realität vs 

Modell 

Neuberechnung auf Anfrage 

Farbbild 

Tiefenbild 


Objektbeschreibung 


Sensordaten Modelldaten 

Tiefenbild 

Richtung 


Szenengraph 

Kontinuierliche Neuberechnung 




Aktualisierung des 

3D-Modells 







a) Systemdesign b) Berechnungsschritte des 

Navigationsprogramms 

Abbildung 4.12: Berechnungsschritte zur Positionsbestimmung. Bild (a) zeigt nochmals das im Lösungsansatz 

entwickelte Systemdesign. Bild (b) zeigt die Berechnungsschritte, welche 

das Programm zur Navigationsunterstützung durchführen muss. 

Das im Lösungsentwurf vorgestellte Verfahren zur Bestimmung der eigenen Position verschiebt die 

virtuelle Kamera solange, bis der Unterschied zwischen Simulation und Realität minimal wird. Der Locator 

setzt für den Vergleich zwischen Realität und Modell ein Verfahren zur Verfolgung von geeigneten 

Messpunkten ein. Die Art der Auswahl der Messpunkte wird dabei dynamisch vom Programm gesteuert. 

4.3.1 Bestimmung geeigneter Messpunkte 

Wie im Lösungsansatz bereits erwähnt wurde, eignen sich für annähernd quadratische Räume Featurepunkte 

auf Wänden als Messpunkte. In langen Gängen ist ein Punkt am Ende des Ganges aussagekräftiger. 

Die Berechnung des Wandabstandsschätzwertes beziehungsweise des Gangendes zur Kategorisierung 

und Auswahl der über cvGoodFeaturesToTrack() gefundenen Featurepunkte ist in der tvCalcPos- 

Klasse implementiert.

4.3. POSITIONSBESTIMMUNG 49 

Schätzung des Wandabstandes 

Die Schätzung des Wandabstandes beruht auf der Annahme, dass sich in der oberen Hälfte des Bildes üblicherweise 

keine Gegenstände befinden. In Abbildung 4.13 (a) sind die vier verwendeten Höhen durch 

farbige Linien dargestellt. Bild (b) zeigt die über die Stereokamera ermittelten Tiefen in den verschiedenen 

Höhen. Die obere (rote) Linie zeigt deutlich die extremen Tiefenunterschiede an Fenstern. Diese 

sind an den roten „Zacken“ zu erkennen. Durch die Mittelung aller gemessenen Tiefen und die Auswahl 

des größten Mittelwertes, nach Elemination der „Zacken“, kann der Wandabstand abgeschätzt werden. 

Abbildung 4.13 zeigt die gemäß Absatz 3.2.3 anhand des Abstands kategorisierten Featurepunkte des 

Bildes. Als Messpunkte geeignete Featurepunkte sind gelb eingefärbt. 

a) Eingesetzte Messhöhen b) Ermittelte Tiefen c) Kategorisierte Featurepunkte 

Abbildung 4.13: Schätzung des Wandabstandes durch Tiefensampling in verschiedenen Höhen. Abbildung 

(a) zeigt in verschiedenen Farben kodierte Messhöhen. Die an den Messhöhen 

ermittelten Tiefen sind in (b) dargestellt. Bild (c) zeigt die kategorisierten Featurepunkte. 

Bestimmung des Fluchtpunktes 

Als Fluchtpunkt wird der Punkt im Bild bezeichnet, in dem sich die meisten diagonalen Kanten eines 

Kantenbildes schneiden. Für lange Gänge lässt sich dieser Schnittpunkt über die in Abbildung 3.6 (e) 

dargestellten Hough-Linien im Bild berechnen. Zu diesem Zweck werden in der tvCalcPos-Klasse über 

einen Aufruf cvHoughLines2() alle Hough-Linien (siehe Abschnitt 2.1.5) extrahiert und ihre Richtung 

anhand des Hough-Winkels bestimmt. Den gesuchten Schnittpunkt P1 jeweils zweier Diagonalen g und 

n, mit den Steigungswinkeln α1 und α2, wie sie in Abbildung 4.14 dargestellt sind, berechnet tvCalc- 

Pos::getVanisingPoint(). 

Abbildung 4.14: Schnittpunkt zweier Geraden im 2D-Raum, Quelle [32]


Nach dieser Berechnung werden die Featurepunkte im Bild weiterverwendet, welche dem gefundenen 

„Fluchtpunkt“ am nächsten liegen. 

Weiterer Programmablauf: Unabhängig vom Berechnungsverfahren werden die gefundenen Featurepunkte 

solange im Bild verfolgt, bis diese nicht mehr gefunden werden oder sie ihren Quadranten 

verlassen haben (siehe Abschnitt 3.2.3, Wiederverwendung der Messpunkte). Auf diese Weise muss 

die rechenintensive Auswahl der Messpunkte nicht in jedem Durchlauf durchgeführt werden. So bleibt 

trotz kontinuierlicher Neuberechnung der eigenen Position noch Rechenleistung, um andere Objekte, 

wie verschiebbare Hindernisse, im Raum zu erkennen. Für diesen Zweck ist zunächst der aktuelle Aufenthaltsraum 

der virtuellen Kamera im Modell zu bestimmen. 

4.3.2 Positionsbestimmung der virtuellen Kamera 

Wechselt der blinde Benutzer seinen Aufenthaltsraum, so wird diese Raumänderung auch im Modell 

nachvollzogen. Eine einfache Möglichkeit zu bestimmen, in welchem Raum sich die virtuelle Kamera 

befindet, ist über ein Picking-ähnliches Verfahren implementiert. Die tvRoomFinder-Klasse berechnet 

die Schnittpunkte eines vom Mittelpunkt der Kamera senkrecht nach unten gehenden Strahls mit der 

Szene. Das erste getroffene Objekt liefert gemäß der Namenskonvention (raum_*, flur_* oder treppenhaus_*) 

(siehe Abschnitt 4.2.1) den Namen des aktuellen Aufenthaltsraumes. Der entsprechende 

Szenengraph Knoten wird zurückgegeben und ermöglicht die Extraktion des Raumnamens und der im 

Raum enthaltenen Geometrie. 

4.4 Erkennung von verschiebbaren, modellierten Objekten 

Neben der kontinuierlichen Neuberechnung der eigenen Position kann über den Locator nach verschiebbaren, 

modellierten Objekten im Bild gesucht werden. Auf diese Weise ist es möglich, das Modell 

anhand der gefundenen Objektpositionen aktuell zu halten. Die tvObjectDetector-Klasse implementiert 

den in Abschnitt 3.2.4 vorgestellten Ansatz zur farb- und formbasierten Erkennung von Objekten. Durch 

Vererbung kann dieses allgemeine Objekterkennungsverfahren auf die Detektion spezieller Objekte wie 

zum Beispiel Stühle zugeschnitten werden. 

Der ObjektDetector segmentiert in einem ersten Schritt Regionen im Bild. Die cvFloodFill() Funktion 

wird hierfür in diskreten Abständen im unteren Drittel des Bildes aufgerufen. Eine gefüllte Region 

wird dann als Binärbild zurückgegeben. Die Beschränkung auf das untere Bilddrittel ist in diesem Fall 

möglich, da nur nach Objekten am Boden gesucht werden soll. Sie reduziert den Aufwand der Suche 

auf diese Weise um zwei Drittel. Zur Bestimmung der Farbe wird das Kamerabild in den Lab-Farbraum 

konvertiert und der Farbwert des gefundenen Bereichs gemittelt. Dieser wird zusammen mit dem gemittelten 

Lab-Farbwert der Umgebung an den nach Hub [15] implementierten Farbklassifizierungsalgorithmus 

(colorClassifier()) übergeben. Der Name der ermittelten, wahrgenommenen Farbe kann dann mit 

dem Farbnamen der in Abschnitt 3.2.4 entworfenen Modellbeschreibung verglichen werden. 

Stimmt der aus dem Kamerabild ermittelte Farbname mit dem Farbnamen der Modellbeschreibung überein, 

so wird nach der Maskierung des Farbbildes über den logischen Und-Operator mit dem Binärbild 

der gefüllten Region, das Histogramm berechnet. In OpenCV steht für den Vergleich zweier Histogram-

4.5. AKTUALISIERUNG DES 3D-MODELLS 51 

me die cvCompareHist() Funktion zur Verfügung. Über diese wird das berechnete Histogram mit den in 

der Modellbeschreibung gespeicherten Histogrammwerten des zu suchenden Objektes verglichen. 

Waren beide Farbtests erfolgreich, wird zuletzt der Unterschied zwischen gefundener Region und dem 

Form-Muster der Beschreibung berechnet. Der ObjektDetector setzt hierfür die ebenfalls in der OpenCV 

Bibliothek enthaltene cvMatchShapes() Funktion ein. Das Ergebnis dieses Aufrufs gibt den Unterschied 

der verglichenen Form zurück. 

Wird das gesuchte Objekt in der gefüllten Region wiedererkannt, speichert der ObjektDetector die räumlichen 

Koordinaten (x,y,z) des Mittelpunktes der gefundenen Region und ruft die Fülloperation für einen 

weiteren Startpunkt im Bild auf. Auf diese Weise können alle in der Objektbeschreibung vorhandenen 

Objekte gesucht und gefunden werden. Über die in Gleichung 3.10 entwickelte Positionsbestimmung 

der Objekte im Raum ist eine Aktualisierung der Objektpositionen im 3D-Modell möglich. 

Der hohe Rechenaufwand, der zur Segmentierung der Bildbereiche notwendig ist, erlaubt bisher keine 

Berechnung der Objektpositionen in Echtzeit. Aus diesem Grund wird die Objektsuche nicht kontinuierlich 

durchgeführt, sondern muss vom Benutzer bei Bedarf manuell gestartet werden. Auf diese Weise 

kann zum Beispiel beim Betreten eines neuen Raumes die Lage der verschiebbaren Objekte aktualisiert 

werden. 

4.5 Aktualisierung des 3D-Modells 

Die Bestimmung des aktuellen Aufenthaltsraumes der virtuellen Kamera, wie sie in Absatz 4.3.2 beschrieben 

ist, ermöglicht eine schnelle Abfrage der enthaltenen Geometrie über den Szenengraphen. 

Die Beispiel-Klasse zur Suche nach Stühlen implementiert die Suche nach allen Stühlen im aktuellen 

Aufenthaltsraum. Zeiger auf die entsprechenden Szenengraphen-Knoten ermöglichen es, bei Erkennung 

einer geänderten Position, den Translationsknoten eines Stuhles zu aktualisieren, um ihn auf diese Weise 

an seine neue Position zu verschieben. Um sicherzustellen, dass die Objekte weiterhin auf dem Boden 

stehen, werden nur die X- und Y-Koordinaten der gefunden Objekte neu berechnet. 

Nach der Aktualisierung des Gebäudemodells kann dieses über die im OpenSceneGraph-Paket enthaltenen 

Funktionen wieder als OSG-Datei abgespeichert werden. 

Das aktualisierte Modell ermöglicht es blinde Benutzer bei der Erforschung ihrer Umgebung zu unterstützen. 

Über einen Abtaststrahl im Modell können Informationen wie Abstand und Art von betrachteten 

Objekten an den Benutzer zurückgegeben werden. Zudem ist die Warnung vor Hindernissen über Kollisionserkennung 

im Modell möglich.

Kapitel 5 

Ergebnisse 

Dieses Kapitel stellt die Ergebnisse der Selbstlokalisation und Positionserkennung von verschiebbaren, 

modellierten Objekten vor. Es beschreibt kurz die Testbedingungen unter welchen die Ergebnisse gemessen 

wurden. Alle Tests wurden auf der im nächsten Absatz beschriebenen Hardware durchgeführt. 

5.1 Hardwarekomponenten des Navigationsassistenten 

Als Entwicklungsplattform diente in dieser Arbeit ein Samsung x20 Laptop mit 1.6 GHz Pentium CPU 

(siehe Abbildung 5.1 (a)). Dieses verfügt über einen sechspoligen Firewire-Anschluss und eignet sich 

deshalb besonders gut zur Ansteuerung der Stereokamera, da keine zusätzliche Stromquelle benötigt 

wird. Das Laptop wurde aus diesem Grund auch zur Messung der Ergebnisse eingesetzt. Zur Positionsbestimmung 

sind die in Bild (b) gezeigte Stereokamera und der Inertialsensor (Bild (c)) aus den im 

Lösungsansatz beschriebenen Gründen auf einen Fahrradhelm montiert. 

a) Samsung x20 Centrino Laptop b) Point Grey Bumblebee c) Xsens MT9-B 

mit 1.6 GHz Stereokamera Inertialsensor 

Abbildung 5.1: Navigationsassistent bestehend aus Samsung x20 und Sensormodul. Bild (a) zeigt das 

eingesetzte Laptop im Betrieb, Bild (b) die Stereokamera und (c) den Inertialsensor. 

53

54 KAPITEL 5. ERGEBNISSE 

5.2 Distanzmessung über Stereokamera 

Vor dem Einsatz im Navigationsassistenten wurde zunächst die Abstandsmessung über die Stereokamera 

getestet. Die aus dem Disparitätsbild ermittelten Abstände wurden mit den gemessenen Abständen 

eines Laserentfernungsmessers (Leica Disto pro 4 a) verglichen. In einem großen Raum des Gebäudes 

wurden hierfür in bestimmten Entfernungen Markierungen an Einrichtungsgegenständen und Wänden 

angebracht und die Abstände zur Kamera gemessen. Abbildung 5.2 zeigt die Abweichung der Entfernungsmessung 

über die Bumblebee vom exakten Wert. Im Nahbereich (bis sechs Meter) ergibt sich eine 

Abweichung im Dezimeterbereich. Für Distanzen über neun Metern ist mit einem Messfehler von über 

einem Meter zu rechnen. Der Fehler steigt dabei exponentiell mit wachsendem Abstand. 

Abbildung 5.2: Abweichung der Abstandsmessung über Stereobilder der Bumblebee 

5.3 Selbstlokalisierung 

Zur Bestimmung der Qualität der Selbstlokalisierung wurden in verschiedenen Räumen Markierungen 

am Boden angebracht. Die Position der Markierungen wurde mit dem Laserentfernungsmesser bestimmt 

und in einer Karte eingetragen (siehe Abbildung 5.3 - grüne Markierungen). 

Testparcours 1: VIS-GS-Pool im Informatikgebäude 

Als erster Testparcours diente der VIS-GS-Pool im Informatikgebäude. Die Messpunkte wurden mit 

dem Navigationsassistenten abgelaufen und die Position der virtuellen Kamera an diesen Punkten abgespeichert. 

Durchgeführt wurden vier Messungen. Die Ergebnisse der ersten Testläufe sind in Abbildung 

5.3 (a) dargestellt. In diesen wurden vom Navigationsassistenten kontinuierlich alle Positionsvarianten 

berechnet. Tabelle 5.1 zeigt die zugrundeliegenden Messdaten. In Abbildung 5.3 (b) und Tabelle 5.2 sind 

die Ergebnisse der Selbstlokalisierung bei Beschränkung auf die Berechnung zweier Positionsvarianten 

(vor und zurück) abgebildet.

5.3. SELBSTLOKALISIERUNG 55 

a) Selbstlokalisierung durch Berechnung aller Positionsvarianten 

b) Selbstlokalisierung bei Beschränkung auf zwei Varianten 

Abbildung 5.3: Ergebnisse der Positionsbestimmung im VIS-GS-Pool. Abbildung (a) zeigt die Markerpositionen 

(grün) und die Positionen der virtuellen Kamera des Navigationsassistenten 

bei Berechnung aller Positionsvarianten (rot bzw. blau). Bild (b) stellt die Selbstlokalisierung 

bei Beschränkung der Berechnung auf zwei Varianten dar. Für annähernd 

quadratische Räume (Raum 1 und Raum 2) zeigt sich eine durchschnittliche Abweichung 

im Meterbereich. In langen Gängen weichen die Positionen über zwei Meter von 

den exakten Werten ab. Türdurchgänge, an denen vom Benutzer nachgeholfen werden 

musste, sind gelb markiert.


Messpunkte Messung 1 Messung 2 

X Y x y |∆x| |∆y| x y |∆x| |∆y| 

Raum 1 66,71 -53,61 66,19 -54,09 0,51 0,48 66,28 -53,41 0,42 0,19 

(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 

61,45 -53,46 62,09 -55,05 0,64 1,59 61,93 -54,22 0,48 0,76 

61,45 -57,31 63,85 -56,98 2,40 0,32 64,25 -57,32 2,80 0,01 

63,85 -57,46 62,93 -57,11 0,91 0,34 62,71 -54,19 1,13 3,26 

66,72 -57,51 65,56 -57,52 1,15 0,01 65,98 -54,92 0,73 2,58 

66,75 -61,05 64,61 -60,96 2,13 0,08 65,96 -60,77 0,78 0,27 

63,85 -61,41 63,46 -59,33 0,38 2,07 64,26 -60,39 0,41 1,01 

61,45 -61,09 61,79 -60,57 0,34 0,51 62,32 -59,87 0,87 1,21 

Abweichung Ø 0,32 0,29 0,35 0,12 

Raum 2 58,22 -61,1 59,77 -61,95 1,55 0,85 59,80 -60,49 1,58 0,60 

(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 

58,18 -53,82 59,06 -55,23 0,88 1,41 59,30 -55,71 1,12 1,89 

58,23 -57,64 58,55 -57,61 0,32 0,02 57,66 -57,08 0,56 0,55 

58,22 -61,1 58,05 -60,98 0,16 0,11 58,41 -60,65 0,19 0,44 

58,17 -64,12 58,43 -64,02 0,26 0,09 58,05 -63,99 0,11 0,12 

58,13 -66,35 58,02 -65,25 0,10 1,09 57,48 -65,42 0,64 0,92 

56,25 -66,43 57,16 -66,48 0,91 0,05 57,85 -66,40 1,60 0,02 

Abweichung Ø 0,67 0,09 0,54 0,13 

Raum 3 56,22 -68,39 56,73 -67,54 0,51 0,84 58,25 -68,94 2,03 0,55 

(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 

41,86 -68,4 41,83 -68,75 0,02 0,35 48,65 -68,70 6,79 0,30 

50,92 -68,38 51,44 -69,54 0,52 1,16 49,82 -68,24 1,09 0,13 

56,22 -68,39 59,79 -67,99 3,57 0,39 57,41 -68,54 1,19 0,15 

61,02 -68,31 61,94 -68,31 0,92 0,00 59,96 -68,48 1,05 0,17 

66,42 -68,42 65,67 -69,27 0,74 0,85 66,30 -67,91 0,11 0,50 

Abweichung Ø 0,11 0,37 0,21 0,56 

Tabelle 5.1: Positionen der virtuellen Kamera bei Berechnung aller vier Positionsvarianten. |∆x| und 

|∆y| geben den Betrag der Abweichung in X- und Y-Richtung an. Es ergibt sich für die in 

Abbildung 5.3 (a) markierten Räume eine durchschnittliche Abweichung im Meterbereich. 

Im Gang mit einfarbigen Wänden fällt diese Abweichung wesentlich größer aus.



X Y x y |∆x| |∆y| x y |∆x| |∆y| 

Raum 1 66,71 -53,61 66,12 -53,96 0,59 0,35 66,37 -53,86 0,34 0,25 

(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 

61,45 -53,46 60,21 -53,53 1,24 0,07 61,64 -53,85 0,19 0,39 

61,45 -57,31 60,80 -56,97 0,65 0,34 61,18 -57,01 0,27 0,30 

63,85 -57,46 63,44 -58,50 0,41 1,04 63,50 -57,80 0,35 0,34 

66,72 -57,51 65,92 -58,72 0,80 1,21 65,62 -58,26 1,10 0,75 

66,75 -61,05 66,62 -61,24 0,13 0,19 66,10 -60,78 0,65 0,27 

63,85 -61,41 63,10 -60,45 0,75 0,96 63,60 -61,10 0,25 0,31 

61,45 -61,09 62,15 -61,26 0,70 0,17 62,23 -61,32 0,78 0,23 

Abweichung Ø 0,60 0,56 0,47 0,40 

Raum 2 58,22 -61,10 56,55 -61,30 1,67 0,20 59,68 -61,47 1,46 0,37 

(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 

58,18 -53,82 57,68 -54,59 0,50 0,77 58,52 -55,07 0,34 1,25 

58,23 -57,64 57,79 -57,97 0,44 0,33 58,34 -56,88 0,11 0,76 

58,22 -61,10 57,64 -63,98 0,58 2,88 57,93 -60,93 0,29 0,17 

58,17 -64,12 57,58 -65,97 0,59 1,85 57,89 -63,90 0,28 0,22 

58,13 -66,35 57,70 -66,53 0,43 0,18 58,11 -65,77 0,02 0,58 

56,25 -66,43 55,86 -68,07 0,40 1,64 57,90 -66,14 1,65 0,29 

Abweichung Ø 0,67 1,01 0,54 0,50 

Raum 3 56,22 -68,39 55,13 -68,33 1,09 0,06 56,07 -68,13 0,15 0,26 

(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 

41,86 -68,40 42,94 -68,32 1,08 0,08 46,51 -68,71 4,65 0,31 

50,92 -68,38 46,14 -68,52 4,78 0,14 47,64 -68,90 3,28 0,52 

56,22 -68,39 58,69 -68,69 2,47 0,30 58,48 -68,04 2,26 0,35 

61,02 -68,31 61,94 -68,54 0,92 0,23 60,35 -68,44 0,67 0,13 

66,42 -68,42 65,79 -68,66 0,63 0,24 64,01 -68,75 2,41 0,33 

Abweichung Ø 1,65 0,19 2,62 0,31 

Tabelle 5.2: Positionswerte der virtuellen Kamera für Abbildung 5.3 (b) bei Beschränkung der Berechnung 

auf zwei Positionsvarianten. |∆x| und |∆y| geben wieder den Betrag der Abweichung 

in X- und Y-Richtung an. Es zeigt sich, dass durch Beschränkung eine genauere Positionsbestimmung 

in Räumen möglich ist (vergleiche Abbildung 5.3 (b). In Gängen erzielt die 

Beschränkung keine besseren Ergebnisse, ist aber aufgrund des niedrigeren Berechnungsaufwands 

zu bevorzugen.


Testparcours 2: Wohnräume 

Aufgrund starker magnetischer Störungen im ersten Testparcours musste die Orientierung der virtuellen 

Kamera bei den Tests gelegentlich von Hand nachjustiert werden. Zudem stellen die vielen homogenen 

Flächen im Informatikgebäude ein „Worst Case Szenario“ für die Berechnung des Disparitätsbildes dar. 

Aus diesem Grund wurde ein zweiter Testparcours in einem Wohnhaus aufgebaut. Abbildung 5.4 und 

Tabelle 5.3 zeigen die hier gemessenen Ergebnisse. 

Abbildung 5.4: Ergebnisse der Positionsbestimmung in Wohnräumen. Aufgrund geringer magnetischer 

Störungen und besserer Texturen auf den Wänden, kann die eigene Position wesentlich 

exakter bestimmt werden. 

Ergebnis der Selbstlokalisierung 

Tabelle 5.1 und 5.2 zeigen die Ergebnisse der Positionsbestimmung des Sensormoduls bei unterschiedlichen 

Einstellungen der Navigationssoftware. Für annähernd quadratische Räume ergibt sich eine durchschnittliche 

Abweichung von der exakten Position von circa einem Meter. In langen Gängen ist mit 

einer durchschnittlichen Abweichung längs des Ganges von zwei Metern zu rechnen. Der Vergleich mit 

den Messergebnissen in Räumen, die weniger magnetische Störungen und wenige homogene Flächen 

aufweisen zeigt, dass dort eine Positionsbestimmung im Bereich weniger Dezimeter möglich ist. Die 

starke Positionsabweichung in langen Gängen entsteht zum einen durch die Schwierigkeit, geeignete 

Messpunkte zu finden (einfarbige Wände und wenige Texturen auf den Wänden), zum anderen aus der 

für große Entfernungen ungenauen Abstandsmessung der Bumblebee. Dieser Effekt ist in Abbildung 

5.2 dargestellt.



X Y x y |∆x| |∆y| x y |∆x| |∆y| 

Raum 1 1,00 0,70 1,55 0,18 0,55 0,52 1,34 0,35 0,34 0,35 

2,30 0,75 2,65 0,29 0,35 0,46 2,53 0,46 0,23 0,29 

4,00 0,70 4,16 0,32 0,16 0,38 3,92 0,52 0,08 0,18 

4,00 2,30 4,10 2,74 0,10 0,44 4,05 2,24 0,05 0,06 

2,30 2,30 2,63 2,36 0,33 0,06 2,78 2,30 0,48 0,00 

1,00 2,30 1,20 2,62 0,20 0,32 0,08 2,30 0,92 0,00 

1,00 3,50 1,59 3,29 0,59 0,21 1,17 3,40 0,17 0,10 

2,30 3,50 2,44 3,34 0,14 0,16 2,48 3,36 0,18 0,14 

4,00 3,50 3,60 3,41 0,40 0,09 3,27 3,48 0,73 0,02 

Abweichung Ø 1,65 0,19 2,62 0,31 

Gang 4,66 5,11 4,58 4,95 0,08 0,16 3,83 4,90 0,83 0,21 

6,66 5,11 6,26 4,97 0,40 0,14 6,92 5,00 0,26 0,11 

8,00 5,11 7,45 5,11 0,55 0,00 7,53 4,98 0,47 0,13 

9,50 5,11 7,86 5,03 1,64 0,08 8,91 5,18 0,59 0,07 

Abweichung Ø 1,65 0,19 2,62 0,31 

Raum 2 9,50 7,00 9,41 7,49 0,09 0,49 9,15 7,90 0,35 0,90 

9,50 8,50 9,47 8,38 0,03 0,12 9,22 8,50 0,28 0,00 

9,50 9,78 9,56 9,46 0,06 0,32 9,31 9,29 0,19 0,49 

7,74 9,78 8,07 9,74 0,33 0,04 8,09 9,63 0,35 0,15 

7,74 8,50 7,62 7,72 0,12 0,78 7,72 7,30 0,02 1,20 

7,74 7,00 7,68 6,52 0,06 0,48 7,69 6,39 0,05 0,61 

7,74 7,00 7,6787 6,52 0,06 0,48 7,69 6,39 0,05 0,61 

Abweichung Ø 1,65 0,19 2,62 0,31 

Tabelle 5.3: Positionswerte der virtuellen Kamera zu Abbildung 5.4. Es wird deutlich, dass in Räumen 

mit besseren Wandtexturen und geringen magnetischen Störungen eine bessere Positionsbestimmung 

erzielt werden kann. Die durchschnittliche Abweichung liegt hier im Bereich 

weniger Dezimeter.


5.4 Lokalisierung von verschiebbaren Objekten 

Anhand einer Modellbeschreibung für modellierte, verschiebbare Objekte ist es möglich, diese über 

ein bildbasiertes Verfahren in der Szene zu lokalisieren. Um das entwickelte Suchverfahren zu testen, 

wurden Modellbeschreibungen für mehrere Ansichten verschiedener Stühle erstellt und diese in unterschiedlichen 

Abständen vor der Kamera positioniert. Die exakten Abstände zu den Objekten und die 

über die Stereokamera ermittelten Distanzen sind in Abbildung 5.5 zusammengefasst. Aufgrund der 

Eigenschaften des eingesetzten Lokalisierungsverfahrens konnten nicht in jedem Durchgang alle Stühle 

gefunden werden (fehlende orange Balken im Bild). Vor allem dunkelblaue Stühle heben sich bei 

zu schwacher Beleuchtung zu wenig von ihrer grauen Umgebung ab und können deshalb schlechter 

gefunden werden. 

Abbildung 5.5: Distanzen zu lokalisierten Objekten. Für Abstände von bis zu 4,5 Metern können Objekte 

im Stereobild lokalisiert werden. Ob ein gesuchtes Objekt gefunden werden kann, 

ist von der Beleuchtung und dem Farbkontrast zur Umgebung abhängig. 

Ergebnisse der Objektlokalisierung 

Für die Bestimmung der Position erkannter Objekte lässt sich, aus den Schaubild 5.5 zugrundeliegenden 

Daten, eine durchschnittliche Abweichung von 0,2 Metern ermitteln. Aufgrund der Einschränkung des 

Verfahrens auf eine bestimmte Objektgröße werden Objekte ab einer Entfernung von circa viereinhalb 

Metern nicht mehr gefunden. Dies ist für eine Hindernis-Erkennung für Blinde noch annehmbar, da 

innerhalb dieser Distanz noch Gelegenheit besteht, Hindernisse zu erkennen und zu umgehen.

5.5. PERFORMANCEMESSUNG DER NAVIGATIONSSOFTWARE 61 

5.5 Performancemessung der Navigationssoftware 

Zur Bestimmung der Geschwindigkeit der Navigationssoftware wurde die Anzahl der verarbeiteten Bilder 

pro Sekunde (Fps) gemessen. Abhängig von der Komplexität der Szene kann diese mit bis zu 230 

Fps dargestellt werden. Wird zusätzlich das Disparitätsbild der Stereokamera angezeigt, sinkt die Geschwindigkeit 

auf 16 Fps. Dies entspricht circa zehn Prozent der von der Grafikhardware möglichen 

Leistung. Abbildung 5.6 zeigt die Berechnungsgeschwindigkeiten mit und ohne Stereokamera und bei 

Zuschaltung der entwickelten Verfahren zur Selbstlokalisierung und Suche nach verschiebbaren Objekten. 

Abbildung 5.6: Performancemessung der Navigationssoftware. Aufgrund der zeitaufwändigen Berechnung 

sinkt die Anzahl der verarbeiteten Bilder der Software bei Anzeige des Disparitätsbildes 

um circa 90 Prozent.

Kapitel 6 

Diskussion 

Dieses Kapitel diskutiert die im letzten Kapitel gemessenen Ergebnisse. Es geht auf die Bedeutung der 

ermittelten Positionsdaten und die errechnete Abweichung vom mit Laser vermessenen, exakten Wert 

ein und gibt einen Ausblick auf die Maßnahmen, die zur weiteren Verbesserung der Positionsbestimmung 

führen könnten. 

6.1 Bewertung der Ergebnisse 

Die Ergebnisse der Selbstlokalisation des Sensormoduls zeigen, dass eine deutliche Verbesserung der 

Positionsbestimmung gegenüber dem bisher eingesetzten WLAN-Positionierungssystem, welches die 

eigene Position nur auf Raumgenauigkeit bestimmt, erreicht werden kann. Je nach Beschaffenheit der 

Räume ist es möglich, die Position des Benutzers auf einen Bereich von einem halben Meter bis maximal 

zwei Meter einzugrenzen. Der Blinde ist damit einerseits weiterhin auf den Blindenstock zur 

Erforschung seiner direkten Umgebung angewiesen, andererseits können erweiterte Informationen aus 

dem Modell die Navigation zusätzlich erleichtern. 

Durch das in Abschnitt 3.2.3 vorgestellte Verfahren ist es möglich, die Selbstlokalisation echtzeitnahe 

durchzuführen. Der Einsatz geeigneter Bildpunkte zur Abstandsbestimmung ist robust gegenüber Störungen 

und somit in vielen Umgebungen einsetzbar. Tests mit unterschiedlichen Anzahlen berechneter 

Positionsvarianten im Modell zeigen, dass es im Allgemeinen ausreicht, die ersten zwei Varianten (vor 

und zurück) zusätzlich zur aktuellen Position mit der Realität zu vergleichen. In diesem Fall sollte der 

Benutzer gelegentlich den Kopf um 90 Grad drehen, um durch Abweichungen des Kompasses entstandene 

Fehler zu korrigieren. 

Die Performancemessung in Abschnitt 5.5 macht deutlich, dass eine kontinuierliche Suche nach modellierten, 

verschiebbaren Hindernissen, bei gleichzeitiger Erfassung des Stereobildes, den Programmablauf 

zu stark verzögert (0,62 Bilder pro Sekunde). Diese Berechnung muss deshalb vom System oder 

vom Benutzer bei Bedarf aufgerufen werden. Die Ergebnisse der Objektlokalisierung zeigen, dass das 

zur Detektion der Objekte entworfene Verfahren (siehe Abschnitt 3.2.4) Hindernisse mit Dezimetergenauigkeit 

lokalisieren kann, sofern diese nicht zu weit entfernt oder von anderen Objekten verdeckt sind. 

Durch Vergleiche mit dem Modell können genauere Informationen über die Art und Lage von Objek- 

63

64 KAPITEL 6. DISKUSSION 

ten in der Umgebung des Benutzers bereitgestellt werden, als das über bisherige Verfahren möglich ist 

(Abschnitt 2.2). 

6.2 Ausblick 

Im Verlauf dieser Arbeit wurde deutlich, dass viele der eingesetzten Verfahren durch die Wahl geeigneter 

Parameter oder durch die Kombination mit anderen Methoden und Sensordaten verbessert werden 

können. Der implementierte Prototyp zeigt, dass das entworfene Konzept zur Selbstlokalisation und 

Detektion geeignet ist und durch Beschleunigung der eingesetzten Verfahren und schnellere Hardware 

schon bald eine Navigationsunterstützung für Blinde echtzeitnahe möglich ist. 

Die Geschwindigkeitsmessung der Software zeigt, dass bis zu 90 Prozent der Rechenzeit für die Berechnung 

des Tiefenbildes benötigt werden. Da diese Berechnung komplett auf der CPU stattfindet bleibt 

nur wenig Zeit für die zur Positionsbestimmung notwendigen Verfahren. Eine GPU-basierte Berechnung 

des Disparitätsbildes könnte die CPU stark entlasten und auf diese Weise die Suche nach verschiebbaren 

Objekten beschleunigen. 

Die Ende Oktober 2005 erscheinende Umsetzung eines Embedded Systems zur Berechnung der Stereobilder 

von Videre Design [33] stellt ebenfalls eine interessante Möglichkeit zur Beschleunigung des 

Systems dar. Der auf einem kleinen FPGA (2x3 cm) synthetisierte Stereoalgorithmus soll die CPU von 

allen Berechnungen befreien, die zur Ermittlung der Abstände aus dem Tiefenbild notwendig sind und 

ausreichende Bildfrequenzen liefern. 

Prinzipbedingt ist ein Raumwechsel über die Stereokamera oft nicht zu erkennen. In diesen Fällen wird 

die Kamera aufgrund ungleicher Distanzen im Modell rückwärts bewegt, obwohl sie in der Realität 

vorwärts bewegt wird. Dieser Effekt könnte durch die zusätzliche Nutzung der Beschleunigungssensoren 

des Inertialsensors oder durch eine Fusion der Positionsbestimmung mit anderen Verfahren, wie zum 

Beispiel dem von Kombrink [14] verbessert werden. 

Neue Erkenntnisse aus der Psychophysik könnten zudem helfen, die Suche nach verschobenen Objekten 

zu verbessern und die Segmentierung der Bildregionen zu beschleunigen. Eine geeignete Wahl von 

wenigen Startpunkten, von deren Position aus die Regionen segmentiert werden, würde das eingesetzte 

Suchverfahren erheblich beschleunigen. 

Die zunehmende Miniaturisierung von Kamerasensoren macht eine Integration der Sensorhardware in 

eine Brille denkbar. Das immer häufiger verfügbare WLAN-Netz könnte in diesem Fall genutzt werden 

um aufwändige Berechnungen vom Navigationsassistenten auf einen externen Server zu verlagern und 

so den blinden Benutzer, bezüglich der zu tragenden Hardware, weiter zu entlasten. 

Über die von Hub et al. in [34] vorgestellte Methode zur Sprachausgabe oder ein taktiles Display können 

die über den Navigationsassistenten gewonnenen Informationen an den blinden Benutzer weitergegeben 

werden.

Kapitel 7 

Zusammenfassung 

Ziel dieser Arbeit war die Optimierung eines elektronischen Navigationsassistenten für Blinde, der auf 

der Kombination lokaler Sensorik mit 3D-Gebäudemodellen basiert. Zum einen sollte die Position des 

Benutzers und die von modellierten Objekten, unter Verwendung einer Stereokamera und eines Inertialsensors, 

bestimmt werden. Des Weiteren sollten veränderte Positionen von verschiebbaren Objekten 

erkannt und das Gebäudemodell entsprechend aktualisiert werden. 

Nach der Auswahl und Kalibrierung geeigneter Sensorhardware wurden Verfahren evaluiert, über die 

Daten aus dem virtuellen Modell mit realen Messungen verglichen werden können. Aufgrund der langen 

Rechenzeit vorhandener Verfahren, wurde eine neue Methode zur Auswahl von geeigneten Messpunkten 

entwickelt und implementiert. Als geeignet stellen sich Bildpunkte heraus, die einen starken 

Helligkeitskontrast bezüglich ihrer Umgebung aufweisen. Diese können über richtungsbasierte Gradientverfahren 

gefunden werden. An diesen Stellen kann die Tiefe über die Stereodisparität zuverlässig 

berechnet werden. Parameterbereiche zur Auswahl der Messpunkte wurden über Tests in verschiedenen 

Umgebungen ermittelt. Durch den Vergleich von Messdaten mit einer simulierten Umgebung kann die 

Selbstlokalisation gegenüber bisher verwendeten Verfahren erheblich verbessert werden. Die Messfehler 

liegen in Umgebungen mit einfarbigen Wänden im Bereich von ein bis zwei Metern. In kontrastreichen 

Umgebungen liegt der Fehler im Bereich weniger Dezimeter. 

Zur bildbasierten Detektion verschobener Objekte wurden charakteristische Objekteigenschaften ermittelt 

und in einer Modellbeschreibung zusammengefasst. Diese umfasst Farbnamen, Farbtonwerte und 

Forminformationen. Durch die Kombination bestehender Verfahren aus der farbbasierten Bildsegmentierung 

und deren Erweiterung um die Nutzung der Tiefeninformationen, können Regionen im Bild segmentiert 

und mit der Modellbeschreibung verglichen werden. Der zusätzliche Vergleich der Form und 

die Optimierung der Erkennungsparameter können dabei beleuchtungsbedingte Störungen der Farbsegmentierung 

kompensieren. Verschiebbare, modellierte Objekte können auf diese Weise lokalisiert und 

das Modell ohne ständiges Eingreifen eines 3D-Designers aktuell gehalten werden. 

Über die im Rahmen dieser Arbeit entwickelten Methoden können Blinde ihre Position innerhalb einzelner 

Räume bis auf eine ertastbare Abweichung bestimmen. Die Verwendung eines 3D-Gebäudemodells 

ermöglicht es, auf zusätzliche Infrastruktur im Gebäude weitgehend zu verzichten. Durch Ausgabe von 

Objektnamen, Distanzmessungen zu modellierten Objekten und Kollisionserkennung im Modell kann 

der blinde Benutzer neuartige Informationen erhalten und vor Hindernissen gewarnt werden. Für Blinde 

ist somit eine Basis für eine sichere und unabhängige Navigation in unbekannten Gebäuden gegeben. 

65

Anhang A 

Bedienungsanleitungen 

A.1 Kalibrierungs-Tool 

Zur Kalibrierung von Kameras wurde das Programm CamCalibrator entwickelt. Es ermöglicht die Kalibrierung 

von Kameras über die Aufnahme eines Schachbrettmusters aus verschiedenen Positionen. 

a) CamCalibrator-GUI b) Kamerabild mit gefundenen Ecken 

Abbildung A.1: CamCalibrator zur Kalibrierung von Kameras. Bild (a) zeigt die GUI zur Steuerung 

der Kalibrierung, (b) zeigt die gefundenen inneren Ecken des Schachbrettmusters als 

farbige Punkte. 

Nach Programmstart muss die Kamera über den „Start Cam“-Button gestartet werden. Sofern die Kamera 

dies unterstützt, wird ein Video Device Konfigurationsfenster geöffnet. In diesem sollte die maximale 

Auflösung und RGB als Farbspektrum gewählt werden. Die Anzahl der Zeilen und Spalten des verwen- 

67

68 ANHANG A. BEDIENUNGSANLEITUNGEN 

deten Schachbrettmusters muss in die Felder „Rows, Cols“ eingetragen werden. Das Programm sucht 

nach dieser Angabe automatisch die inneren Ecken des Schachbrettmusters. Der „Save Image“-Button 

wird erst freigegeben, wenn alle Ecken gefunden wurden. Im „Num Images“-Feld kann die Anzahl der 

zur Kalibrierung verwendeten Bilder angegeben werden. Für die Bestimmung der Verzerrungen sind 

mindestens drei Bilder des Musters aus unterschiedlichen Betrachtungswinkeln notwendig. Nachdem 

die notwendige Anzahl an Bildern abgespeichert wurde, erlaubt der Knopf „Get Calibration Parameters“ 

die Berechnung der gesuchten Kalibrierungsdaten. Diese können über den „Save“-Button abgespeichert 

und später in anderen Programmen geladen werden. 

Über den „Verbose“ Schalter kann eine grafische Darstellung der Suche nach den inneren Ecken zugeschaltet 

werden. „Flip Image“ ermöglicht das Spiegeln der Bilder an der Horizontalen, falls die Kamerabilder 

auf dem Kopf stehen sollten. 

Nach der Berechnung der Parameter kann die Kamera gestoppt und über den „Quit“-Knopf die Anwendung 

beendet werden. 

A.2 Rektifizierungs-Tool 

Die mit StereoCam bezeichnete Anwendung erweitert den CamCalibrator um die Ansteuerung einer 

zweiten Kamera und die Möglichkeit neben den Kalibrierungsdaten gleichzeitig die zur Rektifizierung 

notwendigen Parameter mitzuberechnen. 

a) StereoCam-GUI b) linkes Kamerabild c) rechtes Kamerabild 

Abbildung A.2: StereoCam zur Kalibrierung und Rektifizierung von Kameras. Bild (a) zeigt die StereoCam 

Oberfläche, in Bild (b) und (c) sind die Kamerabilder mit gefundenen Schachbrettecken 

dargestellt.

A.3. NAVIGATIONSSOFTWARE - LOCATOR 69 

Der Ablauf des Programms ist dem CamCalibrator nachempfunden. Nach dem Start der Anwendung 

muss zunächst die Auflösung und das Farbspektrum beider Kameras eingestellt werden. Farbe und Helligkeit 

der Kameras sind über die „Left, Right“-Knöpfe im „Cam Settings“-Bereich einstellbar. Die 

Anzahl der Spalten und Zeilen des verwendeten Schachbrettmusters muss wieder in die „Rows-, Cols“- 

Felder eingetragen werden. Nach Drücken des „Calibrate“-Buttons sucht das Programm im linken und 

rechten Kamerabild die inneren Ecken des Musters und markiert diese mit farbkodierten Punkten. Bei 

Positionsänderungen des Musters muss darauf geachtet werden, dass das Schachbrett immer in beiden 

Kamerabildern zu sehen ist. Durch die Betätigung des „Snap“-Knopfes wird die aktuelle Ansicht gespeichert. 

Zur Rektifizierung sind mindestens fünf Ansichten aus verschiedenen Winkeln notwendig. Die 

gewünschte Anzahl kann in „Num Images“ eingestellt werden, sollte aber nicht zu hoch angesetzt werden, 

da sonst die Berechnung der Kalibrations- und Rektifizierungsdaten unnötig lange dauert. Der „Sort 

Points“-Schalter wurde eingefügt, da sich die Reihenfolge der linken und rechten Schachbrettecken unterscheiden 

kann (erkennbar durch unterschiedliche Farbkodierung der Punkte in den Kamerabildern). 

Ist der Schalter aktiviert, werden die Ecken automatisch sortiert. Dies führte in allen Tests zu besseren 

Ergebnissen. Steht dem Programm eine ausreichende Anzahl an Bildpaaren zur Verfügung, werden 

die Kalibrierungs- und Rektifizierungsdaten automatisch berechnet. Diese können über die „Save“- und 

„Load“-Knöpfe abgespeichert und später wieder geladen werden. 

Über den „Show/Hide“-Button kann das berechnete Stereobild ein- und ausgeblendet werden. Das Ausund 

Einschalten der „Undistort“- und „Rectify“-Schalter macht den Einfluss von Kalibrierung und Rektifizierung 

auf das Disparitätsbild deutlich. Der „Steps“-Regler steuert die Anzahl der verwendeten Disparitätsstufen. 

Die Anwendung kann nach dem Anhalten der Kameras über den „Quit“-Knopf verlassen 

werden. 

A.3 Navigationssoftware - Locator 

Locator ist die implementierte Software des Navigationsassistenten. Sie bestimmt die Position des Sensormoduls 

durch Vergleiche zwischen real gemessenen und simulierten Abstandsdaten in Gebäuden. Für 

den Vergleich zwischen Realität und Modell wird ein OpenSceneGraph-Modell des Gebäudes verwendet. 

Aus diesem Grund baut der Locator auf dem OpenSceneGraph-Viewer auf und erbt das Konzept 

zur Mausinteraktion mit der Szene und einige Tastaturkürzel. 

Bevor der Viewer, welcher die aktuelle Position und Navigationshilfen anzeigt, gestartet wird, fragt eine 

MFC-Oberfläche den aktuellen Aufenthaltsraum ab. 

Abbildung A.3: Raum-Auswahl-Dialog. Über diesen Dialog muss beim Programmstart der aktuelle 

Aufenthaltsraum angegeben werden.


Nach der Angabe des Startraumes zeigt der Locator im Hauptfenster die virtuelle Szene mit der aktuellen 

Position und Orientierung der Kamera an (siehe Abbildung A.4 (a)). Nebenfenster Right zeigt das Bild 

der realen Kamera mit den Messpunkten in den oberen sechs Quadranten. Im Nebenfenster Disp wird 

das aus der Stereodisparität berechnete Tiefenbild und ebenfalls die Position der Messpunkte angezeigt. 

Über die Schieberegler im Right-Fenster kann das Rot-Blau-Verhältnis der Kamera und die Anzahl der 

berechneten Varianten eingestellt werden. Die Zahlen entsprechen folgenden Varianten: 

Variants Berechnete Varianten 

0 keine 

1 aktuelle Position 

2, 3 aktuelle Position, vor, zurück 

3, 4 aktuelle Position, vor, zurück, links, rechts (alle) 

Tabelle A.1: Einfluss des Reglers „Variants“ auf die Anzahl der berechneten Varianten 

Über die s-Taste kann die Selbstlokalisation gestartet werden. Sollte die Orientierung der virtuellen 

Kamera nicht mit der realen Blickrichtung übereinstimmen kann dies über die r- / l-Tasten korrigiert 

werden. Die Suche nach modellierten Objekten steht über die f-Taste bereit. Tabelle A.2 fasst alle Tastaturkürzel 

zusammen, die zur Steuerung des Locators notwendig sind. Diese können im laufenden 

Programm über die h-Taste im Locator-Fenster eingeblendet werden. Die i-Taste ermöglicht zudem das 

Anzeigen der Navigationshinweise in einem HUD. Dieses gibt Auskunft über den aktuellen Aufenthaltsraum 

und zeigt den Namen und Abstand des Objekts im Zentrum des Kamerabildes an. Errechnet 

die Bewegungsextrapolation Kollisionen im Modell wird hier auch eine entsprechende Warnung ausgegeben. 

Zur besseren Visualisierung der aktuellen Position wird im oberen Teil des 3D-Modell-Fensters 

die Szene von außen angezeigt. Über die linke Maustaste kann die Szene rotiert werden. Die rechte 

Maustaste erlaubt das Hinein- und Herauszoomen. Werden beide Tasten gedrückt, ist zudem das Verschieben 

der betrachteten Szene möglich. 

Taste Locator-Funktion 

h Anzeige der Hilfe im Viewer 

i HUD anzeigen / ausblenden 

s Start / Stop der Positionsbestimmung 

← ↑ ↓ → Verschiebung der virtuellen Kamera 

l, r Rotation der virtuellen Kamera nach links, rechts 

u, d Translation der virtuellen Kamera nach unten, oben 

f Einmalige Suche nach Objekten 

t Trainieren einer neuen Objektbeschreibung 

w Modellbeschreibung speichern 

o Aktualisiertes 3D-Modell abspeichern 

ESC Programmende 

SPACE Rücksetzen der Außenansicht 

Tabelle A.2: Tastaturkürzel zur Steuerung des Navigationsassistenten

A.3. NAVIGATIONSSOFTWARE - LOCATOR 71 

a) 

Abbildung A.4: Locator Programmoberfläche. Das Hauptfenster (a) zeigt die Position der virtuellen 

Kamera, welche aus den Messdaten der Stereokamera berechnet wurde. Über dieses 

Fenster kann die Navigationssoftware gesteuert und die Position und Orientierung der 

Kamera nach Programmstart korrigiert werden. Bild (b) zeigt die Position der augenblicklich 

verwendeten Messpunkte in den Quadranten. Schieberegler ermöglichen die 

Begrenzung der berechneten Varianten und die Einstellung der Kamerafarben. In Bild 

(c) wird das Disparitätsbild und ebenfalls die Messpunkte angezeigt. 

b) 

c)


A.3.1 Lernen einer Objektbeschreibung 

Über den Locator besteht die Möglichkeit neue Objektbeschreibungen für verschiebbare Objekte zu 

erzeugen. Bisher ist diese Funktion allerdings nur für das Objekt „Stuhl“ implementiert. Wird das zu 

erlernende Objekt wie in Abbildung A.5 (a) im Zentrum des Kamerabildes positioniert, kann über die 

t-Taste die Objekt-Trainings-Funktion gestartet werden. Wurde eine ausreichend große und charakteristische 

Region des Objekts markiert (siehe Abbildung A.5 (b)) kann die zugehörige Modellbeschreibung 

über die w-Taste abgespeichert werden. 

a) b) 

Abbildung A.5: Trainieren eines verschiebbaren Objekts im Locator. Bild (a) zeigt das zu trainierende 

Objekt im Zentrum des Bildes. In (b) ist die gefundene Region Weiß markiert. 

Die im Locator-Verzeichnis unter data/ abgelegte Modellbeschreibung enthält den Namen der wahrgenommenen 

Farbe des Objekts und die zur Erkennung notwendigen Histogrammwerte (siehe Abbildung 

A.6 (a). Das in Bild (b) gezeigte Form-Muster wird ebenfalls abgespeichert. 

a) b) 

Abbildung A.6: Histogramm und Forminformationen der Modellbeschreibung. In (a) sind die Histogrammwerte 

des gefundenen Stuhls dargestellt, Bild (b) zeigt das aus der gefüllten 

Region abgeleitete Form-Muster.

Literaturverzeichnis 

[1] Harris, C.; Stephens, M.: A Combined Corner and Edge Detector. In: M.M. Matthews, (eds.): 4th 

ALVEY vision conference, 147–151. University of Manchester, England, September, 1988 

[2] Matching with Invariant Features, 19. Oktober, 2005. 

Internetseite: http://www.wisdom.weizmann.ac.il/ deniss/vision_spring04/files/InvariantFeatures.ppt 

[3] Intel Corporation: Open Source Computer Vision Library, Reference Manual, 19. Oktober, 2001. 

Internetseite: http://www710.univ-lyon1.fr/ ameyer/devel/opencv/docs/opencvman_old.pdf 

[4] Zhang, Z.: Flexible Camera Calibration by Viewing a Plane from Unknown Orientations. In: 

ICCV, 666–673. 1999 

[5] Owens, R.: Epipolar geometry, 19. Oktober, 2005. 

Internetseite: http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/OWENS/LECT10/ 

node3.html 

[6] Bougnoux, S.: Learning Epipolar Geometry, 19. Oktober, 2005. 

Internetseite: http://www-sop.inria.fr/robotvis/personnel/sbougnou/Meta3DViewer/EpipolarGeo.html 

[7] Li, X.: Stereo Vision based Object Distance Estimation in 3D Environment Models. Diplomarbeit, 

Universität Stuttgart, 2005 

[8] Canny, J. Finding Edges and Lines in Images. Technical report, Cambridge, MA, USA, 1983 

[9] Fermüller, C.: Edge detection, 19. Oktober, 2005. 

Internetseite: http://www.cfar.umd.edu/ fer/cmsc426/lectures/edge1.ppt 

[10] Wyszecki, G.; Stiles, W. S.: Color Science. John Wiley & Sons, 1982 

[11] Ulrich, I.; Borenstein, J.: The GuideCane-applying mobile robot technologies to assist the visually 

impaired. IEEE Transactions on Systems, Man, and Cybernetics, Part A Vol. 31.2, 131–136 , 2001 

[12] Kalkusch, M. (eds.). Structured Visual Markers for Indoor Pathfinding, 2002 

[13] Chaitanya, V. K.: A Robotic Wayfinding System for the Visually Impaired 

[14] Kombrink, S.: Positionsbestimmung in Gebäuden auf der Basis von Sensordaten und Umgebungsinformationen. 

Diplomarbeit, Universität Stuttgart, 2005 

73

74 LITERATURVERZEICHNIS 

[15] Hub, A. und Teufel, H. in Jamal, R. and Jaschinski, H.,: Virtuelle Instrumente in der Praxis. Hüthig 

2003 

[16] Hub, A.; Diepstraten, J.; Ertl, T.: Augmented Indoor Modeling for Navigation Support for the Blind. 

In: International Conference on Computers for People with Special Needs, 54–59. Las Vegas, NV, 

USA, 2005 

[17] Rogler, U.: NAS Navigation Assistance System - Orientierungshilfe für Blinde. Diplomarbeit, 

Hochschule für Gestaltung Offenbach am Main, 2005 

[18] Lienhart, R.; Maydt, J.: An Extended Set of Haar-like Features for Rapid Object Detection. IEEE 

ICIP Vol. 1, 900–903 , 2002 

[19] Viola, P.; Jones, M. J.: Rapid Object Detection using a Boosted Cascade of Simple Features. IEEE 

CVPR Vol. 1, 511–518 , 2001 

[20] Adolf, F.: OpenCV´s Rapid Object Detection, 19. Oktober, 2005. 

Internetseite: http://terasu.cntl.kyutech.ac.jp/ nishida/opencv/OpenCV_ObjectDetection_HowTo.pdf 

[21] Bouguet, J.-Y. Pyramidal Implementation of the Lucas Kanade Feature Tracker Description of the 

Algorithm. Intel Corporation, Microprocessor Research Labs, 1999 

[22] Lucas, B. D.; Kanade, T.: An Iterative Image Registration Technique with an Application to Stereo 

Vision (IJCAI). In: Proceedings of the 7th International Joint Conference on Artificial Intelligence 

(IJCAI ’81), 674–679. April, 1981 

[23] Open Computer Vision Library, 19. Oktober, 2005. 

Internetseite: http://sourceforge.net/project/showfiles.php?group_id=22870&package_id=16937 

[24] Open Scene Graph, 19. Oktober, 2005. 

Internetseite: http://www.openscenegraph.org 

[25] Sanftmann, H.: Objekt Registrierung für AR-Anwendungen. Diplomarbeit, Universität Stuttgart, 

2005 

[26] OpenCV Library Documentation, 19. Oktober, 2005. 

Internetseite: http://www.cs.bham.ac.uk/resources/courses/robotics/doc/index.php 

[27] Hu, M.-K.: Visual pattern recognition by moment invariants. IEEE Trans. Inform. Theory Vol. 8, 

179–187 , 1962 

[28] Point Grey Research, 19. Oktober, 2005. 

Internetseite: http://www.ptgrey.com 

[29] Point Grey Customer Support Login, 19. Oktober, 2005. 

Internetseite: http://www.ptgrey.com/support/downloads/ps-downloads.html 

[30] Birchfield, S.; Tomasi, C.: Depth Discontinuities by Pixel-to-Pixel Stereo. Int. J. Comput. Vision 

Vol. 35.3, 269–293 , 1999 

[31] Schmidt Jensen, R.: Open source exporter from 3ds max to openscenegraph, 19. Oktober, 2005. 

Internetseite: http://osgexp.vr-c.dk/

LITERATURVERZEICHNIS 75 

[32] Hinterseher, M.: Schnittpunkt zweier Gerden, 19. Oktober, 2005. 

Internetseite: http://www.hinterseher.de/Diplomarbeit/GeometrischeFunktionen.html 

[33] Videre Design, 19. Oktober, 2005. 

Internetseite: http://www.videredesign.com/stereo_on_a_chip.htm 

[34] Hub, A.; Diepstraten, J.; Ertl, T.: Design of an Object Identification and Orientation Assistant for 

the Deafblind. In: 6th DbI European Conference On Deafblindness. Presov, Slovakia, 2005

Abbildungsverzeichnis 

2.1 Verhältnis von Eigenwerten an Kanten und Ecken . . . . . . . . . . . . . . . . . . . . . 4 

2.2 Kamerakalibrierung über Schachbrettmuster . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.3 Epipolarlinien nach [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.4 Disparitätsbild aus rektifizierten Einzelbildern . . . . . . . . . . . . . . . . . . . . . . . 7 

2.5 Gerade-zu-Punkt-Transformation zur Darstellung von vertikalen Geraden . . . . . . . . 9 

2.6 RGB-Würfel und HSV-Farbmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.7 Lab-Farben für verschiedene Luminanzwerte . . . . . . . . . . . . . . . . . . . . . . . 10 

2.8 Regiongrowing-Algorithmus zur farbtonbasierten Selektion . . . . . . . . . . . . . . . . 11 

2.9 Prototyp eines Navigationsassistenten mit integrierter Kamera und Inertialsensor . . . . 13 

2.10 Navigation Assistant System - Designstudie . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.1 Aufbau des Sensormoduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

3.2 Positionierung und Ausrichtung der virtuellen Kamera . . . . . . . . . . . . . . . . . . 19 

3.3 Berechnung der besten Positionsvariante . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.4 Abstandsmessung im Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

3.5 Messpunktauswahl anhand von erkannten Objekten . . . . . . . . . . . . . . . . . . . . 24 

3.6 Zuordnung von erkannten Linien zu Modellkanten . . . . . . . . . . . . . . . . . . . . 25 

3.7 Schnittpunkt von Diagonalen in langen Gängen . . . . . . . . . . . . . . . . . . . . . . 26 

3.8 Featurepunkte mit Wandabstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.9 Geschwindigkeitsvergleich zw. Messpunkt-Such-Verfahren . . . . . . . . . . . . . . . . 28 

3.10 Farbsegmentierung über Regiongrowing . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.11 Regiongrowing mit und ohne Berücksichtung der Tiefenunterschiede . . . . . . . . . . . 29 

3.12 Modellbeschreibung für einen roten Stuhl . . . . . . . . . . . . . . . . . . . . . . . . . 30 

3.13 Farbtöne des Histogramms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

3.14 Visuelle Ausgabe von Navigationshinweisen . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.15 Systemdesign des Navigationsassistenten . . . . . . . . . . . . . . . . . . . . . . . . . 33 

77

78 ABBILDUNGSVERZEICHNIS 

4.1 Testaufbauten zur Erfassung von Stereobildern . . . . . . . . . . . . . . . . . . . . . . 35 

4.2 Screenshot des entwickelten MFC-Programms zur Kalibrierung von Firewire-Kameras . 38 

4.3 MFC Programm zur Kalibrierung und Rektifizierung der Kameras . . . . . . . . . . . . 38 

4.4 Versuchsaufbau für Synchronitätstests . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

4.5 Zeitversatz zwischen Einzelbildern bei unterschiedlichen Kameras und APIs . . . . . . . 40 

4.6 Point Grey Bumblebee Stereokamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

4.7 Geschwindigkeitsvergleich zwischen OpenCV und Point Grey API . . . . . . . . . . . . 43 

4.8 Zur Navigationsunterstützung eingesetzter, modellierter Gebäudeabschnitt . . . . . . . . 45 

4.9 Anzeige verschiedener Hierarchiestufen des Gebäudes . . . . . . . . . . . . . . . . . . 46 

4.10 Osg Export Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.11 Darstellung des gerenderten 3D-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.12 Berechnungsschritte zur Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . 48 

4.13 Ermittlung des Wandabstandsschätzwertes . . . . . . . . . . . . . . . . . . . . . . . . . 49 

4.14 Schnittpunkt zweier Geraden im 2D-Raum, Quelle [32] . . . . . . . . . . . . . . . . . . 49 

5.1 Navigationsassistent bestehend aus Samsung x20 und Sensormodul . . . . . . . . . . . 53 

5.2 Abweichung der Abstandsmessung über Stereobilder der Bumblebee . . . . . . . . . . . 54 

5.3 Ergebnisse der Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

5.4 Ergebnisse der Positionsbestimmung in Wohnräumen . . . . . . . . . . . . . . . . . . . 58 

5.5 Distanzen zu lokalisierten Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

5.6 Performancemessung der Navigationssoftware . . . . . . . . . . . . . . . . . . . . . . . 61 

A.1 CamCalibrator - Programm zur Kalibrierung von Kameras . . . . . . . . . . . . . . . . 67 

A.2 StereoCam - Programm zur Kalibrierung und Rektifizierung von Kameras . . . . . . . . 68 

A.3 Raum-Auswahl-Diealog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

A.4 Locator Programmoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

A.5 Trainieren eines verschiebbaren Objekts im Locator . . . . . . . . . . . . . . . . . . . . 72 

A.6 Histogramm und Forminformationen der Modellbeschreibung . . . . . . . . . . . . . . 72

Erklärung 

Hiermit versichere ich, diese Arbeit 

selbständig verfaßt und nur die 

angegebenen Quellen benutzt zu haben. 

(Tim Hartter)

Schriftliche Ausarbeitung herunterladen

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?