Optical Tracking - Dokumentation zum Projekt

Dies ist die Dokumentation zum Projekt Optical Tracking.
Es wurde im Sommersemester 2002 von der Fakultät Medien der Bauhaus-Universität-Weimar angeboten.
Das Projekt wurde angeboten von der Professur Systeme der Virtuellen Realität und betreut von Prof. Dr. rer. nat. Bernd Fröhlich und Mitarbeitern.

0. Inhalt

1. Ziel des Projektes

1.1. Spezifizierung der Aufgabenstellung
1.2. Randbedingungen

2. Technologien

2.1. Busse

2.1.1. Vergleich USB-Firewire
2.1.2. Firewire
2.1.3. PCI-Bus

2.2. Webcams

2.3. ARToolKit

2.3.1. Was ist das ARToolKit
2.3.2. Arbeitsweise des ARToolKit
2.3.3. Farbmodi des ARToolKit

3. Mathematische Grundlagen

3.1. 3D-Ortung
3.2. Verdeutlichung des Ablaufs
3.3. Ermittlung der extrinsischen Kameraparameter
3.4. Ermittlung der intrinsischen Kameraparameter
3.5. Bestimmung der Bildebene
3.6. Der Schnittpunkt der Geraden

4. Eingabegeräte

4.1. LED-Greifer
4.2. LED-Drücker
4.3. LED-Stift
4.4. Brillen

5. Setup

5.1. Aufbau
5.2. Setup-Probleme

6. LED-Erkennung auf den Kamerabildern

7. trackIt vs ARToolKit

1. Ziel des Projektes

nach oben

In diesem Projekt soll ein optisches Trackingsystem entwickelt werden, welches auf Basis von verschiedenfarbigen Leuchtdioden und handelsüblichen Webcams arbeiten soll. Damit soll das wesentlich teurere und in der Reichweite beschränkte elektromagnetische Trackingsystem ersetzt werden können.

1.1. Spezifizierung der Aufgabenstellung

Das Erkennen und Tracken eines oder meherer Eingabegeräte, welche unter anderem für das Illusionhole benutzt werden können, soll mittels solcher, an diesem Gerät angebrachter, LEDs möglich sein.
Die Erkennung der LEDs soll mittels Softwareverarbeitung mehrerer Firewire-Kamera-Bilder erfolgen.

1.2. Randbedingungen

Folgende Randbedingungen sind bei der Bearbeitung des Problems zu berücksichtigen:

•   Erfassung und Auswertung der Kamerabilder müssen in einer akzeptablen Geschwindigkeit erfolgen (mindestens 25 Bilder/Sekunde)
•   die Kameras müssen handelsübliche Webcams sein
•   Eingabegerät soll mindestens 6 trackbare Freiheitsgrade besitzen
•   Eingabegeräte sollen möglichst drahtlos arbeiten, um die Bewegungsfreiheit der Benutzer nicht einzuschränken

2. Technologien

nach oben

Da eine Randbedingung für die Bearbeitung unseres Projektes das Benutzen von handelsüblichen, und damit preisgünstigen, Webcams ist, werden hier die Möglichkeiten dieser Aufgezeigt.

Im Moment werden die meisten Webcams für folgende beide Systembusse angeboten:

1.	USB	ToUCam der Firma Phillips
2.	Firewire	unibrain's Fire-i™ Digital Camera
		orange micro's iBOT FireWire Web Cam

Um die Leistungsfähigkeit der Kombination von Bus und Camera einschätzen zu können, mußten beide Busse als auch die Kameras in ihren Spezifikationen untersucht werden.

2.1. Busse

nach oben

Wie oben schon erwähnt, müssen zwei , im Moment übliche, Busse hinsichtlich ihrer Übertragunsgeschwindigkeiten untersucht werden: USB und FireWire.

2.1.1. Vergleich USB und FireWire

Bus	Übertragungsrate in MByte/sec	Treiber für Linux / Stadium
USB1.1	max 1,5 MByte/s	ja / experimental
USB2.0	480 Mbit/s	ja (erst Kernel 2.4.19)
IEEE1394a	max 50 MByte/s	ja / experimental
IEEE1394b	800 Mbit / s	nicht bekannt

Die Gesamt-Spezifikation des USB-Standards ist unter http://www.usb.org und die des Firewire-Busses unter www.1394ta.org genau nachlesbar. Für uns waren lediglich diese Details wichtig.
Aus diesen Angaben ist zu ersehen, daß ein guter Kompromiss aus Leistungsfähigkeit und Linux-Unterstützung der IEEE1394a-Standard ist.Aus diesem Grund und aus der Tatsache heraus, dass das ARToolKit (siehe unten), mit IEEE1394a funktioniert, haben wir uns für die Lösung Firewire-Kamera entschlossen.
Und deshalb wird nun auch die Firewire-Technologie noch etwas weiter untersucht.

2.1.2.

