Anwendung von Personenverfolgung mittels Kinect für Kooperationsaufgaben

Transkript

1 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 (Matr.-Nr.: ) Erstprüfer: Prof. Dr. Andrea Kienle Zweitprüfer: Prof. Dr. Thomas Herrmann Dortmund,

2 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.

3 I. Inhaltsverzeichnis I I. Inhaltsverzeichnis Abbildungsverzeichnis... II 1 Einleitung Szenario Ziele, Aufgaben und Vorgehen Definitionen Vorbereitungen Positionierung der Kameras Das Framework OpenNI Architektur Verwendung Anmerkungen zur Benutzung zweier Kameras (OpenNI) Sonstiges zur Arbeit mit OpenNI und dem Java Wrapper Zusammenfassung der wichtigsten Erkenntnisse Prototyp Anforderungen Software-Prozessmodell Gesamtarchitektur Umsetzung Server Softwarestruktur Einbindung von zwei Kameras in ein gemeinsames Softwaresystem Zusammenführung der Koordinatensysteme Personenverwaltung Abbildung des Smartboards Kommunikationsschnittstelle... 32

4 I. Inhaltsverzeichnis I 3.5 Umsetzung Client Softwarestruktur Die verfolgende Toolbox Clustering Prototyp Machbarkeitsstudie Demoset Ergebnisse Ausblick Fazit Quellen und Literaturverzeichnis Quellen Internetquellen... 44

5 Abbildungsverzeichnis II 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 Abbildung 6 Vermischung der Benutzer bei der Verwendung zweier Kameras in derselben Applikation Abbildung 7 Gesamtsoftwarearchitektur Abbildung 8 Grobstruktur des Prototypen Abbildung 9 links: Das verwendete Protokoll; Rechts: Ausschnitt Sequenzdiagramm Verbindungsaufbau Abbildung 10 Grafische Oberfläche des verwendeten Kalibrierungstools mit Kalibrierungsmuster (Schachbrett) 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) 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 Abbildung 14 Fehlzuordnung durch das Framework (mitte) und der Zustand nach der Korrektur(rechts)... 28

6 Abbildungsverzeichnis II Abbildung 15 Verfolgung des Benutzers über den Schnittbereich der Kameras hinweg Abbildung 16 Abbildung des Smartboards in das Koordinatensystem der Kameras als Realsicht (links) und als Ansicht in der Software (rechts) Abbildung 17 Umrechnung des Klickpunktes in Raumkoordinaten (links); Umrechnung des Mittelpunktes einer Person in X-Wert des Smartboards (rechts) Abbildung 18 Beispielhafte Kommunikation zwischen Client und Server Abbildung 19 Softwarestruktur des Client PlugIns Abbildung 20 Seeme-Editor mit der beweglichen Toolbar Abbildung 21 Das benutzerspezifische ButtonSet (links) und das Clockface (rechts) Abbildung 22 Ein Element wurde selektiert(links) und anschließend verschoben (rechts) Abbildung 23 Das Ausgangsmodell des Clusterexperiments... 38

7 1. Einleitung 1 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

8 1. Einleitung 2 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

9 1. Einleitung 3 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) Vgl. Herrmann, Thomas; Hoffmann, Marcel; Loser, Kai-Uwe (1998), S.1

10 1. Einleitung 4 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 SMARTBOARD 4 (LINKS) DER SEEME-EDITOR IM EINSATZ AM SMARTBOARD 5 (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: 5 Quelle:

11 1. Einleitung 5 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.

12 1. Einleitung 6 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

13 1. Einleitung 7 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 Deregistrierungsmethoden 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

14 2. Vorbereitungen 8 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 Informationsund 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

15 2. Vorbereitungen 9 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

16 2. Vorbereitungen 10 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 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

17 2. Vorbereitungen 11 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 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 Pixel. Der Tiefengenerator ermittelt zu jedem dieser Pixel den Abstand zur Kamera. Die Ausgabe des Tiefengenerators ist ein Array der Größe , 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 *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

18 2. Vorbereitungen 12 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

19 2. Vorbereitungen 13 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(X res Y res ) die jeweilige X (X proj ) und Y (Y proj ) Koordinate im Bild und den zugehörigen Tiefenwert Z. Realweltkoordinaten geben zu jedem dieser

20 2. Vorbereitungen 14 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 abfragt 9. Dabei wird anfangs der Sichtbereich der Kamera in horizontaler (FOV H ) und vertikaler (FOV V ) 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: X RW = X proj X res 0,5 z X FoV Y RW = 0,5 Y proj Y res z Y FoV Z RW = z Mit X FoV = tan FOV H 2 2 und Y FoV = tan FOV V 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-win32 10 ein USB-Treiber für die Motoransteuerung erzeugt werden, der dann über den libusb-win32 Java Wrapper 11 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: 10 Quelle: 11 Quelle:

21 2. Vorbereitungen 15 Die zweite Kinect wird dann allerdings folgendermaßen initialisiert: 12 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

22 3. Prototyp 16 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

23 3. Prototyp 17 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 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

24 3. Prototyp 18 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 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.

25 3. Prototyp 19 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

26 3. Prototyp 20 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 beschriebenen Fehlerüberprüfungsroutine wird allerdings über die Implementierung der Schnittstelle UpdateableComponent realisiert. Die Klasse Board stellt die in Abschnitt 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.

27 3. Prototyp 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

28 3. Prototyp 22 ü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 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 M t v = v t mit den entsprechenden drei Punktpaaren (v = ) v t nach M t 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

29 3. Prototyp 23 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)