Hochschule Bremen

Echtzeit-Erkennung einer Kurve mit dem Core

Motion Framework des IOS SDK

Bachelorarbeit

im Studiengang Internationaler Studiengang Medieninformatik

von

Jan Christoph Schrader

Matrikelnummer: 339786

Datum der Abgabe 04.05.2015

Erstprüfer: Prof. Dr. Barbara Grüter

Zweitprüfer: Simon Bogutzky M. Sc.

II

Eidesstattliche Erklärung

Hiermit versichere ich eidesstattlich, dass ich die vorliegende Arbeit selbständig und

ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle

Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten

Schriften entnommen sind, wurden als solche kenntlich gemacht. Die Arbeit wurde

in gleicher oder ähnlicher Form keinem anderen Prüfungsamt vorgelegt. Mir ist

bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.

Bremen, 4. Mai 2015

Unterschrift

III

Zusammenfassung

Die Themen Ganganalyse und Bewegungserkennung sind ein aktuelles und breites

Thema der Informatik. Diese Arbeit beschäftigt sich mit dem Teilaspekt der

Kurvenerkennung. Mit Hilfe des Core Motion Framework von Apple soll ein

Algorithmus entwickelt werden, welcher in Echtzeit erkennt, wann ein Benutzer mit

dem Handy in der Tasche um eine Kurve geht. Hierfür wurden drei Konzepte

erarbeitet die auf verschiedene Sensoren und Daten zurückgreifen. Während ein

Konzept das Magnetometer nutzt, greifen zwei Sensoren auf Werte des Gyroskops

zurück.

Im Rahmen der Arbeit wird auf Eigenarten und Probleme der Konzepte

eingegangen und mögliche Lösungen werden aufgezeigt.

Die verschiedenen Konzepte werden nach deren Ausarbeitung in einem Prototyp

umgesetzt, welcher für einen Test auf einer vorgegeben Strecke verwendet wird.

Die Auswertung der Ergebnisse zeigen ein deutlich besseres Abschneiden des

Konzeptes, welches Attitude Roll Daten nutzt und mit einem Referenzwinkel

arbeitet, gegenüber den anderen beiden Konzepten.

Einige mögliche Verbesserungen und Erweiterungen der Erkennung werden

abschließend in dieser Arbeit aufgezeigt.

Abstract

Gait analysis and motion tracking is a present and large topic in computer science.

This thesis deals with turn detection. Using the Core Motion Framework from the

Apple SDK the goal of this thesis is to develop an algorithm that detects a turn while

the user has an iPhone in his pants pocket. Three different approaches using the

magnetometer or the gyroscopes roll value doing a data analysis or using a

reference angle were developed. Multiple problems of the approaches had to be

dealt with before they were tested on a fixed track.

An evaluation of the results shows the advantages using a reference angle and the

roll values of the gyroscope over the other approaches. Though several weaknesses

could be determined and possible improvements were provided in a forward plan.

IV

Inhaltsverzeichnis

1. Einleitung 1

1.1. Motivation 1

1.2. Aufgabenstellung 2

1.3. Aufbau der Arbeit 2

2. Grundlagen 4

2.1. Core Motion Framework 4

2.2. Sensoren des iPhone 5

2.2.1. Beschleunigungssensor 6

2.2.2. Gyroskop 7

2.2.3. Magnetometer 7

2.2.4. GPS 7

2.3. Definition einer Kurve 8

3. Konzepte 9

3.1. Magnetometer 9

3.2. Attitude-Roll Analyse 10

3.3. Referenzwinkel 13

3.4. Bekannte Probleme der Konzepte 15

3.4.1. Probleme des Magnetometer-Konzepts 15

3.4.2. Probleme des Attitude-Roll Analyse-Konzepts 16

3.4.3. Kardanische Blockade 16

4. Umsetzung 18

4.1. Allgemeiner Aufbau des Prototyps 18

4.2. Grundkonfiguration Location Manager 20

4.3 Grundkonfiguration Motion Manager 20

4.4. Umsetzung Magnetometer Konzept 22

4.5. Umsetzung Attitude-Roll Analyse Konzept 22

4.6. Umsetzung Referenzwinkel Konzept 24

5. Evaluation 26

5.1. Testaufbau 26

5.1.1. Teststrecke 27

5.1.2. Testpersonen 28

5.2. Testergebnisse 28

5.3. Auswertung 31

6. Fazit und Ausblick 32

6.1. Fazit 32

6.2. Ausblick 32

Literaturverzeichnis 34

Abbildungsverzeichnis 37

Tabellenverzeichnis 38

1

1 Einleitung

Die Einleitung bietet einen Einstieg in die Problematik, die Motivation hinter dem

Thema und die Struktur der Arbeit.

1.1 Motivation

Die Ganganalyse und Bewegungserkennung ist ein aktuelles und breit gefächertes

Thema der Informatik. In diesen Bereich fällt auch das Thema dieser Arbeit.

Viele weit verbreitete Anwendungen für Smartphones wie zum Beispiel “Google Fit”

[1], “Moves” [2] oder “Apple Health” [3] führen Ganganalysen durch. Diese

Anwendungen verfolgen und analysieren, wie auch viele Fitness Anwendungen, die

Bewegungen und Aktivitäten des Benutzers. Dies geschieht in der Regel allerdings

recht oberflächlich und beinhaltet meist nur einen Schrittzähler, eine

Aktivitätserkennung und einen Streckenverlauf der mittels GPS aufgezeichnet

wurde.

Eine Erkennung einer Kurve in Echtzeit geht einen Schritt weiter und analysiert die

Aktivität des Benutzers im Detail.

In der Informatik wird der Kontext in dem der Benutzer eine Anwendung benutzt,

immer wichtiger. Wenn dem Benutzer zum Beispiel Werbung gezeigt wird, soll diese

möglichst von dem Supermarkt sein, welchen er gerade betritt. Das sollte so

funktionieren, dass das Gerät erkennt in welchem Kontext es sich gerade bewegt,

und nicht erst durch eine Eingabe des Benutzers an diese Information gelangen.

Informationen zu einem solchen Kontext kann eine Kurvenerkennung beisteuern.

Navigationssysteme für Autos greifen auf GPS zurück um den aktuellen Fortschritt

der Route zu erfassen. Wenn man zu Fuß unterwegs ist und auf eine Navigation

zurückgreift, ist dieses Vorgehen vielleicht zu ungenau und könnte zu fehlerhaft

sein. Eine Kurvenerkennung kann hier zuverlässiger sagen, dass der Benutzer

abgebogen ist, als die Positionsbestimmung über GPS.

Hier wären als Anwendungsgebiet auch mobile Spiele zu nennen. Ein mobiles Spiel

“Fangen” zum Beispiel könnte den suchenden Spielern mitteilen, dass der

flüchtende Spieler gerade abgebogen ist.

2

Ein weiteres Beispiel in der das Thema Bedeutung finden kann sind Flow-

Maschinen [4]. Diese analysieren den Gang des Benutzers und unterstützen ihn

durch Klang, der auf Basis der Ganganalyse erstellt wurde, das Flow Erlebnis zu

erlangen [5].

1.2 Aufgabenstellung

In dieser Arbeit werden mehrere Konzepte zur Erkennung einer Kurve entwickelt

und evaluiert. Hierzu müssen zunächst die nötigen Grundlagen geschaffen werden

bevor die Lösungskonzepte erarbeitet werden können. Zu der Herausarbeitung der

Konzepte gehört auch eine Analyse, welche Probleme auftreten könnten und wie

man diese lösen kann.

Der nächste Schritt in dieser Arbeit ist die Umsetzung der verschiedenen Konzepte

in einem Prototyp, welcher genutzt werden kann um in einer Studie die

verschiedenen Konzepte zeitgleich zu evaluieren.

Eine Schwierigkeit dieser Arbeit ist es, die Erkennung einer Kurve in Echtzeit zu

