Institut fu¨r Informatik und Praktische Mathematik der Christian-Albrechts-Universit¨at zu Kiel Multimediale Systeme zur Informationsverarbeitung Prof. Dr.-Ing. Reinhard Koch

Entwicklung einer orientierungssensitiven Kamera zur Erstellung von Panoramabildern

Diplomarbeit Jan-Friso Evers Betreuer: Dipl.-Inf. Jan-Michael Frahm 25. Juni 2001

Inhaltsverzeichnis 1 Einleitung

1

2 Orientierungsinformationen 2.1 Orientierungssensoren . . . . . . . . . 2.1.1 Struktur des USB-Subsystems 2.1.2 Die USB-Event Kette . . . . . 2.1.3 Das Itrax-Modul . . . . . . . 2.2 Eigenschaften des InterTrax2 . . . . 2.2.1 Impulsantwort . . . . . . . . . 2.2.2 Filter . . . . . . . . . . . . . . 2.2.3 Mittelwertfilter . . . . . . . . 2.2.4 Drift . . . . . . . . . . . . . . 3 Aufnahme von Videodaten 3.1 Aufnahmetechnik . . . . . . . . 3.1.1 Die Brennweite . . . . . 3.2 Struktur des Video-Subsystems 3.2.1 Anforderungen . . . . . 3.2.2 Verwendete Kameras . . 3.2.3 Messung der Videolatenz

. . . . . .

4 Video-/Tracker-Kombination 4.1 Online-Zusammenf¨ uhrung . . . . 4.2 Offline-Zusammenf¨ uhrung . . . . 4.3 Zusammenf¨ uhrung via Ringpuffer 4.4 Hand-Eye-Calibration . . . . . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

. . . . . .

. . . .

. . . . . . . . .

3 3 4 6 7 8 8 10 11 13

. . . . . .

15 15 17 18 21 22 22

. . . .

25 25 26 27 28

5 Mosaicing 31 5.1 Verfahren f¨ ur Mosaicing . . . . . . . . . . . . . . . . . . . . . 31 5.2 General Manifold Mosaicing . . . . . . . . . . . . . . . . . . . 32 5.3 Topology Inference . . . . . . . . . . . . . . . . . . . . . . . . 32 iii

iv

INHALTSVERZEICHNIS 5.4

5.5

5.6 5.7 5.8

Rotational Mosaicing . . . . . . . . . . . 5.4.1 Registrierung . . . . . . . . . . . 5.4.2 Iterative Sch¨atzung . . . . . . . . 5.4.3 Kamera-Transformation . . . . . 5.4.4 Rotationsmodell . . . . . . . . . . 5.4.5 Reduktion von Fehlern . . . . . . Realisierung von Rotational Mosaicing . 5.5.1 Hierarchische lokale Registrierung 5.5.2 Fehlerkorrektur und Mapping . . 5.5.3 Robustheit . . . . . . . . . . . . . 5.5.4 Modifikationen zur Verbesserung Erweiterung f¨ ur Orientierungsdaten . . . Hand-Eye-Calibration . . . . . . . . . . Qualitative Bewertung der Trackerdaten

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

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

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

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

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

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

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

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

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

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

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

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

33 34 34 35 37 39 39 39 41 41 42 43 43 45

6 Erstellung von Panoramen 51 6.1 Anforderungen und Komponenten . . . . . . . . . . . . . . . . 51 6.2 Echtzeitanzeige (Painting-by-Looking) . . . . . . . . . . . . . 52 7 Zusammenfassung

57

A Implementierung A.1 Die Klasse tracker . . . . . . . A.2 Die Klasse v4lsource . . . . . A.3 Die Klasse v4lpicture . . . . . A.4 Programme zur Bildaufnahme A.5 Pbl-Projekt . . . . . . . . . .

59 59 60 60 61 61

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Kapitel 1 Einleitung Ein Aspekt der digitalen Bildverarbeitung ist es, m¨oglichst realistisch wirkende Darstellungen einer Szene zu gewinnen. Dies kann durch dreidimensionale Modelle oder zweidimensionale Panoramen geschehen. Ziel hierbei ist es, aus Sequenzen von Einzelbildern durch Einsatz geeigneter Algorithmen solche Modelle bzw. Panoramen automatisch zu erstellen. Dies wird umso schwieriger, je weniger einschr¨ankende Anforderungen an die Aufnahmetechnik, wie Kalibrierung der Kamera oder Verwendung eines Stativs, gestellt werden. Deshalb soll zur Unterst¨ utzung der digitalen Bildverarbeitung die Kameraorientierung erfasst werden. Diese Arbeit befasst sich mit der Konstruktion und Realisierung einer orientierungssensitiven Kamera, welche f¨ ur jedes Bild einer Sequenz die Orientierung der Kamera zum Aufnahmezeitpunkt registriert. Das Gesamtsystem besteht aus den Komponenten Orientierungssensor, Kamera, Rechner und Software. Als Plattform dient ein handels¨ ublicher PC mit Linux als Betriebssystem, auch an die verwendete Kamera werden keine weiteren Anspr¨ uche gestellt. Im zweiten Kapitel wird erl¨autert wie Orientierungsdaten erfasst werden, welche Sensoren hierf¨ ur zum Einsatz kommen und wie die Datenakquisition durchgef¨ uhrt wird. Im dritten Kapitel wird die Videoaufnahmetechnik vorgestellt. Dabei wird auf das Zusammenspiel der Videoquellen mit dem Betriebssystem eingegangen. F¨ ur das dabei auftretende Problem der Messung der Videolatenz wird eine L¨osung vorgestellt. In Kapitel 4 werden Probleme und L¨osungen zur Zusammenf¨ uhrung der beiden Datenstr¨ome erl¨autert. In Kapitel 5 werden verschiedene Ans¨atze und ein Verfahren zum Erstellen von Panoramen vorgestellt. Das Verfahren wird anschließend erweitert, so dass Orientierungsdaten des Sensors einbezogen werden. Die damit erzielten Ergebnisse werden anschließend diskutiert. 1

