bachelorarbeit anwendung von personenverfolgung mittels ... · im vorlauf der projektarbeit wurde...
TRANSCRIPT
Bachelorarbeit
Anwendung von Personenverfolgung mittels Kinect für
Kooperationsaufgaben
An der Fachhochschule Dortmund im Fachbereich Informatik
erstellte Bachelorarbeit im Studiengang Wirtschaftsinformatik
zur Erlangung des Grades Bachelor of Science von
Moritz Wiechers
geboren am 26.02.1988
(Matr.-Nr.: 7077554)
Erstprüfer: Prof. Dr. Andrea Kienle Zweitprüfer: Prof. Dr. Thomas Herrmann
Dortmund, 17.08.2012
Kurzfassung
Die vorliegende Arbeit befasst sich mit dem Einsatz von Personenverfolgungsalgorithmen für
die Unterstützung von kooperativen Aufgaben bei Benutzung eines Smartboards. Dabei wird
besonders der Aspekt der Mehrkamerabenutzung und die Zusammenführung zwei getrennt
laufender Personenverfolgungsalgorithmen beleuchtet. Die Arbeit soll die Frage
beantworten, inwieweit eine softwaretechnische Umsetzung des in einer vorigen Arbeit
erstellten Konzepts möglich ist und inwieweit das entwickelte System zur Unterstützung bei
Kooperationsaufgaben dienen kann. Das entwickelte System benutzt die Tiefenkamera
Kinect von Microsoft und das Framework OpenNI mit der Middleware NITE, die den
Personenverfolgungsalgorithmus liefert. Zu Beginn dieser Arbeit wird das verwendete
Framework beschrieben und Besonderheiten und Probleme erörtert. Im Hauptteil der Arbeit
wird dann die entwickelte Software ausführlich beschrieben. Der letzte Teil zeigt die
Realisierbarkeit des Konzeptes und den Mehrwert von Personenverfolgung bei
Kooperationsaufgaben.
Abstract
This work deals with the deployment of people tracking algorithms for supporting
cooperative tasks while using a smartboard. The focus in this work is on the aspect of the
multi-camera usage and the reunion of two separated people tracking algorithm. This work
should answer the question if an implementation of a concept, which was developed in a
previous work, is realisable and if the developed system can be used to support cooperative
tasks. The developed system uses the depth camera „Kinect“ from Microsoft and the
framework OpenNI in cooperation with a middleware component called NITE, which
provides the people tracking algorithm. At the beginning of this work the framework OpenNI
is described in general and its characteristics and problems are presented. Afterwards the
main part of the work, the software development, is explained in detail. The last section
provides the feasibility of the concept and the usability of people tracking for supporting
cooperative tasks.
I I. Inhaltsverzeichnis
Moritz Wiechers
I. Inhaltsverzeichnis
Abbildungsverzeichnis ................................................................................................................ II
1 Einleitung ............................................................................................................................ 1
1.1 Szenario ....................................................................................................................... 1
1.2 Ziele, Aufgaben und Vorgehen .................................................................................... 2
1.3 Definitionen ................................................................................................................. 3
2 Vorbereitungen .................................................................................................................. 8
2.1 Positionierung der Kameras ........................................................................................ 8
2.2 Das Framework OpenNI ............................................................................................ 10
2.2.1 Architektur ......................................................................................................... 10
2.2.2 Verwendung ....................................................................................................... 11
2.3 Anmerkungen zur Benutzung zweier Kameras (OpenNI) .......................................... 12
2.4 Sonstiges zur Arbeit mit OpenNI und dem Java Wrapper ......................................... 13
2.5 Zusammenfassung der wichtigsten Erkenntnisse ..................................................... 15
3 Prototyp ............................................................................................................................ 16
3.1 Anforderungen .......................................................................................................... 16
3.2 Software-Prozessmodell ............................................................................................ 16
3.3 Gesamtarchitektur ..................................................................................................... 17
3.4 Umsetzung Server ...................................................................................................... 18
3.4.1 Softwarestruktur ................................................................................................ 18
3.4.2 Einbindung von zwei Kameras in ein gemeinsames Softwaresystem ............... 21
3.4.3 Zusammenführung der Koordinatensysteme .................................................... 22
3.4.4 Personenverwaltung .......................................................................................... 25
3.4.5 Abbildung des Smartboards ............................................................................... 29
3.4.6 Kommunikationsschnittstelle ............................................................................. 32
I I. Inhaltsverzeichnis
Moritz Wiechers
3.5 Umsetzung Client ....................................................................................................... 33
3.5.1 Softwarestruktur ................................................................................................ 33
3.5.2 Die verfolgende Toolbox .................................................................................... 35
3.5.3 Clustering Prototyp ............................................................................................ 35
4 Machbarkeitsstudie .......................................................................................................... 38
4.1 Demoset ..................................................................................................................... 38
4.2 Ergebnisse .................................................................................................................. 39
4.3 Ausblick ...................................................................................................................... 40
5 Fazit .................................................................................................................................. 42
6 Quellen und Literaturverzeichnis ..................................................................................... 44
6.1 Quellen ...................................................................................................................... 44
6.2 Internetquellen .......................................................................................................... 44
II Abbildungsverzeichnis
Moritz Wiechers
II. Abbildungsverzeichnis
Abbildung 1 SeeMe-Editor ......................................................................................................... 4
Abbildung 2 Moderationslabor mit dem Smartboard (links) Der SeeMe-Editor im Einsatz am
Smartboard (rechts) ................................................................................................................... 4
Abbildung 3 Positionierungstest der Kameras Im Moderationslabor (links), Fehlerhafte
Benutzersegmentierung durch falsche Bodenerkennung (rechts) ............................................ 9
Abbildung 4 Unterschiedliche Aufnahmebereiche durch seitlichere Positionierung der
Kameras. (links: mittig, Rechts: außen) ...................................................................................... 9
Abbildung 5 OpenNI Framework Architektur .......................................................................... 10
Abbildung 6 Vermischung der Benutzer bei der Verwendung zweier Kameras in derselben
Applikation ............................................................................................................................... 13
Abbildung 7 Gesamtsoftwarearchitektur ................................................................................. 18
Abbildung 8 Grobstruktur des Prototypen .............................................................................. 19
Abbildung 9 links: Das verwendete Protokoll; Rechts: Ausschnitt Sequenzdiagramm
Verbindungsaufbau .................................................................................................................. 21
Abbildung 10 Grafische Oberfläche des verwendeten Kalibrierungstools mit
Kalibrierungsmuster (Schachbrett) .......................................................................................... 23
Abbildung 11 Umschließende Quader einer Person ohne (links) und mit (Mitte) Korrektur des
Blickwinkels der Kameras; Rechts: Aufteilung des Quaders in mehrere kleine grüne Quader26
Abbildung 12 Eine Person mit den entsprechenden umschließenden Quadern (rote Linien) in
der jeweiligen Kamera (blaue & rote Punkte) und den gemeinsamen Teilquadern (grün) .... 27
Abbildung 13 Eintritt einer Person in die Szene (mittig hinten), Links: Beim Zusammenführen
der Benutzer existiert kein gemeinsamer Schnittquader, Rechts: Korrektur Nach zeitlich
versetzter Überprüfung ............................................................................................................ 28
Abbildung 14 Fehlzuordnung durch das Framework (mitte) und der Zustand nach der
Korrektur(rechts) ...................................................................................................................... 28
II Abbildungsverzeichnis
Moritz Wiechers
Abbildung 15 Verfolgung des Benutzers über den Schnittbereich der Kameras hinweg ........ 29
Abbildung 16 Abbildung des Smartboards in das Koordinatensystem der Kameras als
Realsicht (links) und als Ansicht in der Software (rechts) ........................................................ 30
Abbildung 17 Umrechnung des Klickpunktes in Raumkoordinaten (links); Umrechnung des
Mittelpunktes einer Person in X-Wert des Smartboards (rechts) ........................................... 32
Abbildung 18 Beispielhafte Kommunikation zwischen Client und Server ............................... 33
Abbildung 19 Softwarestruktur des Client PlugIns .................................................................. 34
Abbildung 20 Seeme-Editor mit der beweglichen Toolbar ...................................................... 35
Abbildung 21 Das benutzerspezifische ButtonSet (links) und das Clockface (rechts) ............. 36
Abbildung 22 Ein Element wurde selektiert(links) und anschließend verschoben (rechts) .... 36
Abbildung 23 Das Ausgangsmodell des Clusterexperiments ................................................... 38
1 1. Einleitung
Moritz Wiechers
1 Einleitung
Dieses Kapitel soll in das Thema einführen, die wichtigsten Aspekte der Projektarbeit
erläutern und Ziele und Aufgaben für diese Arbeit darstellen. Zudem werden andere
Arbeiten in diesem Bereich erwähnt und zum Schluss elementare Begriffe definiert, um ein
einheitliches Vokabular zu verwenden.
1.1 Szenario
Im Rahmen meiner Tätigkeit als studentische Hilfskraft am Lehrstuhl für Informations- und
Technikmanagement an der Ruhr-Universität-Bochum habe ich an der Entwicklung des
SeeMe-Editors mitgearbeitet. Der SeeMe-Editor ist ein Modellierungseditor, der die
Modellierungsmethode SeeMe (Abschnitt 1.3) umsetzt. Dieser Modellierungseditor wird u.a.
im Moderationslabor des Instituts für Arbeitswissenschaft an der Ruhr-Universität-Bochum
(Abschnitt 1.3) benutzt. Kernbestandteil dieses Moderationslabors ist eine große
Interaktionsfläche (10 qm), die per Touch bedient werden kann. Die Interaktionsfläche
eignet sich besonders gut um große Modelle zu präsentieren oder für die gemeinsame
Arbeit im Editor. Im Vorlauf der Projektarbeit wurde am Lehrstuhl intensiv an einem Konzept
für die Mehrbenutzerbedienbarkeit an dieser Interaktionsfläche mit Hilfe des SeeMe-Editors
gearbeitet. Dieses Konzept wird in Abschnitt 1.3. „Multi-User-Multi-Action Konzept“ genauer
beschrieben. Bei der Umsetzung und experimentellen Auswertung des erarbeiteten
Konzepts stellte sich besonders das Problem des Wiederauffindens der eigenen gestarteten
Operation durch den Benutzer heraus. Aus dieser Situation entsprang die Idee, dass die
Zuordnung von Benutzern zu ihren Operationen automatisiert ablaufen könnte. Dabei
könnte das Umfeld der Interaktionsfläche beobachtet und analysiert werden, um
festzustellen, welcher Benutzer zur Zeit der Interaktion mit der Wand diese durchführt.
Dadurch müsste der Benutzer lediglich an eine Stelle der Wand touchen, um
benutzerspezifisch Menüs zu seinen Operationen angezeigt zu bekommen oder seine
Operation direkt fortzuführen. Ein Wiederauffinden der eigenen gestarteten Operationen ist
so nicht mehr nötig. Die Analyse des Umfeldes des Smartboards durch Kameras erfordert
den Einsatz von Personenverfolgungsalgorithmen, um aus den aufgenommenen Daten
Rückschlüsse über Benutzerinteraktionen zu ziehen. Im Rahmen der Projektarbeit wurden
verschiedene Personenverfolgungsalgorithmen untersucht, die eine leichte Anbindung an
2 1. Einleitung
Moritz Wiechers
die Daten der Tiefenkamera Kinect von Microsoft ermöglichen. Dabei wurden für den
geplanten Einsatz innerhalb des am Lehrstuhl erarbeiteten Konzepts zur
Mehrbenutzerbedienung an großen Interaktionsflächen die einzelnen
Personenverfolgungsalgorithmen untersucht und ausgewertet. Ausgewählt wurde das
Framework OpenNI in Zusammenarbeit mit der Middleware NITE von der Firma Primesense,
weil es sich als am besten geeignetes herausstellte. Neben der Auswahl eines geeigneten
Personenverfolgungsalgorithmus‘ wurde während der Projektarbeit ein Konzept für die
softwaretechnische Umsetzung des Systems entwickelt. Dieses Konzept gilt es nun
umzusetzen und zu evaluieren.
1.2 Ziele, Aufgaben und Vorgehen
Die zentrale Frage der Arbeit, ob eine Umsetzung des Konzepts der Projektarbeit realisierbar
ist und inwieweit mit solch einem System, dessen Hauptbestandteil die Personenverfolgung
ist, kooperative Arbeit unterstützt werden kann. Ziel dieser Arbeit ist es also, das in der
Projektarbeit beschriebene Konzept zur Personenverfolgung mittels zweier Kameras und der
Anbindung an eine große Interaktionsfläche zu verfeinern und umzusetzen und zusätzlich
den Einsatz bei kollaborativem Arbeiten an dem Smartboard des Moderationslabors (siehe
1.3) zu testen. Aus diesem Ziel lassen sich mehrere Aufgaben ableiten, die in dieser Arbeit in
verschiedenen Kapiteln bearbeitet werden. Vor der eigentlichen Softwareentwicklung, der
Umsetzung des Konzepts, werden im Kapitel 2 Vorbereitungen getroffen. Zum einem wird
eine optimale Positionierung der Kameras in Hinblick auf Abdeckungsbereich,
Überlagerungssituationen und Funktionalität des Personenverfolgungsalgorithmus‘ ermittelt
und zum anderen wird besonders im Hinblick auf die Benutzung zweier Kameras eine
Einarbeitung in das zu verwendende Framework OpenNI erfolgen. Nach diesen
Vorbereitungen werden im dritten Kapitel Anforderungen an die Software genannt und
anschließend die Implementierung des Konzepts mit besonderem Bezug auf die
Zusammenführung der beiden Kamerakoordinatensysteme, die Vereinigung der getrennt
laufenden Personenverfolgungsalgorithmen und die Anbindung an das Smartboard
beschrieben. Der letzte Teil des dritten Kapitels beschäftigt sich dann mit der
Implementierung für die Anschauungssoftware im Modellierungseditor SeeMe. Im Rahmen
der Bachelorarbeit wird zusätzlich im Kapitel 4 die durchgeführte Machbarkeitsstudie
erläutert, die die Funktionalität des Prototypen in einer kooperativen Arbeit zeigen und
3 1. Einleitung
Moritz Wiechers
Erkenntnisse über den Einsatz von Personenverfolgung bei Kooperationsaufgaben
generieren soll. Zudem werden dort mögliche Erweiterungsideen und
Verbesserungsvorschläge für das umgesetzte System gegeben. Im letzten Kapitel folgt ein
Fazit über die gesamte Arbeit. Im Bereich der Personenverfolgung zur Unterstützung von
Kooperationsaufgaben an großen Interaktionsflächen gibt es nur wenige verwandte
Arbeiten. Eine im Bereich der benutzerspezifischen Interaktion mit Touchoberflächen ist z.B.
die von Jung et al.1, bei der mithilfe von RFID Chips an einem Touch-Tisch Benutzer
identifiziert und zugeordnet werden können. Zudem wurde an der École Polytechnique
Fédérale de Lausanne eine Mehrpersonenverfolgung mittels mehrerer Kinects entwickelt
und in einem kurzen Video demonstriert.2 Alle diese Arbeiten beschäftigen sich aber
entweder konzentriert auf die Personenverfolgung durch mehrere Kameras oder die
Benutzung von Touchtischen in Zusammenhang mit Kooperationsaufgaben.
1.3 Definitionen
Dieser Abschnitt erläutert im Rahmen der Bachelorarbeit und der Ausarbeitung des
Prototypen häufig verwendete Begriffe, um ein einheitliches Verständnis zu schaffen.
Modellierungsmethode SeeMe
Die Modellierungsmethode SeeMe dient der Darstellung semi-strukturierter und sozialer
Aspekte bei Kommunikations- und Kooperationsprozessen. Weiterhin wird eine
Modellierungsmethode als ein Beschreibungsmittel, bestehend aus Konzepten zur Abbildung
von Phänomenen der Realität, angesehen. Diese Konzepte werden durch eine Notation
ausgedrückt, die aus Zeichen oder Symbolen besteht. Die Bedeutung und die
Kombinierbarkeit dieser Notationselemente werden beispielsweise in Form eines
Metamodells festgelegt. 3
SeeMe-Editor
Der SeeMe-Editor ist ein Editor, der am Lehrstuhl für Informations- und Technikmanagement
(im Folgenden nur noch als "IMTM" bezeichnet) weiterentwickelt wird und die
Modellierungsmethode SeeMe umsetzt. Der Editor bietet zahlreiche Möglichkeiten, Modelle
1 Vgl. Jung et al. (2011) 2 http://actu.epfl.ch/news/connecting-kinects-for-group-surveillance/ 3 Vgl. Herrmann, Thomas; Hoffmann, Marcel; Loser, Kai-Uwe (1998), S.1
4 1. Einleitung
Moritz Wiechers
zu erstellen und zu präsentieren. In den letzten Jahren wurden zahlreiche Plug-ins
entwickelt, die es u.a. ermöglichen, eine Brainstormingsitzung abzuhalten oder
Abstimmungsverfahren durchzuführen. Die Funktionalität und Bedienbarkeit wird ständig
getestet und erweitert.
ABBILDUNG 1 SEEME-EDITOR
"ModLab" des Instituts für Arbeitswissenschaften der RUB
Das am Institut für Arbeitswissenschaften der Ruhr-Universität Bochum eingerichtete
Moderationslabor verfügt über diverse Komponenten, mit denen technische
Unterstützungen zur kooperativen Arbeit realisiert, analysiert und bewertet werden können.
Neben der Möglichkeit, Gruppenprozesse durch Videoanalyse zu untersuchen, bietet eine
fünf Meter breite interaktive Wand Möglichkeiten, kooperative Arbeit durch
Computersysteme zu unterstützen. Diese interaktive Wand wird fortan nur noch als
Smartboard bezeichnet.
ABBILDUNG 2 MODERATIONSLABOR MIT DEM SMARTBOARD4 (LINKS) DER SEEME-EDITOR IM EINSATZ AM SMARTBOARD5
(RECHTS)
Multi-User-Multi-Action Konzept
Das Multi-User-Multi-Action Konzept ist ein speziell für interaktive Wände entwickeltes
System, um eine gleichzeitige Benutzung durch mehrere Benutzer zu gewährleisten. State of
4 Quelle: http://www.imtm-iaw.rub.de/kategorie/modlab-blog/ 5 Quelle: http://www.imtm-iaw.rub.de/kategorie/modlab-blog/
5 1. Einleitung
Moritz Wiechers
the Art Technologien, wie Multitouch, reichen z.B. für das Modellieren an einer großen
Interaktionsfläche durch mehrere Personen gleichzeitig nicht aus. Probleme, wie
Positionswechsel bei kontinuierlichem Kontakt (Dragging), können damit nicht gelöst
werden. Das Konzept sieht vor, bestimmte Aktionen, die eine Drag-Operation benötigen, wie
das Bewegen von Elementen, in Einzelschritte zu zerlegen. Drag-Operationen sind bei einer
Mehrbenutzerbedienung einer Touch-Wand problematisch, wenn die Benutzer sich
überkreuzen, da sie sich im Weg stehen würden. Außerdem ist eine Zerlegung von
Operationen in die Schritte „Start“, „Ende“ und eventuell als Zwischenschritt „Weiter“
vorgesehen. Der Benutzer möchte z.B. ein Element bewegen, dazu wird das Element
ausgewählt und die entsprechende Operation gestartet. Beim Start der Operation werden
über ein Ticketsystem eine Zahl und eine Farbe angezeigt, um dem Benutzer das
Wiederfinden seiner Operation im nächsten Schritt zu ermöglichen. Im nächsten Schritt wird
die Operation fortgesetzt, dazu toucht der Benutzer nun an eine andere Stelle der Wand,
wählt über die Farbe bzw. Zahl die entsprechende Operation aus und bestätigt diese. Das
Konzept wird besonders im Hinblick auf die Benutzung anderer Zuordnungsmechanismen,
wie Bilder, Icons oder Wörter, für das Wiederauffinden der eigenen gestarteten Aktionen
weiterentwickelt und getestet.
Benutzersegmentierung / Personenverfolgung
Unter dem Begriff Segmentierung wird in der Bildverarbeitung das Zuordnen von Pixeln
eines Bildes zu bestimmten Objekten verstanden. Jeder Pixel eines Bildes erhält so eine
zusätzliche Information, zu welchem Objekt er gehört. Es gibt Pixel-, Kanten-, Regionen-,
Modell- und Textur-orientierte Segmentierungsverfahren, die Farb- oder Tiefenbilder
hinsichtlich bestimmter Objekte analysieren. 6 Unter dem Begriff der
Benutzersegmentierung wird im Rahmen der Bachelorarbeit ein Segmentierungsverfahren
verstanden, das das Tiefenbild der Kinect auf das Vorkommen von Personen analysiert und
diese vom Rest der Szene abgrenzt. Die Zuweisung einer ID zu jeder erkannten Person und
die Aufrechterhaltung dieser Zuweisung über mehrere Bilder hinweg wird als
Personenverfolgung verstanden.
6 Vgl. http://www.mathematik.uni-ulm.de/stochastik/lehre/ws05_06/seminar/sauter.pdf
6 1. Einleitung
Moritz Wiechers
Client-Server-Architektur
Die Client-Server-Architektur gilt als die traditionelle Architektur für verteilte Systeme.
Neben ihr existieren noch die Web-Architektur, die serviceorientierte Architektur und die
Peer-to-Peer Architektur. Die Peer-to-Peer Architektur ist dabei die einzige, bei der alle
beteiligten Computer bzw. Subsysteme gleichberechtigt sind. Jeder Teilnehmer kann also
Dienste bereitstellen und in Anspruch nehmen. Bei den anderen Architekturen gibt es immer
einen verwaltenden Server, der Dienste bereitstellt und auf der anderen Seite Clients, die
sich mit dem Server verbinden und diese Dienste nutzen. Die Software wird so auf
verschiedene Subsysteme innerhalb eines Netzwerks aufgeteilt, die miteinander
kommunizieren. Die Kommunikation findet meist über Protokolle statt und bietet eine lose
Kopplung der Subsysteme untereinander. Im Rahmen der Client-Server-Architektur gibt es
verschiedene Typen von Clients, je nach dem wie die Aufgabenbewältigung im System
aufgeteilt ist. Führt der Client die meisten Aufgaben durch, so ist die Rede von einem Fat
Client; führt er wenige Aufgaben durch und funktioniert nur mit einem verbundenen Server,
so wird er Thin Client genannt. Die Web-Architektur stellt eine Client-Server-Architektur
unter der Verwendung von Web-Techniken dar und die serviceorientierte Architektur
versucht die Kommunikation für z.B. unternehmensübergreifende Zusammenarbeit von
Systemen zu gewährleisten. Im Rahmen der Bachelorarbeit wird die Client-Server-
Architektur einmal auf unterschiedlicher Hardware und einmal auf derselben Hardware
umgesetzt (siehe 3.3). Da keine Web-Techniken zum Einsatz kommen und die
Kommunikation ausschließlich in einem lokalen Netzwerk „unternehmensintern“ stattfindet,
kommen die beiden Alternativen, deren Umsetzung im Allgemeinen einen Mehraufwand
erfordern, nicht in Betracht.7
Observer Konzept
Das Observer Konzept, auch Beobachter oder Listener Konzept genannt, ist ein
Entwurfsmuster. Entwurfsmuster beziehen sich in der Regel auf Subsysteme im Gegensatz zu
Architekturen, die meist das Zusammenspiel der Subsysteme behandeln. Das Konzept dient
dem Ziel der losen Kopplung von Komponenten innerhalb eines Softwaresystems. Ein Objekt
informiert bei ihm angemeldete Objekte (Beobachter, Observer, Listener) z.B. über
Veränderungen. Zuvor müssen sich die Objekte, die informiert werden sollen, bei dem 7 Vgl. Balzert, Helmut (2011), S.192-195
7 1. Einleitung
Moritz Wiechers
gewünschten Objekt registrieren. Dabei müssen die zu informierenden Objekte vordefinierte
Methoden implementieren (z.B. über die Implementierung eines Interface in Java) und das
Objekt, das über Zustandsänderungen informiert, Registrierungs- und Deregistrierungs-
methoden anbieten. Ein zu informierendes Objekt implementiert also die benötigte
Schnittstelle und dabei z.B. die Methode A der Schnittstelle. Anschließend registriert es sich
bei dem zu beobachtenden Objekt, welches nun bei Veränderung die Methode A des
Beobachters aufruft. Im Rahmen der Bachelorarbeit ist dieses Entwurfsmuster z.B. bei der
losen Kopplung von Komponenten an das Objekt Kinect zum Einsatz gekommen. Dadurch ist
es leicht möglich neue Komponenten anzubinden und eine Abkapselung der Klasse Kinect zu
gewährleisten.8
8 Vgl Balzert, Helmut (2011), S.54-62
8 2. Vorbereitungen
Moritz Wiechers
2 Vorbereitungen
Bevor der Prototyp eingesetzt werden kann, müssen einige Vorbereitungen getroffen
werden. Aus diesem Grund behandelt dieses Kapitel zum einem die Frage der optimalen
Positionierung der beiden Kameras im Moderationslabor des Lehrstuhls für Informations-
und Technikmanagement an der Ruhr-Universität-Bochum und zum anderen das zu
verwendende Framework OpenNI und die durch den Mehrkameraeinsatz bedingten
Probleme des Frameworks.
2.1 Positionierung der Kameras
Die Positionierung der Kameras hat entscheidende Auswirkungen auf die Fehleranfälligkeit
der Personenverfolgungsalgorithmen und die Funktionalität der zu entwickelnden Software.
Der verwendete Personenverfolgungsalgorithmus ist für eine horizontale Positionierung der
Kamera zur Szene entwickelt worden und macht deshalb bestimmte Annahmen über die
Lage des Bodens in der Szene. Gleichzeitig erfordert eine Vermeidung von vollständigen
Überlagerungen der Personen in der Szene, dass die Kameras möglichst aus einer höheren
Position auf die Szene schauen, um in den meisten Fällen der Überlagerungen die Köpfe der
Personen noch zu erkennen. Aus dem Szenario ergibt sich zudem ein benötigter
Abdeckungsbereich von Personen, die bis zu 2m entfernt vor dem Smartboard stehen. Diese
drei Anforderungen an die Positionierung sind in Einklang zu bringen. Vor der festen
Montage der Kameras an der Decke muss also die beste Positionierung ermittelt werden.
Dazu wurden die Kameras in verschiedenen Positionierungen im Hinblick auf die erörterten
Anforderungen untersucht. Der linke Teil der Abbildung 3 zeigt eine untersuchte
Positionierung der Kameras im Moderationslabor. Durch die verschiedenen
Positionierungstests hat sich herausgestellt, dass bei einer Positionierung der Kameras auf
Höhe der Ränder des Smartboards und einer Entfernung zum Smartboard von ca. 3,7 m die
Kameras nicht höher als 2,8m positioniert werden können, da dann der Boden der Szene
durch das OpenNI Framework nicht mehr richtig bestimmt werden kann. Das führt dazu,
dass die Personen in der Szene fälschlicher Weise mit dem Boden vermischt werden, da
dieser nicht mehr berücksichtigt werden kann. Der rechte Teil der Abbildung 3 zeigt dieses
Verhalten. Die Vermischung mit dem Boden führt im weiteren Verlauf zu Fehlerkennungen
durch die Personenverfolgungsalgorithmen, was eine Weiterverarbeitung der Daten
9 2. Vorbereitungen
Moritz Wiechers
verhindern würde. Die maximale Höhe nimmt bei näherer Positionierung zum Smartboard
ab, da auch der Winkel, in dem die Kamera die Szene aufnimmt, entsprechend steiler wird.
ABBILDUNG 3 POSITIONIERUNGSTEST DER KAMERAS IM MODERATIONSLABOR (LINKS), FEHLERHAFTE BENUTZERSEGMENTIERUNG DURCH FALSCHE BODENERKENNUNG (RECHTS)
Um Situationen zu verhindern, in denen eine Person durch eine andere Person von beiden
Kameras nicht mehr gesehen wird, sollten die Kameras aus unterschiedlichen Winkeln auf
die Szene blicken. Dazu müssen sie weiter auseinander positioniert werden, was wiederum
den gemeinsamen Schnittbereich verkleinert und eine korrekte Zusammenführung der
Personenverfolgungsalgorithmen erschwert. Zudem ändert sich dadurch der
Aufnahmebereich vor dem Smartboard so, dass in der Mitte befindliche Personen bis zu ca.
2,8 m, am Rand aber nur noch bis ca. 1,4 m erkannt werden. Die Abbildung 4 zeigt diese
unterschiedlichen Aufnahmebereiche ziemlich deutlich.
ABBILDUNG 4 UNTERSCHIEDLICHE AUFNAHMEBEREICHE DURCH SEITLICHERE POSITIONIERUNG DER KAMERAS. (LINKS: MITTIG, RECHTS: AUßEN)
Die für das Szenario optimale Position ist die in Abbildung 4 (links) erkennbare
Positionierung. Mit Blick in Richtung des Smartboards befinden sich beide Kameras ca. 3,7 m
von dem Smartboard entfernt und 2,8m hoch. Die linke Kamera ist 1,2 m von den Lamellen
10 2. Vorbereitungen
Moritz Wiechers
des Moderationslabors und die rechte Kamera 1,2 m von der rechten Wand entfernt. Neben
der Auswahl der Positionierung musste eine Halterung für die Kameras beschafft werden,
die in die gegebene Umgebung integriert werden sollte. Die Halterungen, die an der Decke
befestigt werden sollen, müssen einmal für die dünnen Querbalken im Moderationslabor
und einmal für die Anbringung der Kinect modifiziert werden, da es für die gewünschte
Positionierung keine fertige Halterung gibt.
2.2 Das Framework OpenNI
2.2.1 Architektur
Das OpenNI Framework besteht grob aus drei unterschiedlichen Ebenen. Die unterste Ebene
bildet die Hardware, die die Daten für das OpenNI Framework bereitstellt. Im Rahmen dieser
Arbeit wurde die Kamera Kinect von Microsoft benutzt, jedoch ist auch eine Benutzung
anderer Hardware möglich. Die mittlere Ebene bildet das OpenNI Interface. Dieses
kommuniziert auf der einen Seite mit der Hardware und stellt auf der anderen Seite für die
obere Ebene, die Applikationen, Funktionalitäten bereit. Zusätzlich bietet das Interface die
Möglichkeit verschiedene Middlewarekomponenten einzubinden, um das Framework zu
erweitern.
ABBILDUNG 5 OPENNI FRAMEWORK ARCHITEKTUR
11 2. Vorbereitungen
Moritz Wiechers
Das OpenNI Framework stellt selbst grundlegende Zugriffsmöglichkeiten auf die Daten des
Sensors dar und kann durch eine Middleware für die Verarbeitung dieser Daten zu anderen
Auswertungszwecken, wie z.B. der Benutzersegmentierung, erweitert werden. Die
ausgewählte Lösung benutzt die Middleware NITE von PrimeSense. Diese stellt den für diese
Arbeit besonders wichtigen Benutzergenerator zur Verfügung und erweitert das OpenNI
Framework noch um weitere Funktionalitäten, wie die Analyse der Szene oder das Erkennen
von Handgesten.
2.2.2 Verwendung
Das OpenNI Framework verwendet sogenannte Nodes, die eine eigenständige Einheit
darstellen und spezifische Daten zur Verfügung stellen, sei es auf Rohdatenebene oder über
eine Middleware auf einem hohen Datenniveau. Das OpenNI Framework bietet von Haus
aus folgende implementierte Nodes: Gerät, Tiefengenerator, Bildgenerator, IR-Generator,
Audiogenerator. Dazu kommen Nodes, die durch entsprechende Middleware umgesetzt
werden können: Gestengenerator, Szenenanalysator, Handdetektor, Benutzergenerator. Die
Daten, die das Framework liefert und die für diese Arbeit relevant sind, sind die des
Tiefengenerators, des Bildgenerators und des Benutzergenerators. Die Kamera hat eine
Auflösung von 640x480, das ergibt 307200 Pixel. Der Tiefengenerator ermittelt zu jedem
dieser Pixel den Abstand zur Kamera. Die Ausgabe des Tiefengenerators ist ein Array der
Größe 307200, in dem die Entfernung in mm zum jeweiligen Bildpunkt steht. Der
Bildgenerator ordnet jedem Pixel eine 3Byte RGB-Farbe zu. Die Ausgabe ist ein Array,
bestehend aus 307200*3 Einträgen, wobei pro Pixel jeweils die drei Farbkomponenten als
Byte enthalten sind. Der Benutzergenerator ordnet jedem Pixel eine Benutzer ID zu. Erkennt
der Benutzergenerator eine Person, so erhält diese eine ID, die größer als 0 ist. Alle Pixel, die
keiner Person zugeordnet werden, erhalten die ID 0. Anzumerken ist noch, dass der
Tiefensensor und der Bildgenerator bei der Kinect nebeneinander angeordnet sind. Dadurch
ergibt sich ein Versatz, wenn man die Daten des Tiefensensors und des Bildgenerators
übereinander legen möchte. Das OpenNI Framework bietet die Möglichkeit, dies anhand von
voreingestellten extrinsischen Parametern für die Kinect automatisch durchzuführen. Zu
beachten ist, dass das Tiefenbild dadurch etwas kleiner wird (schwarzer Rand am Tiefenbild).
Für die zu analysierende Szene erhält man also insgesamt für jeden Bildpunkt die
Informationen, wie weit dieser von der Kamera entfernt ist, welchen Farbwert er besitzt und
12 2. Vorbereitungen
Moritz Wiechers
ob er zu einem erkannten Benutzer gehört oder nicht. Aufbauend auf diesen Informationen
kann eine Applikation entwickelt werden, die diese weiterverarbeitet.
2.3 Anmerkungen zur Benutzung zweier Kameras (OpenNI)
Während der Projektarbeit hat sich herausgestellt, dass eine Benutzung eines separaten
Rechners pro Kinect ausgeschlossen ist, da die Bandbreite der zu übertragenden Daten für
die vorhandene Infrastruktur (100Mbit Leitung) zu gewaltig ist. Generell ist bei der
Verwendung von mehreren Kinects an einem Rechner zu beachten, dass jede Kinect mehr
als 50% der USB 2.0 Bandbreite beansprucht und so nur eine Kinect pro USB Hub
angeschlossen werden kann. Als erstes muss also herausgefunden werden, welche USB-
Anschlüsse am Rechner nicht über dasselbe USB Hub verfügen, um die beiden Kinects richtig
anzuschließen. Bei der Verwendung zweier Kinects über das OpenNI Framework sind
zusätzlich einige Dinge zu beachten, die nicht dokumentiert sind. Zudem gibt es einige Fehler
im Framework, die eine Verwendung zweier Kameras in einer Applikation verhindern. Bei
der Arbeit mit dem OpenNI Framework ist es prinzipiell möglich mehrere Kinects zu
benutzen. Der Tiefengenerator und der Bildgenerator funktionieren einwandfrei. Der
Benutzergenerator allerdings birgt einen Fehler im Framework, der zu Fehlern bei der
Benutzererkennung führt. Nach ausgiebigem Kontakt mit einem Mitarbeiter der Firma
Primesense, die das OpenNI Framework entwickelt, stellte sich heraus, dass es mit Hilfe
eines schnellen Bugfix möglich ist, zwei Benutzergeneratoren gleichzeitig zu betreiben,
indem unterschiedliche Versionen des Benutzergenerators verwendet werden. Dennoch
kommt es nach einer gewissen Zeit zu einer Vermischung der Benutzer, wie aus Abbildung 6
ersichtlich wird. Dabei wird der in der rechten Kamera erkannte Benutzer auch in der linken
als ein Benutzer erkannt. Jedoch wird der zu erkennende Benutzer am rechten Rand der
linken Kamera nicht erkannt. Dieser Fehler macht die Nutzung zweier Kinects über das
OpenNI Framework in einer Applikation unmöglich. Diese Erkenntnis führt dazu, dass jede
Kamera in einer separaten Applikation auf dem Rechner verwendet werden muss und die
Daten dieser Applikationen zusammengeführt werden müssen. In der Umsetzung
kommunizieren die beiden Applikationen im Rahmen einer Client-Server-Architektur über
Sockets (TCP/IP). Eine genauere Beschreibung der Umsetzung und der damit verbundenen
Probleme findet sich im Abschnitt 3.4.2.
13 2. Vorbereitungen
Moritz Wiechers
ABBILDUNG 6 VERMISCHUNG DER BENUTZER BEI DER VERWENDUNG ZWEIER KAMERAS IN DERSELBEN APPLIKATION
2.4 Sonstiges zur Arbeit mit OpenNI und dem Java Wrapper
Performanceprobleme
Durch die intensive Arbeit mit dem JavaWrapper des Frameworks sind zwei Probleme
aufgetaucht. Diese Probleme beeinflussen die Performance der Applikation leider so stark,
dass sie nicht einsatztauglich ist. Zum einem wird beim Abruf der neuen Daten der Kinect
über die Generatoren jedes Mal ein neuer Puffer angelegt, der kontinuierlich Speicher
alloziert, und zum anderen werden unnötige Abfragen an die Hardware gestellt, wenn die
Funktion zur Umrechnung von Realweltkoordinaten in projizierte Koordinaten benutzt wird.
Beide Probleme können durch eigene Implementationen umgangen werden. Um das
Problem des ständigen Initiierens des Puffers zu umgehen, wird eine entsprechende native
Methode des Frameworks aufgerufen, die die Daten lediglich in den Puffer kopiert. Dazu ist
eine Klasse im Paket org.OpenNI zu erzeugen, die folgende Methode bereitstellt:
Der Methode wird der bereits benutzte Puffer mit seiner Länge und einem Zeiger auf den
entsprechenden Generator übergeben. Anschließend enthält der übergebene Puffer die
neuen Daten. Die genaue Verwendung wird aus der Datei Kinect.java in der eingereichten
Softwarelösung ersichtlich. Das Framework bietet zudem die Möglichkeit, anhand der durch
die Hardware gegebenen Parameter eine Umrechnung von projektiven Koordinaten in
Realweltkoordinaten durchzuführen. Projektive Koordinaten beinhalten für jeden Pixel
rechnerisch aus der Auflösung(𝑋𝑟𝑒𝑠 ∗ 𝑌𝑟𝑒𝑠) die jeweilige X (𝑋𝑝𝑟𝑜𝑗) und Y (𝑌𝑝𝑟𝑜𝑗) Koordinate
im Bild und den zugehörigen Tiefenwert Z. Realweltkoordinaten geben zu jedem dieser
14 2. Vorbereitungen
Moritz Wiechers
Punkte die Koordinaten im Raum in mm an. Die vom Framework angebotene Methode
„ConvertProjectiveToRealWorld“ zur Umrechnung birgt leider das Problem, dass ständig auf
Hardwareebene Anfragen an die Kamera gestellt werden, die das System auslasten und so
eine Nutzung der Funktion unmöglich machen. Im Entwicklerforum des Frameworks wurde
eine Lösung erarbeitet, die nur einmal die Parameter der Hardware abfragt9. Dabei wird
anfangs der Sichtbereich der Kamera in horizontaler (FOVH) und vertikaler (FOVV) Richtung
in Radiant ermittelt. Dazu bietet das Framework die entsprechende Funktion
„getFieldOfView“ des Tiefengenerators. Danach wird für jeden Punkt die Realweltkoordinate
nach folgender Formel berechnet:
XRW = �𝑋𝑝𝑟𝑜𝑗𝑋𝑟𝑒𝑠
− 0,5� ∗ z ∗ 𝑋𝐹𝑜𝑉
YRW = �0,5 −𝑌𝑝𝑟𝑜𝑗𝑌𝑟𝑒𝑠
� ∗ z ∗ 𝑌𝐹𝑜𝑉
ZRW = 𝑧
Mit 𝑋𝐹𝑜𝑉 = tan �𝐹𝑂𝑉𝐻2� ∗ 2 und 𝑌𝐹𝑜𝑉 = tan �𝐹𝑂𝑉𝑉
2� ∗ 2
Durch diese Optimierung kann die Berechnung in Echtzeit erfolgen. Die Umsetzung befindet
sich in der Datei Transformations.java in der eingereichten Softwarelösung.
Fehlende Ansteuerung des Motors
Das OpenNI Framework bietet derzeit keine Funktionalitäten, um den Motor der Kinect
anzusteuern. Um trotzdem innerhalb der zu erstellenden Applikation eine Steuerung des
Motors zu ermöglichen, kann mittels libusb-win3210 ein USB-Treiber für die
Motoransteuerung erzeugt werden, der dann über den libusb-win32 Java Wrapper11 benutzt
werden kann. Dr. Andrew Davison erklärt im 6. Kapitel seines Buchs „Kinect Open Source
Programming Secrets“ detailliert, wie solch ein Treiber erstellt und wie u.a. der Motor der
Kamera angesteuert wird. Dabei ist zu beachten, dass zur Benutzung von zwei Kameras der
beschriebene Quellcode etwas modifiziert werden muss. In meiner Implementierung in der
Datei MotorCommunicator.java wird die erste Kinect genauso initialisiert wie im Beispiel von
Dr. Andrew Davison:
9 Quelle: https://groups.google.com/d/msg/openni-dev/BayNHv_sgEg/E56061mf92cJ 10 Quelle: http://sourceforge.net/apps/trac/libusb-win32/wiki 11Quelle: http://libusbjava.sourceforge.net/wp/
15 2. Vorbereitungen
Moritz Wiechers
12 Die zweite Kinect wird dann allerdings folgendermaßen initialisiert:
Durch diese Modifikation ist es möglich, mehrere Kinects per libusb-win32 anzusteuern. Neben der Ansteuerung des Motors wird so auch der Zugriff auf die LED und den Lagesensor der Kinect möglich.
2.5 Zusammenfassung der wichtigsten Erkenntnisse
Dieses Kapitel hat die nötigen Vorbereitungen und Besonderheiten des OpenNI Frameworks
erörtert, angefangen bei der Positionierung, die unter Berücksichtigung mehrerer
Einflussfaktoren wie Überlagerungshäufigkeit, Funktionalität des Algorithmus‘ und
aufzunehmender Bereich bestimmt werden muss. Dabei stellte sich eine höhere
Positionierung der Kamera für die Überlagerungshäufigkeit als positiv, aber für die
Funktionalität des Algorithmus als negativ heraus. Eine Positionierung nah am Smartboard
bewirkt eine Steigerung des nötigen Neigungswinkels und so auch geringere Funktionalität
des Algorithmus‘. Für eine bessere Abdeckung des Aufnahmebereichs bewährte sich
ebenfalls eine Positionierung weiter entfernt vom Smartboard. Bei der Verwendung zweier
Kinects ist zu beachten, dass diese über separate USB-Hubs angeschlossen und bedingt
durch das Framework OpenNI in getrennten Applikationen verwendet werden müssen.
Zudem sind noch einige Performanceprobleme des Frameworks zu beheben, bevor im
Rahmen dieser Arbeit mit der Entwicklung begonnen werden kann.
12 Vgl. Davison, Andrew (2012), S.141
16 3. Prototyp
Moritz Wiechers
3 Prototyp
In diesem Kapitel, dem Hauptteil der Arbeit, wird der konzipierte und entwickelte Prototyp
beschrieben. Dazu zählt eine grobe Beschreibung der Anforderung, eine allgemeine
Erläuterung des Server Client/Konzepts sowie der Aufbau der jeweiligen
Softwarekomponenten und eine detaillierte Betrachtung besonders wichtiger Aspekte der
Lösung. Dabei wird erst das jeweilige konzeptionelle Vorgehen, zum Teil aus meiner
Projektarbeit, und anschließend die implementierte Lösung vorgestellt. Der komplette
Quellcode wird in digitaler Form eingereicht.
3.1 Anforderungen
Nach der Entscheidung für das OpenNI/NITE Framework wird auf dessen Grundlage ein
Prototyp entwickelt, der die Möglichkeiten und die Realisierbarkeit des Projektes darstellen
soll. Der Prototyp soll mit mehreren Kameras (2 Kinects) umgehen können und zusammen
mit dem Smartboard innerhalb des SeeMe-Editors einsetzbar sein. Die Arbeit mit zwei
Kameras erfordert das Herstellen eines gemeinsamen Koordinatensystems und eine
Zusammenführung der getrennt laufenden Personenverfolgungsalgorithmen (siehe. 1.2,
3.2). Weiterhin soll der Prototyp bei Klick auf das Smartboard den entsprechenden Benutzer
ermitteln, der den Klick durchgeführt hat. Innerhalb des SeeMe-Editors soll diese Fähigkeit in
das Multi-Action-Multi-User-Konzept eingebaut werden, um z.B. Verschiebungsaktionen
durchführen zu können, ohne eine manuelle Zuordnung des jeweiligen Benutzers zu einer
Operation vornehmen zu müssen. Zudem soll die Ansteuerung der Kameras vom SeeMe-
Editor hardwaretechnisch getrennt realisiert werden. Diese Anforderung führt dazu, dass der
Prototyp aus zwei Teilsystemen bestehen muss, die über ein Netzwerk kommunizieren und
so im Rahmen einer Client-Server-Struktur umgesetzt wird. Zum einen ist ein Client für das
Smartboard zu entwickeln, welcher im SeeMe-Editor integriert ist, und zum anderen ein
Server, an dem die Kameras angeschlossen sind, welcher diese koordiniert und
Abfragemöglichkeiten für die Clients bereitstellt.
3.2 Software-Prozessmodell
Die Einordnung der Vorgehensweise der Softwareentwicklung in ein Software-Prozessmodell
soll einen Einblick in die Arbeitsorganisation und den Arbeitsablauf während der
Bachelorarbeit geben. Software-Prozessmodelle lassen sich grob in schwergewichtige und
17 3. Prototyp
Moritz Wiechers
leichtgewichtige Prozessmodelle unterteilen. Die Unterscheidung liegt hier im Bereich der
Flexibilität der Modelle. Schwergewichtige Modelle sind meist starr, formal und stark
dokumentengestützt. Dadurch eignen sie sich besonders für Projekte, in denen die
Anforderungen an die Software und die Projektplanung klar definiert sind. Bei
leichtgewichtigen Modellen sind die Anforderungen an die Software nicht vor
Entwicklungsbeginn bekannt und können sich während der Entwicklungsphase noch ändern.
Eine Prototypentwicklung in der Forschung ist meist im Rahmen von leichtgewichtigen
Prozessmodellen einzuordnen, da flexibel auf eventuelle Probleme und neue Anforderungen
reagiert werden muss. Die Dokumentation und Planung jeder Entwicklungsphase ist
sekundär. Im Bereich der leichtgewichtigen Prozessmodelle finden sich die sogenannten
agilen Prozessmodelle, bei denen funktionierender Code im Vordergrund steht. Das Agile
Manifest (Beck et al. 2001) dient als Grundlage dieser Prozessmodelle und definiert vier
Leitsätze für die agile Softwareentwicklung. Die vier Leitsätze besagen, dass die Beteiligten
und deren Interaktion wichtiger als Prozesse und Modelle sind, dass lauffähige Software
wichtiger ist als eine umfassende Dokumentation, die Zusammenarbeit mit dem Kunden
wichtiger ist als Vertragsverhandlungen und dass das Eingehen auf Änderungen und
Anforderungen wichtiger ist als die sture Verfolgung eines Plans. Die Leitsätze werden
während der Bachelorarbeit größtenteils eingehalten, wobei stärkere Anforderungen an die
Dokumentation der Software gestellt werden, um eine Weiterverwendung zu gewährleisten
und um auf die wichtigsten Aspekte des verwendeten Systems hinzuweisen. Daher ist das
Vorgehen während der Bachelorarbeit in Bezug auf die Softwareentwicklung bei den agilen
Softwareentwicklungsmethoden einzuordnen.13
3.3 Gesamtarchitektur
Die Gesamtarchitektur soll den Zusammenhang der einzelnen Komponenten des Prototyps
und der Kameras verdeutlichen. Das System besteht aus zwei Rechnern und zwei Kameras.
Der erste Rechner fungiert als Server und verwaltet die Kinects. Die beschriebene
Problematik in Abschnitt 2.3 führt dazu, dass auf dem Server zwei Applikationen laufen, die
jeweils eine Kinect über das OpenNI Framework ansprechen und miteinander
kommunizieren können. Auf dem zweiten Rechner wird der Client ausgeführt, der durch die
13 Vgl. Hanser, Eckhart (2010), S. 5-10
18 3. Prototyp
Moritz Wiechers
Interaktionswand gesteuert wird. Der Client nimmt Benutzeranfragen entgegen und benutzt
bei Bedarf den Server bezüglich der Frage nach der interagierenden Person.
ABBILDUNG 7 GESAMTSOFTWAREARCHITEKTUR
3.4 Umsetzung Server
3.4.1 Softwarestruktur
Die Software soll möglichst schlicht aufgebaut sein und der einzelnen Aufgabe nach
klassenweise getrennt umgesetzt werden. Die Abbildung 8 zeigt die Grobstruktur des Server-
Prototypen, welche Klassen es gibt und wie diese miteinander verknüpft sind. Die Software
soll möglichst modular aufgebaut sein, d.h. z.B., dass die Klassen, so weit es geht, lose
gekoppelt interagieren, um eine leichte Erweiterung zu gewährleisten.
19 3. Prototyp
Moritz Wiechers
ABBILDUNG 8 GROBSTRUKTUR DES PROTOTYPEN
Im Folgenden werden die einzelnen Klassen mit ihren Funktionalitäten und das
Zusammenspiel mit anderen Klassen erläutert. Die Grundklasse bildet die Klasse OpenNI,
welche sowohl die Kinects als auch die UpdateableComponents verwaltet. Wird das
Programm gestartet, so übernimmt die Klasse die Initialisierung des Frameworks und die
Einbindung der jeweils benötigten Generatoren (Tiefen-, Bild- und Benutzergenerator). Die
Kinect und auch die UpdateableComponents werden bei neu bereitgestellten Daten durch
das Framework über den UpdateThread aufgerufen. Genauer: Jede Klasse, die das Interface
UpdateableComponent implementiert, muss die Methode „update“ bereitstellen, die bei
erfolgter Listeneranbindung aufgerufen wird, sobald neue Daten vorhanden sind. Das
ermöglicht eine lose Kopplung z.B. verschiedener grafischer Oberflächen, die die Daten des
Frameworks benutzen, um z.B. das Tiefenbild anzuzeigen. Dabei greifen die Komponenten
nicht direkt auf die Daten des Frameworks zu, sondern auf die Daten, die die Klasse Kinect
bereitstellt. Dazu gehören Daten des Tiefengenerators, des Usergenerators und des
Bildgenerators in verschiedenster Form. Die Daten des Tiefengenerators werden z.B. in
projektiver Form, in Koordinatenform für die jeweilige Kamera und in transformierter
Koordinatenform des gemeinsamen Koordinatensystems bereitgestellt. Die Aktualisierung
der Daten übernimmt die Klasse Kinect selbst, die spezielle Umrechnung übernimmt die
Klasse Transformation, die an die jeweilige Kinect gekoppelt ist (Genaueres in Abschnitt
3.4.3). Zudem prüft die Klasse Kinect die erhaltenen Daten auf bestimmte Events, wie das
Eintreten und das Austreten eines Benutzers. Klassen können sich hier flexibel an die Events
in Form des Listenerkonzepts anhängen. Die in Abschnitt 2.3. beschriebene Besonderheit
20 3. Prototyp
Moritz Wiechers
des Frameworks bei Verwendung mehrerer Kameras führt dazu, dass über eine Client-
Server-Architektur die zweite Kinect angebunden wird. Eine Client-Server Architektur
ermöglicht für die Zukunft eine leichte Anschlussmöglichkeit weiterer Kameras an das
System. Eine eingehende Verbindung erzeugt ein neues Objekt der Klasse Kinect, die intern
eine spezielle Behandlung der Daten erfordert, nach außen hin allerdings für z.B. die
UpdateableComponents dieselben Daten bereitstellt. Die in Abschnitt 2.4 beschriebene
Problematik der Steuerung des Motors wird durch die Klasse MotorCommunicator gelöst.
Die Klasse erzeugt bei Programmstart für jede angeschlossene Kinect über die lib-usb
Schnittstelle ein Objekt, über das dann Veränderungen am Motor vorgenommen werden
können. Da die Anbindung außerhalb des Frameworks stattfindet, muss eine Zuordnung von
USB-Gerät zu den im Framework verwendeten Geräten stattfinden. Der UserManager stellt
die Zusammenführung der getrennt laufenden Personenverfolgungsalgorithmen dar. Er
reagiert dafür auf Benutzerevents der Kinects. Die in Abschnitt 3.4.5 beschriebenen
Fehlerüberprüfungsroutine wird allerdings über die Implementierung der Schnittstelle
UpdateableComponent realisiert. Die Klasse Board stellt die in Abschnitt 3.4.5. beschriebene
Abbildung des Smartboards in der Software dar. Zudem übernimmt diese die Umrechnung
von Klickkoordinaten in Raumkoordinaten. Die Kommunikation zum Client (SeeMe-Editor,
siehe Abschnitt 3.4.6) erfolgt durch eine Client-Server-Architektur, wobei der Server in Form
der Klasse BoardServer umgesetzt wird und neben der Kommunikation auch die Anfragen
bearbeitet, also z.B. zu gegebenem Klickpunkt den entsprechenden Benutzer ermittelt. Zur
Durchführung der nötigen Kalibrierungen und anderen Vorbereitungen werden grafische
Oberflächen benötigt, die einmal Daten der Kinects repräsentieren und zum anderen die
Aufnahme gewisser Daten ermöglichen. Das Panel „TrackerPanelForOneKinect“ stellt die
Tiefendaten und bei Bedarf auch Bilddaten einer Kamera dar und ermöglicht das Selektieren
einzelner Punkte im Bild für die Abbildung des Smartboards und die zwischenzeitlich
benötigte Aufnahme des Fußbodens. Des Weiteren wurden ein CalibrationPanel und ein
ControlPanel eingebaut, welche für die Kalibrierung der Koordinatensysteme und das
Speichern und Laden aller benötigten Voreinstellungen benötigt werden. Um den
Prototypen zu debuggen und auch die Situation vor dem Smartboard zu veranschaulichen,
wurden mit Hilfe von Java3D dreidimensionale Ansichten der aufgenommenen Tiefen- und
Benutzerdaten erzeugt. Die Klassen PointCloud und PointCloudPanel stellen diese
Funktionalitäten zur Verfügung.
21 3. Prototyp
Moritz Wiechers
3.4.2 Einbindung von zwei Kameras in ein gemeinsames Softwaresystem
Wie schon im Abschnitt 2.3 erläutert, führt ein Bug im benutzten Framework dazu, dass jede
Kinect in einer separaten Applikation verwendet werden muss. Dabei fungiert ein Teil der
Software als Server, der schon bereits auf eine der beiden Kinects zugreift, und ein Teil als
Client, der ausschließlich die Daten der anderen Kinect abfragt und diese an den Server
sendet. Zur Kommunikation wurde ein Protokoll entwickelt, das zum einen verschiedene
Zustände einnehmen kann und zum anderen die Daten bereithält, die übertragen werden
sollen. Zudem ist zur eindeutigen Zuordnung die GeräteID der Kinect und ein Timestamp
eingebaut. Der Server wartet nach Programmstart auf eingehende Verbindungen. Der Client
verbindet sich mit dem Server und sendet diesem seine GeräteID als Initialisierung zu. Der
Server erzeugt daraus ein neues Objekt der Klasse Kinect und übergibt diese an die
Verwaltungsklasse OpenNI. Wenn der Client neue Daten der Kinect ausgelesen hat, sendet
er diese anschließend an den Server. Der Server nimmt die Daten entgegen und stellt dem
Rest des Programms diese in derselben Form wie die eigene verwaltete Kinect zur
Verfügung. Abbildung 9 zeigt zum einem das verwendete Protokoll und zum anderen die
Verknüpfung von Server und Client, wobei die Funktionalitäten sendData und aquireData
iterativ ausgeführt werden.
ABBILDUNG 9 LINKS: DAS VERWENDETE PROTOKOLL; RECHTS: AUSSCHNITT SEQUENZDIAGRAMM VERBINDUNGSAUFBAU
Bei der softwaretechnischen Umsetzung ist bei der Verwendung von Objektserialisierung zur
Speicherung bzw. Übertragung per Sockets zu beachten, dass der ObjectOutputStream der
Java Bibliothek die zu serialisierenden Objekte zwischenspeichert. Wenn beim nächsten
Serialisieren keine Veränderung aufgetreten ist, wird das zwischengespeicherte Objekt
erneut versendet. Bei der Überprüfung auf Veränderung werden aber nur die Referenzen
des Objekts überprüft, nicht deren Inhalt. Das führt dazu, dass trotz veränderter Daten die
zwischengespeicherten Daten übertragen werden. Um dies zu umgehen, muss der
ObjectOutputStream resettet werden. Das Resetten dauert je nach Übertragungsdaten eine
gewisse Zeit. Um diese Zeit möglichst gering zu halten, werden nur die Rohdaten der Kinect
22 3. Prototyp
Moritz Wiechers
übertragen und diese dann im Serverprogramm weiterverarbeitet (z.B. Tiefenwerte
transformiert). In Folge der Benutzung von Sockets und der unterliegenden TCP/IP Schicht
werden zusätzlich Headerdaten mitgesendet, die die zu transportierende Datengröße
erweitern. Anfängliche Bedenken bezüglich der Performance der Methode konnten durch
Tests widerlegt werden: Die Übertragung kann mehr als 25 Mal pro Sekunde erfolgen. Dieser
Wert reicht für den Prototypen vollkommen aus. Nach der Lösung dieses technischen
Problems kann man sich nun den konzeptionellen Anforderungen widmen.
3.4.3 Zusammenführung der Koordinatensysteme
Eigene Kalibrierungsversuche innerhalb des Prototypen
Der erste Schritt des erarbeiteten Konzepts sieht die Zusammenführung der beiden
Koordinatensysteme der Kameras vor. Ziel ist ein gemeinsames Koordinatensystem und
Umrechnungsparameter für die Kameras, damit die aufgenommenen Punkte in das neue
Koordinatensystem transformiert werden können. Die erste Idee bestand darin, drei Punkte
im gemeinsamen Schnittbereich der Kameras zu selektieren und die entsprechenden
Punktkoordinaten der jeweiligen Kamera zu benutzen, um eine Transformationsmatrix zu
berechnen. Dazu sollte die Transformationsgleichung
𝑀𝑡 ∗ �⃗� = 𝑣𝑡���⃗
mit den entsprechenden drei Punktpaaren (�⃗� = 𝑣𝑡���⃗ ) nach 𝑀𝑡 aufgelöst werden. Erste
Versuche zeigten schnell, dass die Aufnahme der Punkte nicht exakt genug erfolgen kann.
Zum einem ist es schwer bei der Auswahl der Punkte in der jeweiligen Kamera exakt
denselben Punkt zu treffen, also ein korrespondierendes Punktepaar auszuwählen, und zum
anderen macht die vorherrschende Ungenauigkeit der Tiefenwerte eine genaue Aufnahme
unmöglich. Um dieser durch die Hardware gegebenen Ungenauigkeit entgegen zu wirken
wurden im nächsten Schritt mehrere Punkte aufgenommen und das entstandene
überbestimmte Gleichungssystem mittels Singulärwertzerlegung gelöst. Die
Singulärwertzerlegung ermöglicht die Bestimmung der Lösung entsprechend der Methode
der kleinsten Quadrate für das gegebene Gleichungssystem. Die Methode der kleinsten
Quadrate befindet die Lösung als die beste, bei der die summierte quadratische Abweichung
aller Messpunkte vom mathematischen Modell minimiert ist. Das Modell bezeichnet in
diesem Fall die Transformationsmatrix. Wegen der schon beschriebenen Problematik der
23 3. Prototyp
Moritz Wiechers
Aufnahme korrespondierender Punktpaare bildet auch die durch die Singulärwertzerlegung
bestimmte Transformationsmatrix ein unzureichendes Ergebnis. Mit dieser Erkenntnis kam
die Idee, die Punkte automatisiert im Bild erkennen zu lassen. Eine Implementierung eines
Algorithmus‘, der im Bild bestimmte Punkte auf z.B. einem Schachbrett erkennt und so
korrespondierende Punktpaare automatisch bestimmt, hätte aus zeitlichen Gründen die
vollständige Umsetzung des Konzepts verhindert. Aus diesem Grund und weil es bereits ein
speziell für die Kinect entwickeltes Programm zur Kalibrierung zweier Kameras mit dem
Namen „RGB-Demo“ gibt, wurde dieses Tool zur Bestimmung der extrinsischen Parameter
der Kameras benutzt.
Kalibrierung mit Hilfe der Software „RGB-Demo“
Die während der Bachelorarbeit verwendete Version des Kalibrierungstools „RGB-Demo“
wurde aufgrund der komfortableren Handhabung der Kalibrierung aus dem Quellcode
gebaut, da die aktuelle binäre Version dieses Feature nicht enthält. Zur Kalibrierung wird ein
Schachbrettmuster benötigt, das entsprechend der Entfernung zur Kamera groß genug sein
muss. Das verwendete Schachbrettmuster besteht aus 8 Spalten und 5 Zeilen und jedes
quadratische Feld hat eine Seitenlänge von 9,7cm. Um ein gutes Ergebnis der Kalibrierung zu
erhalten, sollte das Schachbrett in möglichst vielen verschiedenen Positionen aufgenommen
werden. Bei der Aufnahme wird das Schachbrettmuster in beiden Kameras erkannt und
entsprechende Punktpaare werden gebildet. Die Kalibrierung wird aus allen richtig
erkannten Punktpaaren vorgenommen. Das Ergebnis der Kalibrierung stellt die Angabe der
Lagebeziehung der einen Kamera zur anderen Kamera in Form von extrinsischen Parametern
dar.
ABBILDUNG 10 GRAFISCHE OBERFLÄCHE DES VERWENDETEN KALIBRIERUNGSTOOLS MIT KALIBRIERUNGSMUSTER (SCHACHBRETT)
24 3. Prototyp
Moritz Wiechers
Übertragung der externen Parameter in den Prototypen
Das verwendete Programm zur Kalibrierung der beiden Kameras gibt die Positionierung
zueinander in Form eines Translationsvektors 𝑡 und den Rotationswinkeln Rx, Ry und Rz in
Form von eulerischen Winkeln an . Anzumerken ist noch, dass das benutzte Kalibrierungstool
ein rechtshändisches Koordinatenssystem mit einer Rotationsrichtung gegen den
Uhrzeigersinn verwendet. Aus den erhaltenen Positionierungsdaten können die beiden
unterschiedlichen Kamerakoordinatensysteme zusammengeführt werden, indem jeder
Vektor der Kamerakoordinatensysteme transformiert wird. Die Benutzung der
Positionierungsdaten und die Berechnung werden im Folgenden kurz erläutert:
Aus den drei Rotationswinkeln lässt sich für jede Achse eine Rotationsmatrix aufstellen, die
in einem rechtshändischen, gegen den Uhrzeigersinn drehenden Koordinatensystem
folgendermaßen aussehen:
Berechnung der Rotationsmatrix:
Rotation um die X-Achse. (Rx ist der Rotationswinkel)
𝑋 = �1 0 00 cos(𝑅𝑥) sin(𝑅𝑥)0 − sin(𝑅𝑥) cos(𝑅𝑥)
�
Rotation um die Y-Achse. (Ry ist der Rotationswinkel)
𝑌 = �cos(𝑅𝑦) 0 − sin(𝑅𝑦)
0 1 0sin(𝑅𝑦) 0 cos(𝑅𝑦)
�
Rotation um die Z-Achse. (Rz ist der Rotationswinkel)
𝑍 = �cos(𝑅𝑧) sin(𝑅𝑧) 0− sin(𝑅𝑧) cos(𝑅𝑧) 0
0 0 1�
Diese drei Rotationsmatrizen können nun per Matrixmultiplikation in eine gemeinsame
Rotationsmatrix R überführt werden, indem diese miteinander multipliziert werden:
𝑅 = 𝑋 ∗ 𝑌 ∗ 𝑍
⇔𝑅 = �cos(𝑅𝑦) ∗ cos(𝑅𝑧) cos(𝑅𝑦) ∗ sin(𝑅𝑧) − sin(𝑅𝑦)
cos(𝑅𝑧) ∗ sin(𝑅𝑥) ∗ sin(𝑅𝑦) − cos(𝑅𝑥) ∗ sin(𝑅𝑧) cos(𝑅𝑥) ∗ cos(𝑅𝑧) + sin(𝑅𝑥) ∗ sin(𝑅𝑦) ∗ sin(𝑅𝑧) cos(𝑅𝑦) ∗ sin(𝑅𝑥)sin(𝑅𝑥) ∗ sin(𝑅𝑧) + cos(𝑅𝑥) ∗ cos(𝑅𝑧) ∗ sin(𝑅𝑦) cos(𝑅𝑥) ∗ sin(𝑅𝑦) ∗ sin(𝑅𝑧) − cos(𝑅𝑧) ∗ sin(𝑅𝑥) cos(𝑅𝑥) ∗ cos(𝑅𝑦)
�
25 3. Prototyp
Moritz Wiechers
Berechnung der Transformation
Bei der Berechnung eines transformierten Vektors 𝑣𝑡 �����⃗ wird zuerst der Translationsvektor 𝑡 zu
dem Ausgangsvektor �⃑� addiert, um die Translation umzusetzen. (Zwischenvektor 𝑣𝑡𝑙�����⃑ )
𝑣𝑡𝑙�����⃗ = �𝑣𝑥𝑣𝑦𝑣𝑧� + �
𝑡𝑥𝑡𝑦𝑡𝑧�
Anschließend wird der verschobene Vektor mit Hilfe der Rotationsmatrix gedreht, in dem die
Rotationsmatrix R mit dem Vektor 𝑣𝑡𝑙�����⃗ multipliziert wird.
𝑣𝑡���⃗ = 𝑅 ∗ 𝑣𝑡𝑙�����⃗
= �cos(𝑅𝑦) ∗ cos(𝑅𝑧) ∗ 𝑣𝑡𝑙𝑥 + cos(𝑅𝑦) ∗ sin(𝑅𝑧) ∗ vtly − sin(𝑅𝑦) ∗ 𝑣𝑡𝑙𝑧
�cos(𝑅𝑧) ∗ sin(𝑅𝑥) ∗ sin(𝑅𝑦) − cos(𝑅𝑥) ∗ sin〖(𝑅𝑧)� ∗ 𝑣𝑡𝑙𝑥 + (cos(𝑅𝑥) ∗ cos(𝑅𝑧) + sin(𝑅𝑥) ∗ sin(𝑅𝑦) ∗ sin(𝑅𝑧)) ∗ 𝑣𝑡𝑙𝑦 + cos(𝑅𝑦) ∗ sin(𝑅𝑥) ∗ 𝑣𝑡𝑙𝑧〗(sin(𝑅𝑥) ∗ sin(𝑅𝑧) + cos(𝑅𝑥) ∗ cos(𝑅𝑧) ∗ sin(𝑅𝑦)) ∗ 𝑣𝑡𝑙𝑥 + 〖(cos〗(𝑅𝑥) ∗ sin(𝑅𝑦) ∗ sin(𝑅𝑧) − cos(𝑅𝑧) ∗ sin(𝑅𝑥)) ∗ 𝑣𝑡𝑙𝑦 + cos(𝑅𝑥) ∗ cos(𝑅𝑦) ∗ 𝑣𝑡𝑙𝑧
�
Nach der erfolgreichen Kalibrierung kann auf der Grundlage des gemeinsamen
Koordinatensystems im nächsten Schritt die Personenverwaltung implementiert werden.
3.4.4 Personenverwaltung
Im folgenden Abschnitt ist unter dem Begriff „Person“ immer der reale Mensch im
Aufnahmebereich der Kamera und unter dem Begriff „Benutzer“ die Abbildung der Person in
der jeweiligen Kamera in Form von Punktwolken gemeint. Die Personenverwaltung sieht die
Zusammenführung der getrennt laufenden Personenverfolgungsalgorithmen vor. Basis der
Zusammenführung bilden immer die Punktwolken der jeweiligen Benutzer. Dabei ist die
unterschiedliche Perspektive jeder Kamera zu berücksichtigen, aus der die Personen
aufgenommen werden, da dadurch nicht in beiden Kameras derselbe Teil der Person
aufgenommen wird. Während der Bachelorarbeit wurden verschiedene Ideen für eine
Zusammenführung entwickelt und getestet. Die erste war die, Personen über den Abstand
ihrer Massenmittelpunkte zuzuordnen. Ist der Abstand zweier Massenmittelpunkte unter
einem Schwellwert, so handelt es sich höchstwahrscheinlich um eine Person. Diese Methode
hat den Nachteil, dass bei Überdeckungen der Personen oder nur Halbsichtbarkeiten der
Person am Rand der Kamera der Massenmittelpunkt einer Person aus beiden Perspektiven
stark unterschiedlich ist. Eine Verbesserung der Überlagerungsproblematik wurde im
zweiten Schritt erreicht, indem die Kopfpositionen der einzelnen Personen verglichen
26 3. Prototyp
Moritz Wiechers
wurden, da diese durch die Kamerapositionierung seltener Überdeckt sind. Aber besonders
die Übergangsbereiche der Kameras, in denen oft nur Teile von Personen in einer der beiden
Kameras zu sehen sind, machte es unmöglich die Kopfposition korrekt zu bestimmen. Aus
dieser Problematik heraus wurde die Überprüfung auf den Bereich beschränkt, der für beide
Kameras sichtbar ist. Diesen Bereich zu bestimmen ist in Hinblick auf die Performance des
Prototypen erst einmal nur grob möglich. Dazu wird für jede Person in der jeweiligen Kamera
der umschließende Quader berechnet, der Schnittbereich dieser Quader ermittelt und die
aufgenommenen Punkte innerhalb dieses Quaders untersucht. Die Untersuchung beinhaltet
die Berechnung des Mittelpunktes der Punktwolke der jeweiligen Kamera innerhalb des
Quaders und die Berechnung des Abstandes dieser Mittelpunkte zueinander. Liegt der
Abstand unter einem Schwellwert, so ist die in den verschiedenen Kameras aufgenommene
Person höchstwahrscheinlich dieselbe. Bei den umschließenden Quadern (auch
Boundingboxes genannt) handelt es sich um achsenorientierte Quader, die durch die
Positionierung der Kameras und einen Winkel um den Horizont von ca. 30 Grad eine nicht
optimale Abdeckung der Person darstellt. Deshalb muss vor der Berechnung das
Koordinatensystem um diesen Winkel rotiert werden. Die beiden Kameras blicken mit einem
Winkel von 30 Grad auf die Szene und so kann das gemeinsam verwendete
Koordinatensystem um 30 Grad korrigiert werden. Die Abbildung 11 zeigt die dadurch
bewirkte Verbesserung der umschließenden Quader.
ABBILDUNG 11 UMSCHLIEßENDE QUADER EINER PERSON OHNE (LINKS) UND MIT (MITTE) KORREKTUR DES BLICKWINKELS DER KAMERAS; RECHTS: AUFTEILUNG DES QUADERS IN MEHRERE KLEINE GRÜNE QUADER
27 3. Prototyp
Moritz Wiechers
Die Zusammenführung von Benutzern findet immer dann statt, wenn eine der beiden
Kameras eine neue Person wahrnimmt. In kleinen Vortests, bei denen mehrere Personen vor
dem Smartboard interagierten, stellte sich schnell heraus, dass in speziellen
Überlagerungssituationen, bei denen Personen nah aneinander vorbei gehen, die
Erkennungsmethode zu Fehlzuordnungen führen kann. Dies liegt zum einem bei einer
Berührung der Personen an falschen Daten des Frameworks und zum anderen bei zu nahem
Passieren der Personen an dem Vergleich der Mittelpunkte innerhalb des Schnittquaders.
Die beschriebene Methode zur Zusammenführung der Benutzer ist an manchen Stellen nicht
genau genug und so entstehen auch Schnittquader mit anderen Personen, wodurch der
Vergleich der Mittelpunkte dieser Schnittquader zu Fehlern führen kann. Die Genauigkeit der
Methode wurde erhöht, indem der umschließende Quader in mehrere kleinere Quader
unterteilt wurde und die prozentuale Anzahl der gemeinsamen Teilschnittquader
berücksichtigt wird. Dabei ist einmal zu beachten, dass die Quader nicht zu klein sein dürfen,
da die Kameras aus unterschiedlichen Seiten auf die Person blicken und so nie exakt
dieselben Punkte aufnehmen. Zum anderen muss der Quader klein genug sein, um möglichst
wenig fehlerhafte Überschneidungen zu einer nahestehenden Person zu generieren. Die
Abbildung 12 zeigt eine Person mit den umschließenden Quadern (rot) , dem Schnittquader
(rot,fett) und den gemeinsamen Schnittquaderteilen (grün).
ABBILDUNG 12 EINE PERSON MIT DEN ENTSPRECHENDEN UMSCHLIEßENDEN QUADERN (ROTE LINIEN) IN DER JEWEILIGEN KAMERA (BLAUE & ROTE PUNKTE) UND DEN GEMEINSAMEN TEILQUADERN (GRÜN)
Bedingt durch die überlagernden Aufnahmebereiche der Kameras können, besonders beim
Eintreten einer Person im mittleren hinteren Bereich vor dem Smartboard, die Benutzer
nicht eindeutig zusammengefasst werden, da keine Schnittquader existieren. Deswegen und
28 3. Prototyp
Moritz Wiechers
besonders aufgrund der Tatsache der fehlerhaften Zuordnung durch das Framework heraus
muss in zeitlichen Abständen eine Überprüfung der Zuordnungen stattfinden, die dann,
wenn die Überlagerungssituation nicht mehr besteht, eine korrekte Zuordnung
wiederherstellt. Die Korrektur der Zuordnung sieht in der eingereichten Lösung so aus, dass
in einem ersten Schritt die falsch zugeordneten Benutzer getrennt werden, um anschließend
in einem zweiten Schritt wieder richtig zusammengesetzt zu werden. So wird sichergestellt,
dass nicht eine Person aus zwei Benutzern bestehen kann. Die Abbildung 13 zeigt die
beschriebene Problematik beim Eintritt einer Person und den Effekt der Korrektur. Die
Problematik bei Fehlzuordnung durch das Framework und den Effekt der Korrektur wird in
der Abbildung 14 ersichtlich.
ABBILDUNG 13 EINTRITT EINER PERSON IN DIE SZENE (MITTIG HINTEN), LINKS: BEIM ZUSAMMENFÜHREN DER BENUTZER EXISTIERT KEIN GEMEINSAMER SCHNITTQUADER, RECHTS: KORREKTUR NACH ZEITLICH VERSETZTER ÜBERPRÜFUNG (LINKS VON DER WEIßEN TRENNUNG IST IMMER DIE SICHT DER BEIDEN GETRENNT LAUFENDEN PERSONENVERFOLGUNGSALGORITHMEN, RECHTS IMMER DIE SICHT DER ZUSAMMENGEFÜHRTEN PERSONENVERFOLGUNGSALGORITHMEN)
ABBILDUNG 14 FEHLZUORDNUNG DURCH DAS FRAMEWORK (MITTE) UND DER ZUSTAND NACH DER KORREKTUR(RECHTS) (LINKS VON DER WEIßEN TRENNUNG IST IMMER DIE SICHT DER BEIDEN GETRENNT LAUFENDEN PERSONENVERFOLGUNGSALGORITHMEN, RECHTS IMMER DIE SICHT DER ZUSAMMENGEFÜHRTEN PERSONENVERFOLGUNGSALGORITHMEN)
Bei der Wiederherstellung der Zuordnungen ist es nicht immer möglich, den Zustand vor der
Fehlzuordnung vollständig zu rekonstruieren. Deshalb muss der Client der Softwarelösung
entsprechend informiert werden, wenn Korrekturen an der Zuordnung vorgenommen
werden, um auf solche Situationen zu reagieren. Die beschriebenen Probleme treten fast nur
bei einem Mehrpersoneneinsatz bei Überlagerungssituationen und Berührungen auf. Im
Abschnitt 4.3 werden u. a. verschiedene Verbesserungsvorschläge für die
Personenverwaltung in Bezug auf die erörterten Probleme beschrieben. Die
29 3. Prototyp
Moritz Wiechers
Personenverwaltung ermöglicht also die fehlerfreie Verfolgung einer Person über die
Kameragrenzen hinweg, wenn keine vollständigen Überlagerungen oder Berührungen
auftreten. Im Falle der Fehlzuordnung muss der Client entsprechende Funktionalitäten zur
Zuordnung anbieten. Die Abbildung 15 zeigt eine aufgenommene Person, die von der linken
Seite des Smartboards zur rechten Seite läuft, dabei erst von der einen Kamera, dann im
Schnittbereich von beiden Kameras und auf der rechten Seite nur noch von der anderen
Kamera gesehen wird. Dabei wird einmal die Sicht der beiden separaten
Personenverfolgungsalgorithmen (links) und direkt daneben die zusammengeführte Sicht
(rechts) dargestellt.
ABBILDUNG 15 VERFOLGUNG DES BENUTZERS ÜBER DEN SCHNITTBEREICH DER KAMERAS HINWEG (LINKS IMMER DIE SICHT DER BEIDEN GETRENNT LAUFENDEN PERSONENVERFOLGUNGSALGORITHMEN, RECHTS IMMER DIE SICHT DER ZUSAMMENGEFÜHRTEN PERSONENVERFOLGUNGSALGORITHMEN)
Aus dem eingereichten Quellcode wird ersichtlich, dass es viele Parameter gibt, die die
Zusammenführung und Überprüfung beeinflussen. Schwellwerte für die maximale Distanz
zweier Benutzer zueinander um sie als eine Person zu identifizieren oder aber der
prozentuale Anteil an Teilschnittquadern zweier Benutzer bestimmen das Verhalten des
Algorithmus wesentlich. Im Rahmen dieser Arbeit wurden unterschiedliche
Parameterkombinationen untersucht und die für am besten empfundene Kombination
eingestellt. Um die Personenverwaltung im Zusammenhang mit dem Smartboard nutzen zu
können, muss dieses im nächsten Schritt in dem gemeinsam verwendeten
Koordinatensystem der beiden Kameras abgebildet werden.
3.4.5 Abbildung des Smartboards
Um eine Zuordnung von Personen zu einer Interaktion an dem Smartboard zu ermöglichen,
muss das Smartboard innerhalb des Koordinatensystems der Kameras abgebildet werden.
Die Software soll eine Initialisierung der Wandposition für das Koordinatensystem der
Kameras bereitstellen. Dazu werden die 4 Eckpunkte des Smartboards abgeklebt, um so für
30 3. Prototyp
Moritz Wiechers
die Kameras erkennbar zu werden. Über die Software werden nun diese Eckpunkte
ausgewählt und die Wand als Rechteck in einer dreidimensionalen Welt dargestellt (siehe
Abbildung 15). Zudem muss der Software die Breite und Höhe des Clients in Pixel bekannt
sein, um nachher einen Klickpunkt z.B. innerhalb des SeeMe-Editors in Raumkoordinaten der
Kameras umzurechnen.
ABBILDUNG 16 ABBILDUNG DES SMARTBOARDS IN DAS KOORDINATENSYSTEM DER KAMERAS ALS REALSICHT (LINKS) UND ALS ANSICHT IN DER SOFTWARE (RECHTS)
Nach Abbildung des Smartboards kann nun zu einer bestimmten Klickkoordinate des
Smartboards der korrespondierende Punkt im Koordinatensystem der Kameras berechnet
werden. Die Transformation des Klickpunktes der Wand in das Koordinatensystem der
Kamera erfolgt durch eine Berechnung mit Hilfe der bekannten Eckpunkte der Wand im
Raum, der Breite und Höhe des Clients und des Klickpunktes. Diese Berechnung wird im
folgendem erläutert:
Im ersten Schritt wir das relative Verhältnis (Xrel, Yrel) der X- und Y-Werte der Klickkoordinate
zu der Breite und Höhe der Wand berechnet:
Xrel = X / Breite
Yrel = Y / Höhe
Anschließend werden die aufspannenden Seitenvektoren der Wand SVlinks, SVrechts
berechnet, indem die Differenz der jeweiligen Eckvektoren der Wand gebildet wird.
31 3. Prototyp
Moritz Wiechers
SVlinks = EVuntenlinks - EVobenlinks
SVrechts = EVuntenrechts - EVobenrechts
Nun werden die aufspannenden Seitenvektoren der Wand SVlinks , SVrechts jeweils mit dem
relativen Verhältnis der Y-Werte multipliziert.
SVlinksrel = SVlinks * Yrel
SVrechtsrel = SVrechts* Yrel
Dadurch erhält man zwei Vektoren SVlinksrel , SVrechtsrel , die die Strecken von den oberen
Eckvektoren der Wand EVobenlinks , EVobenrechts zu den jeweiligen um die relativen Verhältnisse
skalierten Seitenvektoren darstellen. Die entstandenen Vektoren werden wieder zu dem
jeweiligen Ausgangseckvektor der Wand addiert, um den einzelnen Vektor in Bezug zur
Wand zu setzen.
SVlinksrelproj = SVlinksrel + EVlinksoben
SVrechtsrelproj = SVrechtsrel + EVrechtsoben
Um nun das relative Verhältnis des X-Werts einzurechnen, wird zuerst die Differenz der
beiden relativierten Seitenvektoren gebildet. Dieser Vektor stellt die Strecke zwischen den
relativierten Seitenvektoren dar.
Vrechtslinks = SVrechtsrelproj - SVlinksrelproj
Dieser Vektor wird nun mittels des errechneten relativen Verhältnisses in X Richtung skaliert.
Dadurch erhält man wiederum die skalierte Strecke zum Klickpunkt in 3D Koordinaten,
ausgehend vom linken skalierten Seitenvektor SVlinksrelproj.
Vrechtslinksrel = Vrechtslinks * Xrel
Zuletzt wird dieser skalierte Vektor zum Ausgangsvektor SVlinksrelproj addiert.
VklickPointIn3D = SVlinksrelproj + Vrechtslinksrel
Das Ergebnis ist ein Vektor, der der Klickposition der Wand in dem Koordinatensystem der
Kameras entspricht (siehe linker Teil der Abbildung 17). Ausgehend von diesem Vektor wird
nun der Benutzer ermittelt, der diesem Vektor am nahesten ist. Da zu jedem Benutzer eine
gewisse Anzahl an Vektoren im Koordinatensystem der Kamera existiert, wird einfach die
32 3. Prototyp
Moritz Wiechers
Distanz zwischen dem berechneten Vektor und jedem Vektor, der einem Benutzer gehört,
berechnet. Die geringste Distanz ergibt den Benutzer, der dem Klickpunkt auf der Wand am
wahrscheinlichsten zuzuordnen ist. Neben dieser Funktionalität des Servers bietet dieser die
Funktion an, zu einer gegebenen Person die entsprechende Positionierung zum Board, in
Form der korrespondierenden X-Koordinate, zu ermitteln. Dazu wird dem Server die
BenutzerID übergeben. Dieser berechnet im ersten Schritt den Mittelpunkt der
gemeinsamen Punktwolke des Benutzers über beide Kameras, um anschließend den
entsprechenden Punkt auf dem Smartboard in Raumkoordinaten zu erhalten. Mathematisch
entspricht das dem Lotfußpunkt des Mittelpunktes der Person auf die Ebene, die durch das
Smartboard aufgespannt wird. Mit Hilfe des ermittelten Lotfußpunkts wird der Abstand in
horizontaler Richtung zum Rand des Smartboards berechnet. Dieser Abstand, bezogen auf
die gesamte Breite des Smartboards, ergibt ein Verhältnis, das für die Umrechnung des
Punktes in die X-Koordinate des 2D-Koordinatensystems des Smartboards benutzt wird
(siehe rechter Teil der Abbildung 17).
ABBILDUNG 17 UMRECHNUNG DES KLICKPUNKTES IN RAUMKOORDINATEN (LINKS); UMRECHNUNG DES MITTELPUNKTES EINER PERSON IN X-WERT DES SMARTBOARDS (RECHTS)
3.4.6 Kommunikationsschnittstelle
Die Kommunikation zwischen BoardServer und Client findet über Sockets statt. Die Client-
Server-Architektur bietet auch hier später eine einfache Erweiterung des Systems und
ermöglicht zudem den Einsatz mehrerer Clients gleichzeitig. Zur Übertragung der Daten
wurde ein eigenes Protokoll entwickelt, welches verschiedene Zustände für die jeweiligen
unterschiedlichen Anfrage- und Antwortarten annehmen kann und zudem aus der
Klickkoordinate, einer BenutzerID und einem Entfernungswert besteht. Die Schnittstelle
ermöglicht es so, mittels Verwendung des Protokolls verschiedene Abfragen des Clients an
den Server zu leiten und dessen Antworten dem Client zur Verfügung zu stellen. Der Server
33 3. Prototyp
Moritz Wiechers
sendet beim Eintritt und Verlassen einer Person ein entsprechendes Event an die Clients,
damit diese eine Benutzerverwaltung realisieren können. Zudem werden die Clients bei
einer möglichen Korrektur falsch zugeordneter Benutzer (siehe 3.5.5) über diese Korrektur
informiert, um diese entsprechend zu verarbeiten. Der Client wiederum kann den Server zu
einer gegebenen Klickkoordinate nach dem zugehörigen Benutzer und zu einem bestimmten
Benutzer die vertikale Position und Entfernung zur Wand fragen. Der Server bearbeitet, wie
z.B. in Abschnitt 3.5.4 beschrieben, die Anfrage und sendet das Ergebnis zurück an den
Client. Die Abbildung 18 zeigt in UML ähnlicher Form, wie die Kommunikation zwischen
Server und Client ablaufen könnte.
ABBILDUNG 18 BEISPIELHAFTE KOMMUNIKATION ZWISCHEN CLIENT UND SERVER
Die geschaffene Kommunikationsschnittstelle ermöglicht nun die Anbindung verschiedener
Clients an das Serversystem. Ein beispielhafter Client, der innerhalb des SeeMe-Editors
agiert, wird im Folgenden beschrieben.
3.5 Umsetzung Client
3.5.1 Softwarestruktur
Der Client soll möglichst modular innerhalb des SeeMe-Editors einsetzbar sein. Aus diesem
Grund wird im ersten Schritt ein PlugIn für den SeeMe-Editor entwickelt, das die
Kommunikation zum Server kapselt und für andere PlugIns und den Kern des Editors
verschiedene Funktionalitäten anbietet. Zur Benutzung muss dann dieses PlugIn entweder
über Abhängigkeiten oder mittels Proxy im Rahmen der SeeMe Softwarearchitektur
eingebunden werden. Die Softwarestruktur des PlugIns wird in der Abbildung 19 ersichtlich.
34 3. Prototyp
Moritz Wiechers
ABBILDUNG 19 SOFTWARESTRUKTUR DES CLIENT PLUGINS
Die Klasse KinectClient stellt die Hauptklasse des PlugIns dar. Über sie wird das PLugIn
gestartet und gestoppt, die weiteren Klassen werden initialisiert und auch die Schnittstelle
zu anderen Softwarekomponenten realisiert. So kann sich z.B. ein anderes PlugIn über diese
Klasse als Beobachter anmelden, um über Antworten des Servers informiert zu werden und
gleichzeitig Anfragen an diesen zu stellen. Die Klasse KinectClient nutzt dabei den
KinectClientManager, der wiederum die Klasse Client zur Kommunikation benutzt. Die
eigentliche Kommunikation mit dem Server über Sockets erfolgt also in der Klasse Client. Der
KinectClientManager verwaltet die Beobachter (IKinectClientObserver) und informiert diese
z.B. bei einem neuen Benutzer oder einer ermittelten BenutzerID zu einer bestimmten
Klickkoordinate. Der KinectClientInspector und KinectClientController stellen die grafische
Oberfläche (View) und die Verbindung dieser zum Rest des PlugIns dar. Die grafische
Oberfläche zeigt die sich aktuell in der Szene befindlichen Personen in Form der IDs in einer
Liste an. Zusätzlich kann die Verbindung zum Server aufgebaut, die IP Adresse des Servers
geändert und ein Testlayer hinzugefügt werden. Dieser TestLayer dient der Überprüfung der
Verbindung und Funktionalität des Servers. Ein Benutzer erhält bei Interaktion mit der Wand
ein entsprechendes Feedback über seine BenutzerID. Das zuletzt erzeugte Feedback verfolgt
den Benutzer auf der Wand (ähnlich der Toolbox in Abschnitt 3.5.2) , solange er vom Server
korrekt verfolgt wird. Eine erste anschauliche Benutzung des entwickelten Systems soll eine
Toolbox darstellen, die den interagierenden Benutzer am Smartboard verfolgt und so immer
dort, wo der Benutzer gerade steht, Funktionalitäten zum Modellieren anbietet.
35 3. Prototyp
Moritz Wiechers
3.5.2 Die verfolgende Toolbox
Die Toolbox stellt die erste anschauliche Verwendung des Clients im Zusammenspiel mit
dem in 3.4 beschriebenen Server dar. Sie soll einer Person vor dem Smartboard eine
Sammlung von Tools bereitstellen, die während der gesamten Modellierung in erreichbarer
Umgebung bleibt. Dazu wird die Toolbox kontinuierlich die Position des Benutzers über das
KinectClient PlugIn abfragen und bei einer Veränderung eine entsprechende Position am
Smartboard einnehmen. Die Toolbox wird initiiert, wenn ein Benutzer auf das Smartboard
toucht, und befindet sich am unteren Rand des SeeMe-Editors. In der getesteten Version
konnten über die Toolbox Tracker für MetaBasisElement, Rolle, Aktivität, Entität, Relation
und Modifkator aktiviert und zudem für selektierte Elemente der Name geändert oder das
Element gelöscht werden. Innerhalb eines Versuchs wurde mit der Toolbox ein Modell
erstellt, um die Modellierung mit Hilfe der Toolbox zu testen. Der Versuch zeigte, dass durch
die immer in der Nähe befindliche Toolbox die Arbeit am Smartboard erheblich erleichtert
und viele unnötige Laufwege vor dem Board eingespart werden. In der digitalen Einreichung
zur Arbeit befindet sich ein Video, das die Benutzung der Toolbox und das Zusammenspiel
des Clients mit dem Server ausführlich darlegt.
ABBILDUNG 20 SEEME-EDITOR MIT DER BEWEGLICHEN TOOLBAR 3.5.3 Clustering Prototyp
Ein weiterer Prototyp soll den Einsatz bei einem Mehrpersonenszenario, speziell beim
Clustern, ermöglichen. Dabei wird das Multi-User-Multi-Action-Konzept angepasst. Die
gesamte Interaktion erfolgt, wie im ursprünglichen Konzept auch, über sogenannte
Buttonsets, die eine Ansammlung von Schaltflächen für den Benutzer darstellen, ähnlich der
Toolbox, allerdings positioniert um die jeweilige Touchposition. Da zu jeder Touchposition
der zugehörige Benutzer ermittelt werden kann, wird sofort im Namen des Benutzers die
entsprechende Aktion, z.B. Selektion eines Elementes, ausgeführt. Um eine falsche
36 3. Prototyp
Moritz Wiechers
Zuordnung der Benutzer durch die Personenverwaltung zu erkennen, wird das normale
Buttonset zusätzlich mit einer benutzerspezifischen Farbe und einem zugehörigen
Buchstaben unterlegt (siehe Abbildung 21, links). Erscheint also beim Benutzer „M“ mit der
Farbe Blau ein rotes Buttonset mit dem Buchstaben „N“ hat eine Fehlzuordnung
stattgefunden und der Benutzer kann diese Zuordnung innerhalb eines einstellbaren
Zeitfensters über den Benutzerbutton und das Clockface korrigieren (siehe Abbildung 21,
rechts). Diese Korrekturmöglichkeit der Zuordnung bietet jedes angezeigte Buttonset.
ABBILDUNG 21 DAS BENUTZERSPEZIFISCHE BUTTONSET (LINKS) UND DAS CLOCKFACE (RECHTS)
Der Benutzer kann so per einfachem Touch ein Element zum Verschieben selektieren. Das
zugehörige ButtonSet ermöglicht eine Deselektion, die zudem bei erneutem Touch auf das
Element eintritt (siehe Abbildung 22, links). Anschließend kann der Benutzer an die Stelle
touchen, an die das Element verschoben werden soll. Dort erscheint dann ein ButtonSet, mit
dem der Benutzer die Verschiebung rückgängig machen, zusätzlich die Selektion aufheben
oder aber, wie bei jedem ButtonSet, eine Fehlzuordnung korrigieren kann. (siehe Abbildung
22, rechts).
ABBILDUNG 22 EIN ELEMENT WURDE SELEKTIERT(LINKS) UND ANSCHLIEßEND VERSCHOBEN (RECHTS)
Dieser Prototyp erspart bei äquivalenter Umsetzung ohne Personenverfolgung und keiner
Fehlzuordnung 50 % der Touchs, da im Gegensatz zu einem benötigten Touch und
automatischer Identifikation zweimal getoucht werden müsste. In einem Szenario mit 88
37 3. Prototyp
Moritz Wiechers
Elementen, die jeweils nur einmal bewegt werden, werden 176 Touchs eingespart.14 Eine
Benutzung des Prototypen durch mehrere Benutzer ohne Fehlzuordnungen ist sehr
unwahrscheinlich. Wie beschrieben kann der Benutzer sich über das ButtonSet neu
identifizieren. Diese Identifizierung braucht 2 zusätzliche Touchs. Es ist zusätzlich möglich,
sich bei Erkennung einer Fehlzuordnung durch das System sofort durch das Clockface zu
identifizieren. Diese Identifikation ist mit einem zusätzlichen Touch möglich. Um die Anzahl
der Fehlzuordnungen und die damit verbundene Ersparnis der Touchs in einem realen
Szenario zu ermitteln und das gesamte Zusammenspiel zwischen Client und Server zu testen,
wird im nächsten Kapitel eine Machbarkeitsstudie durchgeführt.
14 [88 (Elemente) * 2 Aktionen(Selektieren, Bewegen) * 2 (Identifikation)] = 356 zu [(88 (Elemente) * 2 Aktionen (Selektieren, Bewegen)] = 176
38 4. Machbarkeitsstudie
Moritz Wiechers
4 Machbarkeitsstudie
Die Machbarkeitsstudie soll die Fragen beantworten, ob das entwickelte System und das
Konzept der Mehrbenutzerunterstützung durch die Personenverfolgung in der Praxis
einsatztauglich ist, inwieweit Interaktionsersparnisse eintreten und welche Probleme
auftreten.
4.1 Demoset
Die Machbarkeitsstudie sieht ein Experiment mit dem Prototypen im Moderationslabor mit
drei Probanden vor, das insgesamt zweimal durchgeführt wird. Dabei werden 88 Elemente
vorgegeben, die in 8 Kategorien einsortiert werden sollen. Es existieren zu jeder Kategorie 11
Elemente, die jedoch auch Überschneidungen beinhalten, um eine Diskussion anzuregen. So
ist z.B. die „Kirsche“ nicht eindeutig zu der Kategorie „Obst“ oder „Farbe Rot“ zuzuordnen.
Während des Experiments wird in einer Logdatei festgehalten, wie oft der Server nach einer
BenutzerID angefragt wird, wie oft die Probanden sich neu identifizieren mussten und wie
oft Elemente bewegt wurden. Zusätzlich werden die Probanden nach der Arbeit mit dem
Prototypen in Hinblick auf folgende Aspekte qualitativ befragt:
• Einarbeitungszeit zur Benutzung des Prototypen • Unterstützung der gemeinsamen Arbeit durch den Prototypen • Identifikationshäufigkeit • Qualität der Art der Identifikation
Die Abbildung 23 zeigt die Startansicht der Machbarkeitsstudie innerhalb des SeeMe-Editors.
ABBILDUNG 23 DAS AUSGANGSMODELL DES CLUSTEREXPERIMENTS
In der digitalen Einreichung befinden sich die aufgenommenen Videos der Experimente, die
entstandenen SeeMe Modelle und die Logdateien.
39 4. Machbarkeitsstudie
Moritz Wiechers
4.2 Ergebnisse
Die Machbarkeitsstudie zeigte, dass das generelle Konzept, die Unterstützung von
kollaborativer Arbeit durch Personenverfolgung, einen erheblichen Mehrwert mit sich
bringt. In den durchgeführten Experimenten waren unterschiedliche Fehlzuordnungsquoten
festzustellen. Im ersten lag die Fehlzuordnungsquote bei ca. 25%, im zweiten Experiment bei
ca. 16%. Dieser Unterschied liegt zum einem an einer kleinen Veränderung des Prototypen,
die verlorengegangene Benutzer, die wieder als Benutzer mit anderer ID erkannt wurden,
dem Buchstaben des Prototypen zugeordnet wurden, der noch keinen Benutzer besitzt, und
zum anderen an den unterschiedlichen Konstellationen der Größe der Probanden und der
unterschiedlichen Laufwege. So führt z.B. ein Hinterlaufen des größten Probanden von
anderen Probanden zu Überlagerungen und auch ein geringerer zueinander eingehaltener
Abstand der Probanden zu Fehlzuordnungen. Die Ersparnisse bei der Interaktion beliefen
sich im ersten Experiment auf 130 Touchs, was im Vergleich zum alternativen Prototypen
eine Ersparnis von 33% ausmacht15 und im zweiten Experiment auf 187 Touchs, was
wiederum eine Ersparnis von 35% darstellt.16 Der geringe Unterschied der Touchersparnis
trotz großem Unterschied bei der Fehlerquote liegt an der implementierten Veränderung für
das zweite Experiment. Die Veränderung verringert das erneute Identifizieren insgesamt,
erhöht aber die Identifizierung über zwei Touchs. Die Auswertung der Fragebögen hat
ergeben, dass im ersten Experiment auch gefühlt öfter eine erneute Identifikation
stattgefunden hat als im zweiten Experiment.17 Die Identifikationsmöglichkeit durch das
Clockface wurde im Durchschnitt mit gut bewertet.18 Fünf der sechs Probanden waren sehr
schnell mit der Bedienung des Prototypen vertraut, ein Proband gab an, schnell vertraut
gewesen zu sein.19 Der Aussage „Der Prototyp hat bei der gemeinsamen Arbeit
Unterstützung geleistet“ stimmten 2 Probanden mit „voll“ und 4 Probanden mit „eher“ zu.20
Die ausgewerteten Ergebnisse der Studie zeigen also, dass der beispielhaft entwickelte
Prototyp eine erhebliche Unterstützung bei kooperativen Aufgaben leistet. Zudem zeigt sie,
15 Touchs Experiment: 96 Bewegungen * 2 + (0,25 Fehlquote * 96 Bewegungen * 2)*1,3 (1+Anteil Zweifachtouchidentifikation) = 254 |zu 384 theoretischen Touchs 16 Touchs Experiment: 131 Bewegungen * 2 + (0,25 Fehlquote * 131 Bewegungen * 2)*1,7 (1+Anteil Zweifachtouchidentifikation) = 337 |zu 524 theoretischen Touchs 17 Skala: [nie, selten, oft, immer] Ergebnis Exp1: 2x oft, 1x selten; Ergebnis Exp2: 1xoft, 2x selten 18 Skala: [sehr gut, gut, neutral, störend, unbrauchbar] Ergebnisse: 2x sehr gut, 3x gut, 1x neutral 19 Skala: [sehr schnell, schnell, langsam, sehr langsam] 20 Skala: [voll, eher, neutral, nicht, gar nicht]
40 4. Machbarkeitsstudie
Moritz Wiechers
dass eine Verringerung der Fehlzuordnungsquote nicht alleine für eine Ersparnis an
Interaktionen sorgt, da beachtet werden muss, ob die Identifikation über einen oder zwei
Touchs erfolgt. Eine mögliche Verbesserung des Prototypen liegt also zum einem in der
Verbesserung der Fehlzuordnungsquote und zum anderen in der besseren Erkennung von
aufgetretenen Fehlern.
4.3 Ausblick
Dieser Abschnitt soll mögliche Optimierungsvorschläge für die Zusammenführung der
Personenverfolgung, weitere Ideen für Anwendungsszenarien und Erweiterungsvorschläge
für das gesamte System aufzeigen. Eine Optimierung besteht darin, die Fehlzuordnungen
möglichst gering zu halten. Die Fehlzuordnungen entstehen bei der Zusammenfassung der
getrennt laufenden Personenverfolgungsalgorithmen und bei Fehlern durch das Framework.
Fehlzuordnungen, die aufgrund des unterliegenden Frameworks erfolgen, sind nur schwer zu
korrigieren. Eine Idee wäre, die Personen anhand der Farben der Kleidung zu identifizieren.
Es könnte z.B. ein Hashwert der Farben der Kleidung an bestimmten Punkten erstellt und
dieser regelmäßig überprüft werden. Vorteil bei der Methode wäre eine Identifizierung der
Personen nach Wiedereintritt in die Szene. Dabei ist natürlich zu beachten, dass Personen
durchaus farblich ähnliche Kleidung tragen können und durch Drehung in Kombination mit
unterschiedlichen Farben der Vor- und Rückseite von Oberbekleidung eventuell falsch
zugeordnet werden könnten. Eine weitere Idee wäre, die Position und den Richtungsvektor
der Person festzuhalten, damit bei kurzzeitigem Verlust der Person durch Überlagerung oder
Berührung diese bei Wiedereintritt identifiziert werden kann. Fehlzuordnungen, die
aufgrund der implementierten Personenverwaltung entstehen, könnten durch verschiedene
Maßnahmen vermieden werden. Als erster Schritt sollte die Kalibrierung verbessert werden,
um eine genauere Überdeckung der beiden Kameraperspektiven zu erreichen. Zum einem
kann manuell im benutzten Programm RGBDemo die berechnete Kalibrierung optimiert
werden und zum anderen innerhalb des Servers z.B. eine Optimierung mithilfe eines ICP-
Algorithmus (Iterative Closest Point Algorithm) vorgenommen werden. Der derzeitige
Algorithmus der Personenverwaltung betrachtet neben dem Abstand der Schnittquader
auch die prozentuale Anzahl an gemeinsamen Teilschnittquadern, um zwei Benutzer beider
Kameras als eine Person zu identifizieren. Dieser Algorithmus könnte auch durch die oben
beschriebene Überprüfung der Kleidungsfarben der Benutzer erweitert werden. Die durch
41 4. Machbarkeitsstudie
Moritz Wiechers
das Framework in Kombination mit der Middleware NITE mitgelieferte skelettöse Verfolgung
von Personen ordnet jeder Person im Bild verschiedene anatomische Punkte, wie den Kopf,
Hals, Hände, Füße, Knie oder Ellbogen. Diese Punkte könnten bei allen potentiellen zu einer
Person gehörenden Benutzern überprüft werden, um so eine deutlichere Zuordnung zu
ermöglichen. Neben den Überprüfungen jeder einzelnen Person könnte der Algorithmus um
Kenntnisse über z.B. die Anzahl der Personen erweitert werden um so, Fehlzuordnungen
besser zu erkennen und zu vermeiden. Eine mögliche Aufhebung der
Zuordnungsproblematik bei den Übergängen von einer in die andere Kamera stellt ein
derzeit in Entwicklung befindlicher Personenverfolgungsalgorithmus der PointCloudLibrary
dar. Diesem könnte einfach die komplette Punktwolke des zusammengeführten
Koordinatensystems übergeben werden, um auf dessen Grundlage eine Personenverfolgung
zu gewährleisten. Zudem gibt es, wie schon in der Einleitung erwähnt, an der EFPL einen
dem ersten Augenschein nach recht stabilen Personenverfolgungsalgorithmus für mehrere
Kinects. Dieser ist allerdings patentiert und ein Kontaktversuch meinerseits zum
entwickelnden Forscher scheiterte. Neben dem schon gezeigten mitwandernden Menü und
Clustering sind noch viele andere Anwendungsszenarien für die entwickelte Software
denkbar. So könnten z.B. während der kooperativen Arbeit am Smartboard für die
Auswertung von Experimenten eine Zuordnung von Benutzern zu Interaktionen
automatisiert ablaufen und so benutzerspezifische Statistiken erstellt werden. Im
Allgemeinen könnte gemeinsam modelliert werden und dabei könnten bestimmte Rollen an
die Personen verteilt werden. Auch die Implementierung unterschiedlicher Rechte von
Personen oder individualisierte Benutzermenüs wären denkbar. Ein Proband des
Experiments hatte die Idee einer Sprechblase, die eine Person während einer Präsentation
verfolgt und dabei die aktuelle Folie der Präsentation anzeigt. Eine andere Person merkte an,
dass ein Einsatz immer denkbar wäre, wenn mehrere Personen an der Wand gleichzeitig
arbeiten. Dies ist nur ein kleiner Auszug im Laufe der Bachelorarbeit entwickelter Ideen und
Anregungen der Probanden und dieser zeigt deutlich, welche Möglichkeiten der Einsatz von
Personenverfolgung zur Unterstützung kooperativer und auch nicht kooperativer Aufgaben
mit sich bringt.
42 5. Fazit
Moritz Wiechers
5 Fazit
Die Frage nach der Umsetzbarkeit des erstellten Konzepts der Projektarbeit konnte durch
diese Arbeit eindeutig beantwortet werden. Die Arbeit mit dem genutzten Framework führte
an vielen Stellen zu Problemen, sei es bei der gleichzeitigen Benutzung der
Personenverfolgungsalgorithmen mit mehreren Kameras oder Problemen im Java Wrapper
des Frameworks. Zudem traten durch die für den Personenverfolgungsalgorithmus nicht
angedachte Positionierung der Kameras weitere Probleme auf. Nach Bewältigung dieser
Problematik stand der Umsetzung des Konzepts jedoch nichts mehr im Wege. Die
Zusammenführung der Personenverfolgungsalgorithmen, also die Personenverwaltung,
bildet den Kern der Arbeit. Dabei wurden Schwächen und Stärken des Algorithmus
aufgezeigt und Verbesserungsvorschläge gegeben. Nach der Zusammenführung wurde das
Smartboard des Moderationslabors in das Koordinatensystem der Kameras abgebildet und
eine Kommunikationsschnittstelle geschaffen, die es anderen Softwaresystemen ermöglicht
die Funktionalitäten der Personenverwaltung zu nutzen. Dazu zählen die Bestimmung von
BenutzerIDs zu einer bestimmten Koordinate des Smartboards und die Ermittlung einer
horizontalen Position am Smartboard zu einem gegebenen Benutzer. Diese Funktionalitäten
wurden dann in einem PlugIn innerhalb des SeeMeEditors genutzt, das zudem die
Kommunikation mit der Personenverwaltung gekapselt für andere Teile des Editors bereit
stellt. Darauf aufbauend wurden dann zwei weitere PlugIns entwickelt, die die Funktionalität
des Systems darstellen. Am Ende entstand so ein Softwaresystem, welches das angedachte
Konzept und zusätzliche Erweiterungen beinhaltet und lauffähig in einem Experiment
getestet werden konnte. Für dieses Experiment wurde ein Prototyp entwickelt, mit dessen
Hilfe zusätzlich die Frage, ob durch Personenverfolgung Kooperationsaufgaben unterstützt
werden können, beantwortet werden sollte. Das Experiment sah eine Aufgabe im Bereich
des Clusterings mit drei Probanden vor. Die Auswertung des Experimentes hat wesentliche
Einsparung von Interaktionen mit einem Vergleichskonzept ohne Personenverfolgung
ergeben. Die Probanden gaben nach dem Experiment positive Rückmeldung zum
eingesetzten Prototypen und empfanden diesen als gute Unterstützung bei der
vorgegebenen Aufgabe. Die Befürchtung, dass die Fehlzuordnungen und die damit
verbundenen Korrekturen diese Einsparungen aufheben, konnte beseitigt werden. Zudem
kann mit den gegebenen Verbesserungs- und Erweiterungsvorschlägen die Fehlerquote der
43 5. Fazit
Moritz Wiechers
Personenverwaltung gesenkt werden, um so den positiven Effekt der Unterstützung durch
die Personenverfolgung zu steigern. Neben dem im Experimente getesteten Prototypen sind
noch viele andere Einsatzszenarien der Personenverfolgung denkbar. So könnten z.B. eine
mitwandernde Sprechblase bei Präsentationen oder aber das automatisierte Aufzeichnen
von Benutzerinteraktionen implementiert werden.
44 6. Quellen und Literaturverzeichnis
Moritz Wiechers
6 Quellen und Literaturverzeichnis
6.1 Quellen Helge Jung, Karsten Nebe, Florian Klompmaker, Holger Fischer (2011): Authentifizierte Eingaben auf Multitouch-Tischen. In: Maximilian Eibl (Hg.): Mensch & Computer 2011. 11. fachübergreifende Konferenz für interaktive und kooperative Medien. überMedien - Übermorgen: Oldenbourg-Verlag, S. 319–322.
Herrmann, Thomas; Hoffmann, Marcel; Loser, Kai-Uwe (1998): Sozio-orientierte und semi-strukturierte Modellierung mit SeeMe. In: Proceedings der Fachtagung MobIS´98. Informationssystem Architekturen. Rundbrief des GI-Fachausschusses, Bd. 5, S. 15–22. Online verfügbar unter http://www.sociotech-lit.de/HeHL98-Sus.pdf.
Maximilian Eibl (Hg.) (2011): Mensch & Computer 2011. 11. fachübergreifende Konferenz für interaktive und kooperative Medien. überMedien - Übermorgen: Oldenbourg-Verlag
Proceedings der Fachtagung MobIS´98. Informationssystem Architekturen. Rundbrief des GI-Fachausschusses (1998).
Balzert, Helmut (2011): Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und Betrieb. Heidelberg. Spektrum Akademischer Verlag
6.2 Internetquellen http://sourceforge.net/apps/trac/libusb-win32/wiki (Stand 15.8.2012)
http://libusbjava.sourceforge.net/wp/ (Stand 15.8.2012)
https://groups.google.com/d/msg/openni-dev/BayNHv_sgEg/E56061mf92cJ (Stand 15.8.2012)
http://www.imtm-iaw.rub.de/kategorie/modlab-blog/ (Stand 15.8.2012) http://www.mathematik.uni-ulm.de/stochastik/lehre/ws05_06/seminar/sauter.pdf (Stand 15.8.2012)
Eidesstattliche Erklärung
Ich versichere an Eides statt, dass ich die vorliegende Arbeit selbständig angefertigt und mich keiner fremden Hilfe bedient sowie keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Stellen, die wörtlich oder sinngemäß veröffentlichten oder nicht
veröffentlichten Schriften und anderen Quellen entnommen sind, habe ich als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder
ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Datum, Unterschrift
Erklärung
Mir ist bekannt, dass nach § 156 StGB bzw. § 161 StGB eine falsche Versicherung an Eides statt bzw. eine fahrlässige falsche Versicherung
an Eides Statt mit Freiheitsstrafe bis zu drei Jahren bzw. bis zu einem Jahr oder mit Geldstrafe bestraft werden kann.
Datum, Unterschrift