realisieren und nicht in einem Datensatz Kurven zu erkennen.

Die fertige Arbeit soll eine solide Grundlage für weitere Arbeit in diesem

Themengebiet und mögliche Erweiterungen der Erkennung bieten.

1.3 Aufbau der Arbeit

Das zweite Kapitel dieser Arbeit befasst sich mit den Grundlagen die für das Thema

dieser Arbeit erforderlich sind. Zunächst wird auf das genutzte Core Motion

Framework eingegangen und anschließend werden die verfügbaren Sensoren

erläutert, sowie eine Definition einer Kurve aufgestellt.

Im dritten Kapitel werden die verschiedenen Konzepte zur Erkennung hergeleitet

und erläutert. Ebenso werden hier verschiedene Einschränkungen und Probleme

beschrieben.

Das vierte Kapitel umfasst die Umsetzung und Implementation der Konzepte.

Im fünften Kapitel der Arbeit wird ein Testszenario für eine Evaluation beschrieben

und die Ergebnisse der Testpersonen werden aufgezeigt und ausgewertet.

3

Das sechste Kapitel zieht ein abschließendes Fazit, gefolgt von einem Ausblick was

für Änderungen und Erweiterungen möglich und sinnvoll wären.

4

2 Grundlagen

Dieses Kapitel befasst sich mit den Grundlagen der für die Kurvenerkennung

erforderlichen Technik. In Kapitel 2.1 wird das Core Motion Framework des iOS

SDK genauer betrachtet.

In Kapitel 2.2 werden die verfügbaren Sensoren eines iPhone beschrieben. Die

verwendete Definition einer Kurve wird in Kapitel 2.3 beschrieben.

2.1 Core Motion Framework

Das Core Motion Framework bietet eine Unterstützung beim Zugriff auf die Daten

der im iPhone verbauten Sensoren. Es besteht die Möglichkeit entweder auf die

Rohdaten zuzugreifen oder auf transformierte Daten, relativ zur aktuellen

Orientierung des Geräts. Ebenso ist die Möglichkeit gegeben an gewisse Daten auf

mehreren Wegen zu gelangen. Die Roll, Pitch und Yaw Daten, die auf die Rotation

des Geräts schließen lassen, können zum Beispiel direkt über das Framework

ausgelesen werden. Diese werden mit Hilfe der Euler-Winkel errechnet. Da dies in

gewissen Situationen Probleme verursachen kann [vgl. 3.4] bietet das Framework

die Alternative der Quaternionen aus denen sich die Werte berechnen lassen.

Auch gibt es die Möglichkeit Daten zu erhalten, die mit Hilfe mehrerer Sensoren

errechnet wurden, um Ungenauigkeiten der einzelnen Sensoren zu korrigieren. Dies

geschieht durch verschiedene Algorithmen die im Framework durch Apple

implementiert wurden.

Für die verschiedenen Sensoren kann man unterschiedliche Frequenzen einstellen

in denen neue Werte geliefert werden sollen. Zusätzlich beinhaltet das Framework

einen Schrittzähler und eine Bewegungserkennnung, die ermittelt ob der Benutzer

gerade geht, läuft oder Auto fährt [6].

Das Core Motion Framework kann ab iOS Version 4.0 aufwärts genutzt werden.

Funktionen für den Magnetometer Sensor wurden in Version 5.0 eingeführt.

5

2.2 Sensoren des iPhone

Die Sensoren bilden die Grundlagen für die Kurvenerkennung. Sie liefern Daten, die

Aufschluss über die aktuelle Orientierung und Veränderungen der Orientierung des

Geräts geben. Sie bieten die Möglichkeit Rückschlüsse auf Aktivitäten und

Verhalten des Benutzers zu ziehen.

Die verschiedenen Sensoren sind nicht in allen Geräten verfügbar. Die

nachfolgende Grafik zeigt eine Übersicht der Verfügbarkeit.

Abbildung 2.1: Verfügbarkeit der Sensoren [7]

Für diese Arbeit sind der Beschleunigungssensor, das Magnetometer, das

Gyroskop und GPS interessant. Diese sind alle spätestens ab dem iPhone 4

verfügbar.

Mehrere Sensoren errechnen ihre Daten in Relation zu einem internen

Koordinatensystem. Dieses basiert auf den drei Achsen X, Y und Z.

6

Abbildung 2.2: Aufbau der Achsen in einem iPhone [8]

In Abbildung 2.2 sind die angesprochenen drei Achsen zu sehen. Sensoren wie zum

Beispiel der Beschleunigungssensor liefern einen Wert für jede der drei Achsen.

Weiterhin gibt es zum Beispiel auch die Möglichkeit die Rotation des Geräts um eine

bestimmte Achse mit dem Gyroskop zu errechnen [Abb. 2.2].

Auf die Funktionsweise der Sensoren im Einzelnen wird in den nächsten

Abschnitten eingegangen.

2.2.1 Beschleunigungssensor

Der Beschleunigungssensor misst die lineare Beschleunigung des Geräts. Dies

geschieht indirekt über ein kleines Objekt auf das die Gravitationskraft wirkt. Über

die Intensität lässt sich schließen, wie stark diese Beschleunigung ist. Wendet man

dieses Verfahren auf drei relativ zum Gerät positionierte Achsen an, kann man die

lineare Beschleunigung des ganzen Geräts messen [9].

Der Beschleunigungssensor ist in jedem iPhone verfügbar [Abb. 2.1].

7

2.2.2 Gyroskop

Das Gyroskop bestimmt die aktuelle Ausrichtung des Geräts an allen drei Achsen

[vgl. Abb. 2.2].

Zur Bestimmung der Orientierung wird die Erdanziehung genutzt. Ein Wert

beschreibt die Rotation um jeweils eine der Achsen und wird in Bogenmaß pro

Sekunde angegeben. Die gelieferten Sensordaten stehen im Verhältnis zum

vorherigen Wert und sind keine absoluten Werte [10].

Das Gyroskop ist verfügbar ab dem iPhone 4 [Abb. 2.1].

2.2.3 Magnetometer

Ein Magnetometer misst die Stärke des Magnetfeldes um das Gerät herum. Es

berechnet die Ausrichtung zum magnetischen Nordpol und funktioniert damit ähnlich

wie ein analoger Kompass.

Zu unterscheiden ist der magnetische Nordpol vom geografischen Nordpol. Der

magnetische Nordpol bewegt sich und befindet sich zurzeit nördlich von Kanada.

Der geografische Nordpol liegt auf der Erdachse. Nutzt man den

CLLocationManager, errechnet dieser mit Hilfe des Magnetometers das “True

Heading”, welches die Ausrichtung zum geografischen Nordpol darstellt [11].

Ein Magnetometer ist verfügbar ab dem iPhone 3GS [Abb. 2.1].

2.2.4 GPS

Der GPS Sensor bestimmt die aktuelle Position des Geräts. Hierzu werden

verschiedene Daten wie die geografische Länge, Breite und Höhe ebenso wie die

Geschwindigkeit und die Genauigkeit ermittelt. GPS ist verfügbar ab dem iPhone 3

[Abb. 2.1].

8

2.3 Definition einer Kurve

Eine Kurve wird in dieser Arbeit dadurch definiert, dass eine Person ihren normalen

Gang unterbricht und ihre Ausrichtung ändert. Da dies nicht innerhalb von sehr

kurzer Zeit geschehen kann, muss die Veränderung über einen Zeitraum betrachtet

werden. Zusätzlich muss ein Grenzwert festgelegt werden, ab dem die Veränderung

der Ausrichtung ausreichend ist um als Kurve erkannt zu werden. Analog zu der

Ausarbeitung wird dieser Grenzwert auf 45° festgelegt, da er genug Spielraum lässt

um einen unregelmäßigen Gang zuzulassen und dennoch genau genug ist um ein