2

KAPITEL 1. EINLEITUNG

In Kapitel 6 wird ein mobiles Aufnahmesystem f¨ ur Panoramen vorgestellt. Weiter wird eine Echtzeitanzeige auf Basis der orientierungssensitiven Kamera erl¨autert.

Kapitel 2 Orientierungsinformationen Die orientierungssensitive Kamera besteht aus zwei Teilen. Eine Komponente erfasst Bildinformationen, die zweite Komponente soll Orientierungsinformationen erfassen. In diesem Kapitel wird das verwendete System f¨ ur die Erfassung der Orientierungsinformationen beschrieben.

2.1

Orientierungssensoren

Es existieren verschiedene Systeme zur Erfassung von Positions- oder Orientierungsinformationen. Sie werden nach der Anzahl und Art der betrachteten Parameter unterschieden. Ein 6DOF (Degree-of-Freedom) Tracker erfasst sowohl Rotationen um die drei Raumachsen als auch Translation in jede der drei Raumrichtungen, so dass Position und Orientierung im Bezugskoordinatensystem, und damit auch im Weltkoordinatensystem, vollst¨andig bekannt sind. Ein 3DOF Tracker erfasst nur drei Freiheitsgrade, beispielsweise nur die Rotationen. Zur Bestimmung der Position im Raum wird entweder das Erdmagnetfeld verwendet, oder es kommen externe Ger¨ate, die das Bezugssystem darstellen, zum Einsatz. Bei Verwendung des Erdmagnetfeldes liefert die Bewegung des Sensors nur differenzielle Informationen. Absolute Positionen k¨onnen dann nur berechnet werden, wenn der Startpunkt im Weltkoordinatensystem bekannt ist. Bei externem Bezugssystem kann eine Ortung des Sensors mittels Ultraschall, Magnetfeldern oder Funksignalen erfolgen. Solche Systeme existieren in verschiedensten Auspr¨agungen und Genauigkeiten. Ein bekanntes System ist GPS, bei dem 14 Satelliten ein Bezugssystem vorgeben, und der Empf¨anger aus Laufzeitdifferenzen der Signale seine Position ermittelt. Der hier verwendete Sensor InterTrax2 der Firma Intersense ist ein 3DOFSensor und erfasst nur die Rotationen um drei Raumachsen mit Gyroskopen, 3

4

KAPITEL 2. ORIENTIERUNGSINFORMATIONEN

externe Ger¨ate f¨ ur das Bezugssystem sind nicht n¨otig. Ein Gyroskop misst die Rotationsbeschleunigung um eine Achse, durch die Kombination von drei orthogonal zueinander angeordeten Gyroskopen werden alle drei Raumachsen erfasst. Beschleunigungssensoren und auch gyroskopische Sensoren k¨onnen heute in Chip-Technologie hergestellt werden, wobei zugeh¨orige elektronische Schaltungen wie Verst¨arker und A/D-Wandler auf dem Chip integriert werden. ±80◦ ±180◦ ±90◦ 3◦ /s 720◦ /s Gieren,Nicken 360◦ /s Rollen Winkelaufl¨osung: 0.02 Grad relativ

Messbereich: Nicken (x-Achse): Gieren (y-Achse): Rollen (z-Achse): ¨ kleinste detektierte Anderungsrate: ¨ gr¨oßte korrekt detektierte Anderungsrate:

Tabelle 2.1: Technische Daten des InterTrax2