Hinter dem IEEE1394 Standart verbirgt sich eine Technologie, die für dieses Projekt wie geschaffen ist. FireWire (Apple) oder i.Link (Sony) ist ein serieller Hochgeschwindigkeitsbus, über den theoretisch bis zu 400 MBit/s übertragen werden können. Die IEEE1394 Geräte heißen auch nodes. Eine Besonderheit beim 1394 Standart ist, dass an einem Bus bis zu 16 solcher nodes seriell hintereinandergeschaltet werden können, der Abstand zwischen zwei nodes sollte jedoch nicht mehr als 4,5 m betragen, da sonst das Signal ohne einen entsprechenden Repeater zu sehr gedämpft würde. So kann man eine baumartige Struktur mit einer Gesamtlänge von bis zu 74 m aufbauen. Der IEEE1394 Bus unterstützt zwei verschiedene Datentransfermodi: asynchronous und isochronous data transfer. Für herkömmliche E/A Geräte ist der asynchrone Modus völlig ausreichend, für Multimediageräte wie z.B. Kameras ist es aber wichtig, immer eine feste Datenrate zu haben die vom System garantiert ist. Dies ist beim isochronen Transfermodus gewährleistet.

Die Sandart ist so ausgelegt, dass die Geräte über den Bus mit Strom versorgt werden können. Es gibt jedoch auch Controller, die z.B. in Notebooks eingesetzt werden, die keine Stromversorgung über den Bus ermöglichen. In diesem Fall muss das Gerät extern mit Strom versorgt werden.

FireWire ohne Stromversorgung

FireWire mit Stromversorgung

Die Entscheidung für unser optisches Trakingsystem IEEE1394 Kameras einzusetzen stand im Prinzip von Anfang an fest, wurde aber auch während des Semestern nie in Frage gestellt, da sich nicht zuletzt durch ARToolKit die Einsatzfähigkeit dieser Technologie gezeigt hatte.

Firewire-API

Es gibt zwei relevante Bibliotheken, die für die Entwicklung von IEEE1394 Software mit Kameraansteuerung unerläßlich sind.

1. libraw1394
2. libdc1394

Beide sind unter linux1394.sourceforge.net erhältlich.

libraw1394 ist die Low Level API, die direkte Ansteuerung von IEEE1394 Controller ermöglicht. Um auf 1394 devices zugreifen zu können muss für jeden port (host adapter) ein handle-Thread initiiert werden. Über diesen kann man dann direkt mit den angeschlossenen nodes kommunizieren.

libdc1394 ist eine auf libraw1394 aufgesetzte API, die zur Steuerung von IEEE1394 Kameras dient. Mit den dc1394 Funktionen kann man Kameras anweisen mit der Datenübertragung zu beginnen bzw. sie zu beenden, die Kamerafeatures auszulesen. Außerdem bietet diese API die Möglichkeit die Übertragungsgeschwindigkeit (100, 200 oder 400 MBit/s), die Framerate der Kamera (15 oder 30 Bilder/s) und den Bildmodus (RGB, YUV411, YUV422, ...) zu regeln.

2.1.3. PCI-Bus

Dieser Bus im inneren des Rechners, mit dem die Datenauswertung vollzogen werden soll, ist schon einige Jahre alt.
Daraus ergibt sich natürlich, dass die Spezifikation dieses Busses im Laufe der Zeit einigen Veränderungen und Erweiterungen unterworfen wurde.
Davon sollen hier kurz die Datenübertragungsraten angesprochen werden. Diese sind für unser Projekt deshalb so wichtig, weil wir mit mehr als einer Kamera arbeiten werden (müssen), um ein Eingabegerät immer sorgfältig von mindestens zwei Kameras erfassen zu können. Und die Datenraten auf dem internen Bus sollten kein Hindernis darstellen.
Hier also die Datenraten in Abhängigkeit der PCI-Spezifikationen:

PCI-Spezifikation	Busbreite (bit) / Busgeschwindigkeit (MHz)	Übertragungsrate (MByte/s)
32 Bit 1.0	32 bit / 33 MHz	125,89
64 Bit 2.0	64 bit / 33 MHz	251,77
32 Bit 2.1	32 bit / 66 MHz	251,77
64 Bit 2.1	64 bit / 66 MHz	503,54

Diese Tabelle zeigt sehr deutlich, dass die meistens Bits bei einer Bandbreite von 64 bit und einem Bustakt von 66 MHz über den PCI-Bus geschoben werden. Und dies sind theoretische 503 MegaByte pro Sekunde.
Wenn wir nun von einer tatsächlichen Bandbreite von ca. 80% der theoretischen Ausgehen, dann können wir bei PCI-Spezifikation 2.1, 64 bit Busbreite und unten angeführtem Bandbreitenbedarf einer Firewire-WebCam an einem solchen Bus maximal ca. 19 Kameras betreiben. Dies wäre für unsere Anwendung sicher erst einmal ausreichend.

Leider ließ sich kein FireWire-Adapter in der Kürze der Zeit besorgen, der nach diesem Standard arbeitet. Hätten wir einen gefunden, so hätte ebenfalls ein Rechner (Mainboard) besorgt werden müssen, welches einen 64bit breiten PCI-Bus besitzt. Und zu guter Letzt hätte Linux dieses Board und diesen Adapter auch noch unterstützen müssen. Alles in Allem entschieden wir uns dafür, einen Adapter nach PCI 1.0 zu verwenden. Einer, für den es für Linux Treiber gibt und der stabil läuft, ist der FireConnect4300 der Firma Adaptec.
Dieser ließ sich dann auch ganz gut benutzen. Nur leider konnte wir damit eine unserer Randbedingungen nicht einhalten. Die Framerate beim Verarbeiten dreier Kamerabilder sank auf wesentlich weniger als 30 fps pro Kamera. Als Echtzeitverarbeitung kann man dies natürlich nicht bezeichnen, aber unter den gegebenen Bedingungen war das schon ein gutes Ergebnis.

 