nicht abruptes Abbiegen zu erfassen [12].

9

3 Konzepte

3.1 Magnetometer

Mit dem Magnetometer des iPhones lässt sich ein Kompass nachbauen. Dieser

nutzt, wie in Kapitel 2.2.3 beschrieben, das Magnetfeld um das Gerät, um damit die

aktuelle Ausrichtung des Geräts zum magnetischen Norden zu errechnen.

Diese Eigenschaft kann man nutzen um die aktuelle Ausrichtung des Geräts in der

Hosentasche zu ermitteln und durch Veränderungen feststellen wann um eine Kurve

gegangen wurde.

Wie in der Definition einer Kurve in Kapitel 2.3 festgelegt wurde, soll ab einer

Veränderung um 45° eine Kurve erkannt werden.

Durch den Location Manager werden, wie in Kapitel 2.2.3 beschrieben, regelmäßig

die Werte des “True Heading”, also der aktuellen Ausrichtung zum geografischen

Nordpol, geliefert. Dieser Wert wird zu Beginn der Erkennung gespeichert und als

aktuelle Gangrichtung definiert. In regelmäßigen Abständen soll nun geprüft werden

ob sich die aktuelle Ausrichtung im Vergleich zu der anfänglich gespeicherten

Ausrichtung um mehr als 45° verändert hat. Sollte dies der Fall sein, wurde eine

Kurve erkannt und die Gangrichtung muss neu definiert werden. Hierfür wird der

Wert gespeichert der bei der Überprüfung genutzt wurde.

Abbildung 3.1: Übersicht der Bereiche für eine Ausrichtung oder eine erkannte

Kurve

10

Da ein Gang selten komplett geradeaus geht, aber dabei nicht unbedingt immer

eine Kurve beinhalten muss, wird, wie in der oben stehenden Grafik zu sehen ist,

ein zusätzlicher Bereich eingeführt der ab 30° Veränderung beginnt und bis 45°

geht. Hier wird die Ausrichtung neu definiert, aber keine Kurve erkannt.

Der Bereich ist groß genug um mögliche Korrekturen der Gangrichtung vornehmen

zu können, wie zum Beispiel der Gang an einer lang gezogenen Strecke die über

mehrere Meter ihre Richtung ändert.

Veränderungen im Bereich bis 30° werden nicht betrachtet, da in diesem Ereignisse

wie zum Beispiel das Überholen eines anderen Fußgängers liegen.

3.2 Attitude-Roll Analyse

Dieser Ansatz basiert auf einer kontinuierlichen Betrachtung der Roll Werte, die vom

Core Motion Framework geliefert werden [vgl. 2.1]. Der Roll Wert beschreibt die

Rotation des Geräts um die Y-Achse. Je nach Drehrichtung verändern sich die

Werte ins Positive oder Negative. Dies ist in der folgenden Grafik zu sehen.

Abbildung 3.2: Übersicht der möglichen Rotationen an den verschiedenen Achsen

[13]

Dieses Verhalten ermöglicht es Daten zu erhalten, die eine Bewegung der Hüfte

repräsentieren und damit sehr geeignet für eine Kurvenerkennung sind.

11

Da die Daten relativ zu den vorherigen und nicht absolut sind, ist es nicht möglich,

wie beim Konzept das auf dem Magnetometer basiert, zu prüfen, ob die Werte einen

Grenzwert überschreiten [vgl. 3.1].

Dieses Konzept soll Unterschiede in den Daten feststellen, die eine Veränderung

zwischen “Geradeaus”-Gang und “Kurve”-Gang charakterisieren.

In der folgenden Grafik sieht man zunächst den Gang geradeaus.

Abbildung 3.3: Verhalten des Roll-Wertes über die Zeit bei einem normalen Gang

Zu sehen ist ein wellenförmiges, stetiges Muster das Ausschläge von ca. -150 bis

+150 Grad beim Roll-Wert hat. Dieses Muster wiederholt sich immer wieder, so

lange man einen gleichmäßigen Gang hat. In der folgenden Grafik wird bereits der

Unterschied zum „Kurven-Gang“ deutlich.

12

Abbildung 3.4: Unterschied im Verhalten des Roll-Wertes über die Zeit zwischen

normalen Gang und Gang um eine Kurve

Zu sehen ist hier ein Teil von ca. Sekunde 4 bis 7 in dem die Ausschläge nur ins

Positive gehen, aber noch ähnlich hoch wie in der vorherigen Grafik beim „Gang

geradeaus” sind. In diesem Abschnitt wurde tatsächlich gerade um eine Kurve

gegangen. Nach der Kurve ist wieder das bereits bekannte Muster des „Gang

geradeaus” zu sehen.

Hier gibt es zwei Möglichkeiten. Neben der eben dargestellten Variante gibt es

zusätzlich noch die Möglichkeit, dass die Werte während einer Kurve nur in den

negativen Bereich ausschlagen. Angenommen das iPhone befindet sich in der

linken Hosentasche, dann werden bei einer Kurve nach links nur kleine Schritte mit

dem linken Bein gemacht. Bei einer Kurve nach rechts muss man hingegen große

Schritte machen um die Drehung zu vollziehen und daher auch eine größere

13

Bewegung mit der Hüfte machen. Mit dem Gerät in der rechten Hosentasche würde

sich das Verhalten umkehren.

Der Ansatz ist nun, diese Veränderungen zu erkennen. Gelingt das, kann ein Gang

um die Kurve erkannt werden.

Da pro Sekunde ca. 100 neue Werte dazu kommen und diese einzeln keine hohe

Aussagekraft besitzen, wird hier ein Zeitfenster festgelegt in dem die Daten

analysiert und verglichen werden. Dieses wird auf 100 Werte festgelegt und

entspricht einer kompletten Schwingung vom Ausgangswert, in den positiven

Bereich, in den negativen Bereich und zurück zum Ausgangswert. Es muss also ein

Mechanismus entwickelt werden, welcher aus den Werten immer zwei Zeitfenster

an Daten bereitstellt. Eins mit den aktuellsten 100 Werten und eins mit den älteren

100 Werten. Diese beiden Zeitfenster müssen nun unterschieden werden. Da die

Ausschläge größer oder kleiner werden, ändert sich auch der Durchschnittswert in

diesem Bereich. Eine zusätzliche Möglichkeit die gewünschte Veränderung

festzustellen bietet die Distanz zwischen den kleinsten und dem größten Wert eines

Zeitfensters. Idealerweise gehören die beiden Werte zu einer Schwingung,

allerdings stellt es auch kein Problem dar sollte dies nicht der Fall sein. Wenn die

Größe der Schwingung sich verändert, wirkt sich das auch auf die Distanz aus.

Daher kann ein solcher Wert auch zum Vergleich heran gezogen werden.

Einige Datenanalysen haben ergeben, dass 95 Prozent Unterschied bei der Distanz

zwischen neuem und altem Zeitfenster und 80 Prozent Unterschied beim

Durchschnittswert eine gute Ausgangslage für eine Kurvenerkennung bieten.

Auf Probleme mit diesen Werten wird im Kapitel 3.4.2 eingegangen.

3.3 Referenzwinkel

Dieses Konzept funktioniert ähnlich wie das Konzept des Magnetometers [vgl. 3.1]

von einer Referenzausrichtung aus. Das Core Motion Framework bietet eine Klasse

“CMAttitude” welche die Ausrichtung des Geräts auf verschiedene Arten

repräsentiert [14]. Neben der Repräsentation als Drehmatrix gibt es auch die

Möglichkeit der Eulerwinkel (Roll, Yaw, Pitch) und der Quaternionen. Der Vorteil

durch die Nutzung der Quaternionen gegenüber der Nutzung der Eulerwinkel wird in

Kapitel 3.4 behandelt.

14

Beim Start der Erkennung wird das aktuelle CMAttitude-Objekt gespeichert und als