Das InterTrax2 Ger¨at wurde im Hinblick auf den geplanten Einsatz zusammen mit Videokameras gew¨ahlt, weil es im Vergleich mit anderen Sensoren klein und leicht ist, keine besonderen Anforderungen an die verwendete Hard- und Software stellt und eines der preiswertesten ist. Die technischen Daten finden sich in Tabelle 2.1. Der Winkelbereich deckt eine Kugelober¨ fl¨ache mit Ausnahme der “Pole” ab, die Aufl¨osung und die maximale Anderungsrate sind f¨ ur den geplanten Verwendungszweck ausreichend. Eine Ein¨ schr¨ankung stellt die kleinste detektierte Anderungsrate dar, bei allen Aufnahmen muss darauf geachtet werden, dass diese nicht unterschritten wird. Da die Anbindung des Trackers InterTrax2 an den Rechner u ¨ber USB erfolgt, wird an dieser Stelle auf das USB-Subsystem eingegangen, und der Entwurf eines geeigneten Treibers vorgestellt.

2.1.1

Struktur des USB-Subsystems

Der Universal-Serial-Bus, kurz USB wurde etwa 1994 von einem Zusammenschluss vieler Firmen der Computerindustrie vorgestellt, um die Vielfalt der verwendeten Anschl¨ usse bei PCs und Peripherieger¨aten zu verringern. Die Daten¨ ubertragungsrate betr¨agt in der USB 1.1 Spezifikation maximal 12 Mbits/s, wobei sich alle angeschlossenen Ger¨ate diese Bandbreite teilen m¨ ussen. In der bereits verabschiedeten Spezifikation USB 2.0 ist eine Bandbreite von 480 Mbits/s vorgesehen, einzelne Hostadapter sind be-

2.1. ORIENTIERUNGSSENSOREN

5

reits verf¨ ugbar. Weitere technische Spezifikationen siehe im Internet unter www.usb.org. USB-Schnittstellen der Version 1.1 sind schon seit einigen Jahren auf den meisten Mainboards vorhanden, allein die Verf¨ ugbarkeit entsprechender Endger¨ate entwickelte sich schleppend. Um USB nutzen zu k¨onnen, muss das Betriebssystem Treiber sowohl f¨ ur den Host-Adapter als auch f¨ ur jedes angeschlossene Ger¨at bereitstellen. Die Entwicklung von USB-Treibern f¨ ur Linux begann mit der Entwickler-KernelVersion 2.3.x und wurde fester Bestandteil des Anwender-Kernels 2.4.0. Parallel zu dieser Entwicklung verlief eine R¨ uckportierung des USB-Stacks f¨ ur die Kernelreihe 2.2.x, so dass die meisten Linux-Distributionen schon seit etwa 1-2 Jahren USB Unterst¨ utzung bieten. Die verwendeten Host-Adapter k¨onnen grob in zwei Kategorien eingeteilt werden: UHCI (Universal Host Controller Interface, vornehmlich Intel) und OHCI (Open Host Controller Interface, Apple, Compaq und andere). Beide Varianten werden von Linux vollst¨andig unterst¨ utzt, f¨ ur UHCI stehen sogar zwei unabh¨angige Implementierungen zur Verf¨ ugung. USB-Ger¨ate werden auf Grund ihres Verwendungszwecks in Klassen eingeteilt. Hier gibt es unter anderem folgende Klassen: • HID (Human Interface Device: Maus, Tastatur, Joystick) • Massenspeicher (Fest-/Wechselplatten, CD-R, einige Digitalkameras) • Drucker • Scanner • DAUSB (Digital-Audio-USB, Lautsprecher mit D/A-Wandler) Hier reicht ein Treiber f¨ ur die ganze Klasse nicht aus, vielmehr stellt ein Klassentreiber nur eine gemeinsame Schnittstelle f¨ ur alle Ger¨ate der Klasse zur Verf¨ ugung. Jedes Ger¨at ben¨otigt dar¨ uber hinaus einen eigenen Treiber zur Unterst¨ utzung seiner Funktionen. Der verwendete Headtracker geh¨ort zur Klasse HID, da er eine Mensch-Maschine-Schnittstelle darstellt. Nachdem die elektrische Verbindung hergestellt ist, wird der Tracker korrekt als HID identifiziert, und der HID-Klassen-Treiber u ¨bernimmt die Kommunikation auf unterster Ebene, d.h. Interrupts des Hostadapters, die vom Headtracker ausgel¨ost wurden, werden vom Hostadapter-Treiber an den HID-KlassenTreiber weitergeleitet. Im Linux-Kernel ist eine weitere Abstraktionsebene f¨ ur Eingabeger¨ate implementiert. Diese als Input-API bezeichnete Schnittstelle soll den Zugriff auf Ger¨ate wie Tastatur, Maus und ¨ahnliche von der verwendeten Anschlussart abstrahieren, so dass aus Sicht der dar¨ uber liegenden Softwareschicht kein

6

KAPITEL 2. ORIENTIERUNGSINFORMATIONEN