2.2. WebCams

nach oben

Ausgehend von den Bussen, die wir untersucht haben, entschieden wir uns für die Benutzung von Firewire-Webcams .
Da schon vor unserem Projekt mit dem ARToolKit gearbeitet wurde, waren schon Firewire-Kameras folgender Fabrikate vorhanden. So blieb uns das Testen verschiedener auf dem Markt erhältlicher Kameras erspart.
Vorhanden waren unter anderem folgende zwei Kamera-Typen:

iBOT FireWire Web Cam der Firma Orange Micro inc.

Fire-i™ Digital Camera der Firma Unibrain

Beide Kameras unterstützen YUV 4:1:1, YUV 4:2:2, YUV 4:4:4, and RGB 24-bit bei bis zu 30 Bildern pro Sekunde bei einer Auflösung von 640x480 Pixeln.
Der Vorteil der Fire-i™ besteht in der Möglichkeit der Stromversorgung dieser Kamera. Damit ist sie auch an oben beschriebene Firewire-Adapter ohne Stromversorgung anschließbar. Ein weiterer Vorteil dieses Kameratyps ist die Möglichkeit der Aufhängung mittels eines dreh- und kippbaren Clips. Somit ist diese Kamera von Ihren Möglichkeiten her für uns am besten geeignet.

2.3. ARToolKit

nach oben

2.3.1. Was ist das ARToolKit (Augmented Reality ToolKit)

Das ARToolKit ist eine Open Source C-Softwarebibliothek die es Entwicklern ermöglicht, einfache Augmented-Reality-Anwendungen zu programmieren. Augmented Reality (erweiterte Realität) bezeichnet eine Darstellung oder Projektion von virtuellen Objekten in den realen Raum auf einem Bildschirm. Entwickelt wurde es an der Hiroshima City University in Japan und dem Human Interface Technology Laboratory der University of Washington von Hirokazu Kato, Mark Billinghurst und Ivan Poupyrew. Dabei werden von Kameras übertragene Bilder analysiert und die relative Position und Orientierung derselbigen anhand von Markern berechnet. Dadurch ist es möglich, auf eben solche Marker virtuelle Objekte zu projezieren. Dies können zum Beispiel drei- bzw. zweidimensionale Bilder oder Figuren sein:

2.3.2. Arbeitsweise des ARToolKit

Es wird ein virtueller Raum aufgespannt in dem der Marker den Koordinatenursprung bildet. An diesem Marker kalibriert sich die Kamera. Danach wird das Livebild der Kamera in ein schwarz/weiß Bild umgewandelt und anhand der Helligkeitswerte nach Quadraten durchsucht. Der Inhalt aller gefundenen Quadrate wird dann nach speziellen Mustern (AR tracking marker) analysiert, falls ein Marker erkannt wurde, können Position und Orientierung der realen Kamera bezüglich des realen Markers berechnet werden. Die Werte werden als Extrinsische Parameter bezeichnet und in einer 3x4 Matrix abgelegt. Die ersten 9 Werte (3x3) stellen die Rotation der Kamera bzgl. des Koordinatenursprungs dar. Sie wird als Rotationsmatrix bezeichnet. Die anderen 3 Werte (1x3) geben die Kameraposition im Raum an, sie wird als Translationsmatrix bezeichnet. Für die Projektion von dreidimensionalen Objekten wird die OpenGl API verwendet:




Die Arbeitsweise des ARToolkit in einer Grafik dargestellt:




Startet man im Verzeichnis './examples/exview' die ausführbare Datei exview wird das gerade Beschriebene deutlicher, auf den Marker wird ein virtuelles Koordinatensystem projiziert. Am unteren Bildrand wird die Position der Kamera relativ zum Marker angegeben.

2.3.3. Farbmodi des ARToolKit

In der Software werden zwei Bildmodi (RGB, YUV411) und zwei Frameraten (15 bzw. 30 fps) verwendet. Dadurch ergeben sich Kombinationen, die z.T. eine unterschiedliche Anzahl von angeschlossenen Kameras zulassen.

Bildmodus	Framerate	Datenvolumen pro Kamera	Anzahl Kameras pro port
RGB*	15	106 MBit/s	2
RGB*	30	211 MBit/s	n.a.
YUV411*	15	53 MBit/s	3
YUV411*	30	106 Mbit/s	2

*bei einer Bildauflösung von 640x480 Pixeln

3. Mathematische Grundlagen

nach oben

3.1. Die 3D-Ortung

nach oben

Das Problem ist es anhand von Pixelkoordinaten eines bestimmten Punktes seine Position im Raum zu berechnen. Das Prinzip ist eigentlich ganz einfach. Man ermittelt zuerst die Position der Kameras im Raum. Der nächste Schritt ist es mit Hilfe von ein paar Parametern der Kamera, wie in erster Linie die Brennweite, die Lage des aufgenommenen Kamerabildes im Raumm zu bestimmen. Nun legt man jeweils eine Gerade durch die entsprechenden Bildpunkte und der Schnittpunkt dieser Geraden ist der Raumpunkt der LED. Im folgenden wird der mathematische Hintergrund dieses Verfahren genauer beschrieben.