aktuelle Gangrichtung festgelegt um eine Referenzausrichtung für die

Kurvenerkennung zu haben.

Da in regelmäßigen Abständen neue CMAttitude-Objekte durch den Motion

Manager bereitgestellt werden, soll durch Methoden der CMAttitude-Klasse die

Differenz zwischen der Referenzausrichtung und der neu erhaltenen Ausrichtung

errechnet werden. Da es sich hierbei um die komplette Orientierung des Geräts

handelt, müssen aus den neuen Werten noch die für die Erkennung relevanten

Werte errechnet werden. Hierfür wird wie im “Attitude Roll Analyse”-Konzept der

Roll Wert herangezogen, da er die Hüftbewegung abbildet, wenn sich das Gerät in

der Hosentasche befindet [vgl. 3.2].

Abbildung 3.5: Übersicht der Bereiche für eine Ausrichtung oder eine erkannte

Kurve

Wie in der Grafik zu sehen ist, werden Veränderungen bis 30° nicht beachtet um

kleinere Korrekturen der Gangrichtung zu ignorieren. Der Bereich zwischen 30° und

45° Veränderung wird genutzt um die aktuelle Gangrichtung festzulegen. Dafür wird

das aktuelle CMAttitude-Objekt wie beim Start der Erkennung als

Referenzausrichtung gespeichert. Hiermit werden Korrekturen der Gangrichtung

abgefangen wie zum Beispiel bei einer Strecke die einen Drall nach rechts hat, aber

eigentlich keine Kurve beinhaltet.

15

Beträgt die Veränderung mehr als 45°, wird die Ausrichtung ebenfalls als neue

Referenz gesetzt und zusätzlich eine Kurve erkannt [vgl. 2.3].

3.4 Bekannte Probleme der Konzepte

Die verschiedenen Konzepte haben mehrere bekannte Probleme oder

Einschränkungen in ihrer Funktionalität die in diesem Kapitel der Arbeit behandelt

werden.

Ein allgemeines Problem der Konzepte besteht darin, dass sich das Gerät während

der Erkennung immer in der gleichen aufrechten Lage in der Tasche befinden muss.

Sollte das Gerät auf die Seite rutschen, oder von Beginn an auf der Seite liegen,

kann es zu fehlerhaften Erkennungen führen. Sollte das Gerät schief liegen, werden

zwar dieselben Bewegungen registriert, allerdings auf einer anderen Achse oder auf

mehrere Achsen verteilt. Das würde die in den Konzepten verwendeten Werte

verfälschen und zu ausbleibenden oder falschen Erkennungen führen.

Im folgenden Abschnitt wird auf mehrere spezifische Probleme eingegangen.

3.4.1 Probleme des Magnetometer-Konzepts

Ein allgemeines Problem bei der Verwendung des Magnetometers ist, dass es von

anderen elektronischen Geräten gestört werden kann. Dies nimmt dann direkten

Einfluss auf die Daten. Ebenso kann es vorkommen, dass man sich in Bereichen

ohne magnetischen Einfluss befindet. In diesen Bereichen würde der Magnetometer

nicht funktionieren und fehlerhafte Daten liefern.

Die hohe Anfälligkeit des Magnetometers wird auch damit belegt, dass es

Unterschiede in den Daten gibt, die durch Veränderungen der Höhe verursacht

werden. Die Werte, die man zum Beispiel im 5. Stock erhält, unterscheiden sich von

Werten die man auf Meeresspiegel-Höhe erhält [15].

16

3.4.2 Probleme des Attitude-Roll Analyse-Konzepts

Das Konzept der Attitude-Roll Analyse [vgl. 3.2] unterscheidet sich stark von den

anderen Konzepten. Es nutzt zwar die gleichen Daten wie die anderen Konzepte,

aber in einem anderen Format. Durch die Verwendung des Bogenmaßes kann nicht

einfach definiert werden, dass ab 45° eine Kurve erkannt werden soll. Daher werden

andere Grenzwerte verwendet, welche allerdings schwer zu finden und von vorne

herein festzulegen sind. Dies liegt daran, dass Personen, auf Grund von

unterschiedlichen Beinlängen, unterschiedliche Gangarten aufweisen.

3.4.3 Kardanische Blockade

Die kardanische Blockade, auch bekannt als “Gimbal Lock” (engl.), bezeichnet ein

Problem das bei der Verwendung der Eulerwinkel auftreten kann. Hierbei kann es

passieren, dass zwei der drei Achsen aufeinander liegen und daher den gleichen

Effekt haben.

Abbildung 3.6: Beispielhafter Ablauf für eine kardanische Blockade [16]

In der Abbildung ist zu sehen, dass durch die Drehung an der Y Achse im zweiten

Schritt der Effekt entsteht, dass die Drehung in Schritt eins und in Schritt drei die

gleiche Wirkung haben obwohl die Drehung einmal auf der X- und einmal auf der Z-

Achse durchgeführt wird. Dieses Verhalten hat zur Folge, dass jede Rotation um

90° unweigerlich zum Verlust eines Freiheitgrades führt und zwei zuvor

unterschiedliche Rotationen den gleichen Effekt haben [17, 18].

Dieses Problem kann bei beiden Konzepten die mit dem Roll-Wert arbeiten,

auftreten, und muss bei der Umsetzung beachtet werden. Eine Möglichkeit dieses

Problem zu umgehen, bietet die Nutzung von Quaternionen. Diese verwenden einen

vierdimensionalen Vektor um die aktuelle Orientierung zu repräsentieren und

17

Probleme wie die kardanische Blockade zu umgehen [18]. Quaternionen werden

durch das Core Motion Framework zur Verfügung gestellt und können daher als

Alternative zu den Eulerwinkeln genutzt werden.

18

4 Umsetzung

Dieses Kapitel der Arbeit behandelt die Implementation der verschiedenen

Konzepte für einen Prototypen, der für den Test verwendet werden soll [vgl. 5.1].

4.1 Allgemeiner Aufbau des Prototyps

Der allgemeine Aufbau des Prototyps ist in der folgenden Grafik dargestellt.

Abbildung 4.1: Aufbau des Prototypen

19

Die Basis bilden zwei Manager-Klassen, die Rohdaten von den Sensoren über den

CLLocationManager [11] und den CMMotionManager [6] erhalten. Diese Daten

werden an die verschiedenen Erkennungen weitergereicht. Dort werden sie

entsprechend aufbereitet und analysiert.

Erkannte Kurven werden als Event an den ViewController weitergegeben und dort

mit einem Zeitstempel und der aktuellen GPS-Position verknüpft. Diese Information

wird dann mit CoreData in der Anwendung gespeichert. Zusätzlich bietet die

Anwendung die Möglichkeit, diese Daten danach als CSV-Datei zu exportieren. Der

ViewController ist das Herzstück der Anwendung. In dieser Klasse werden alle

Funktionen übernommen, die nicht direkt mit der Erkennung zu tun haben. Ebenso

werden hier auch die beiden oben genannten Manager-Klassen für die Erkennung

initialisiert.

Außerdem wurde eine Klasse “MotionEvent” eingeführt.

Abbildung 4.2: Aufbau der MotionEvent-Klasse

Diese wird genutzt um eine erkannte Kurve zu repräsentieren. Wie in der Abbildung

zu sehen ist, gibt es einen Zeitstempel der aussagt, wann das Event erkannt wurde

und einen NSString der von der Erkennung gesetzt wird um identifizieren zu

können, welche Erkennung das Objekt erstellt hat.

Mit der Methode “sendEvent” kann das Event über einen Delegate verschickt

werden. Ein Delegate stellt eine Beziehung zwischen zwei Klassen her und

ermöglicht den Austausch von Nachrichten [19]. Angenommen Klasse A setzt

Klasse B als Delegate, dann kann Klasse A sicherstellen, dass Klasse B eine