Unterschied zwischen etwa einer PS/2-Maus und einer USB-Maus existiert. Hier erfolgt auch der Zugriff auf den verwendeten Headtracker. Die Schnittstelle zur Applikationsebene wird, wie unter Unix u ¨blich, u ¨ber Ger¨atedateien (devicefiles) hergestellt. Dies sind besondere Dateien im Dateisystem (/dev) die keinen statischen Inhalt haben, sondern nur aus einem In¨ ode, das ist eine Datenstrutur die als Kopf einer Datei dient, besteht. Uber Major- und Minor-Devicenumbers wird die Verbindung zum entsprechenden Ger¨atetreiber des Kerns hergestellt. Die Datei f¨ ur den ersten angeschlossenen Tracker heißt /dev/input/tracker0. Eine Application kann diese Datei mit Standard-Systemcalls (open, close, read, write, poll) bearbeiten. Zus¨atzlich k¨onnen mit ioctl Parameter des Ger¨atetreibers eingestellt werden. open()

Userspace programs

read() ioctl()

Device files

/dev/input/tracker0

13 : 128 itrax.o

Device Handler Tracker Eventhandler

/dev/input/mouse0

/dev/input/keyb0

Mouse

Keyboard

input.o

Input

Kernel hid.o

HID−Class Driver

USB core architecture

usb−core.o

USB OHCI driver

usb−ohci.o

USB Hostadapter (OHCI) Tracker Class: HID

USB Root−Hub

Hardware

Abbildung 2.1: Struktur des Linux-USB-Stack

2.1.2

Die USB-Event Kette

Wenn ein Ger¨at am USB Daten anliefern will, signalisiert es dies dem Hostadapter. Der Hostadapter generiert einen Interrupt auf der ihm zur Verf¨ ugung stehenden IRQ-Leitung, die von der CPU u ¨berwacht wird. Diese unterbricht ihre Arbeit, liest aus einer Tabelle, dem Interruptvektor, die Adresse der Interrupt-Service-Routine und startet diese. Bei Linux ist der USB-Hostadapter-Treiber als Interrupt-Service-Routine registriert. Da die InterruptService-Routine weitere Interrupts blockiert (maskiert) solange sie l¨auft, wird

2.1. ORIENTIERUNGSSENSOREN

7

in der Regel nur eine synchrone Unterbrechung (Exception) generiert, und die CPU nimmt wieder die Arbeit im alten Kontext auf. Durch die Exception wird der zweite Teil der Interrupt-Service-Routine gestartet, die sogenannte Bottom-Half. Diese bearbeitet nun die angelieferten Daten, und ordnet sie anhand der Kennung des absendenden Ger¨ates einem Treiber der h¨oheren Ebene zu, in diesem Fall dem HID-Treiber. Der HID-Treiber generiert Events f¨ ur das Input-System und reicht diese an den Input-Treiber durch. Jeder Treiber f¨ ur ein Ger¨at des Input-Systems registriert sich beim InputTreiber f¨ ur “sein” Ger¨at. Der Input-Treiber schickt nun die erhaltenen Events an die entsprechenden Ger¨atetreiber, hier das Itrax-Modul, zur Bearbeitung.

2.1.3

Das Itrax-Modul

Da f¨ ur den InterTrax2 kein Linux-Ger¨atetreiber verf¨ ugbar war, musste dieser in Form eines Kernel-Moduls entwickelt werden. Ein solches Modul kann zur Laufzeit geladen und auch wieder entladen werden. Beim Laden des Moduls werden Funktionen als Handler f¨ ur verschiedene Ereignisse des Ger¨ates beim Input-Treiber registriert, umgekehrt werden diese Funktionen beim Entladen des Moduls wieder abgemeldet. Genauso werden Funktionen zur Behandlung von Zugriffen auf das Devicefile registriert und deregistriert. Das Modul ist auf der einen Seite Event-Handler f¨ ur Input-Events und auf der anderen Seite Device-File-Handler als Schnittstelle zu Anwendungen. Da der InterTrax2 Headtracker vom HID-Klassentreiber erkannt und bedient wird, generiert dieser sogenannte Events und reicht sie an den InputTreiber weiter. Wird ein Tracker am USB angeschlossen, so wird ein Handler f¨ ur neue Ger¨ate aufgerufen, dieser initialisiert eine Datenstruktur, welche Orientierungsdaten und Zeitstempel vorh¨alt. Der f¨ ur eingehende Daten zust¨andige Event-Handler des Itrax-Moduls wird nun vom Input-Treiber immer dann aufgerufen, wenn der Tracker eine Richtungs¨anderung registriert und die ¨ neue Orientierung u der Daten vom Input-Treiber ¨bermittelt. Die Ubergabe an das Itrax-Modul erfolgt dabei u ¨ber die Funktionsargumente der HandlerRoutinen. Diese Daten werden mit einem Zeitstempel zusammen in der Datenstruktur gespeichert. Im einfachsten Fall h¨alt die Datenstruktur nur drei Gleitkommazahlen f¨ ur die drei behandelten Achsen und zwei Ganzzahlen f¨ ur die Zeit, sie kann aber auch als Ringpuffer einstellbarer Gr¨oße arbeiten, um mehrere Orientierungsdaten zur Filterung vorzuhalten. F¨ ur jeden Tracker werden getrennte Datens¨atze verwaltet, so dass ein Betrieb mit mehreren Ger¨aten m¨oglich ist. Wird ein Tracker vom USB getrennt, so wird die daf¨ ur zust¨andige Routine aufgerufen, die alle Datenstrukturen, die diesem Ger¨at zugeordnet waren, abbaut.

