Abschlussarbeit
zur Erlangung des akademischen Grades:
Bachelor of Science (B.Sc.)
an der
Hochschule für Technik und Wirtschaft (HTW) Berlin Fachbereich 4: Informatik, Kommunikation und Wirtschaft
StudiengangAngewandte Informatik
1. Gutachter: Prof. Dr. Alexander Huhn 2. Gutachter: Prof. Dr.-Ing. Thomas Schwotzer
Eingereicht von Erdene-Ochir Purevdorj [547695]
23.10.2021
Die Zielstellung der vorliegenden Abschlussarbeit war es eine Android-Bibliothek zu entwickeln, die die Ausführung vier grundlegender Gesten zuverlässig innerhalb eines eigenständigen Android-Services detektieren soll. Die Basis für die Gestenerkennung bilden vorhandene Sensoren auf Mobilgeräten mit dem Android-Betriebssystem. Dabei wurden folgende Sensoren genutzt: Linear-Acceleration-Sensor, Gravity-Sensor und Gyroscope-Sensor. Die zu detektierenden Gesten dienen dem Empfangen (MotionTy- pe.RECEIVE) und Versenden (MotionType.SEND) und Ablegen (Motiontype.DROP) und Aufheben (MotionType.SCOOP) von Nachrichten.
Diese Arbeit schafft eine erste Basis für andere Entwickler*innen, die die Bibliothek in ihre Anwendungen integrieren oder weiter aufbauen wollen.
1. Einleitung 1
1.1. Hintergrund der Arbeit . . . 1
1.2. Problem- und Zielstellung . . . 1
1.3. Aufbau der Arbeit . . . 1
2. Grundlagen 3 2.1. Sensoren . . . 3
2.1.1. Definition und Wirkungsweise . . . 3
2.1.2. Kategorisierung . . . 4
2.1.3. MEMS . . . 5
2.1.4. Bewegungssensoren . . . 6
2.1.5. Koordinatensysteme . . . 7
2.2. Definition der Gesten . . . 8
2.2.1. Standardposition . . . 9
2.2.2. MotionType.SEND . . . 9
2.2.3. MotionType.RECEIVE . . . 10
2.2.4. MotionType.DROP . . . 11
2.2.5. MotionType.SCOOP . . . 12
2.3. Design Patterns . . . 12
2.3.1. Facade Pattern . . . 13
2.3.2. Singleton Pattern . . . 13
2.3.3. Observer Pattern . . . 13
3. Anforderungsanalyse 14 3.1. Zielgruppen . . . 14
3.2. Anforderungen . . . 14
3.2.1. Funktionale Anforderungen . . . 14
3.2.2. Nicht-funktionale Anforderungen . . . 15
4. Konzeption und Entwurf 16 4.1. Gesamtsystem-Architektur . . . 16
4.2. Bibliothek-Architektur . . . 17
4.3. Sensoren und Sensordaten . . . 19
5. Implementierung 23 5.1. Konditionswerte . . . 23
5.1.1. Konditionswert MIN_HORIZONTAL_ACCELERATION_VALUE 24 5.1.2. Konditionswert MIN_VERTICAL_ACCELERATION_VALUE . . 26
5.1.3. Konditionswert MIN_ROTATION_VALUE . . . 26
5.1.4. Konditionswert MIN_GRAVITY_VALUE . . . 27
5.2. Detektoren . . . 27
5.2.1. DetectionManager . . . 27
5.2.2. MotionDetector . . . 28
5.2.3. SendMotionDetector . . . 30
5.2.4. ReceiveMotionDetector . . . 33
5.2.5. DropMotionDetector und ScoopMotionDetector . . . 36
5.3. MotionDetectionService . . . 39
6. Testing 42 6.1. Unit-Tests . . . 42
6.2. Manuelle Tests . . . 44
7. Fazit 47 7.1. Zusammenfassung . . . 47
7.2. Bewertung der Ergebnisse . . . 47
7.3. Ausblick . . . 48
Quellenverzeichnis I
Abkürzungsverzeichnis III
A. Appendix IV
A.1. Quell-Code . . . IV
2.1. Wirkungsweise Sensoren; Bildquelle [14] . . . 4
2.2. Klassifikation der Sensoren (Eigene Darstellung) . . . 5
2.3. Mikrosystem-Komponenten im Smartphone; Bildquelle [1] . . . 5
2.4. Übersicht von Android unterstützten Sensoren (Eigene Darstellung) . . 6
2.5. Koordinatensystem im Porträtmodus (relativ zum Mobilgerät); Bildquelle [15, S.17] . . . 8
2.6. Koordinatensystem im Landschaftsmodus (relativ zum Mobilgerät); Bild- quelle [15, S.17] . . . 8
2.7. Standardposition (Eigene Darstellung) . . . 9
2.8. Teilbewegungen der Geste MotionType.SEND (Eigene Darstellung) . . . 10
2.9. Rotation X-Achse (Eigene Darstellung) . . . 10
2.10. Rotation Y-Achse (Eigene Darstellung) . . . 10
2.11. Rotation Z-Achse (Eigene Darstellung . . . 10
2.12. Teilbewegungen der Geste MotionType.RECEIVE (Eigene Darstellung) . 11 2.13. Teilbewegungen der Geste MotionType.DROP (Eigene Darstellung) . . 11
2.14. Teilbewegungen der Geste MotionType.SCOOP (Eigene Darstellung) . . 12
4.1. Grobes Komponentendiagramm (Eigene Darstellung) . . . 16
4.2. Veranschaulichung der Fassade (Eigene Darstellung) . . . 17
4.3. UML-Diagramm zur Servicestruktur (Eigene Darstellung) . . . 18
4.4. UML-Diagramm zur Detection-Struktur (Eigene Darstellung) . . . 19
4.5. Übersicht Sensoren und Android-Version; Bildquelle [8] . . . 21
4.6. Anteile der verschiedenen Android-Versionen an der Internetnutzung von Geräten mit Android OS weltweit im Juli 2021; Bildquelle [16] . . . 22
5.1. Sequenzdiagramm Gestenerkennungs-Bibliothek (Eigene Darstellung) . 41 6.1. Detektion der Receive-Geste Beispiel-App (Eigene Darstellung) . . . 44
6.2. Detektion der Send-Geste Beispiel-App (Eigene Darstellung) . . . 44
4.1. Übersicht Intervall-Parameter . . . 20
5.1. Ergebnisse Horizontale Beschleunigung . . . 25
5.2. Ergebnisse Vertikale Beschleunigung . . . 26
5.3. Sensoren und Mock-Sensorwerte . . . 35
6.1. Übersicht SendMotionDetectorTest . . . 43
6.2. Ergebnisse der manuellen Tests mit linker Hand . . . 46
6.3. Ergebnisse der manuellen Tests mit rechter Hand . . . 46
6.4. Ergebnisse der manuellen Tests der Testperson . . . 46
5.1. Instanziierung des SensorManagers und des Linear-Accelerometers . . 23
5.2. Ermittlung der Konditionsgröße . . . 24
5.3. MIN_HORIZONTAL_ACCELERATION_VALUE . . . 25
5.4. MIN_VERTICAL_ACCELERATION_VALUE . . . 26
5.5. MIN_ROTATION_VALUE . . . 26
5.6. MIN_GRAVITY_VALUE . . . 27
5.7. Methode zur Instanziierung der Detektoren . . . 28
5.8. Methode zum Versenden eines Broadcasts bei erfolgreicher Gestenerken- nung . . . 28
5.9. Registrierung des BroadcastReceivers . . . 29
5.10. MotionDetectionStates der SendMotionDetectors . . . 31
5.11. Verarbeitung der Werte des Gyroskop-Sensors . . . 31
5.12. Zurücksetzen der MotionDetectionStates . . . 33
5.13. Variablen der ReceiveMotionDetector-Klasse . . . 33
5.14. Berechnung der Variable portraitMode . . . 33
5.15. processGyroData()-Methode . . . 34
5.16. Berechnung der Variable gravityValuePositive . . . 38
5.17. Detektion der MotionDetectionStates liftMotion und dropMotion für die Scoop-Geste . . . 38
5.18. Starten der Gestenerkennung von der App-Komponente durch die Ser- viceFacade . . . 39
6.1. Test-Beispiel SendMotionDetectorTest . . . 42
Um ein Verständnis für die Motivation der Bachelorarbeit zu erhalten, wird in diesem Kapitel auf den Hintergrund, die Problem- und Zielstellung und den Aufbau der Arbeit eingegangen.
1.1. Hintergrund der Arbeit
In der vorliegenden Bachelorarbeit wird eine Komponente eines gemeinsamen Projektes, angelehnt an die Veranstaltung Grundlagen mobiler Anwendungen und im Rahmen mehrerer, autonomer Abschlussarbeiten ausgearbeitet. Ziel des gesamten Projektes besteht in der Entwicklung einer dezentralen Messenger-Anwendung, mit welcher Nutzer*innen durch Tätigung verschiedener Bewegungen Nachrichten austauschen können.
Die Umsetzung dieser Anwendung umfasst unter anderem die Implementierung folgen- der Komponenten als eigenständige Abschlussarbeiten: die Gestaltung des Graphical User Interfaces, die Erstellung dezentraler Bewegungsprofile und die Detektion vier verschiedener Gesten.
1.2. Problem- und Zielstellung
Die Vier-Gestenerkennung stellt das Thema dieser Arbeit dar und wird mithilfe der vorhandenen Sensorik auf dem Android-Betriebssystem umgesetzt. Diesbezüglich wur- den im Vorfeld vier Gesten definiert: zwei zum Versenden und zwei von Empfangen von Nachrichten. Dabei steht die Implementierung eines verlässlichen Algorithmus zur Detektion ausschließlich gewünschter Gesten im Mittelpunkt. Die besondere Heraus- forderung der Arbeit ist es, dass benannte Gesten nur dann erkannt werden, wenn sie korrekt ausgeführt werden.
Darüber hinaus soll die Bibliothek als ein eigenständiger Android-Service implemen- tiert werden, welcher sich leicht in andere Anwendungen einpflegen, erweitern und modifizieren lässt. Dazu müssen notwendige Schnittstellen bereitgestellt werden.
Um einen statistischen Nachweis über die Funktionsfähigkeit der Software zu erbrin- gen, wird ein Testkonzept erstellt. Dieser beinhaltet Unit-Testing der entsprechenden Klassen und Methoden, sowie unterschiedliche manuelle Tests.
1.3. Aufbau der Arbeit
Um der Problem- und Zielstellung der Arbeit gerecht zu werden, werden zuerst die vier Gesten definiert. Das zweite inhaltliche Kapitel beschäftigt sich mit den theoretischen
Grundlagen als Voraussetzung für die Implementierung des Algorithmus: Sensorik und vorhandene Sensoren in der Android-Umgebung. Darauffolgend wurden Anfor- derungen an die Anwendung analysiert, auf dessen Grundlage ein Entwurf erstellt wurde. Basierend darauf wurde schließlich der Prototyp implementiert. Auf das Testen einzelner Funktionen und Programmteile wird in dem nächsten Kapitel eingegan- gen. Das Fazit wertet die Arbeit aus. Letztlich wird auf mögliche Erweiterungen und Verbesserungen der Komponente hingewiesen.
In diesem Kapitel wird auf die wesentlichen Funktionen und den Aufbau von Sen- soren näher eingegangen, da diese den Grundkern der Arbeit widerspiegeln. An- schließend werden die vier im Vorfeld definierten und vorgegebenen Gesten, die die Endnutzer*innen mit dem Mobiltelefon tätigen sollen, erläutert. Da die Detektion eine unabhängige Komponente darstellt und im Hintergrund einer laufenden Anwen- dung funktionieren soll, werden Android-Services näher beleuchtet. Im Falle einer erfolgreichen Erkennung einer korrekt ausgeführten Geste müssen Applikationen, die an den Ergebnissen der Detektion interessiert sind, benachrichtigt werden, weshalb nachfolgend der BroadcastReceiver erläutert wird. Mit dem Eingehen auf die in der Implementierung genutzten Design Patterns wird dieses Kapitel beendet.
2.1. Sensoren
Um eine Übersicht über die dieser Arbeit zu Grunde liegende Technologie - die Arbeit mit Sensoren - zu bekommen, wird in diesem Kapitel auf die Wirkungswei- se eingegangen. Weiterhin wird erklärt, wie Sensorarten eingeteilt sind und welche Rolle mikroelektronische Systeme heutzutage spielen. Zuletzt wird erklärt, wie die Bewegungssensoren, die für den Algorithmus genutzt wurden, funktionieren, welche Eigenschaften sie besitzen und welche Achsen sie im Koordinatensystem nutzen.
2.1.1. Definition und Wirkungsweise
„Das Wort „Sensor“ stammt aus dem Lateinischen (sensus: Sinn) und bedeutet Fühler.
[. . . ] Ein Sensor dient zur quantitativen und qualitativen Messung von physikalischen, chemischen, klimatischen, biologischen und medizinischen Größen.“[14, S.1]
Wie in Abbildung 2.1 dargestellt, wird ein Sensor in zwei Abschnitte eingeteilt: das Sensor-Element und die Auswerte-Elektronik. Nicht-elektrische Eingangsgrößen strö- men auf das Sensor-Element zu und werden durch naturwissenschaftliche Gesetze in elektrische Ausgangssignale umgewandelt. Mithilfe von Softwareprogrammen oder durch Schaltungselektronik werden die elektrischen Ausgangssignale im zweiten Teilab- schnitt des Sensors: der Auswerte-Elektronik zu Sensor-Ausgangssignalen verarbeitet.
Diese stehen zur Weiterverarbeitung für Auswerte- oder Steuerungszwecke bereit.
Aufkommende Störgrößen, welche das Sensor-Element beeinflussen können, müssen rechnerisch berücksichtigt werden [Vgl. 14, S.1].
Abbildung 2.1.:Wirkungsweise Sensoren; Bildquelle [14]
2.1.2. Kategorisierung
Wie in Abbildung 2.2 zu sehen, wird eine Klassifikation der Sensoren nach Sensortyp und nach den Typen der Sensorwerte unterschieden.
Bei den Sensortypen wird nach physischen und synthetischen Sensoren unterschieden.
• Physische Sensoren: Diese Sensoren sind als physische Hardware im Gerät verbaut und liefern unbearbeitete Rohdaten. Beispiele für diese Kategorie sind: Accelero- meter (Beschleunigungssensor), Gyroscope (Gyroskop) und der Magnetometer (Magnetometer).
• Synthetische Sensoren: Diese Sensoren sind nicht als physische Hardware im Gerät verbaut, sondern abgeleitet von anderen Sensoren. Sie werden auch virtuelle oder Software-Sensoren genannt. Beispiel für diese Kategorie ist der Gravity Sensor (Schwerkraftsensor).
Bei der Unterteilung nach Sensorwerten wird in drei Kategorien unterschieden:
• Roh: Die Werte werden direkt und unbearbeitet zu den Apps weitergeleitet. Rohe Werte werden bspw. bei Beschleunigungssensoren kreiert und weitergegeben.
• Kalibriert: Bei kalibrierten Sensorwerten handelt es sich um Rohdaten, welche durch Algorithmen korrigiert werden um Störungen („Noise") zu beseitigen.
Kalibrierte Sensordaten werden z.B. vom Magnetometer geliefert.
• Fusioniert: Fusionierte Sensordaten werden von mehreren Sensoren als Kom- bination erhalten. Schwerkraftsensoren und Lineare Beschleunigungssensoren liefern fusionierte Sensordaten auf Grundlage von Beschleunigungssensoren und Sensoren aus dem Gyroskop [Vgl. 15, S.8f].
Abbildung 2.2.:Klassifikation der Sensoren (Eigene Darstellung)
2.1.3. MEMS
Aufgrund der steigenden Anforderungen an die Funktionalität der Geräte in denen Sensoren verbaut sind und dem Trend der Portabilität wurden die Funktionselemen- te miniaturisiert – bekannt unter den Begriffen Mikroelektronik bzw. Micro-Electro- Mechanic Systems (MEMS). Durch diese Entwicklung war es möglich dem Bauraum- mangel entgegenzutreten und wirtschaftlicher zu produzieren. Mikrosysteme haben Abmessungen von bis zu 10 mm, wobei verbaute Sensoren Strukturgrößen von 10 nm bis zu 100 µm haben können. Wie in Abbildung 2.3 aufgezeigt, sind in Mobilgeräten u.a. Beschleunigungs- und Drehratensensoren für die Erkennung von Bewegungen und Rotationen verbaut, welche einen signifikanten Teil dieser Arbeit darstellen. Hierdurch wird bspw. die Orientierung des Displays festgelegt (Hoch- oder Querformat). Erweitert werden diese durch Magnetfeldsensoren, welche das Erdmagnetfeld zur Bestimmung der Himmelsrichtung nutzen, Temperatur- und Feuchtsensoren, Näherungssensoren und weitere [Vgl. 1, S.4ff].
Abbildung 2.3.:Mikrosystem-Komponenten im Smartphone; Bildquelle [1]
2.1.4. Bewegungssensoren
In Android Systemen findet man drei Arten von Sensoren: Bewegungssensoren (Motion Sensors), Positionssensoren (Position Sensors) und Umweltsensoren (Environmental Sensors). Beispiele für Umweltsensoren sind: Lichtsensoren oder Drucksensoren und Vertreter von Positionssensoren sind Magnetfeldsensoren oder Drehvektorsensoren, wie in Abbildung 2.4 dargestellt. In dieser Arbeit liegt der Fokus auf Bewegungssensoren – im Besonderen Lineare Beschleunigungssensoren (Linear Acceleration), Gyroskope (Gyroscope) und Schwerkraftsensoren (Gravity), weshalb auf diese weiter eingegangen wird.
Abbildung 2.4.:Übersicht von Android unterstützten Sensoren (Eigene Darstellung)
Linear Acceleration
Der lineare Beschleunigungssensor ist ein physischer oder synthetischer Sensor, welcher die auf das Gerät einwirkende Beschleunigung, ausschließlich der Schwerkraft, misst.
Die lineare Beschleunigung wird berechnet durch die Subtraktion der Beschleunigung aufgrund der Schwerkraft von der Beschleunigung selbst. Es werden Beschleunigungen entlang der X-, Y- und Z-Achse gemessen und als fusionierte Werte in m/s² verarbeitet weitergegeben. Mit dem Linear-Acceleration-Sensor können Bewegungen wie Schütteln, Schwingen und Neigungen erkannt werden [Vgl. 12].
Gyroscope
Das Gyroskop ist ein physischer Sensor, welcher kalibirierte oder Rohwerte in Radiant pro Sekunde (rad/s) zurückgibt. Der Sensor misst die Drehgeschwindigkeit des Gerätes
entlang der X-, Y- und Z-Achse. Es werden positive Werte übermittelt, wenn sich das Gerät gegen den Uhzeigersinn dreht und negative Werte für eine Drehung im Uhrzeigersinn. Mit dem Gyroscope können Drehungen, Schleuderbewegungen und Winkelbewegungen des Mobilgerätes erkannt werden [Vgl. 11].
Gravity
Der Schwerkraftsensor ist ein synthetischer Sensor, welcher vom Accelerometer und Gyroscope fusionierte Werte in m/s² erhält. Er misst die Schwerkraft entlang der X-, Y- und Z-Achse [Vgl. 15, S.10]. Wird das Gerät im Porträtmodus orthogonal zum Boden gehalten, gibt der Sensor an, dass die Schwerkraft auf der Y-Achse liegt. Befindet sich das Gerät im Landschaftsmodus, liegt die Schwerkraft auf der X-Achse. Sollte die Kamera orthogonal zum Boden gerichtet sein und das Gerät sich parallel zum Boden befinden, liegt die Schwerkraft auf der Z-Achse. In der Regel wird dieser Sensor verwendet, um die relative Ausrichtung des Geräts im Raum zu bestimmen [Vgl. 10].
2.1.5. Koordinatensysteme
Bei der Nutzung von Sensordaten wird auf die Werte aus zwei verschiedenen Koordi- natensystemen zurückgegriffen: dem globalen Koordinatensystem und dem Geräte- Koordinatensystem. Beim globalen Koordinatensystem handelt es sich um ein System, welches relativ zur Erde liegt. Die zurückgegeben Werte zeigen die relative Position oder Bewegung des Gerätes zur Erde auf.
Da in dieser Arbeit ausschließlich mit dem Geräte-Koordinatensystem gearbeitet wur- de, wird auf dieses näher eingegangen. Die meisten der Sensoren in der Android- Umgebung nutzen das Standardkoordinatensystem mit X-, Y- und Z-Achse, um Sen- sorwerte zurückzugeben. Dabei liegt der 0-Punkt des Koordinatensystems in der Mitte des Bildschirms, wie in Abbildung 2.5 und Abbildung 2.6 zu sehen. Wenn sich das Mobilgerät in der Standardposition (Bildschirm ist aufrecht zum User gerichtet) be- findet, dann verläuft die X-Achse horizontal von links nach rechts, wobei links vom Nullpunkt negative Werte und rechts vom Nullpunkt positive Werte zurückgegeben werden. Die Y-Achse verläuft vertikal zum Mobilgerät, wobei sich unter dem Null- punkt negative und über dem Nullpunkt positive Werte befinden. Die Z-Achse verläuft orthogonal durch die Bildschirm- und Rückseite des Mobilgerätes im Nullpunkt. Alle Werte, welche sich hinter dem Gerät befinden sind negative und alle Werte vor dem Bildschirm sind positiv. Befindet sich das Mobilgerät im Landschaftsmodus, wie in Abbildung 2.6 dargestellt, bleibt das Koordinatensystem unverändert zum Mobiltelefon.
Für diese Einstellung ist die X-Achse vertikal, die Y-Achse horizontal und die Z-Achse weiterhin orthogonal durch das Gerät verlaufend. Das Koordinatensystem bleibt stets in derselben Anordnung bei jeglicher Bewegung und verändert sich nicht.
Abbildung 2.5.:Koordinatensystem im Porträtmodus (relativ zum Mobilgerät); Bildquelle [15, S.17]
Abbildung 2.6.:Koordinatensystem im Landschaftsmodus (relativ zum Mobilgerät); Bildquelle [15, S.17]
2.2. Definition der Gesten
Das Endprojekt stellt eine Applikationen dar, die in ihrem Grundkern eine dezentrale Messenger-Funktion besitzt. Nutzer*innen der Applikation sollen demnach eine Hand- bewegung mit dem Mobiltelefon ausführen, welche als MotionType.SEND definiert wird, um eine Nachricht zu senden. Ein weiterer Nutzer*in führt die Geste MotionTy- pe.RECEIVE aus, um die versendete Nachricht zu empfangen. Das virtuelle Ablegen einer Nachricht an einem bestimmten Ort kann durch die Ausführung der Geste Mo-
tionType.DROP bewältigt werden, wobei sich Nutzer*innen durch die Tätigung der Geste MotionType.SCOOP diese Nchricht anzeigen lassen können.
2.2.1. Standardposition
Für die Veranschaulichung und der Definition der Gesten wird im Vorfeld eine grundle- gende Position festgelegt: die Standardposition, s. Abbildung 2.7. Die Standardposition entspricht der Position, in der Nutzer*innen das Mobiltelefon im Porträtmodus halten, wenn sie im aufrechten Stehen oder Sitzen eine Nachricht in das Gerät eingeben. Ein weiteres relevantes Merkmal bildet die Blickrichtung der Nutzer*innen, die in etwa im 90°-Winkel (orthogonal) auf den Bildschirm eintrifft. Es wird davon ausgegangen, dass die Nutzer*innen alle folgenden Gesten aus der Standardposition heraus durchführen.
Abbildung 2.7.:Standardposition (Eigene Darstellung)
2.2.2. MotionType.SEND
Die Geste MotionType.SEND dient dem Versenden einer Nachricht, welche einer Wurf- bewegung ähnelt. Dazu wird diese Bewegung in vier Teilbewegungen unterteilt. Um die Gesten voneinander deutlich abzugrenzen, werden alle Gesten zum einen bildlich zum anderen technisch erläutert.
Bildliche Erläuterung:
Abbildung 2.8.:Teilbewegungen der Geste MotionType.SEND (Eigene Darstellung)
Wie in Abbildung 2.8 zu erkennen, wird mit der ersten Bewegung das Mobilgerät von der Standardposition nach rechts oder links geführt (Teilbewegung 1), um 90 Grad nach außen gedreht (Teilbewegung 2). Die dritte und vierte Teilbewegung stellen eine Ausholbewegung zum Ohr und anschließend eine Wurfbewegung vom Körper weg dar.
Technische Erläuterung:
Ausgehend vom Koordinatensystem des Linear-Acceleration-Sensors stellt die Teilbe- wegung 1 eine Bewegung auf der X-Achse in die negative oder positive Richtung dar.
Teilbewegung 2 bildet die Drehung um die Y-Achse ab. Bei der dritten Teilbewegung wird das Gerät an der Z-Achse rotiert und entlang der X-Achse bewegt. Zum besseren Verständnis des Rotationsverhaltens dienen die folgenden Abbildungen. Ausgehend
Abbildung 2.9.:Rotation X- Achse (Eigene Darstellung)
Abbildung 2.10.:Rotation Y- Achse (Eigene Darstellung)
Abbildung 2.11.:Rotation Z- Achse (Eigene Darstellung von der Standardposition stellen Abbildung 2.9 die Rotation um die X-Achse, Ab- bildung 2.10 die Rotation um die Y-Achse und Abbildung 2.11 die Rotation um die Z-Achse dar.
2.2.3. MotionType.RECEIVE
Die Geste MotionType.RECEIVE dient dem Empfangen einer Nachricht. Dazu wird diese Bewegung ebenfalls in drei Teilbewegungen unterteilt.
Bildliche Erläuterung:
Abbildung 2.12.:Teilbewegungen der Geste MotionType.RECEIVE (Eigene Darstellung) Wie in Abbildung 2.12 zu erkennen, wird mit der ersten Bewegung das Gerät von der Standardposition zu der Position bewegt, in der die Y-Achse des Geräts in etwa orthogonal zum physischen Boden gerichtet ist (Teilbewegung 1). Die Teilbewegungen 2 und 3 werden ohne eine vordefinierte Reihefolge unabhängig voneinander betrachtet, da diese Teilbewegungen nahezu zeitgleich stattfinden. Diese Teilgesten bestehen aus dem Heben und Drehen des Mobilgerätes.
Technische Erläuterung:
Für die Ausführung der Teilbewegung 1 muss das Gerät entlang seiner X-Achse rotiert werden bis die Orthogonalität der Y-Achse des Geräts zu der X-Achse des Erdbodens erreicht ist. Die Rotation nach außen erfolgt durch die Y-Achse, wobei das Heben des Geräts einer Bewegung in den positiven Bereich auf der Y-Achse gleicht.
2.2.4. MotionType.DROP
Die Geste MotionType.DROP dient dem standortgebundenen Hinterlegen einer Nach- richt. Dazu wird diese Bewegung in vier Teilbewegungen unterteilt.
Bildliche Erläuterung:
Abbildung 2.13.:Teilbewegungen der Geste MotionType.DROP (Eigene Darstellung) Wie in Abbildung 2.13 zu erkennen, wird in der Teilbewegung 1 das Gerät von der Standardposition so bewegt, dass die Rückseite des Mobiltelefons parallel zum Boden
gerichtet ist. Teilbewegung 2 besteht aus einer Hebebewegung, wobei Teilbewegung 3 eine Senkbewegung zum Boden bedeutet. Die Geste gilt als vollendet, wenn sich die Bildschirmseite des Gerätes zum Schluss parallel zum Boden befindet.
Technische Erläuterung:
Für die Ausführung der Teilbewegung 1 muss das Gerät entlang seiner Z-Achse so rotiert werden bis die Parallelität der Y-Achse und die Rückseite des Gerätes zu der X-Achse des Bodens erreicht ist. Die Hebebewegung erfolgt durch die Bewegung in die positive Richtung entlang der Z-Achse, sowie das Senken des Geräts.
2.2.5. MotionType.SCOOP
Die Geste MotionType.SCOOP dient dem standortgebundenen Abfangen einer Nach- richt. Dazu wird diese Bewegung in vier Teilbewegungen unterteilt.
Bildliche Erläuterung:
Abbildung 2.14.:Teilbewegungen der Geste MotionType.SCOOP (Eigene Darstellung) Wie in Abbildung 2.14 zu erkennen, wird in der Teilbewegung 1 das Gerät von der Standardposition so bewegt, dass die Vorderseite des Mobiltelefons parallel zum Bo- den gerichtet ist. Teilbewegung 2 besteht aus einer Senkbewegung zum Boden, wobei Teilbewegung 3 eine Hebebewegung bedeutet. Die Geste gilt als vollendet, wenn sich im Anschluss die Rückseite des Gerätes parallel zum Boden befindet.
Technische Erläuterung:
Für die Ausführung der Teilbewegung 1 muss das Gerät entlang seiner Z-Achse so rotiert werden bis die Parallelität der Y-Achse und Vorderseite des Gerätes zu der X-Achse des Erdbodens erreicht ist. Die Senkbewegung erfolgt durch die Bewegung in die positive Richtung entlang der Z-Achse, sowie das Senken des Geräts.
2.3. Design Patterns
Im folgenden Abschnitt wird näher auf einzelne Design Patterns eingegangen, welche beim Entwurf und der Implementierung verwendet wurden.
2.3.1. Facade Pattern
Das Facade Design Pattern definiert eine vereinfachte Schnittstelle zur Nutzung eines Systems oder einer Menge von Objekten und gehört zu der Kategorie der Struktur- muster. Ein komplexes Subsystem mit vielen Klassen und Abhängigkeiten hat zur Folge, dass Nutzer*innen (Clients), welche Teile des Systems nutzen, die verschiedenen Schnittstellen der enthaltenen Klassen zunächst ergründen müssen. Dabei werden Abhängigkeiten zu verschiedenen Objekten aufgebaut und es entsteht eine enge Kopp- lung. Die Fassade steht zwischen den Clients und dem Subsystem. Sie kapselt das Subsystem, enthält die komplexe Logik für die Arbeit mit dem Subsystem und bietet dem Client eine vereinfachte Schnittstelle (Methoden). Client-Aufrufe über jene werden an das Subsystem delegiert. Demnach ermöglicht die Verwendung einer Fassade dem Client das System zu nutzen, ohne die dazugehörigen Klassen, ihre Beziehungen und Abhängigkeiten kennen zu müssen [Vgl. 13, S.116-117].
2.3.2. Singleton Pattern
Das Singleton Pattern gehört zur Kategorie der Erzeugungsmuster. Dieses Muster findet dann Verwendung, wenn von einer Klasse nicht mehr als eine Instanz erstellt werden darf. Diese Klasse wird Singleton genannt. Ein Singleton-Objekt kann nur von der Klasse Singleton erzeugt werden und besitzt aus diesem Grund nur private Konstruktoren.
Zur Laufzeit kann auf die Singleton-Instanz einzig mit der KlassenmethodegetInstance() zugegriffen werden, welche eine Referenz auf das einzig existierende Objekt retourniert [Vgl. 13, S.262].
2.3.3. Observer Pattern
Das Observer (Beobachter) Pattern gehört zur Kategorie der Verhaltensmuster. Dieses Muster wird eingesetzt, wenn eine dynamisch veränderbare Menge von Objekten über die Zustandsänderung eines einzelnen Objektes informiert werden sollen. Das Objekt, welches über ändernde Daten (Zustand) verfügt, wird als Observable (Beobachtbares Objekt) bezeichnet und stellt einen von zwei Akteuren dieses Entwurfmusters dar. Den zweiten Akteur bilden Objekte, welche Interessenten für die Daten des Observables sind und werden als Observer (Beobachter) benannt. Observer sind zur Kompilierzeit dem Observable nicht bekannt, da sie sich zur Laufzeit erst beim Observable anmelden müssen. Anschließend erhalten alle registrierten Observer solange Benachrichtigungen über die Änderung der gekapselten Daten des Observables bis sie sich selbst abmelden.
Da der angemeldete Beobachter das beobachtbare Objekt nicht über seinen Zustand befragen muss, sondern das beobachtbare Objekt bei jeder Änderung registrierte Beob- achter eigenständig benachrichtigt, wird hierbei der Steuerfluss umgekehrt (Inversion of Control).
In der Android-Umgebung lassen sich zahlreiche Beispiele für den Einsatz des Beob- achtermusters finden, wie z.B. bei dem Einsatz von LiveData oder SensorEventListener.
Häufig wird in der Android-Umgebung das Observer Pattern auch Listener Pattern genannt, wobei die Observer als Listener betitelt werden [Vgl. 13, S.163-164].
In diesem Kapitel sollen Zielgruppen, sowie funktionale und nicht-funktionale Anfor- derungen an die zu entwickelnde Bibliothek herausgearbeitet werden.
3.1. Zielgruppen
Die zu entwickelnde Bibliothek bildet eine abgeschlossene Komponente eines größeren Projektes. Demzufolge stellen im Wesentlichen zukünftige Entwickler*innen die Haupt- zielgruppe dar. Entwickler*innen der Zielgruppe lassen sich unterteilen in jene, die das Ziel verfolgen die Komponente zu erweitern und jene, die das Ziel verfolgen die Komponente in vorhandene Applikationen zu integrieren. Eine entferntere Zielgruppe verkörpern Endnutzer*innen, die die tatsächliche Anwendung nutzen und die Gesten ausführen.
3.2. Anforderungen
Um ein ganzheitliches Anforderungsprofil zu erstellen, werden im folgenden funktio- nale und nicht-funktionale Bedingungen und Ansprüche an die Bibliothek aufgestellt.
3.2.1. Funktionale Anforderungen Muss-Kriterien
• Die Nutzer*innen sollen durch die angemessene Ausführung der vier Gesten bestimmte Aktionen in der Schluss-Anwendung auslösen. Die Erkennung der Gesten soll algorithmisch eine hohe Wahscheinlichkeit aufweisen.
• Undefinierte Bewegungen mit dem Mobiltelefon sollen mit möglichst geringer Wahrscheinlichkeit zu einer irrtümlichen Detektion einer definierten Geste führen.
Um diesem Ziel gerecht zu werden, sollten definierte Gesten gut voneinander differenzierbar sein.
• Die Detektion der Gesten soll nur erfolgen, wenn sich die Applikation im Vorder- grund befindet bzw. aktiv verwendet wird und somit den Nutzer*innen sichtbar ist. Wird die Anwendung unterbrochen oder beendet, muss auch der Service gestoppt werden.
• Im Falle einer gelungenen Gestenerkennung muss eine Meldung per Broadcast an das Betriebssystem gesendet werden, damit andere Anwendungen, die an dieser interessiert sind (BroadcastReceiver), darüber benachrichtigt werden können.
Kann-Kriterium
• Im Optimalfall soll die Gestenerkennung sowohl für Rechts- als auch für Links- händer gleichermaßen gut funktionieren.
3.2.2. Nicht-funktionale Anforderungen
• Die zu erstellende Bibliothek soll leicht erweiterbar sein.
• Die vorhandenen Algorithmen sollen leicht austauschbar sein.
• Die Einbindung in zukünftige Projekte soll leicht und in wenigen Schritten erfol- gen können. In Folge dessen muss die Bibliothek möglichst schmale Schnittstellen bereitstellen, sodass der Umfang und die Funktionalität der zugrunde liegenden Klassen bestmöglich verborgen bleiben.
Dieses Kapitel dient zur Erstellung eines Konzeptes auf Grundlage der funktionalen und nicht-funktionalen Anforderungen des vorangegangenen Kapitels. Es soll zum einen der Entwurf wesentlicher Klassen, zum anderen die Beziehungen dieser unterein- ander erarbeitet werden. Konzipiert wird hierbei die zu entwickelnde Bibliothek, sowie eine Beispielanwendung, die die Bibliothek integriert und zu Demonstrationszwecken dient.
4.1. Gesamtsystem-Architektur
Der Aufbau des Gesamtsystems der Beispielapplikation besteht im Groben aus zwei grundlegenden Komponenten: die Beispielanwendung und die Gestenerkennungs- Bibliothek, siehe Abbildung 4.1.
Abbildung 4.1.:Grobes Komponentendiagramm (Eigene Darstellung)
Wie in Abbildung 4.2 zu sehen ist, wird auf das Facade Pattern zurückgegriffen, um die Funktionalität der Bibliothek von der Anwendungskomponente abzukapseln.
Der Anwendung bleibt lediglich die Kontrolle über das Starten und Stoppen der Gestenerkennung. Besonders gut eignet sich dieses Entwurfsmuster auch um der nicht-funktionalen Anforderung des leichten Einbindens in externe Projekte gerecht zu werden. Die Kommunikation zwischen den Komponenten soll unidirektional durch den Broadcast-Mechanismus erfolgen. Folglich sendet die Gestendetektion-Bibliothek einen Broadcast an das Android-Betriebssystem, welches Applikationen benachrichtigt, die diesen Broadcast empfangen. Aufgrund dessen müssen sich die App-Komponenten für diesen Broadcast registrieren. Im Kapitel Implementierung wird näher auf den Broadcast eingegangen.
Abbildung 4.2.:Veranschaulichung der Fassade (Eigene Darstellung)
4.2. Bibliothek-Architektur
Die Bibliothek wird in zwei Komponenten unterteilt: die Service-Komponente und die Detektion-Komponente. Die Service-Komponente umfasst alles Wesentliche im Bezug auf den Android-Service. Der Service stellt neben Activities, Broadcast Receivers und Content Providers eine der vier Application Components in der Android-Umgebung dar [Vgl. 2].
Android-Service
Ein Service ermöglicht einer Applikation bestimmte langwierige Teilprozesse der Soft- ware im Hintergrund laufen zu lassen. Geeignete Anwendungsfälle sind z.B. das Abspielen von Musik während Nutzer*innen andere Applikationen bedienen oder das Abrufen von Daten über das Netzwerk ohne die Anwendung zu blockieren. Eine andere Komponente, z.B. eine Activity, kann den Service starten und stoppen oder sich an ihn binden, um mit ihm zu interagieren. Services sind Komponenten, die über keine Ober- fläche verfügen [Vgl. 9]. Es gibt drei unterschiedliche Arten von Services: Foreground, Background und Bound Services. Background Services führen Aktionen aus, die für Nutzer*innen nicht bemerkbar sind, wie z.B. das Komprimieren von Speicherplatz.
Bound Services werden nur dann ausgeführt, wenn eine andere Komponente sich an den Service bindet, in dem die MethodebindService() aufgerufen wird und bieten fortgeschrittene Methoden zur Interaktion zwischen Service und Komponenten an [Vgl.
9]. Der Foreground Service, welcher in dieser Bibliothek eingesetzt wird, dient zur Aus- führung von Operationen, die für Nutzer*innen erkennbar sind, wie z.B. das Abspielen von Musik oder in diesem Fall, die Gestenerkennung. Eine notwendige Bedingung zur Verwendung von Foreground Services ist das Anzeigen einer Statusbar-Notification,
damit für Nutzer*innen deutlich wird, dass auf Systemressourcen zugegriffen wird [Vgl. 6]. Eine Übersicht über die Methoden und Struktur des gewählten Services gibt Abbildung 2.2.
Darüber hinaus empfiehlt die Android-Plattform die Verwendung von Sensoren und deren Werten nur, wenn sich die Anwendung im Vordergrund oder als Teil eines Foreground Services befindet [Vgl. 3].
Abbildung 4.3.:UML-Diagramm zur Servicestruktur (Eigene Darstellung)
Gestenerkennung
Das Single Responsibility Prinzip stellt ein Prinzip dar, welches genutzt wird um die Erweiterbarkeit von Quellcode zu fördern. Es besagt, dass jede Klasse nur jeweils eine Zuständigkeit besitzen soll. Aus diesem Grund wird zur Erkennung der vier Ges- ten jeweils eine Detektor-Klasse für jede Geste vorgesehen. Somit entstehen folgende Klassen: SendMotionDetector, ReceiveMotionDetector, DropMotionDetector und Scoop- MotionDetector. Den gemeinsamen Nenner der vier Klassen stellt dar, dass sie allesamt Detektoren sind. Aus diesem Grund wird eine Superklasse konstruiert: MotionDetector.
Die MotionDetector-Klasse beinhaltet Methoden, die an die Subklassen vererbt werden.
Wie in Abbildung 4.4 zu erkennen, existiert ein DetectionManager, welcher die Hand- habung der Detektoren aus der Service-Klasse kapselt. Der DetectionManager besitzt die Verantwortung zur Erstellung aller Detektoren durch die Factory-Methode und zur Delegation der Sensorwerte, welche sie aus der Service-Klasse erhält. Die Delegation erfolgt durch das Observer Pattern, in dem sich die Detektor-Klassen als Observer beim DetectionManager (Observable) registrieren. Hierdurch entsteht die Möglichkeit
Detektor-Klassen einfach auszutauschen.
Abbildung 4.4.:UML-Diagramm zur Detection-Struktur (Eigene Darstellung)
4.3. Sensoren und Sensordaten
In diesem Abschnitt sollen zweckmäßige Sensoren des Android-Betriebssystems für die Gestenerkennung herausgearbeitet werden.
Wahl der Sensoren
Im Kapitel Grundlagen wurde jede der vier Gesten in Teilgesten spezifiziert. Ausgehend davon können geeignete Sensoren der Android-Umgebung für die Gestenerkennung bestimmt werden. Grundbewegungen, die in der Ausführung der vier Gesten enthalten sind, sind das Schwingen (in allen Richtungen) und das Rotieren des Gerätes. Weiterhin ist zu jeder Zeit entscheidend, wie das Mobiltelefon relativ zum Raum ausgerichtet ist.
Demnach kann für das Schwingen der Linear-Acceleration-Sensor, für das Rotieren das Gyroskop und für die Ausrichtung im Raum der Gravity-Sensor genutzt werden. Im Kapitel Grundlagen wurde auf diese Sensoren näher eingegangen.
Sensorwerte
Anhand der, von den genannten Sensoren, ausgegebenen Sensorwerte müssen metho- disch konstante Konditionswerte für die jeweiligen Teilbewegungen evaluiert werden, um deren Ausführung zu erkennen. Sind die vom Sensor zurückgegebenen Werte grö- ßer als der erarbeitete Konditionswert, so gilt diese Teilbewegung als ordnungsgemäß ausgeführt und wird erkannt. Zur Ermittlung dieser Konditionsgrößen ist es notwen- dig, die Sensorwerte für die Teilbewegungen im Vorfeld zu analysieren. Damit eine statistisch angemessene Größe gefunden werden kann, ist eine häufige Durchführung unerlässlich. Im nächsten Kapitel wird dieses methodische Verfahren in die Praxis umgesetzt.
Damit auf Sensorwerte zugegriffen werden kann, stellt das Android-Betriebssystem den SensorManager zur Verfügung. Mithilfe des SensorManagers kann erfragt werden, ob nötige Sensoren auf dem jeweiligen Gerät existieren. Im positiven Fall gibt der SensorManager eine Instanz des Sensors zurück, welche man bei dem selben Sensor- Manager registrieren kann, um Benachrichtigungen zu den Werten, die der Sensor misst, zu erhalten. Bei der Regsitrierung über die MethoderegisterListener()muss ein Parameter übergeben werden, welcher das Intervall angibt, in dem Sensorereignisse über die Rückrufmethode onSensorChanged() an die Anwendung gesendet werden sollen. Das Android-Betriebssystem bietet vier Optionen zur Wahl des Parameters an: SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, SENSOR_DELAY_GAME und SENSOR_DELAY_FASTEST, wie der Tabelle 4.1 zu entnehmen ist. Ab der Android Ver- sion 3.0 können selbstgewählte Intervalle in Mikrosekunden als Parameter übergeben werden.
Tabelle 4.1.:Übersicht Intervall-Parameter
Bezeichnung Intervall inµs Intervall in s Updates pro s
SENSOR_DELAY_NORMAL 200 000 0.2 5
SENSOR_DELAY_UI 60 000 0.06 rund 17
SENSOR_DELAY_GAME 20 000 0.02 50
SENSOR_DELAY_FASTEST 0 0 schnellstmöglich
Bei diesen Intervallen handelt es jedoch nur um Intervalle, die dem Betriebssystem vorgeschlagen werden. Es wird keine exakte Einhaltung des angegebenen Intervalls garantiert, da das Betriebssystem sowie andere Anwendungen das Intervall beeinflus- sen und ändern können. Das Android-Betriebssystem nutzt aber geringere Intervalle (bedeutet häufigeres Erhalten von Sensordaten) als die angebebenen, weshalb empfoh- len wird, das Intervall so groß wie möglich zu wählen, sodass der Prozessor und die Batterieleistung entlastet werden können. Das Intervall sollte trotzdessen der Anforde- rungen der Anwendung entsprechen. [Vgl. 7]
Im nächsten Kapitel gilt es herauszuarbeiten, welches der Intervalle für die Erkennung der Gesten sich am idealsten eignet.
Verfügbarkeit der Sensoren
Da die Gestenerkennung in Android-Anwendungen integriert werden soll, welche auf Endgeräten mit dem Android-Betriebssystem laufen sollen, wird in diesem Abschnitt ausgehend von den Sensoren, die genutzt werden, Mindest-System-Anforderungen erarbeitet, welche die jeweiligen Gerätesysteme erfüllen müssen.
Nach aktuellem Stand verfügt die Plattform Android über 11 verschiedene Hauptver- sionen mit 30 unterschiedlichen Application Programming Interface (API)-Levels1[Vgl.
5]. Aufgrund dieser Tatsache existiert eine große Menge an Android-Geräten, die sich nicht nur vom Hersteller, sondern auch von der Android-Version und vom API-Level unterscheiden können. Ein indirektes Ziel stellt folgendermaßen eine möglichst große Spannweite an Android-Geräten dar, auf jene die Gestendetektion funktionieren soll.
Abbildung 4.5.:Übersicht Sensoren und Android-Version; Bildquelle [8]
Auch die Verfügbarkeit von Sensoren auf Android-Geräten kann nicht nur von Herstel- ler zu Hersteller und Gerät zu Gerät variieren, sondern auch zwischen den Android- Versionen. Abbildung 4.5 dient zur Übersicht der vorhandenen Sensoren und zeigt auf, ab welcher Version und API-Level sie eingeführt wurden.
Wie in Abbildung 4.5 zu erkennen, wurde der Accelerometer in API-Level 8 (Android-
1Gibt den eingebauten Entwicklungsstand der Funktionen an, die von Entwickler*innen genutzt werden können.
Version 2.2), wobei die Gyroskop-, Gravity- und Linear-Acceleration-Sensor in API- Level 9 (Android-Version 2.3) eingeführt wurden.
Demzufolge stellen diese Erkenntnisse die Anforderungen an das Geräteystem dar - die Android-Version muss 2.3 oder höher sein und das API-Level muss mindestens auf neun sein.
Um eine Kenngröße zum Anteil der Nutzer*innen zu schaffen, die diesen Anforderun- gen bzgl. ihrer Mobilgeräte gerecht werden, wurde folgende Analyse durchgeführt.
Die Verbreitung der Android-Versionen unter den genutzten Mobilgeräten mit dem Android-Betriebssystem verhält sich wie in Abbildung 4.6 zu sehen:
Abbildung 4.6.:Anteile der verschiedenen Android-Versionen an der Internetnutzung von Geräten mit Android OS weltweit im Juli 2021; Bildquelle [16]
Somit stellt sich heraus, dass mehr als 99,95 Prozent der Android-Nutzer*innen min- destens die Android-Version 2.3 und somit geeignete Geräte für die Gestendetektion besitzen.
Dieses Kapitel dokumentiert die Umsetzungsschritte mit denen die Theorie aus dem vorangegangenen Kapitel in die Praxis überführt wurde. Die dabei aufgetretenen Pro- bleme werden beleuchtet und geeignete Lösungsansätze werden aufgezeigt.
5.1. Konditionswerte
Wenn man jede der vier Gesten auf grundlegende Bewegungen herunterbricht, bestehen alle zu erkennenden Gesten aus einer Kombination von Dreh- und Schwenkbewegun- gen mit dem Gerät.
Die Sensoren und die von ihnen gelieferten Werte geben Auskunft darüber, ob und wie schnell diese Gesten ausgeführt wurden. Aus diesem Grund wird nachfolgend erläutert, wie die Konditionsgrößen, die maßgeblich für erfolgreiche Ausführungen sind, ermittelt wurden. Diese Werte werden verwendet, um entscheiden zu können, ob eine angemessene Ausführung stattgefunden hat.
Verfahren zur Ermittlung des Konditionswerts
Das Verfahren zur Bestimmung einer geeigneten Größe besteht aus der wiederholten Ausführung der Schwenk- und Drehbewegungen. Diese Prozedur wurde manuell bzw.
von Hand durchgeführt. Dabei wurde die gewünschte Geschwindigkeit eingehalten, mit der das Mobilgerät von den Endnutzer*innen bewegt werden soll.
Damit das Verfahren umgesetzt und Sensorwerte erhalten werden können, müssen im Vorfeld notwendige Schritte durchlaufen werden. Der folgende Quellcode gibt einen Überblick über die Instanziierung eines SensorManagers und eines Beschleunigungs- sensors und der Anmeldung des Beschleunigungssensors beim SensorManager.
1 SensorManager sensorManager =
2 ( SensorManager ) g e t S y s t e m S e r v i c e ( SENSOR_SERVICE ) ;
3
4 Sensor a c c e l e r a t i o n S e n s o r =
5 sensorManager . g e t D e f a u l t S e n s o r ( Sensor . TYPE_LINEAR_ACCELERATION) ;
6
7 sensorManager . r e g i s t e r L i s t e n e r (
8 t h i s , a c c e l e r a t i o n S e n s o r , SensorManager . SENSOR_DELAY_UI
9 ) ;
Listing 5.1:Instanziierung des SensorManagers und des Linear-Accelerometers
Weiterhin muss die Schnittstelle SensorEventListener implementiert werden, welche
die MethodeonSensorChangedenthält. Diese Methode gibt ein SensorEvent zurück, das neben den Sensorwerten mitunter auch angibt, um welchen Sensor es sich handelt. Für die Sensorwerte enthält das SensorEvent ein Array aus float-Werten. An erster Stelle sind Werte der X-Achse, an zweiter Stelle Werte der Y-Achse und an dritter Stelle Werte der Z-Achse zu finden. Mit diesen Gegebenheiten kann das Verfahren zur Ermittlung der Konditionsgrößen realisiert werden.
5.1.1. Konditionswert MIN_HORIZONTAL_ACCELERATION_VALUE Zur Berechnung dieser Größe wurden folgende Schritte unternommen: zehnmalige Ausführung der Schwenkbewegung aus der Standardposition nach rechts (positive ho- rizontale Beschleunigung). Diese Prozedur wurde weitere zehnmal wiederholt, sodass die Gesamtzahl der Durchführungen 100 betrug.
Die große Anzahl von Sensormesswerten, die bei hundertfacher Ausführung einer Be- wegung anfielen, stellte ein Problem dar und erschwerte die Auswertung. Bei der Regis- trierung des Sensors beim SensorManager wurde der Parameter SENSOR_DELAY_UI übergeben. Daraus resultiert, wie in Tabelle 4.1 zu erkennen eine Update-Rate von 17 Mal pro Sekunde. Da das Betriebssystem in der Regel häufiger die Sensorwerte liefert als der übergebene Parameter, entsteht eine große Menge an Sensordaten. Wenn man mit einer Sekunde Ausführungszeit pro Ausführung rechnet, beträgt die Gesamtzeit 100 Sekunden, was zu mehr als 1700 Sensorwerten führt.
Um die große Datenmenge zu reduzieren, wurde die folgende Lösung entwickelt. Eine Variable float before wird zum Beginn des Verfahrens mit dem Wert float before = 0f initialisiert. Wenn der neue Wert, den der Sensor während der Durchführung liefert, größer ist als diebefore-Variable wurde der Wert ausgegeben und der Variablebefore zugewiesen.
1 p r i v a t e f l o a t b e f o r e ;
2 @Override
3 p u b l i c void p r o c e s s A c c e l e r a t i o n D a t a ( f l o a t [ ] v a l u e s ) {
4 f l o a t xValue = v a l u e s [ 0 ] ;
5 i f ( xValue > b e f o r e ) {
6 Log . d ("TAG", "VALUE: " + xValue ) ;
7 b e f o r e = xValue ;
8 }
9 }
10
Listing 5.2:Ermittlung der Konditionsgröße
Tabelle 6.1 verschafft einen Überblick über die gemessenen Höchstwerte des Sensors pro Durchgang1. Anschließend wurde anhand dieser Werte der Durchschnitt von 11,61f berechnet.
1Ein Durchgang besteht aus zehnmaligem Ausführen der Schwenkbewegung nach rechts.
Tabelle 5.1.:Ergebnisse Horizontale Beschleunigung Durchgang Höchstwert des Sensors
1 11.76
2 12.83
3 11.42
4 10.31
5 12.12
6 12.01
7 10.95
8 11.33
9 11.49
10 11.91
Durchschnitt 11.61
An diesem Punkt ergaben sich zwei Auswahlmöglichkeiten für die Weiterentwicklung, zwischen denen eine Entscheidung getroffen werden musste.
Option A:
Die Bestimmung der Konditionsgröße für die Schwenkbewegung wird nach den Er- gebnissen der Durchführung beendet und auf 11.61f festgelegt. Nutzer*innen wären dadurch gezwungen, die Gesten in der etwa der selben Geschwindigkeit auszuführen, die für die Ermittlung der Konditionsgröße verwendet wurde. Bei Option A würde der Schwerpunkt somit eher auf der richtigen Ausführungsgeschwindigkeit liegen.
Option B:
Option B besteht darin, einen Toleranzwert zu definieren und zu verwenden, der von dem Konditionswert subtrahiert oder addiert wird. Mithilfe des Toleranzwertes sinkt der Fokus auf die Geschwindigkeit, während gleichzeitig der Fokus auf die häufige Erkennung der Geste steigt, weshalb in der vorliegenden Arbeit mit der Option B fortgefahren wurde.
Da ein stilliegendes Gerät nicht, wie vermutet, den Wert 0 für die Beschleunigung liefert, sondern stets ein Offset vorhanden ist, empfiehlt die Android-Plattform, eine Kalibrierung für die Sensorwerte durchzuführen. Dazu wird beobachtet, wie weit der gemessene Wert von 0 abweicht. Dieser Wert soll im Anschluss von der tatsächlich gemessenenen Beschleunigung subtrahiert werden.
Hierzu wurde die gleiche Methode zur Berechnung des Konditionswertes angewendet und dreimal wiederholt. Der höchste gemessene Offset der drei Achsen ergab für den Test 0,5f. Als Toleranzwert wurde ein Wert von 3f bestimmt, weshalb der errechnete Konditionswert um knapp 3,5f reduziert wird.
So entsteht für die seitliche Schwenkbewegung eine Konditionsgröße von 8f. Alle gemessenen Werte auf der X-Achse, die größer als8fsind, gelten somit als gültig.
1 p u b l i c s t a t i c f i n a l f l o a t MIN_HORIZONTAL_ACCELERATION_VALUE = 8 f ;
Listing 5.3:MIN_HORIZONTAL_ACCELERATION_VALUE
5.1.2. Konditionswert MIN_VERTICAL_ACCELERATION_VALUE
Zur Berechnung des Konditionswertes in der vertikalen Beschleunigung (Beschleuni- gung entlang der Y-Achse) wurde dasselbe Verfahren verwendet. Wie in Tabelle 5.3 zu erkennen, wurde ein Durchschnittswert von 8,92f berechnet. Es wird auch hierbei vom
Tabelle 5.2.:Ergebnisse Vertikale Beschleunigung Durchgang Höchstwert des Sensors
1 8.61
2 8.99
3 7.42
4 8.32
5 10.11
6 11.01
7 9.09
8 8.34
9 8.23
10 9.11
Durchschnitt 8.92
Durchschnittswert der Toleranzwert und der Offset abgezogen. Der Konditionswert wird deshalb mit5fdefiniert.
1 p u b l i c s t a t i c f i n a l f l o a t MIN_VERTICAL_ACCELERATION_VALUE = 5 f ; Listing 5.4:MIN_VERTICAL_ACCELERATION_VALUE
5.1.3. Konditionswert MIN_ROTATION_VALUE
Neben den Schwenkbewegungen sind Drehbewegungen Hauptbestandteil der Gesten, die es zu detektieren gilt. Dabei ist die Rotation um die Y-Achse die einzig relevante für die vorliegende Arbeit. Um die nötige Rotationsgeschwindigkeit bestimmen zu können, muss auch hierfür eine Konditionsgröße ermittelt werden. Die selbe Methodik, wie bei den vorangegangenen Werten, ergab einen Durchschnittswert von rund 11f.
Die Bewegung, die dafür ausgeführt wurde, war die Rotation des Mobilgerätes um die eigene Y-Achse, ausgehend von der Standardposition. Auch dies wurde 100 Mal wiederholt. Nach Entfernen des Toleranzwertes verbleibt der Wert von rund 7f und wird der konstanten Variable MIN_ROTATION_VALUE zugewiesen.
1 p u b l i c s t a t i c f i n a l f l o a t MIN_ROTATION_VALUE = 7 f ;
Listing 5.5:MIN_ROTATION_VALUE
5.1.4. Konditionswert MIN_GRAVITY_VALUE
Wie aus der Benennung des Konditionswertes ersichtlich, soll im Folgenden ein Wert definiert werden, der die Positionierung des Gerätes mithilfe des Gravity-Sensors be- stimmen soll. Legt man das Gerät mit der Rückseite flach auf einen Tisch, gibt der Gravity-Sensor für die Z-Achse einen Wert von maximal 9,81. Legt man das Telefon mit der Bildschirmseite auf den Tisch, würde der Wert -9,81 betragen. Befindet sich das Telefon in der Standardposition, sodass die Y-Achse orthogonal zum Boden verläuft, wirkt die gesamte Schwerkraft auf die Y-Achse mit einem Wert von 9,81. Im Land- schaftsmodus befindet sich die Schwerkraft auf der X-Achse. Der Wertebereich umfasst somit -9,81 bis 9,81.
Um Nutzer*innen die Ausführung zu erleichtern, soll auch hier eine Toleranzgrenze definiert werden. Folglich wird der Wert mit 6f definiert.
1 p u b l i c s t a t i c f i n a l f l o a t MIN_GRAVITY_VALUE = 6 f ; Listing 5.6:MIN_GRAVITY_VALUE
Abschließend kann festgehalten werden, dass zur Ermittlung der Konditionsgrößen nur Dreh- und Schwenkbewegungen berücksichtigt wurden, die feste Bestandteile der vier Gesten bilden. Eine horizontale Schwenkbewegung in den positiven Bereich der X-Achse stellt Teilbewegung 1 der MotionType.Send dar. Dabei wurde ein positiver Konditionswert erarbeitet. Der positive Konditionswert ist jedoch nur für eine Ausfüh- rung der Geste mit der rechten Hand relevant. Im Quellcode wird für die Ausführung mit der linken Hand der selbe Wert im negativen Bereich (-8f) verwendet. Das gleiche Prinzip lässt sich auch auf die Rotationsbewegung übertragen.
5.2. Detektoren
Im kommenden Abschnitt werden Implementierungsdetails zu den Detektor-Klassen aufgezeigt und die verwendeten Algorithmen zur Erkennung der Gesten erläutert.
5.2.1. DetectionManager
Der DetectionManager dient zur Entlastung der Service-Klasse und entkapselt die Verantwortlichkeit für die Detektoren. Weiterhin stellt der DetectionManager nicht nur ein Singleton-Objekt dar, sondern auch das Observable-Objekt des Observer Patterns und implementiert deshalb das Interface MotionSensorSource. Als Ergebnis enthält der DetectionManager eine Liste von Observer-Objekten, die sich als Observer an- und abmelden können. Wenn das System ein neues SensorEvent zurückgibt, werden Observer-Objekte (SensorDataListener) durch dieforwardSensorData()-Methode benach- richtigt. Zusätzliche Funktionalität des DetectionManagers stellt die Factory-Methode
startDetectors()dar, die die Instanziierung der Detektoren vereinfacht und in sich kapselt.
1 @Override
2 p u b l i c void s t a r t D e t e c t o r s ( Context c o n t e x t ) {
3 s e n s o r D a t a L i s t e n e r L i s t = new A r r a y L i s t < >() ;
4 new SendMotionDetector ( c o n t e x t , new I n t e n t ( ) , t h i s ) ;
5 new R ec ei ve Mo ti on De te ct or ( c o n t e x t , new I n t e n t ( ) , t h i s ) ;
6 new DropMotionDetector ( c o n t e x t , new I n t e n t ( ) , t h i s ) ;
7 new ScoopMotionDetector ( c o n t e x t , new I n t e n t ( ) , t h i s ) ;
8 }
Listing 5.7:Methode zur Instanziierung der Detektoren
Aus dem obigen Code-Ausschnitt wird ebenso ersichtlich, welche Konstruktor-Parameter erforderlich sind. Jede Detektor-Klasse erweitert die MotionDetector-Superklasse und benötigt deshalb einen Context-Parameter, ein Intent-Objekt und ein MotionSensorSource- Objekt. Zur Erkennung einer zusätzlichen fünften Geste muss dementsprechend die MotionDetector-Klasse erweitert und die nötigen Methoden implementiert werden.
Anschließend ist erforderlich die neue Instanz mit den nötigen Parameter in der obigen Methode zu erzeugen.
5.2.2. MotionDetector
Die Klasse MotionDetector ist die Superklasse von der die nachfolgenden Detektor- Klassen als Subklassen erben. Die MotionDetector-Klasse wurde als eine abstrakte Superklasse definiert, da sie sowohl Methoden enthält, die sie selbst implementiert und an ihre Subklassen vererbt, als auch Methoden, die von den Unterklassen implementiert werden müssen.
Die MethodensendBroadcast()undtimestamp()sind Methoden, die für alle Subklassen die gleiche Funktionalität besitzen, weshalb diese nur in der Superklasse implementiert werden. Im Folgenden wird diesendBroadcast()-Methode erläutert, die zur Benachrich- tung anderer Komponenten oder Anwendungen dient. Bei Aufruf der Methode muss als Parameter ein MotionType-Objekt übergeben werden. MotionTypes stellen dabei Enumeration-Objekte dar, wovon vier existieren: SEND, RECEIVE, DROP und SCOOP.
1 @Override
2 p u b l i c void sendBroadcast ( MotionType motionType ) {
3 i n t e n t . s e t A c t i o n ( INTENT_IDENTIFIER ) ;
4
5 s w i tc h ( motionType ) {
6 c a s e SEND :
7 i n t e n t . p u t E x t r a ( STRING_EXTRA_IDENTIFIER , SEND_MOTION) ;
8 break;
9 c a s e RECEIVE :
10 i n t e n t . p u t E x t r a ( STRING_EXTRA_IDENTIFIER , RECEIVE_MOTION) ;
11 break;
12 c a s e DROP:
13 i n t e n t . p u t E x t r a ( STRING_EXTRA_IDENTIFIER , DROP_MOTION) ;
14 break;
15 c a s e SCOOP :
16 i n t e n t . p u t E x t r a ( STRING_EXTRA_IDENTIFIER , SCOOP_MOTION) ;
17 break;
18 d e f a u l t :
19 r e t u r n;
20 }
21
22 c o n t e x t . sendBroadcast ( i n t e n t ) ;
23 }
Listing 5.8:Methode zum Versenden eines Broadcasts bei erfolgreicher Gestenerkennung Für das Senden eines Broadcasts wird die Broadcast-Nachricht in ein Intent-Objekt ver- packt. Dafür muss dem Intent-Objekt zur Ermöglichung einer eindeutigen Identifikation des Broadcast-Events ein Aktionsstring übergeben werden2. DerINTENT_IDENTIFIER- String kann von der App-Komponente genutzt werden, um sich für den Broadcast zu registrieren. Eine Möglichkeit zur Registrierung zeigt der folgende Ausschnitt aus der Beispiel-Anwendung, die für diese Arbeit angelegt wurde.
1 @Override
2 p r o t e c t e d void o n S t a r t ( ) {
3 super . o n S t a r t ( ) ;
4 s e r v i c e F a c a d e . s t a r t D e t e c t i o n S e r v i c e ( ) ;
5
6 I n t e n t F i l t e r f i l t e r = new I n t e n t F i l t e r ( ) ;
7 f i l t e r. addAction ( Constants . INTENT_IDENTIFIER ) ;
8 r e g i s t e r R e c e i v e r ( motionBroadcastReceiver , f i l t e r) ;
9 }
Listing 5.9:Registrierung des BroadcastReceivers
Diese Option ist geeignet, wenn der BroadcastReceiver erst und nur zur Laufzeit der Anwendung registriert werden soll. In der onStop() -Lifecyclemethode kann dieser wieder abgemeldet werden. Die alternative Option ist die Registrierung mithilfe der AndroidManifest.xml-Datei. Auf diese Weise bleibt die Anwendung als BroadcastRecei- ver registriert, auch wenn diese geschlossen wird und kann somit vom System gestartet werden. MitputExtra(String, String)können zusätzliche Informationen an den Intent angehangen werden [Vgl. 4]. In der Bibliothek existieren vier konstante String-Werte, die repräsentativ für die vier Gesten stehen und dem Intent als zusätzliche Information hinzugefügt werden können.
Die Methode timestamp() gibt die aktuelle Zeit in Millisekunden zurück und wird verwendet, um Zeitstempel für MotionDetectionState-Objekte zu setzen, wenn die angeforderte Bedingung für die Sensorwerte erfüllt ist. Im nächsten Abschnitt wird näher auf MotionDetectionStates eingegangen.
Die Methoden, die in den Unterklassen implementiert werden müssen, stellen Metho- den dar, deren Implementierungsdetails sich von Klasse zu Klasse unterscheiden.
2Im Quellcode: intent.setAction(INTENT_IDENTIFIER)
MotionDetectionState
Wie in Kapitel Grundlagen erläutert, wird jede Geste in Teilgesten unterteilt. Für jede der Teilgesten werden ein oder mehrere Sensoren verwendet, um feststellen zu können, ob diese Geste vollzogen wurde. Wenn einer der Sensorwerte der verwendeten Sensoren für diese Teilgeste eine notwendige Bedingung erfüllt, wird dieses Ereignis in einem MotionDetectionState-Objekt abgespeichert. Ein MotionDetectionState-Objekt besitzt dementsprechend zwei Attribute:boolean detectedundlong timestamp.
5.2.3. SendMotionDetector
Der SendMotionDetector ist zuständig für die Erkennung der Geste MotionType.SEND.
Im Folgenden werden ursprüngliche und endgültige Lösungen sowie die aufgetretenen Probleme erläutert.
1. Lösungsansatz
Bei der ersten entwickelten Lösung wurden die Sensoren für die Schwerkraft und die lineare Beschleunigung verwendet, um eine angemessene Erkennung der Geste zu ermöglichen. Für eine erfolgreiche Ausführung dieser Geste wurden drei Teilbe- wegungen definiert: Schwenkbewegung entlang der X-Achse, Ausholbewegung und Wurfbewegung entlang der X-Achse. Dafür wurden im Vorfeld drei MotionDetectionS- tates definiert:motionRight,motionBackundmotionForth.
Die Teilbewegung motionRight wird durch den Linear-Acceleration-Sensor mithilfe der Konditionsgröße MIN_HORIZONTAL_ACCELERATION_VALUE ermittelt.
Das Ende der Ausholbewegung kann durch den Gravity-Sensor erkannt werden, da sich in diesem Fall das Gerät im Landschaftsmodus befindet und die Schwerkraft auf die X-Achse des Geräts wirkt. Der Gravity-Sensor liefert hierfür einen kleineren Sensorwert als -6f, wenn das Gerät entsprechend entlang der Z-Achse von der Standardposition in den Landschaftsmodus rotiert wurde.
Das Ende der Wurfbewegung wird auf die gleiche Weise wie die Ausholbewegung detektiert, nur dass sich das Gerät in diesem Fall auf der anderen Seite des Landschafts- modus befindet. Dementsprechend beträgt der Sensorwert größer als 6f sein.
Bei jeder erfolgreichen Ausführung einer Teilgeste wird die Methodedetect()ausgeführt.
Bei jedem Aufruf dieser Methode wird kontrolliert:
• Geben alle MotionDetectionStates für das boolesche Attributdetectedden Wert truezurück?
• Ist die Zeitdifferenz (in Millisekunden) zwischen dem Zeitpunkt der Detektion und dem aktuellen Zeitpunkt kleiner als die erforderliche Größe (MAX_TIME_DIFF
= 500)? Für diese Überprüfung relevante MotionDetectionStates:motionRightund motionBack.
• Wurde die Ausholbewegung vor der Wurfbewegung erkannt?
Wenn alle Bedingungen erfüllt wurden, gilt die Geste als angemessen ausgeführt.
Problem
Der Nachteil bei diesem Ansatz war, dass dieser ersten Implementierung nur rechtshän- dige Ausführungen berücksichtigt wurden. Linkshändige Nutzer*innen wären dadurch auf eine Ausführung mit der rechten Hand gezwungen. Das Problem wird verursacht, da bei dieser Lösung geprüft wird, ob die Ausholbewegung vor der Wurfbewegung erfolgt ist. Da technisch die Ausholbewegung ein Sensorwert von weniger als -6f bedeu- tet, kehrt sich bei Linkshänder*innen die Definition um: eine Ausholbewegung mit der linken Hand liefert einen Wert von größer als 6f. Aus diesem Grund muss die Abfrage über die Reihenfolge der Aushol - und Wurfbewegung an die Handseite angepasst werden.
2. Lösungsansatz
Der zweite und damit der finale Lösungsansatz berücksichtigt Links- sowie Rechtshän- der*innen. Dazu wird zusätzlich der Gyroskop-Sensor verwendet. In Kombination mit dem Beschleunigungssensor soll eindeutig identifiziert werden, ob und mit welcher Hand die Teilbewegung 1 durchgeführt wird. Zum Ausführen der Ausholbewegung muss das Gerät um seine Y-Achse gedreht werden. Die Drehrichtung und der zu- gehörige Sensorwert sind bei links- oder rechtshändige Ausführung entscheidend unterschiedlich. Deshalb werden drei weitere MotionDetectionStates definiert und initialisiert.
1 p r i v a t e f i n a l M o t i o n D e t e c t i o n S t a t e motionRight ;
2 p r i v a t e f i n a l M o t i o n D e t e c t i o n S t a t e motionLeft ;
3 p r i v a t e f i n a l M o t i o n D e t e c t i o n S t a t e r o t a t i o n C l o c k W i s e ;
4 p r i v a t e f i n a l M o t i o n D e t e c t i o n S t a t e r o t a t i o n C o u n t e r C l o c k W i s e ;
5 p r i v a t e f i n a l M o t i o n D e t e c t i o n S t a t e b a c k P o s i t i o n ;
6 p r i v a t e f i n a l M o t i o n D e t e c t i o n S t a t e f o r t h P o s i t i o n ;
7
8 p u b l i c SendMotionDetector ( Context c o n t e x t , I n t e n t i n t e n t , MotionSensorSource motionSensorSource ) {
9 super ( c o n t e x t , i n t e n t , motionSensorSource ) ;
10 b a c k P o s i t i o n = new M o t i o n D e t e c t i o n S t a t e ( f a l s e , 0 ) ;
11 f o r t h P o s i t i o n = new M o t i o n D e t e c t i o n S t a t e ( f a l s e , 0 ) ;
12 motionRight = new M o t i o n D e t e c t i o n S t a t e ( f a l s e , 0 ) ;
13 motionLeft = new M o t i o n D e t e c t i o n S t a t e ( f a l s e , 0 ) ;
14 r o t a t i o n C l o c k W i s e = new M o t i o n D e t e c t i o n S t a t e ( f a l s e , 0 ) ;
15 r o t a t i o n C o u n t e r C l o c k W i s e = new M o t i o n D e t e c t i o n S t a t e ( f a l s e , 0 ) ;
16 }
Listing 5.10:MotionDetectionStates der SendMotionDetectors
Die Rotation gegen den Uhrzeigersinn erfolgt bei der Ausführung mit der rechten Hand, wobei das Gerät im Uhzeigersinn rotiert wird, wenn die Auführung linkshändig erfolgt. Aus diesem Grund wurde der folgende Algorithmus implementiert:
1 @Override
2 p u b l i c void processGyroData ( f l o a t [ ] v a l u e s ) {
3 f l o a t yValue = v a l u e s [ 1 ] ;
4
5 i f ( yValue > MIN_ROTATION_VALUE) {
6 r o t a t i o n C l o c k W i s e . d e t e c t e d = t r u e ;
7 r o t a t i o n C l o c k W i s e . timestamp = timestamp ( ) ;
8 d e t e c t ( ) ;
9 }
10
11 i f ( yValue < −MIN_ROTATION_VALUE) {
12 r o t a t i o n C o u n t e r C l o c k W i s e . d e t e c t e d = t r u e ;
13 r o t a t i o n C o u n t e r C l o c k W i s e . timestamp = timestamp ( ) ;
14 d e t e c t ( ) ;
15 }
16 }
Listing 5.11:Verarbeitung der Werte des Gyroskop-Sensors
Für eine Rotation gegen den Uhrzeigersinn liefert der Gyroskop-Sensor negative Werte, wobei im Uhrzeigersinn positive Werte geliefert werden. Da für die Ausführung der Geste MotionType.SEND die Rotation des Gerätes nur nebensächlich passiert und das Gerät nicht aktiv gedreht wird, stellte sich durch manuelle Tests heraus, dass die Werte des Sensors kleiner ausfallen als z.B. für die Geste MotionType.RECEIVE, wo die Rotation die Rotation die Hauptbewegung ist. Aus diesem Grund wurde der Konditionswert MIN_SEND_ROTATION_VALUE = 3.5f eingeführt.
Demzufolge wird diedetect()-Methode angepasst und unterschieden in zwei Kontroll- zweige:
Ausführung mit der rechten Hand
• Geben die MotionDetectionStatesmotionRight, backPosition, forthPosition, rotation- CounterClockwisefür das boolesche Attributdetectedden Werttruezurück?
• Ist die Zeitdifferenz (in Millisekunden) zwischen dem Zeitpunkt der Detektion und dem aktuellen Zeitpunkt kleiner als die erforderliche Größe (MAX_TIME_DIFF
= 500)? Für diese Überprüfung relevante MotionDetectionStates:motionRightund backPosition.
• Wurde die Ausholbewegung vor der Wurfbewegung erkannt bzw. wurde der negative Gravity-Sensorwert vor dem positiven Gravity-Sensorwert erkannt?
Treffen alle Bedingungen zu, gilt die Ausführung mit der rechten Hand als erkannt.
Ausführung mit der linken Hand
• Geben die MotionDetectionStatesmotionLeft, backPosition, forthPosition, rotation- Clockwisefür das boolesche Attributdetectedden Werttruezurück?
• Ist die Zeitdifferenz (in Millisekunden) zwischen dem Zeitpunkt der Detektion und dem aktuellen Zeitpunkt kleiner als die erforderliche Größe (MAX_TIME_DIFF
= 500)? Für diese Überprüfung relevante MotionDetectionStates:motionLeftund forthPosition.
• Wurde der positive Gravity-Sensorwert vor dem negativen Gravity-Sensorwert erkannt?
Treffen alle Bedingungen zu, gilt die Ausführung mit der linken Hand als erkannt.
Mit diesem Lösungsansatz lassen sich sowhl links- als auch rechtshändige Gesten