Methode zum Empfang einer Nachricht implementiert hat und darüber Nachrichten

an die Klasse B verschicken.

Im nächsten Abschnitt wird auf die grundlegenden Konfigurationen und

Initialisierungen der Ansätze eingegangen.

20

4.2 Grundkonfiguration Location Manager

Als erstes wird ein neues Objekt des CLLocationManager erstellt und seine “init”-

Methode aufgerufen. Dem Location Manager wird der Wert “self” als Delegate

zugewiesen, was bewirkt, dass die Klasse sowohl den Location Manager als auch

die Methode für den Empfang der Daten stellt [vgl 4.1]. Registriert der Location

Manager einen neuen Wert, wird dieser über den Delegate an die Klasse geleitet.

Damit der Location Manager funktioniert, ist es zwingend notwendig, dass die

Methode “requestWhenInUseAuthorization” des Location Manager einmal

aufgerufen wird. Diese ist dafür verantwortlich, dass die Anwendung mittels eines

Popups die Erlaubnis des Benutzers einholt, auf die Position zuzugreifen zu dürfen.

Um eine möglichst genaue Bestimmung der Position zu erhalten wird dem Location

Manager als “distanceFilter” und als “desiredAccuracy” der Wert

“kCLLocationAccuracyBest” gesetzt. Diese Konstante bewirkt möglichst genaue

Positionen. Hier könnte man auch etwas ungenauere Modi wählen um

beispielsweise Akkulaufzeit zu sparen.

Um nicht zu viele Aktualisierungen der Ausrichtung zu erhalten wird der

“headingFilter” auf den Wert 1 gesetzt um erst Veränderung ab 1° zu betrachten.

4.3 Grundkonfiguration Motion Manager

Der Motion Manager muss, ähnlich wie der Location Manager im vorherigen

Abschnitt, konfiguriert werden. Diese Konfiguration wird einmalig aufgerufen, sobald

der User auf den “Start”-Knopf des Prototypen drückt.

Als erstes wird die Methode “setupForStartUpdating” aufgerufen. Diese Methode

setzt diverse Variablen für die Erkennungen auf ihre Ausgangswerte.

An dieser Stelle wird zusätzlich geprüft ob das aktuelle Gerät über die benötigten

Sensoren verfügt. Nur wenn dies der Fall ist, wird fortgefahren mit dem Setzen des

Update Intervalls. Das Update Intervall legt fest wie oft der Motion Manager

Aktualisierungen der Daten liefern soll. Dieses wird auf 1/100 gesetzt, was

gleichbedeutend mit einem Intervall von 100Hz ist. Der Motion Manager soll pro

Sekunde 100 neue Daten liefern. Dies ist ein üblicher Wert für diese Art von

Anwendungen [20].

21

Als nächstes werden die Aktualisierungen gestartet. Hier wird der Parameter

“CMAttitudeReferenceFrameXArbitraryZVertival” als Reference Frame übergeben.

Ein Reference Frame wird als Basis Koordinatensystem für den Motion Manager

genutzt. Es dient als Ausgangsposition, von derer aus alle anderen Daten ausgehen

[17]. Der hier genutzte Wert bedeutet, dass die Z-Achse vertikal und die X-Achse in

eine beliebige Richtung horizontal zeigen soll [21]. Die möglichen Alternativen zu

diesem Reference Frame unterscheiden sich nicht deutlich von dem gewählten, da

diese nur für den Magnetometer Auswirkungen haben. Dieser wird aber in dieser

Arbeit nicht über den Motion Manager angesteuert. Da die Alternativen außerdem

eine höhere CPU-Last zur Folge hätten, wurde das oben genannte Reference Frame

gewählt [21].

Da die Erkennung nur zu gewissen Zeitpunkten ausgeführt werden soll, wird jede

Aktualisierung gezählt und nur wenn eine gewisse Anzahl überschritten wurde

sollen die Erkennungen aufgerufen werden. Andernfalls würden die Erkennungen

nicht richtig funktionieren, da, wie in Kapitel 2.3 definiert wurde, eine Kurve einen

gewissen Zeitraum benötigt. Zusätzlich würde eine ständige Überprüfung eine sehr

hohe CPU Auslastung verursachen. Der Grenzwert wurde hierfür auf 100 festgelegt,

da im Durchschnitt ein Schritt eine Sekunde dauert, was wie zuvor festgelegt ca.

100 Daten bedeutet [22]. Damit wird jede Sekunde beziehungsweise bei in etwa

jedem Schritt auf eine Kurve geprüft.

Den Methoden für die Erkennungen wird ein “CMAttitude”-Objekt [14] übergeben,

was verdeutlicht, dass hier nicht die Rohdaten der Sensoren verwendet werden

sondern über das Core Motion Framework auf die Daten zugegriffen wird. Die

Vorteile dieses Vorgehens wurden in Kapitel 2.1 erläutert.

22

4.4 Umsetzung Magnetometer Konzept

Dieser Abschnitt beschäftigt sich mit der Umsetzung des Magnetometer Konzepts.

Die Aktualisierungen des Location Manager werden über die Methode

“locationManager:didUpdateHeading:” bereitgestellt. Diese wird vom Location

Manager über den Delegate aufgerufen [vgl. 4.1].

Der Parameter “newHeading” enthält die aktuelle Ausrichtung des Magnetometers

und wird an die Methode “detectDirectionChangeWithMagnetometer” übergeben.

Diese errechnet zunächst die Differenz zwischen der letzten gespeicherten

Ausrichtung und der aktuellen Ausrichtung (“newHeading”). Beträgt diese

Veränderung mehr als 30° wird die aktuelle Ausrichtung aktualisiert und in der

Variable “lastHeading” gespeichert. Beträgt die Veränderung zusätzlich mehr als

45°, wurde hier eine Kurve erkannt und ein Motion Event erstellt [vgl. 4.1].

Das Event wird dann durch die “sendMotionEvent” Methode an den ViewController

weiter gegeben.

Bei dieser Umsetzung gibt es noch die Besonderheit, dass auf das Core Location

Framework zugegriffen wird und nicht auf das Core Motion Framework. Bei der

Umsetzung des Konzepts stellte sich heraus, dass die Daten des Magnetometer,

welche das Core Motion Framework durch die Klasse “CMCalibratedMagneticField”

[23] bereitstellt, ungenauer und weniger zuverlässig sind als dieselben Daten die

durch den Location Manager erhalten werden konnten. Der Zugriff auf die

CLHeading-Werte lässt sich allerdings problemlos austauschen mit dem Zugriff auf

die Magnetometer-Daten über das DeviceMotion-Objekt, welches durch das Core

Motion Framework bei jeder Aktualisierung bereitgestellt wird.

4.5 Umsetzung Attitude-Roll Analyse Konzept

Der folgende Abschnitt erläutert die Umsetzung des “Attitude-Roll Analyse”-

Konzepts.

Damit wie in Kapitel 3.2 erläutert immer zwei Listen an Werten zur Verfügung

stehen, werden diese in der Methode “manageFramesForDetection” gehandhabt.

Der Methode wird ein Objekt vom Typ “CMAttitude” übergeben, aus welchem die

aktuelle Ausrichtung errechnet werden kann. Hierfür werden Quaternionen genutzt

23

um in Kapitel 3.4.3 angesprochene Probleme zu vermeiden. Für die Berechnung

des benötigten Roll-Wertes wird folgende Formel angewandt [vgl 3.2] [24]:

𝑎𝑡𝑎𝑛2(2 ∗ (𝑞𝑢𝑎𝑡. 𝑦 ∗ 𝑞𝑢𝑎𝑡. 𝑤 − 𝑞𝑢𝑎𝑡. 𝑥 ∗ 𝑞𝑢𝑎𝑡. 𝑧), 1 − 2 ∗ 𝑞𝑢𝑎𝑡. 𝑦 ∗ 𝑞𝑢𝑎𝑡. 𝑦 − 2 ∗ 𝑞. 𝑧 + 𝑞𝑢𝑎𝑡. 𝑧)