8

KAPITEL 2. ORIENTIERUNGSINFORMATIONEN

Eine Anwendung, die Trackerdaten verwendet, ¨offnet eine mit dem Tracker assoziierte Ger¨atedatei zum Lesen (etwa open(/dev/input/tracker0)). Jeder Aufruf von read wird jetzt vom entsprechenden Device-File-Handler des Itrax-Moduls bedient. In der von Argumenten des read-Aufrufes referenzierten Datenstruktur wird die aktuelle Orientierung des Trackers zur¨ uckgeliefert. Um die aufrufende Anwendung nicht zu blockieren, werden die zuletzt erhaltenen Daten zur¨ uckgegeben, und es wird nicht gewartet, bis neue Daten zur Verf¨ ugung stehen. Da der Tracker bei Stillstand keine Daten liefert, muss in diesem Fall davon ausgegangen werden, dass die letzte gemessene Position noch aktuell ist. Mittels ioctl ist es m¨oglich, die Arbeitsweise des Moduls zu beeinflussen. Es ist m¨oglich, neben den rohen Daten des Trackers auch auf eine frei zu w¨ahlende Orientierung bezogene relative Daten zu erhalten, indem mit ITRAXIOCSCALL die aktuelle Orientierung als Nullpunkt aller Achsen gesetzt wird. Die implementierten Filter werden mit ioctl gew¨ahlt und parametrisiert. F¨ ur den Fall, dass mehrere Anwendungen auf einen einzigen Tracker zugreifen, kann jede Anwendung ihren Datenpfad unabh¨angig von den anderen parametrisieren.

2.2

Eigenschaften des InterTrax2

Zur Beurteilung der Qualit¨at der vom Tracker gelieferten Daten sind mehrere Faktoren interessant. Dies ist zum einen die Impulsantwort, da sie die ¨ Ubertragungsfunktion des “Systems” Tracker charakterisiert. Zum anderen ist dies die Latenz des Systems. Die vom Hersteller angegebene innere Latenz betr¨agt 4 ms. Darin ist nicht die Verz¨ogerung des USB-Subsystems enthalten. Diese hinreichend genau zu bestimmen, ist mit den verf¨ ugbaren Mitteln nicht m¨oglich. Da die genannte Verz¨ogerung jedoch sehr gering ist, in aktuellen Kernelversionen ist ein “low-latency”-Mechanismus implementiert, wird sie im Folgenden vernachl¨assigt. Als Echtzeitverhalten eines Systems wird das Einhalten von definierten Reaktionszeiten auf eingehende Ereignisse bezeichnet. Dies sagt nichts u ¨ber die geforderten Reaktionszeiten aus. Da Linux keinerlei Echtzeiteigenschaften besitzt, k¨onnen auch keine Anwortzeiten auf Interrupts genannt werden. So ist die Latenz des USB-Subsystems h¨ochstwahrscheinlich nicht konstant, sondern abh¨angig von der Last des Systems.

2.2.1

Impulsantwort

Zur Messung der Impulsantwort wurde der Tracker auf einer motorgetriebenen Kamera montiert und diese mittels Software gesteuert. Der Motor be-

2.2. EIGENSCHAFTEN DES INTERTRAX2

9

120

45 40

100

80

30 25

60 20 40

Winkel [Grad]

Winkelgeschwindigkeit [Grad/s]

35

15 10

20 5 0 0

100

200

300

400

Weg des Trackers (rechte y-Achse) Tracker (linke y-Achse)

500 t [ms]

600

700

800

900

0 1000

Kamera (linke y-Achse)

Abbildung 2.2: Impulsantwort des Trackers

schleunigt aus dem Stillstand auf Maximaldrehzahl, einige Sekunden sp¨ater bremst er wieder ab. Da die Drehzahl nicht direkt mess- und kontrollierbar ist, ist die Flankensteilheit dieses Impulses nicht bekannt. Die Kamera erh¨alt nur den Befehl, aus der aktuellen Position um beispielsweise 20 Grad zu drehen. Die gemessene Impulsantwort ist in Diagramm 2.2 gezeigt. Die lilafarbene Linie stellt die Winkelgeschwindigkeit der Kamera dar, die rote Linie zeigt die vom Tracker gemessene Orientierung. Diese steigt nach der Beschleunigungsphase linear an, auff¨allig ist die Welligkeit der Kurve. Zur besseren Analyse ist in blau die zeitliche Ableitung des Trackers dargestellt. Dort f¨allt auf, dass die gemessene Geschwindigkeit nur zwei (diskrete) Niveaus annehmen kann. Weitere Messungen wie etwa in Diagramm 2.3 zeigen, dass es mehr als zwei Niveaus gibt, und diese auch nicht scharf definiert sind. Durch diese Modulation wird die tats¨achliche Geschwindigkeit und damit der Ort approximiert. Vom Hersteller war nicht zu erfahren, wie dieses Verhalten begr¨ undet ist.

