Optical Tracking - Dokumentation zum Projekt
Projektteilnehmer
LaborprojektJörg Hoffman [joerg.hoffman@medien.uni-weimar.de]
Forschungsprojekt
Uwe Hahne [uwe.hahne@medien.uni-weimar.de]
Sebastian Knödel [sebastian@second.de]
Gordon Wetzstein [gordon.wetzsten@medien.uni-weimar.de]
Sebastian Schmidt [info@pixelsalat.de]
Inhalt
4.1 3D-Ortung
4.2 Verdeutlichung des Ablaufs
4.3 Ermittlung der extrinsischen Kameraparameter
4.4 Ermittlung der intrinsischen Kameraparameter
4.5 Bestimmung der Bildebene
4.6 Der Schnittpunkt der Geraden
1. Einleitung
nach obenIn diesem Projekt soll ein optisches Trackingsystem entwickelt werden, welches auf Basis von
verschiedenfarbigen Leuchtdioden und handelsüblichen FireWirecams arbeiten soll. Damit soll das
wesentlich teurere und in der Reichweite beschränkte elektromagnetische Trackingsystem ersetzt
werden können.
1.1 Ziel des Projekts
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.
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
1.2 Tracking
Tracking meint das Ermitteln und Verfolgen von Position und Rotation beliebiger Objekte. Es gibt verschiedene Arten,
gängige Kriterien zu deren Einteilung sind die Art der Technologie, die verwendet wird. So gibt es neben optischem
Tracking auch akustische, elektromagnetisch und mechanische Trackingmethoden.akustisches TrackingDie Position von Objekten wird mit Hilfe von Ultraschallwellen ermittelt. Solche Systeme werden z.B. als Sonar in
mechanisches Tracking
Ubooten eingesetzt. Aber auch in der Natur sind einige Tiere mit Sinnesorganen ausgestattet, die wie akustische
Tracker funktionieren. Wale und Fledermäuse senden hochfrequente Schallwellen aus, werden diese dann an Objekten
reflektiert kann das Tier anhand der Zeit vom Aussenden bis zum Eintreffen der reflektierten Schallwellen den Abstand
und somit die Position relativ zu seiner eigenen ermitteln.Vergleichbar mit dem haptischen Empfindungssystem beim Menschen funktionieren solche Trackingsysteme.
elektromagnetisches Tracking
Es muss eine physikalische Verbindung zwischen zu trackendem Objekt und Messinstrument geben, z.B. einen
beweglichen mechanischen Arm, der am Objekt befestigt ist. Bewegt sich nun das Objekt, so tut dies auch der Arm,
dessen Positionsveränderung dann gemessen wird.Die am meisen verwendeten aber auch relativ stark verzögerungsbehafteten Trackingsysteme sind elektromagnetisch.
optisches Tracking
Ein solches System besteht aus einem Transmitter, der ein Magnetfeld um sich herum aufbaut und kleinen Sensoren,
deren Position und Rotation in diesem Feld von einem Messgerät bestimmt werden kann. Diese Systeme werden auch
beim Illusionhole und virtual Showcase eingesetzt. Einen Nachteil stellt hier die relativ große Verzögerung und der
hohe Preis dar.Beim optischem Tracking werden zwei Arten unterschieden: passives und aktives Tracking.
Beim passiven werden Infrarotkameras, Infrarotleutdioden und Retroreflektoren verwendet. Die LEDs sind auf
den Kameras rund um das Objektiv angebracht, die Retroreflektoren am zu trackendem Objekt. Die LEDs blitzen
nun mit dergleichen Frequenz auf, in der die Kamera Bilder schiesst. Ein Vorteil der kugelförmigen Retroreflektoren
ist, das sie das Infrarotlicht fast ausschliesslich in die Einfallsrichtung wieder reflektieren, so erkennt jede Kamera
nur die von ihr beleuchteten Reflektoren. Der Nachteil dieser Kugeln ist ihre Unhandlichkeit, es sieht schon etwas
merkwürdig aus, wenn man eine Shutterbrille aufsetzt, an der drei grosse Antennen mit Kugeln daran befestigt sind.
Der wirkliche Vorteil solcher Systeme ist aber, dass keine störenden Farben des sichtbaren Lichts das Tracking negativ
beeinflussen.
Ein kommerzielles passives Trackingsystem mit Hard- und Software ist z.B. Vicon, das vor allem bei Film & Fernsehen
eingesetzt wird.
Ein nichtkommerzielles System wird derzeit an der Universität Augsburg von Klaus Dorfmüller entwickelt.
Die zweite und für uns umzusetzende Methode ist das aktive optische Tracking, bei dem in unserem Fall
selbstleutende farbige Leuchtdioden an den zu trackenden Objekten befestigt werden und diese mittels Kameras gefunden
werden müssen. Auf diese Methode und deren Probleme wird im später noch detaillierter eingegangen.
1.3 Vorgehensweise beim optischen Tracking
Um zu verstehen wie ein aktives optisches Trackingsystem mit LEDs funktioniert, soll an dieser Stelle kurz
die allgemeine Vorgehensweise beim Ermitteln der LEDpositionen beschrieben werden.
Zuerst müssen alle Kameras angesteuert werden und ein Zugriffsmechanismus für die Camera Capture Buffer
gefunden werden.
Der erste und wichtige Schritt ist die Kamerakalibrierung, die Kameras bestimmen ihre eigene Position und
Rotation im Weltkoordinatensystem.
Dies Kamerabuffer müssen nun mit geeigneten Algorithmen auf LEDs untersucht werden.
Aus der Menge der georteten LEDs werden die korrespondierenden LEDs jeder Kamera zugeordnet.
Wurden nun LEDs gefunden haben sie eine zweidimensionale Position auf den Kamerabildern, diese müssen nun
mit geeignetten Mitteln in das Weltkoordinatensystem umgerechnet werden.
Um die entgültige Position der LED zu bestimmen muss man nun den Schnittpunkt der Geraden, die durch Kameraposition
und LED in der Kameraebene gehen berechnen.
So ergibt sich eine Menge von georteten LEDs, aus der jetzt noch die entsprechenden Objekte extrahiert werden müssen.
2. Technologien
nach obenDa 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:
ToUCam der Firma Phillips 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 obenWie 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
in MByte/secDie 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.
- libraw1394
- 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.
Farbmodi der FireWire Cams
In unserer Trackingsoftware werden zwei Bildmodi (RGB, YUV411) und zwei Frameraten (15 bzw. 30 fps), die
die FireWire cams zur Verfügung stellen verwendet. Dadurch ergeben sich Kombinationen, die z.T. eine
unterschiedliche Anzahl von angeschlossenen Kameras zulassen.
YUV411*
*bei einer Bildauflösung von 640x480 Pixeln
Farbverlust bei YUV 4:1:1
Durch die Farbmodi entsteht aber auch ein mögliches Problem bei der LED Erkennung. Das YUV 4:1:1
Schema definiert vier verschiedene Helligkeitswerte (Y = 0,3*R + 0,59*G + 0,11*B) und jeweils einen
Blaudifferenz-Chrom (U = B - Y) und Rotdifferenz-Chroma (V = R - Y) Wert (also die eigentlichen
Farbinformationen) pro 4 Pixeln.Bevor der Camera Capture Buffer (Framebuffer der IEEE1394 Kameras)
nach LEDs durchsucht wird wird er falls der Farbmodus YUV 4:1:1 ist zuerst mit der schnellstmöglichen
Umrechnung aus dem ARToolKit in RGB umgerechnet, dabei gehen beträchtliche Farbinformationen verloren,
die zu einer ungenaueren LED Bestimmung führen. Deshalb ist für die Performance und Genauigkeit des
Trackes die beste Wahl eine Kombination von Framerate und Farbmodus 30 FPS (Frames per Second) und RGB.
Dies kann aber nur durch den Einsatz mehrerer FireWire ports erreicht werden.ARTolKit verwendet YUV 4:1:1, weil die Geschwindigkeit der Kameras so höher ist und weil sowieso nur
nach schwarz/weiss Markern gesucht wird, wir hingegen suchen nach farbigen LEDs.
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
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.2WebCams
nach obenAusgehend 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 oben2.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.
3. LED-Erkennung auf den Kamerabildern
nach obenFü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 schonbeschrieben, 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.
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.
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 obenDas 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 die
Tabelle 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.
4. Mathematische Grundlagen
nach oben4.1 Die 3D-Ortung
nach obenDas 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.
4.2 Verdeutlichung des Ablaufs
nach obenWir gehen davon aus, dass die Kameras dem Lochkameramodell entsprechen:
Wir berechnen die Bildebene und die Position der LED auf dieser:
Anschließend transportieren wir diese Ebene in das Weltkoordinatensystem:
Wir legen jeweils eine Gerade durch Kamerazentrum und Bildpunkt und suchen deren Schnittpunkt:
4.3Ermittlung der extrinsischen Kameraparameter
nach obenDie 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.
4.4 Ermittlung der intrinsischen Kameraparameter
nach obenHier 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.
4.5 Bestimmung der Bildebene
nach obenDiese 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.
4.6 Der Schnittpunkt der Geraden
nach obenAls 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.
Diese von zwei Parametern abhängige Gleichung ng wird nach jedem Parameter differenziert. Diese Ableitungen
werden gleich null gesetzt.
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.
5. Objektrekonstruktion
Bisher betrachteten wir nur die Positionsbestimmung der einzelnen LEDs, doch um ganze Objekte auch mit deren
Rotation tracken zu können ist es nötig aus der Menge der gefundenen LEDs die einzelnen Objekte zu rekonstruieren.
Diese Aufgabe ist ein NP Problem, also nicht ganz trivial. Die Objektrekonstruktion ist bisher nicht implementiert,
deshalb gibt es an dieser Stelle nur Lösungsansätze die noch umgesetzt und getestet werden müssen.Freiheitsgrade
Jedes Objekt muss mit mindestens 3 LEDs ausgestattet sein, um 6 Freiheitsgrade (Degrees of Freedom -DOF)
zu garantieren. Die Zahl der Freiheitsgrade kommt durch 3 Positions- (x, y, z) und 3 Rotationswerte
(der Winkel der Normalen in bezug auf die 3 Koordinatenachsen) zustande. Benötigt man mehr als 6 Freiheitsgrade
z.B. der Zustand eins Knopfs (gedrückt / nicht gedrückt) an einem Eingabegerät so gibt es entweder die Möglichkeit
mehr LEDs zu montieren oder eine LED mit variabler Farbe zu benutzen.Objektpool und Objektbeschreibung
Alle trackbaren Objekte müssen wärend des Betriebs des Trackers in einer Art Bibliothek (Objektpool) sein,
die dann vom Rekonstruktionsalgorithmus benutzt wird. Die eleganteste Möglichkeit diese Aufgabe anzugehen
ist die Objektbeschreibung nicht direkt in den Tracker zu integrieren, sondern einen Mechanismus zu entwerfen,
der beim Start des Trackers externe Objektbeschreibungdateien lädt. Damit wäre eine Neukompilierung beim Hinzufügen
eines neuen Objekts nicht nötig. Denkbar ist ein spezieller Ordner in dem das Programm zu Beginn nach solchen Dateien
sucht und alle lädt, kommt ein neues trackbares Objekt hinzu wird einfach eine .to (trackable object) Datei in diesem
Ordner erstellt. Um trackbare Objekte zu beschreiben wäre z.B. eine Art Markupsprache sinnvoll.
Eine solche Datei könnte so aussehen:shutterglasses.to
<trackable object><name>Dr. Schatter Brille</name></trackable object>
<avatar>shutterglass.obj</avatar>
<led><position>0.0, 0.0, 0.0</position></led>
<color>red></color>
<led>...</led>
<led>...</led>Der avatar ist die virtuelle Darstellung des Objekts.
Um solche Dateien in den Objektpool laden zu können müssen natürlich noch Fileparsing-Algorithmen implementiert
werden, was einen zusätzlichen Zeit- und Arbeitaufwand bedeutet, wäre aber sehr elegant.
6. Eingabegeräte
nach obenEin 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:6.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.6.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.6.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.6.4Brillen
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.
7. SETUPnach obenUm 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.7.1Aufbau
nach obenAn 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.
7.2Setup-Probleme
nach obenFü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.
8. trackIt vs ARToolKitnach obenUm 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-Programmesnach obenDas 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:
[KSK_CV98]: R.Klette, K.Schlüns, A.Koschan - Computer Vision Three-Dimensional Data from Images - Springer 1998
[Fau_3D93]: O.Faugeras - Three-Dimensional Computer Vision - A geometric viewpoint - MIT Press 1993
[Zhang98]: Z.Zhang - A Flexible New Technique for Camera Calibration
[Kalib01]: Paul Görtz: Kalibrationsverfahren von Videokamerasystemen
Links
Links zum Quellcode und der Developer-Dokumenation des Projektes
Human Technology Lab an der University of Washington
ARToolKit Website der University of Washington
ARToolKit Download Site
Die Studierstube ist ein Augmented Reality Project, das das ARToolKit bei seinen Entwicklungen häufig verwendet
Studierstube an der Universität Graz
Researchrsite der Studierstube
Developersite der Studierstube
Opentracker der Studierstube
nach oben