Um den nun erhaltenen Wert im Bogenmaß in Gradmaß umrechnen zu können,

wird dieser mit 180/ 𝑝𝑖 multipliziert [25].

Die Listen haben eine festgelegte Größe, welche in der Variable

“frameSizeForDirectionChangeDetection” festgelegt wird. Dieser Wert wurde, wie in

Kapitel 4.3 erläutert, auf 100 gesetzt. Um in einer Liste die letzten 100 Daten und in

der anderen Liste die vorletzten 100 Daten zu haben, müssen die neuen Werte

korrekt einsortiert werden.

Dafür gibt es drei Möglichkeiten, wobei die Erste darin besteht, dass die Liste mit

den älteren Daten noch nicht 100 Werte hat und der neue Wert daher in diese Liste

geschrieben wird.

Die zweite Option ist, dass in der Liste mit den älteren Daten bereits genug Daten

vorhanden sind, aber in der neueren Liste noch nicht genug Daten vorliegen. In

diesem Fall wird der neue Wert in die aktuelle Liste kopiert.

Im dritten Fall sind in beiden Listen bereits genug Werte vorhanden. Daher wird

zunächst der neue Wert in die aktuelle Liste kopiert. Zusätzlich wird der älteste Wert

der aktuellen Liste in die ältere Liste verschoben. Abschließend wird der älteste

Wert in der älteren Liste gelöscht.

Die folgende Abbildung verdeutlicht dieses Vorgehen noch einmal.

Abbildung 4.3: Listenhandhabung bei der Erstellung der Zeitfenster

Wenn die Listen erstellt sind, kann die Erkennung auf diese zugreifen und hat immer

die zwei benötigten Zeitfenster an Daten zu Verfügung.

24

Der erste Teil der Erkennung errechnet die Durchschnittswerte der Daten in den

jeweiligen Zeitfenstern. Hier werden jeweils alle Werte der Liste addiert und durch

die Anzahl der Werte geteilt. Im gleichen Abschnitt wird ebenfalls der jeweils

kleinste und größte Wert für spätere Überprüfungen gespeichert.

Der zweite Teil der Erkennung nutzt die eben errechneten Werte für die Berechnung

der Distanz zwischen dem Minimum und den Maximum, sowie den Unterschied der

Durchschnittswerte.

Zunächst wird berechnet um wie viel Prozent sich die Distanz zwischen dem

Minimum und den Maximum verändert hat. Des Weiteren wird die Veränderung der

Durchschnittswerte berechnet.

Im letzten Teil der Erkennung wird die Überprüfung auf eine Kurve mit den

errechneten Veränderungen vorgenommen.

Wenn die Bedingungen [vgl. 3.2] erfüllt werden, wird ein Motion Event erstellt und

damit die Erkennung einer Kurve signalisiert.

4.6 Umsetzung Referenzwinkel Konzept

Dieses Kapitel behandelt die Umsetzung des Konzepts “Referenzwinkel” [vgl. 3.3].

Der Funktion für diese Erkennung wird ein CMAttitude-Objekt übergeben. Als erstes

wird geprüft, ob für die Erkennung bereits ein Referenzwinkel gespeichert wurde. Ist

dies nicht der Fall, wird die Ausrichtung des übergebenen Objekts als

Referenzwinkel gespeichert.

Gibt es bereits eine gespeicherte Ausrichtung, wird der Unterschied zwischen der

aktuellen Ausrichtung und der als Referenz gespeicherten Ausrichtung errechnet.

Dies geschieht mit Hilfe der Methode “multiplyByInverseOfAttitude” der Klasse

“CMAttitude” [26]. Diese funktioniert so, dass Sie die Inverse des übergebenen

Objekts, in diesem Fall der Referenzausrichtung, errechnet und mit der aktuellen

Ausrichtung multipliziert. Durch dieses Vorgehen wird der Unterschied zwischen den

beiden Ausrichtungen errechnet und durch die verwendete Methode in der Variable

für die aktuelle Ausrichtung gespeichert. Der vorherige Stand wird überschrieben.

Die aktuelle Ausrichtung wird direkt vor jedem Aufruf der Erkennungsmethode

gespeichert.

25

Da Probleme wie die Kardanische Blockade [vgl. 3.4.3] umgangen werden sollen,

werden ab dieser Stelle Quaternionen genutzt. Durch das Core Motion Framework

[vgl. 2.1] kann man auf diese Daten problemlos über das CMAttitude Objekt

zugreifen. Genutzt werden nun die Daten des eben errechneten Unterschieds der in

der Variable “curAttitudeForDirectionChangeDetection” gespeichert ist. Um den

benötigten Roll-Wert zu errechnen, wird folgende Formel [24] verwendet:

𝑎𝑡𝑎𝑛2(2 ∗ (𝑞𝑢𝑎𝑡. 𝑦 ∗ 𝑞𝑢𝑎𝑡. 𝑤 − 𝑞𝑢𝑎𝑡. 𝑥 ∗ 𝑞𝑢𝑎𝑡. 𝑧), 1 − 2 ∗ 𝑞𝑢𝑎𝑡. 𝑦 ∗ 𝑞𝑢𝑎𝑡. 𝑦 − 2 ∗ 𝑞. 𝑧 + 𝑞𝑢𝑎𝑡. 𝑧)

Um den nun erhaltenen Wert im Bogenmaß in Gradmaß um zurechnen, wird dieser

mit 180/ 𝑝𝑖 multipliziert [25]. Durch diese Umrechnung kann nun der Roll-Wert in

Grad dem Konzept in Kapitel 3.3 entsprechend überprüft werden.

Zunächst wird geprüft, ob sich der Wert zwischen 30 und 45 Grad befindet. In

diesem Fall wird die der Methode übergebene Ausrichtung als neue

Referenzausrichtung gespeichert [vgl. 3.3]. Danach wird zusätzlich geprüft ob der

Wert auch über 45 Grad liegt. In diesem Fall wird ein Motion Event-Objekt erstellt,

da eine Kurve erkannt wurde. Dies enthält den aktuellen Zeitstempel und den

Namen der Erkennung. In diesem Fall wird auch noch zwischen Links- (>45°) und

Rechtskurve (<-45°) unterschieden.

26

5 Evaluation

In diesem Kapitel der Arbeit wird ein Test des Prototyps geplant, durchgeführt und

ausgewertet.

5.1 Testaufbau

Zur Überprüfung der Konzepte wurde ein Testszenario für den in Kapitel 4

entwickelten Prototypen erstellt. Für den Test wurden vier Testpersonen gesucht,

die bestimmte Kriterien erfüllen, auf die in Kapitel 5.1.2 eingegangen wird. Die

Testpersonen gehen eine vorgegebene Strecke, welche im Kapitel 5.1.1 gezeigt

wird.

Für alle Testpersonen sollen die gleichen Bedingungen gelten. Das zur Verfügung

gestellte iPhone 4S soll in der linken Hosentasche getragen werden. Das iPhone 4S

hat alle benötigten Sensoren [vgl. 2.2] und daher läuft der Prototyp mit allen drei

Erkennungen der Konzepte parallel. Alle vier Testläufe wurden durchgeführt,

während auf dem Gerät die zu dem Zeitpunkt aktuellste iOS Version 8.2 installiert

war.

Während des Tests wird via GPS durchgehend die Position bestimmt. Wird von

einem der drei Konzepte eine Kurve erkannt, verknüpft der Prototyp die aktuelle

Position mit der Erkennung. So lässt sich in der Auswertung einfacher

nachvollziehen, wo genau eine Kurve erkannt wurde und wo es auf der Strecke

fehlerhafte Erkennungen gab. Sämtliche Daten wie die Erkennungen, die Positionen