10

KAPITEL 2. ORIENTIERUNGSINFORMATIONEN 0

1

-20

0.5

-40

0

-60

-0.5

-80

-1

Winkel [Grad]

Winkelgeschwindigkeit [Grad/s]

1.5

-100

-1.5 0

1000

2000

3000

Weg des Trackers

4000

5000 t [ms]

6000

7000

8000

9000

-120 10000

Tracker

Abbildung 2.3: Eine sinusf¨ormige Bewegung und die zeitliche Ableitung

2.2.2

Filter

Zur Kompensation der gemessenen Effekte wird ein Filter eingesetzt. Das Filter ist direkt im Itrax-Modul implementiert und steht jeder Anwendung seperat zur Verf¨ ugung. Die Parametrisierung erfolgt f¨ ur alle drei Achsen getrennt und wird mit ioctl vorgenommen. Das Filter ist als Sliding Window durch einen Ringpuffer implementiert, es stehen zwei Varianten zur Verf¨ ugung: 1. Einfaches Mittelwert-Filter: Dabei wird jeder Messwert gewichtet im Ringpuffer abgelegt. Zur Berechnung muss der ¨alteste Wert des Ringpuffers vom aktuellen Filterwert abgezogen werden, und der neuste Wert addiert werden. 2. Filter mit modifizierbaren Gewichtungen: Dabei werden ungewichtete Daten im Ringpuffer vorgehalten. Zur Berechnung wird jeder Wert mit der zugeh¨origen Gewichtung multipliziert und die Summe gebildet. Im ersten Fall ist die Berechnung sehr schnell, da nur eine Multiplikation, eine Subtraktion und eine Addition durchgef¨ uhrt werden m¨ ussen. Der Aufwand der Berechnung im zweiten Fall ist abh¨angig von der L¨ange des Filters,

2.2. EIGENSCHAFTEN DES INTERTRAX2

11

da bei jeder Berechnung die Summe der gewichteten Werte neu berechnet werden muss.

Vergangenheit kausales Filter

Gewichtung

Zukunft

D4

D3

D2

D1

D0

W4

W3

W2 W1

W0 Wert

Summe Vergangenheit nichtkausales Filter

Gewichtung

Zukunft

D2

D1

D0 D−1 D−2

W4

W3

W2 W1

W0 Wert

Summe

Abbildung 2.4: Schematische Darstellung eines kausalen Filters und eines nichtkausalen Filters

2.2.3

Mittelwertfilter

Das Mittelwertfilter wurde gew¨ahlt, da es die Ableitung eines Signals gl¨attet. Dabei tritt das Problem auf, dass durch die Mittelwertbildung das Ansprech¨ verhalten des Trackers beeintr¨achtigt wird, also Anderungen in der Bewegung verz¨ogert wiedergegeben werden. Dieses Problem kann durch eine nichtkausale Filterung nicht behoben aber zumindest verringert werden. Dabei wird der gefilterte Wert aus Daten der Vergangenheit und der Zukunft des betrachteten Momentes berechnet. Eine nichtkausale Filterung ist nur offline m¨oglich, da der Tracker, wie die meisten Systeme, nicht in die Zukunft schauen kann. Die Realisierung eines nichtkausalen Filters erfolgt durch Protokollierung der Rohdaten und anschließende Anwendung eines Filters auf diese. Das Filter kennt drei Parameter: die Anzahl der zu ber¨ ucksichtigenden Ereignisse in der Vergangenheit np sowie der Zukunft nf und einen Schwellwert τ in ms. Soll zu einem Zeitpunkt t der Filterwert f (t) berechnet werden, so wird als

12

KAPITEL 2. ORIENTIERUNGSINFORMATIONEN

erstes der Index n des Datenfeldes mit Zeitstempel tn gesucht, f¨ ur den gilt: tn − 8ms ≥ t liegt am dichtesten an t. Die Gewichte des Filters an der Stelle i sind Wi , die Orientierung an der Stelle i ist Oi . Der Filterwert berechnet sich jetzt wie folgt: n+nf X f (t) = wi ki , (2.1) i=n−np

 On    O i mit ki = Oi    0

falls i = n falls i < n ∧ |tj+1 − tj | < τ, ∀j : i ≤ j ≤ n . falls i > n ∧ |tj − ti−j | < τ, ∀j : n ≤ j ≤ i sonst