3.2. Verdeutlichung des Ablaufs

nach oben

Wir gehen davon aus, dass die Kameras dem Lochkameramodell entsprechen:

(Quelle: http://ais.gmd.de/projects/Makro/reports/makro-report-VI-1.pdf,S.10,01.08.2002)

Wir berechnen die Bildebene und die Position der LED auf dieser:

(Quelle: http://www.icg.tu-graz.ac.at/~Education/Diplomarbeiten/1998/augsten/thesis.pdf,S.17, 01.08.2002)

Anschließend transportieren wir diese Ebene in das Weltkoordinatensystem:

(Quelle: http://www.icg.tu-graz.ac.at/~Education/Diplomarbeiten/1998/augsten/thesis.pdf,S.19,01.08.2002)

Wir legen jeweils eine Gerade durch Kamerazentrum und Bildpunkt und suchen deren Schnittpunkt:

3.3. Ermittlung der extrinsischen Kameraparameter

nach oben

Die extrinsischen Kameraparameter sind die Position und die Ausrichtung der Kamera. Es sind jeweils drei Parameter, je einer für die drei Dimensionen. Für die Ermittlung der Kamerapositionen kamen mehrere Verfahren in Betracht. Als erstes war die Idee einer festen Installation der Kameras und eine einfache Abmessung der Positionen. Diese Idee wurde schnell verworfen, weil eine genaue Installation der Kameras sehr aufwendig und ungeschickt gewesen wäre, und sie hätte das ganze System stationär gemacht. Wir wollten aber eine Lösung, bei der wir die Kameras einfach aufbauen und per Software ihre Position ermitteln können. Diesen Vorgang nennt man Kalibration der Kameras, und er wird von Experten als der komplizierteste Schritt angesehen, weil man sehr präzise sein muss, wenn man genaue Ergebnisse erreichen will. Ähnliche Projekte benutzten Tafeln mit Quadraten. Diese werden von den einzelnen Kameras aufgenommen und anhand der Verzerrung im Bild kann man die Kamerapsition errechnen. Dies war für unser Projekt aber ungeeignet, weil wir nur LEDs tracken können. Wir überlegten eine Platte herzustellen auf der 11 LEDs angebracht wären deren Position uns genau bekannt ist. Mit Hilfe des Algorithmus von Tsai [KSK_CV98] könnte man alle Parameter der Kamera bestimmen, allerdings sind eben 11 bzw. mindestens sieben nach Tsai, bekannte Parameter nötig, um die elf Unbekannten zu ermitteln. Diese elf Unbekannten sind die sechs erwähnten extrinsischen Parameter und hinzu kommen noch fünf intrinsische. Zu den intrinsischen Parametern später mehr.

Eine Alternative zu dem Algorithmus von Tsai ist die Methode von Zhang [Zhang98], die uns auch von Experten empfohlen wurde.

Wir entschlossen uns aber dazu, eine zwar sehr ungenau, aber dafür sehr bequeme Variante zu nehmen; das ARToolKit. Im ARToolKit muss auch die Position der Kamera anhand eines Markers berechnet. Im Beispielprogramm "exview" wird die Position ausgegeben. Wir entschieden uns dafür dieses Programm so umzuändern, dass wir einfach die Position der Kamera und ihre Ausrichtung auslesen und an unser Programm übergeben. Diese Variante erwies sich als einfach zu implementieren.

3.4. Ermittlung der intrinsischen Kameraparameter

nach oben

Hier kam es zu Problemen, die wir sehr einfach umgangen sind. Die Literatur beschreibt diese Parameter sehr unterschiedlich, deshalb haben wir auch zwei Wege ausprobiert. Zuerst haben wir auch hier die Lösung des ARToolKit genutzt. Das ARToolKit hat diese Parameter in einer Datei stehen. Dies erschien uns zuerst merkwürdig, aber die Parameter sind fest und nur von der Kamera abhängig, genauer gesagt, sogar nur vom CCD-Chip der Kamera, und da dieser bei sehr vielen Kameras baugleich ist, wird vom ARToolKit nur erkannt mit welchem CCD-Chip gearbeitet wird und dann werden die entsprechenden Parameter ausgelesen. Die Parameter werden in einer Matrix ausgegeben, die in der Form der Projektionsmatrix aus der Literatur [Fau_3D93] entspricht.

Wir setzen die z-Koordinate des Punktes auf eine geschätzte Brennweite und multiplizieren diesen Punkt als Vektor mit der Matrix die das ARToolKit als intrinsische Parameter ausgibt. Die Schätzung der Brennweite erfolgte durch die Darstellung des Punktes in einer OpenGL-Szene und auslesen des besten Wertes durch probieren. Einen festen Wert gab es nicht, weil die Brennweite für die von uns verwendeten Kameras variabel ist. Den erhaltenen Vektor multiplizieren wir noch mit der Rotationsmatrix und subtrahieren den Translationsvektor der jeweiligen Kamera. Diese Herangehensweise ist der Art und Weise, die Olivier Faugeras in [Fau_3D93] beschreibt, nachempfunden. Faugeras beschreibt den Aufbau einer Fundamentalmatrix, die komplette Umrechnung von Pixelkoordinaten in eine Raumgerade projektiver Darstellung. Dieses Verfahren haben wir folgendermaßen vereinfacht. Faugeras beschreibt Schritt für Schritt wie sich diese Fundamentalmatrix aufbaut.
Als erstes ist nur die Brennweite darin enthalten.

Dann wird diese Matrix mit einer Matrix der weiteren inneren Parametern multipliziert.

3.5. Bestimmung der Bildebene

nach oben

Diese Matrix hat den gleichen Aufbau, wie die des ARToolKit, deshalb haben wir sie hier eingesetzt. Um im Falle einer Fehleinschätzung dieser Matrix das ganze übersichtlicher zu gestalten, haben wir dann nicht wie von Faugeras beschrieben diese Matrix immer weiter auch mit denden extrinsischen Parametern multipliziert, sondern die weiteren Schritte einzeln implementiert, und die Pixelwerte Schritt für Schritt weiter verrechnet, so dass nach jedem Schritt eine Kontrolle möglich ist. Außerdem habe wir die Dimensionen der Matrizen so gekürzt, dass wir wir im euklidischen und nicht im projektiven Raum rechnen. Im projektiven Raum hätte unser Bildpunkt vier Koordinaten gehabt, was bedeutet, dass er nicht eindeutig als Punkt dargestellt wird, sondern als Gerade im projektiven Raum. Dies ist eigentlich geschickter da wir schliesslich den Schnittpunktunkt dieser Geraden als den Raumpunkt der LED orten wollen. Wir entschlossen uns aber uns mathematisch im euklidischen Raum zu bleiben, da wir ein sehr geschicktes Verfahren anwenden um den Schnittpunkt der Geraden zu zu entdecken. Dazu später mehr. Wir erhalten also als Ergebnis einen Bildpunkt auf der Bildebene die im selben Raum liegt, wie der zu errechnende Punkt. Wir legten also nun eine Gerade durch diesen und das jeweiligeige Kamerazentrum und suchten deren Schnittpunkt. Die zweite und die erfolgreichere Herangehensweise ist es, einerseits die Schritte, wie sie in [Kalib01] beschrieben, werden zu vereinfachen und sie auszuführen. Und andererseits die benötigten intrinsischen Parameter auszurechnen und die uns unbekannten zu vernachlässigen, weil sie die Ergebnisse nur leicht präzisieren. Die Vereinfachung liegt darin, dass wir die Linsenverzerrung nicht mitbetrachtet haben. Die Brennweite musste auch hier geschätzt werden. Die Schritte laufen wie folgt ab:



Cx, und Cy sind die Koordinaten des Bildhauptpunktes, also in unserem Fall 320,240. dx und dy sind die Abstände der Pixel auf dem Bild in der Bildebene. Diese lassen sich Hilfe der Sichtwinkel der Kameras und der Brennweite grob bestimmen. Der Abstand der Pixel beträgt Brennweite durch Tangens des entsprechenden Winkels (horizontal oder vertikal) und dies dann nochmal durch die Anzahl der Pixel auf dem Bild in dieser Richtung. Wir waren uns nicht sicher ob die angegeben Winkel den gesamten Ausstrahlungswinkel angeben, oder nur den halben. Im Programm kamen wir mit einer Verdopplung der errechneten Werte auf die besten Ergebnisse.
Die Linsenverzerrung Kappa haben wir,wie erwähnt, weggelassen, also auf 1 gesetzt.

Man erhält einen Punkt im Raum, den man nun noch auf die Bildebene projezieren muss. Dies ist im benutzten Dokument auch beschrieben. Man multipliziert den Punkt mit der Rotationsmatrix und subtrahieren den Transformationsvektor, welche wir jeweils aus dem ARToolKit auslesen.

3.6. Der Schnittpunkt der Geraden

nach oben

Als einfachste Lösung erschien uns einfach das Verfahren anzuwenden, welches man aus der linearen Algebra kennt, das Gleichsetzen der Geraden. Uns fiel auf, dass dies nicht möglich ist, da sich die Geraden aufgrund der gewissen Ungenauigkeit, die teils durch unsere Schätzungen und teils durch ganz normale numerische Rundungen auftauchen, meistens gar nicht schneiden. Also suchen wir nach dem minimalen Abstand der Geraden. Die lineare Algebra liefert auch hier nur eine unbefriedigende Lösung, die nur den Abstand der Geraden, jedoch nicht die Punkte minimalen Abstands liefert. Also stellt man eine Gleichung auf, die den Anstand der Geraden im Quadrat in Abhängigkeit zweier Parameter bzw. zweier Punkte auf den Geraden liefert.

(Quelle: http://marvin.sn.schule.de/~mathe/dateien/ma_os/windsch.pdf,S.1, 01.08.2002)

Diese von zwei Parametern abhängige Gleichung ng wird nach jedem Parameter differenziert. Diese Ableitungen werden gleich null gesetzt.

(Quelle: http://marvin.sn.schule.de/~mathe/dateien/ma_os/windsch.pdf, S.1, 01.08.2002)

Daraus ergeben sich zwei Gleichungen mit zwei Unbekannten, die wir eindeutig lösen können. Die Lösungen der gleichen ergeben die Parameter, die die Punkte minimalen Abstands der beiden Geraden bestimmen.

Als Raumpunkt wählen wir einfach den Punkt, der in der Mitte dieser beiden Punkte liegt.

4. Eingabegeräte

nach oben

Ein weiterer Schritt zur Lösung der Aufgabe war der Entwurf möglicher Eingabegeräte , die aus der Aufgabe selbst resultieren.
Bis heute hat man ein elektromagnetisches Trackingsystem mit dem man alle Freiheitsgrade und zusätzlich den Zustand des Manipulierens eines Objektes (Drücken eines Knopfes) darstellen konnte. Bei diesem Trackingsystem sind alle benötigten Geräte (Shutterbrillen, Eingabestifte) mit EM-Detektionsspulen ausgestattet. Diese sind mittels Kabel mit dem System verbunden. Dieser erste Nachteil wird durch weitere Nachteile verstärkt. Es gibt nur eine geringe Reichweite, in der das Tracken gut funktioniert. Außerdem stört jedes elektromagnetische Feld oder auch nur ein magnetischer Gegenstand die Erkennung der Positionen der Geräte sehr.
Aus diesen Gründen mußten neue Konzepte erdacht werden, wie ein Eingabegerät aussehen und handhabbar sein muss, damit das Erkennen und die Usability mindestens gut sind.
Dabei sind folgende Studien in Zusammenarbeit mit den Gestaltern des Projektes "Virtuelle Vitrine" entstanden:

4.1. LED-Greifer

nach oben

Dieses gerät ist ein Eingabegerät, welches ein gewisses haptiles Feedback liefert.
Es besteht aus einem Plexiglas-Bogen, der durch Warmverformung eine gewisse Spannung bekommen hat. An diesem sind, ebenfalls aus Plexiglas geformte, Halteringe angebracht. In diese sind die Finger einer Hand ( Daumen und Mittel-/Zeigefinger ) in oben gezeigter Art und Weise zu stecken.
Am Gerät angebracht sind vier LEDs. Je zwei dieser bilden eine Achse. Damit ist es möglich, in einer VR-Umgebung direkt auf ein Objekt zu zeigen (Verlängerung dieser zwei Achsen) und dieses intuitiv (wenn die Finger des Benutzers sich berühren) anzufassen und zu manipulieren. Der Zustand des Erfassens eines virtuellen Objektes wird also durch das Berühren der verlängerten, durch die LEDs aufgespannten, Achsen erzeugt. Alle anderen Freiheitsgrade sind durch dieses Gerät und die zwei erzeugten Achsen natürlich auch darstellbar.

4.2. LED-Drücker

nach oben

Bei diesem Eingabegerät, welches in Zusammenarbeit mit Regine Kirsch entstanden ist, ist es ebenfalls möglich, ein gewisses haptiles Feedback zu bekommen. Die beiden Bilder auf der linken Seite zeigen das Gerät im Prototypenzustand. Dabei gibt ein gebogener Kunststoffschlauch die Möglichkeit, ein Gefühl des "Anfassen eines virtuellen Objektes" wenigstens zu simulieren (dabei wird ein Taster betätigt, der die Farbe der unteren LED umschaltet). Auch bei diesem Eingabegerät werden alle Freiheitsgrade durch Kameras erfassbar, da wir hier die oberen zwei LEDs für das Erkennen einer Längsachsendrehung benutzen und der Mittelpunkt zwischen diesen und der unteren LED gibt uns die Längsachse. Die zwei Bilder auf der rechten Seite zeigen eine aus Kunststoff gegossene erweiterte Form dieses Drückers und zwei der möglichen Bewegungszustände.

4.3. LED-Stift

nach oben

Dieser Eingabestift ist in der Form dem Eingabegerät des elektromagnetischen Trackingsystems nachempfunden. Außerdem ist diese From eine der gebräuchlichsten Formen überhaupt (wer hat in seinem Leben noch keinen Stift in der Hand gehabt). Mit diesem LED-Stift ist es möglich, die Freiheitsgrade ausser der Längsachsendrehung zu erkennen. Für letzteres sind uns zwar zahlreiche Ideen in den Sinn gekommen, doch zum Ausprobieren und damit zum Testen, welche wirklich praktikabel ist, hat leider die Zeit nicht mehr gereicht. Einige der Ideen sind: ein Muster quergestreifter Linien auf der Verbindungsachse zwischen den beiden LEDs (rund um den Stift herum), eine dritte LED auf selbiger Längsachse, eine dritte und vierte LED etwas nach aussen von der Achse weg versetzt, usw. Der Zustand des "Greifens" eines virtuellen Objektes wird, wie oben auch, mit Hilfe einer zweifarbigen LED verwirklicht, deren Farbe sich mittels eines Tasters umschalten lässt.

4.4. Brillen

nach oben

Auch die Brillen müssen in dieser Art und Weise mit LEDs ausgestattet werden, damit sie mit den Kameras erkannt werden können. So entschieden wir uns, eine Anordnung von 3 LEDs am den Rahmen der Brillen zu befestigen. Wenn nun mindestens zwei Kameras jede einzelne Brille sehen, dann ist deren Position imRaum eindeutig feststellbar.

5. SETUP

nach oben

Um alle Brillen und die Eingabegeräte von möglichst wenigen Kameras erfassen zu können, haben wir uns ein Setup überlegt, welches wir zum Testen der bestmöglichen Kameraanordnungen benutzen können.
Dazu gehören Ständer, die frei beweglich sind. An je einem der Ständer ist eine Kamera vertikal verschiebbar angebracht. Somit können wir die Kameras und deren Positionen zueinander frei im Raum verändern. Außerdem ist jede Kamera über ein drei Meter langes Firewire-Kabel an den Hostadapter am Rechner angeschlossen.

5.1. Aufbau

nach oben

An folgenden Bildern soll der Aufbau des Setups kurz erklärt werden.

Diese Skizzen sollen eine Art des Aufbaus darstellen.
Bei dieser Art der Kameraanordnung benötigt man sichtlich nur drei Kameras. Davon ausgehend, daß die User Rechtshänder sind, wird die Kamera 1 hinter der linken Schulter oberhalb des Rumpfes postiert (im anderen Fall würden Linkshänder die Kamera über ihrer linken Schulter durch diese verdecken, die Kamera müßte auf die linke Seite verschoben werden). Die Kamera 3wird gegenüber Kamera 1 postiert. Diese beiden Kameras sollen jeweils die gegenüberliegende Brille sowie das Eingabegerät des Gegenüber tracken. Die Kamera Nummer 2 befindet sich mittig der beiden anderen Kameras im Winkel von ca. 90 Grad zum Blickwinkel von Kamera 1 und 3. Diese dritte Kamera soll sowohl die Eingabegeräte der User als auch die Brillen der User tracken (leider ist der Winkel, den die Optik der Webcams hergeben, siehe oben). Man müßte bei dieser Kamera also eine Weitwinkel-Vorsatzlinse benutzen, so daß ein größeres Blickfeld der Kamera möglich ist.

5.2. Setup-Probleme

nach oben

Für das Erkennen der zwei Brillen und der Eingabegeräte hätten wir also eigentlich mindestens vier Kamera benötigt. Nur leider ließ die Geschwindigkeit beim "Capturen" der Bilder schon bei drei Kameras an einem Hostadpater so stark nach, daß wir damit erst einmal zufrieden sein mußten. Der zweite Adapter im Rechner ließ sich unter Linux einfach nicht zum Mitarbeiten bewegen.
Eine Fehlfunktion der im Pool vorhandenen Hardware kann als Grund ausgeschlossen werden, da alle Karten einwandfrei funktionieren, wenn sie als erster Adapter identfiziert werden. Es ist außerdem möglich Kamerafeatures auszulesen und die Datenübertragung zu starten. Das Problem liegt eindeutig bei der Funktion dc1394_dma_single_capture(), die einen sofortigen Programmabsturz verursacht. Die Ursache dieses Fehlers liegt also höchstwahrscheinlich bei der libdc1394 Bibliothek, die sich ebenso wie die gesamte IEEE1394 Unterstützung unter Linux noch in der Entwicklung befindet.

6. LED-Erkennung auf den Kamerabildern

nach oben 

Für die exakte Berechnung der 3D-Punkte im realen Raum werden zuerst exakte 2D Koordinaten der benutzen LED's auf den jeweiligen Kamerabildern benötigt. Wie schon beschrieben, strahlen die LED's leider nicht nur eine sondern gleich ein ganzes Spektrum von Farben ab.

Dieses muss nun auf dem Kamerabild gefunden werden, dazu wird Zeilenweise das Kamerabild geparsed und nach Pixeln gesucht die in einem, der für die zu findenden LED's, bestimmten Farbbereich liegen. Der Farbbereich ist durch R,G,B Werte und dazu gehörige R,G,B Farbabstände gekennzeichnet.
Falls nun so ein Pixel gefunden ist wird überprüft ob es in der Nähe schon weitere Pixel des gleichen Farbbereiches gab und dieser dann einer schon möglicherweise gefundenen Pixelhaufen gleichen Farbbereiches zugewiesen, falls in der Nähe bis jetzt keine ähnlichen Pixel gefunden wurden so wird ein neuer Pixelhaufen "angefangen". Im Bild 3 veranschaulicht sieht man das ein Pixel der zu einem schon bestehenden Pixelhaufen dazugehören soll sich im inneren (grünen) Rahmen befinden muss. Damit er aber einen neuer Pixelhaufen angefangen werden kann muss sich der Pixel ausserhalb des roten Rahmens befinden, d.h. es muss ein bestimmter Mindestabstand zwischen den LED's eingehalten werden um Verwechsellungen zu vermeiden.

Hier sind die gefunden Pixel Rot eingefärbt und die maximale Ausdehnung durch die grünen Linien sichtbar gemacht

Da leicht Reflektionen an spiegelnden Flächen auftreten können, und diese auch im Parsevorgang als mögliche LED's gefunden werden, werden nach Beendigung desselben die gefundenen Pixelhaufen auf die Anzahl der dazugehörigen Pixel untersucht. Denn erst ab einer bestimmten Anzahl an Pixeln wird der Pixelhaufen als gefundene LED gewertet. Aus der Ausdehnung der gefunden Pixel kann man nun den Mittelpunkt der gefundenen LED berechnen und diesen weiter an die 3D-Positionsberechnung weitergeben.

Bild 3

Im folgenden Bild wird nun die Ledposition aus dem vorhergehenden Bild benutzt um die LED wiederzufinden dazu wird um die vorherige Position ein Feld gelegt und dieses nach Pixeln der bestimmten Farbbereiche untersuchen. Der Inhalt des roten Rahmens wird durchsucht und ggf. die Pixel der LED wiedergefunden. Falls bei diesem Vorgang nicht alle zuvor angegebenen LED's gefunden (durch zu schnelle Bewegung)wurden so wird das Bild nochmals durchsucht. Eine Möglichkeit dieses zu verbessern wäre eine Implementation das die Pixel über die Epipolar-linie gesucht werden, wenn die LED schon auf dem Bild einer anderen Kamera gefunden wurde.

Probleme und mögliche Verbesserungen

nach oben

Das erste Problem ist uns schon beim Kalibriern der Farbwerte einer LED aufgefallen. Dies betrifft das ungleichmässige Emissionsverhalten der LEDs. Keine der von uns benutzten LEDs hatte ein eindeutiges Leuchtfeld vorzuweisen. Wie dieTabelle unten zeigt, haben alle LEDs bestimmte Farbwerte in bestimmten Regionen des Lichtes vorzuweisen. Dabei kommt es zu starken Schwankungen zwischen den verschiedenen Typen.

Zur Verdeutlichun der benutzten RGB-Werte wurden diese hier rot eingefärbt. Dabei haben wir schon eine Toleranz von max 50 Werten pro Farbe zugelassen, damit überhaupt genug Farbewerte für die Erkennung der LED übrig bleiben. Aus dieser Erkenntnis heraus ist zu sagen, daß es nicht möglich ist, ein und dieselbe LED aus verschiedenen Blickwinkeln eindeutig und zuverlässig zu bestimmen.
Anstelle der Suche nach bestimmten Pixeln mit bestimten Farbbereichen, könnte man die LED-Suche über ein Histogramm gestalten. In diesem Histogramm werden die Häufigkeiten der verschiedenen auftretenden Farben gespeichert. So wird zum Anfang jeder Session oder bei der Einführung einer neuen LED ein Histogramm erstellt und das Bild nun Anhand dieses Histogramms durchsucht. Diese Art der LED-Suche in einem Bild sollte dann genauer und zuverlässiger Funktionieren.
Auch könnte man andere LEDs benutzen. Diese müßten ein gleichmäßigeres Leuchtfeld besitzen. Unsere LED-Typen besaßen dies nicht.

7. trackIt vs ARToolKit

nach oben

Um Objekte mit Hilfe von Kameras optisch tracken zu können, muss ein dreidimensionaler Raum aufgespannt und die relative Position bzw. Ausrichtung der Kameras, bezüglich des Koordinatenursprungs dieses Raumes, bestimmt werden. Genau diese Berechnungen sind im ARToolKit bereits implementiert, daher nutzen wir diese Funktionen für unsere Implementation zur Bestimmung der notwendigen Parameter. Jede Kamera bestimmt mit Hilfe eines Markers, der den Ursprung bildet, ihre Orientierung (Rotation) und Position (Translation). Im trackIt-Programm wird für jede Kamera die Markererkennung sowie die Berechnung der Extrinsischen und Intrinsischen Parameter im ARToolkit aufgerufen, ansonsten werden keinerlei andere Funktionen verwendet. Das ARToolKit dient also ausschließlich zur Kalibrierung der Kameras. Deutlich vorteilhafter wäre es, die extrinsischen und intrinsischen Parameter selbstständig zu bestimmen, im Moment lag jedoch die Nutzung des ARToolKits am nächsten, da es in der Lage ist, mit beliebigen Kameras, Skalierungsfaktoren und Brennweiten zu arbeiten. Leider ist jedoch die Bestimmung der Parameter durch das ARToolKit nicht sonderlich zuverlässig.
Haben die Kameras unterschiedliche Abstände zur z-Achse (steht senkrecht auf dem Marker, blaue Achse im exview-Bild), dann wird die Skalierung sehr ungenau und die Berechnung daher ebenso. Weiterhin funktioniert die Markererkennug bei zu starker Helligkeit sehr schlecht beziehungsweise gar nicht. Ausserdem ist nur schwer nachvollziehbar, welche mathematischen Vorgehensweisen im ARToolKit verwendet wird. Aufgrund dieser Umstände haben wir uns mit Mark Billinghurst in Verbindung gesetzt, bis zu diesem Zeitpunkt jedoch keinerlei, für uns verwertbare, Informationen erhalten.

Ausgabe des trackIt-Programmes

nach oben

Das Programm trackIt, welches von uns entwickelt wurde, hat unten stehende Ausgaben.

Im ersten Bild ist deutlich ein Marker des ARToolKit zu sehen. Dieser wird, wie oben schon beschrieben, zur Ermittlung der Kameraparameter mittels ARToolKit benötigt.
Wir sehen also drei Kamerabilder mit dem Marker und rechts unten ist die OpenGL-Szene, die uns unsere berechneten Kamera-Positionen und den, aus "exview" bekannten Koordinatenursprung.





Hier sehen wir nun eines unserer Eingabegeräten den LED-Stift, wie er von drei Kameras gleichzeitig aufgenommen wird.



Abschliessend ist zu sagen, dass die Kalibrierung der Kameras nicht mit dem ARToolKit erfolgen , sondern mit Hilfe des Tsai oder Zhang Algorithmus selbstständig entwickeln werden sollte.

Literatur:

Links

Links zum Quellcode und der Developer-Dokumenation des Projektes

nach oben