und Zeitstempel die gesammelt werden, speichert der Prototyp in einer Datenbank.

Diese Daten lassen sich nachträglich als CSV-Datei exportieren.

27

5.1.1 Teststrecke

Die geplante Strecke für den Test ist auf der folgenden Karte zu sehen. Die Strecke

beginnt mit einem geraden Stück, welches dafür gedacht ist die Testpersonen in

einen gleichmäßigen Gang beschleunigen zu lassen. Ebenso bietet es Zeit um

eventuelle Korrekturen an der Positionierung des Geräts in der Tasche

vorzunehmen. Danach bietet die Strecke eine Mischung aus sechs Links- und sechs

Rechtskurven, welche unterschiedlich schnell aufeinander folgen können.

Eine zusätzliche Schwierigkeit soll der Abschnitt zwischen Kurve zwei und drei

darstellen. In diesem Bereich gibt es keine Möglichkeit geradeaus zu gehen und

erfordert daher einige Korrekturen der Richtung ohne dass dabei eine Kurve erkannt

werden soll.

Abbildung 5.1: Die Teststrecke mit Start, Ziel und den Kurven

28

5.1.2 Testpersonen

Bei der Auswahl der Testpersonen wurde Wert darauf gelegt, dass drei von vier

Personen unterschiedliche Beinlängen haben, da die Beinlänge die Gangart

beeinflussen und daher zu unterschiedlichen Ergebnissen führen kann.

Um eine Kontrolle der Ergebnisse und deren Aussagekraft zu haben, sollten

allerdings auch zwei Personen relativ gleich gebaut sein und so einen guten

Vergleich bieten können.

Testperson Beinlänge

Person 1 Lang

Person 2 Kurz

Person 3 Lang

Person 4 Mittel

Tabelle 5.1: Beinlänge der Testpersonen

Den Testpersonen war vor dem Test bekannt, dass es sich um das Thema

Kurvenerkennung dreht. Ihnen wurde nahegelegt, während des Tests ganz natürlich

zu gehen. Zusätzlich wurden sie dabei auch in ein Gespräch verwickelt, damit sie

sich möglichst wenig auf ihren Gang konzentrieren, sondern auf das Gespräch. Dies

sollte für einen normalen, authentischen Gang sorgen.

5.2 Testergebnisse

Nach jedem durchgeführten Test wurden die in der Datenbank gespeicherten

Dateien für die Auswertung exportiert. Die gespeicherten Erkennungen wurden mit

den enthaltenen GPS-Positionen auf einer Karte eingezeichnet und konnten dann

den in Kapitel 5.1.1 festgelegten Kurven zugeordnet werden. So konnten Statistiken

zu jeder Erkennung und jeder Person erstellt werden.

29

Magnetometer Attitude-Roll Analyse Referenzwinkel

43,75% 37,5% 81,25%

Tabelle 5.2: Gesamtergebnisse der Konzepte

In Tabelle 5.2 sind die Gesamtergebnisse zu sehen. Hier wird die Erkennungsrate

der drei Konzepte von allen vier Testpersonen zusammengefasst dargestellt. Zu

sehen ist, dass die Erkennung mittels Magnetometer 43,75% der Kurven erkannt

hat. Das sind ca. 5-6 von 12 Kurven pro Person. Das zweite Konzept, welches die

Roll Daten analysiert, kommt nur auf 37,5% was, ca. 4-5 Kurven entspricht. Am

besten funktionierte die Erkennung mit Hilfe eines Referenzwinkels. Dieses Konzept

erkannte 81,25% der Kurven und damit 9-10 Kurven pro Person.

Die folgende Tabelle zeigt die Erkennungsrate aufgeschlüsselt nach Methode und

Person.

Person 1 Person 2 Person 3 Person 4

Magnetometer 50% 50% 41,6% 33,3%

Attitude-Roll

Analyse

58,3% 16,6% 41,6% 33,3%

Referenzwinkel 75% 91,6% 83,3% 75%

Tabelle 5.3: Ergebnisse pro Person und Konzept

In Tabelle 5.3 ist besonders die zweite Testperson hervorzuheben. Bei dieser

Person wurden mittels der Roll-Daten Analyse nur zwei Kurven erkannt. Allerdings

klappte die Erkennung mit einem Referenzwinkel sehr gut. Hier wurden 11 von 12

Kurven erkannt.

30

Abbildung 5.2: Karte mit Ergebnissen der Erkennungen je Kurve

Abbildung 5.2 stellt erneut die Karte mit der Teststrecke aus Kapitel 5.1.1 dar.

Neben jeder Kurve ist zu sehen zu wie viel Prozent welche Erkennung funktioniert

hat. Das Ergebnis bezieht sich hierbei auf alle Testpersonen. Auffällig ist die

schlechte Erkennung der ersten Kurve durch die Referenzwinkel Erkennung.

Ebenso fällt die Erkennung mittels Magnetometer nach Kurve sieben fast komplett

aus.

Jedes der drei Konzepte hatte im Verlauf des Tests insgesamt zwei fehlerhafte

Erkennungen.

31

5.3 Auswertung

Die Testergebnisse zeigen, dass die Erkennung mittels Referenzwinkel mit 81,25%

sehr gut geklappt hat. Lässt man die Erkennung der ersten Kurve außen vor,

erreicht diese Methode sogar 95%. Die erste Kurve unterschied sich nicht von den

anderen. Eine mögliche Erklärung wäre hier, dass die Testpersonen sich noch in

einem ungewohnten Umfeld befanden, allerdings erkannten hier die anderen beiden

Konzepte die Kurve deutlich besser.

Das Konzept der Kurvenerkennung mittels Magnetometer erkannte mit 43,75%

lediglich etwas weniger als die Hälfte der Kurven und die Roll Werte Analyse sogar

nur etwas mehr als ein Drittel der Kurven mit 37,5%. Besonders der letzte Wert

weicht hier stark von den Erwartungen ab. Dass die zweite Testperson, welche die

kürzesten Beine hat [vgl. Tabelle 5.1], hier auf lediglich 16,6% erkannte Kurven

kommt, lässt vermuten, dass diese Erkennung stark abhängig von der Gangart des

Benutzers ist. Die vierte Testperson mit mittlerer Beinlänge kommt auch auf nur

33,4%. Dieses Ergebnis lässt vermuten, dass bei den Personen mit kürzeren

Beinen die Ausschläge in den Daten [vgl. 3.2] nicht stark genug waren um von der

Erkennung erfasst zu werden. Ebenso ist es denkbar, dass die Grenzwerte der

Erkennung nicht ideal sind.

Wie in Kapitel 3.4.1 bereits dargestellt wurde, ist das Magnetometer relativ anfällig

für Fehler. Dennoch erkannte dieses Konzept 43,75% der Kurven. Hier gab es keine

großen Unterschiede zwischen den Testpersonen festzustellen.

Bei der zweiten Testperson gab es eine fehlerhafte Erkennung, die von allen drei

Konzepten gemacht wurde. Diese lag zwischen Kurve zwei und Kurve drei. Dieser

Abschnitt war als Schwierigkeit vorgesehen [vgl. 5.1.1]. Hier ist es gut möglich, dass

die Erkennungen nicht falsch funktioniert haben sondern wirklich eine Kurve erkannt

haben, weil die Testperson dementsprechend gegangen ist.

32

6 Fazit und Ausblick

In diesem Kapitel wird diese Arbeit noch einmal abschließend zusammengefasst

und ein Fazit gezogen. Zusätzlich wird ein Ausblick gegeben, wie man die

verschiedenen Konzepte erweitern und Erkenntnisse aus dem Test in die

Erkennung einfließen lassen kann.

6.1 Fazit

Diese Arbeit beschäftigte sich mit verschiedenen Konzepten zur Erkennung einer

Kurve in Echtzeit mit Hilfe des Core Motion Framework des iOS SDK. Hierfür wurde