Wenn der Tracker nicht bewegt wird, so liefert er auch keine Daten. Wird zu einem Zeitpunkt t der Ort des Trackers ben¨otigt, dieser hat sich aber in der Zeitspanne ∆t nicht bewegt, so sollen Ereignisse ¨alter als t − ∆t nicht ber¨ ucksichtigt werden. Analog verh¨alt es sich, wenn auf t eine Bewegungspause von ∆t folgt. Dann sollen in den Filterwert f (t) keine Daten einfließen, die neuer sind als t + ∆t . Diese Beschr¨ankung verbessert das Ansprechver¨ halten des Filters genau an den Uberg¨ angen vom und zum Stillstand. Die Impulsantwort ist an den Impulsflanken identisch mit der des ungefilterten Trackers, da hier keine Filterung vorgenommen wird. Ansonsten gl¨attet dies Filter a¨hnlich des kausalen Mittelwertfilters die Ableitung. Meanfilter 8 60

45 40

50

40

30 25

30

20 20

15

Winkel [Grad]

Winkelgeschwindigkeit [Grad/s]

35

10

10

5 0 0 -10 0

100

200

Weg des Trackers

300

400

500 t [ms] Tracker

600

700

800

900

-5 1000

Kamera

Abbildung 2.5: Impulsantwort mit kausalem Mittelwert-Filter der Gr¨oße 8

2.2. EIGENSCHAFTEN DES INTERTRAX2

2.2.4

13

Drift

Nach Angaben des Herstellers weist der InterTrax2 keinerlei Drift auf. Jedoch konnte bei gleichzeitiger Verwendung des Trackers und einer USB-Tastatur eine erhebliche Drift festgestellt werden. Diese betrifft alle drei Achsen und liegt im Bereich von mehreren Grad pro Sekunde. Es konnte nicht gekl¨art werden, worauf diese Drift zur¨ uckzuf¨ uhren ist. Beobachtet wurde sie auf zwei verschiedenen Rechnern jeweils mit Linux als Betriebssystem. Auf einer dritten Maschine, einem Sony Vaio Notebook mit Windows 2000 als Betriebssystem trat der Effekt nicht auf. Daher besteht Grund zu der Annahme, dass die Drift nicht vom Sensor erzeugt wird, sondern erst in einer der Softwareschichten des USB-Subsystems.

Kapitel 3 Aufnahme von Videodaten 3.1

Aufnahmetechnik

Zur Aufnahme von Einzelbildern und Bildsequenzen kommen heute vornehmlich Kameras mit CCD-Sensoren zum Einsatz. Als vereinfachtes Modell einer Kamera kann das Lochkameramodell verwendet werden. Das Objektiv dieser ¨ Kamera ist eine Lochblende mit unendlich kleiner Offnung, mit der sichergestellt wird, dass nur ein von einem Objektpunkt ausgesandter Lichtstrahl die Bildebene erreicht und das Bild des Objektpunktes erzeugt. Abbildung 3.1 zeigt dies Modell. Punkt A Bild von Punkt B

Bild von Punkt A

Punkt B

Lochblende

Bildebene

Abbildung 3.1: Schematische Darstellung einer Lochkamera

Praktisch ist ein unendlich kleines Loch nicht realisierbar, aber schon sehr kleine L¨ocher erzeugen Beugungsfehler die zu Farbdispersionen1 f¨ uhren. Mit gr¨oßeren Lochblenden ist keine scharfe Abbildung mehr m¨oglich, daher kom1

Farbdispersion ist die Zerlegung von weißem Licht aufgrund unterschiedlicher Beugung oder Brechung verschiedener Wellenl¨angen 15

16

KAPITEL 3. AUFNAHME VON VIDEODATEN

men Objektive aus ein oder mehreren Linsen zum Einsatz. Ein besseres Abbildungsverhalten wird durch Gruppierung von Linsen aus geeignetem Material erreicht, damit k¨onnen Abbildungsfehler der Linsen in gewissen Grenzen kompensiert werden. Auftretende Fehler sind unter anderem Verzerrungen (Kissen-,Trapez-, Radialverzerrung), Unsch¨arfe und Farbs¨aume, verursacht durch Fertigungstoleranzen und Materialeigenschaften wie unterschiedliche Brechung verschiedener Wellenl¨angen. Als Material werden Quarzglase verschieder G¨ ute mit verschiedenen Brechungsindizes, zunehmend aber auch transparente Polycarbonate verwendet. Ein weiterer, gerade bei sehr einfachen Objektiven zu beobachtender Effekt ist ein Intensit¨atsabfall von der Bildmitte zu den R¨andern und den Ecken. Dieser als Vignettierung bezeichnete Fehler f¨allt besonders bei Mosaiken auf, wo Bildkanten direkt in der Mitte anderer Bilder liegen. Punkt A

Linse Bild von Punkt B

Bild von Punkt A Punkt B

Abbildung 3.2: Strahlengang f¨ ur eine Linse

Die Erfassung des Bildes in der Kamera kann herk¨ommlich chemisch (Negativ- oder Positivfilm) oder elektronisch erfolgen. An der Position der Bildebene wird ein CCD (Charge Coupled Device) montiert, welches f¨ ur eine Abtastung des kontinuierlichen Bildsignals sorgt. Ein CCD ist ¨ahnlich einem DRAM aus einer Matrix von Kondensatoren aufgebaut. Diese werden durch Lichteinfall geladen und zyklisch ausgelesen. Das Auslesen erfolgt nach einem Eimerkettenprinzip, bei dem die erste Zelle jeder Zeile u ¨ber einen Verst¨arker ausgelesen wird, und danach alle Zellen einer Zeile ihre Ladung an den Nachbarn in Ausleserichtung weitergeben. Die Aufl¨osung des CCD bestimmt damit die Aufl¨osung und obere Grenzfrequenz gem¨aß dem Shannonschen Abtasttheorem. Die gr¨oßte abtastbare und damit reproduzierbare Frequenz ist gerade die halbe Abtastrate, n¨aheres dazu in [J¨ah97] und [Sch01]. Das analoge Signal jeder Zelle wird in geeigneter Reihenfolge digitalisiert, wo-

3.1. AUFNAHMETECHNIK

17

bei die Aufl¨osung des D/A-Wandlers die Anzahl der Graustufen/Farbwerte bestimmt. Aus Kostengr¨ unden werden die CCD-Chips m¨oglichst klein produziert, mit dem Effekt, dass bei gegebener Aufl¨osung die Zellen kleiner werden. Da die Empfindlichkeit der Zelle von deren Gr¨oße abh¨angt, sind kleinere CCDs weniger lichtempfindlich als gr¨oßere. Die Anpassung der Kamera an die Beleuchtungsverh¨altnisse kann klassisch u ¨ber die Steuerung der Belichtungszeit und Blenden¨offnung erfolgen, aber auch u ¨ber die Aussteuerung der Ausleseverst¨arker. Bei geringem Lichteinfall kann das Bild durch entsprechende Verst¨arkung aufgehellt werden. Durch gr¨oßere Verst¨arkung erh¨oht sich aber das Rauschen des Bildes, da thermische Aktivit¨at sogenannte Dunkelstr¨ome erzeugt, die bei geringer Belichtung dominieren. Hochempfindliche CCDs sind folglich groß und werden eventuell sogar stark gek¨ uhlt (Einsatz etwa in Spiegelteleskopen). Weiteres Rauschen wird beim Weiterschieben der Ladungen zum Auslesen erzeugt, und auch die Verst¨arkung des Signals erfolgt nicht rauschfrei, siehe dazu [Dav97]. Ein weiterer Effekt von CCD-Sensoren ist das sogenannte Blooming, bei ¨ dem durch Uberbelichtung einzelner Zellen eine Ladungswanderung in benachbarte Zellen entsteht. CCDs haben eine Empfindlichkeit vom Infrarotbis in den UV-Bereich des elektromagnetischen Spektrums. Farbbilder werden erzeugt, in dem alle Pixel einen Farbfilter erhalten, und zwar verteilt u ¨ber die gesamte Fl¨ache des CCD jeweils ein Viertel aller Pixel rot, ein Viertel blau und die H¨alfte gr¨ un. Diese Verteilung bildet die starke Empfindlichkeit des menschlichen Auges f¨ ur gr¨ une Farben nach. Alternativ dazu gibt es 3Chip Kameras die durch einen Strahlteiler drei CCDs gleichzeitig belichten. Jeder Chip hat einen entsprechenden Farbfilter. Soll mit einem Farb-CCD ein Grauwertbild erzeugt werden, so wird dies durch die gewichtete Summation von vier Subpixeln zu einem Grauwertpixel berechnet.

3.1.1

Die Brennweite

F¨ ur den vorgestellten Verwendungszweck relevant ist die Brennweite f (fo¨ callength), ein Maß f¨ ur den Offnungswinkel und den Abbildungsmaßstab des Objektives. Diese ist Bestandteil der Kamerakalibrier-Matrix K. F¨ ur einen Punkt pwelt auf der Bildebene der Kamera ist der entsprechende Punkt in Pixelkoordinaten pbild bestimmt durch:   fm fn  , pbild = Kpwelt mit K =  (3.1) 1 wobei m bzw. n die Aufl¨osung des Sensors in Pixeln in x- bzw. y-Richtung ist.

18

KAPITEL 3. AUFNAHME VON VIDEODATEN

Bildebene Kamerazentrum

W 1

D Objektebene

Abbildung 3.3: Bestimmung der Brennweite einer Kamera

Sei D der Objektabstand, W die Objektgr¨oße und m die horizontale Aufl¨osung (siehe auch Abb. 3.3), dann bestimmt sich die Brennweite f wie folgt: D D fm = m ⇔ f= . (3.2) W W Analog gilt dies f¨ ur n, die vertikale Aufl¨osung. Dieser f¨ ur eine Kamera mit fixer Optik konstante Wert wird bestimmt, indem ein Objekt der Gr¨oße W so positioniert wird, dass es die Bildebene gerade eben komplett abdeckt. Der Abstand D kann nun zwischen dem Objekt und dem CCD als approximiertem Zentrum des Linsensystems gemessen werden, da 1