die Funktionsweise verschiedener Sensoren betrachtet und wie man diese für das

Ziel der Arbeit nutzen kann.

Es wurden drei verschiedene Konzepte erarbeitet und in einem Prototyp umgesetzt.

Diese Konzepte hatten verschiedene Ansätze und verwendeten auch verschiedene

Sensordaten. Ebenso wurden verschiedene Probleme herausgestellt, Eigenarten

der Konzepte erarbeitet und Lösungen in den Prototyp eingearbeitet.

Der Prototyp wurde verwendet um in einem Test die Funktionalität der Erkennung

zu evaluieren. Diese Evaluation ergab, dass das Konzept mit den besten Resultaten

das Core Motion Framework nutzt um die aktuelle Ausrichtung des Geräts zu

analysieren und eventuelle Veränderungen zu erkennen.

6.2 Ausblick

Für die verschiedenen Konzepte gibt es mehrere Möglichkeiten zur Erweiterung.

Eine Möglichkeit, die für alle drei Konzepte denkbar wäre, ist, die Erkennung

unabhängig von der Lage in der Tasche zu machen. Sollte eine Anwendung eine

Kurvenerkennung einsetzen, sollte der Benutzer nicht darauf achten müssen wie

das Gerät in seiner Tasche liegt.

Wie in der Arbeit bereits festgestellt wurde, gibt es verschiedene Gangtypen die sich

auf die Erkennung auswirken. Hier wäre denkbar das Konzept zu erweitern, welches

die Roll Daten analysiert. Hier gäbe es die Möglichkeit ein Lernsystem für die

33

Anwendung zu entwickeln, welches beispielsweise die ersten Gänge eines

Benutzers analysiert und anhand dieser Daten Grenzwerte berechnet und das

Intervall für eine Überprüfung festlegt. Eine weitere Möglichkeit zu vermeiden, dass

Daten in die Zeitfenster falsch eingeteilt werden und damit eine Kurvenerkennung

verhindern, ist der Ansatz auf eine bestimmt Anzahl an Daten eine Fourier

Transformation durchzuführen. So würde sich ermitteln lassen, wann ein Schritt

gemacht wird und anhand dieser Information könnte man seine Zeitfenster erstellen.

Denkbar wäre ebenfalls die Verknüpfung der Kurvenerkennung mit weiteren

Bereichen der Ganganalyse. Hier bietet sich die Schritterkennung an. Diese könnte

ein Taktgeber für die Überprüfung und die Erstellung der Zeitfenster und damit eine

weitere Optimierung des Zeitpunktes der Überprüfung sein.

34

Literaturverzeichnis

[1] https://fit.google.com/

[2] https://www.moves-app.com/

[3] https://www.apple.com/ios/whats-new/health/

[4] http://www.informatik.hs-bremen.de/gob/flow/

[5] Wikipedia (2015): “Eine Tätigkeit im Flow erleben”; Online

http://de.wikipedia.org/wiki/Flow_(Psychologie)#Eine_T.C3.A4tigkeit_im_Flow_erleb

en [Stand 24.4.2015]

[6] IOS Developer Library: “Core Motion Framework Reference”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CoreM

otion_Reference/index.html#//apple_ref/doc/uid/TP40009686 [Stand 24.4.2015]

[7] Alasdair Allan (2011): “Basic Sensors in iOS” S. 2

[8] Alasdair Allan (2011): “Basic Sensors in iOS” S. 39

[9] IOS Developer Library: “Accessing Accelerometer Data”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMAc

celerometerData_Class/index.html#//apple_ref/swift/struct/CMAcceleration [Stand

24.4.2015]

[10] IOS Developer Library: “Getting the Rotation Rate”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMGy

roData_Class/index.html#//apple_ref/c/tdef/CMRotationRate [Stand 24.4.2015]

[11] IOS Developer Library: “CLLocationManager Class Reference”; Online

https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLL

ocationManager_Class/index.html [Stand 24.4.2015]

35

[12] Mahmoud El-Gohary; Sean Pearson; James McNames; Martina Mancini; Fay

Horak; Sabato Mellone; Lorenzo Chiari (2013): “Continuous Monitoring of Turning in

Patients with Movement Disability” S. 4 – 5

[13] Andreas Eichner: “Sensors & Core Motion”; Online

http://wwwbruegge.in.tum.de/lehrstuhl_1/home/98-teaching/tutorials/505-sgd-ws13-

tutorial-core-motion [Stand 24.4.2015]

[14] IOS Developer Library: “CMAttitude Class Reference”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMAtti

tude_Class/index.html [Stand 24.4.2015]

[15] Nirupam Roy; He Wang; Romit Roy Choudhury (2014): “I am a Smartphone

and I can Tell my User’s Walking Direction” K. 4.3

[16] Alex Diener (2010): “Quaternions”; Online

http://www.idevgames.com/articles/quaternions [Stand 24.4.2015]

[17] Denivip Media (2013): “The art of core motion in iOS”; Online

http://blog.denivip.ru/index.php/2013/07/the-art-of-core-motion-in-ios/?lang=en

[Stand 24.4.2015]

[18] Logah Perumal (2011): “Quaternion and Its Application in Rotation Using Sets

of Regions”

[19] Matt Neuburg (2013): “iOS 7 Programming Fundamentals” S. 306

[20] University of Southern California (2013): “Accelerometer Gyroscope”; Online

http://bcf.usc.edu/~trinagre/itp342-20143/lectures/ITP342_Accelerometer.pdf

[Stand 24.4.2015]

36

[21] IOS Developer Library: “CMAttitude Reference Frame”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMAtti

tude_Class/index.html#//apple_ref/c/tdef/CMAttitudeReferenceFrame [Stand

24.4.2015]

[22] Wiebren Zijlstra; At L. Hof (2002): “Assessment of spatio-temporal gait

parameters from trunk accelerations during human walking” S. 6

[23] IOS Developer Library: “Getting the Calibrated Magnetic Field”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMDe

viceMotion_Class/#//apple_ref/occ/instp/CMDeviceMotion/magneticField [Stand

24.4.2015]

[24] Wikipedia (2015): “Conversion between quaternions and Euler angles”; Online

http://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles

[Stand 24.4.2015]

[25] Wikipedia (2015): “Radiant (Einheit)”; Online

http://de.wikipedia.org/wiki/Radiant_(Einheit) [Stand 24.4.2015]

[26] IOS Developer Library: “Obtaining the Change in Attitude”; Online

https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMAtti

tude_Class/index.html#//apple_ref/occ/instm/CMAttitude/multiplyByInverseOfAttitud

e: [Stand 24.4.2015]

37

Abbildungsverzeichnis

2.1: Verfügbarkeit der Sensoren [7] 5

2.2: Aufbau der Achsen in einem iPhone [8] 6

3.1: Übersicht der Bereiche für eine Ausrichtung oder eine erkannte Kurve 9

3.2: Übersicht der möglichen Rotationen an den verschiedenen Achsen [13] 10

3.3: Verhalten des Roll-Wertes über die Zeit bei einem normalen Gang 11

3.4: Unterschied im Verhalten des Roll-Wertes über die Zeit zwischen

normalen und Gang um eine Kurve 12

3.5: Übersicht der Bereiche für eine Ausrichtung oder eine erkannte Kurve 14

3.6: Beispielhafter Ablauf für eine kardanische Blockade [16] 16

4.1: Aufbau des Prototypen 18

4.2: Aufbau der MotionEvent-Klasse 19

4.3: Listenhandhabung bei der Erstellung der Zeitfenster 23

5.1: Die Teststrecke mit Start, Ziel und den Kurven 27

5.2: Karte mit Ergebnissen der Erkennungen je Kurve 30

38

Tabellenverzeichnis

5.1: Beinlänge der Testpersonen 28

5.2: Gesamtergebnisse der Konzepte 29

5.3: Ergebnisse pro Person und Konzept 29