Hochschule Bremen. Echtzeit-Erkennung einer Kurve mit dem Core Motion Framework des IOS SDK

Transkript

1 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: Datum der Abgabe Erstprüfer: Prof. Dr. Barbara Grüter Zweitprüfer: Simon Bogutzky M. Sc.

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

3 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. III

4 Inhaltsverzeichnis 1. Einleitung Motivation Aufgabenstellung Aufbau der Arbeit 2 2. Grundlagen Core Motion Framework Sensoren des iphone Beschleunigungssensor Gyroskop Magnetometer GPS Definition einer Kurve 8 3. Konzepte Magnetometer Attitude-Roll Analyse Referenzwinkel Bekannte Probleme der Konzepte Probleme des Magnetometer-Konzepts Probleme des Attitude-Roll Analyse-Konzepts Kardanische Blockade Umsetzung Allgemeiner Aufbau des Prototyps Grundkonfiguration Location Manager Grundkonfiguration Motion Manager Umsetzung Magnetometer Konzept Umsetzung Attitude-Roll Analyse Konzept Umsetzung Referenzwinkel Konzept Evaluation Testaufbau Teststrecke Testpersonen Testergebnisse Auswertung Fazit und Ausblick Fazit Ausblick 32 Literaturverzeichnis 34 Abbildungsverzeichnis 37 Tabellenverzeichnis 38 IV

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

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

7 Das sechste Kapitel zieht ein abschließendes Fazit, gefolgt von einem Ausblick was für Änderungen und Erweiterungen möglich und sinnvoll wären. 3

8 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. 4

9 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. 5

10 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 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]. 6

11 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] 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] 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]. 7

12 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]. 8

13 3 Konzepte 3.1 Magnetometer Mit dem Magnetometer des iphones lässt sich ein Kompass nachbauen. Dieser nutzt, wie in Kapitel 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 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 9

14 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. 10

15 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 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. 11

16 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 12

17 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 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. 13

18 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. 14

19 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 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]. 15

20 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 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 16

21 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. 17

22 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 18

23 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. 19

24 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]. 20

25 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. 21

26 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 22

27 um in Kapitel angesprochene Probleme zu vermeiden. Für die Berechnung des benötigten Roll-Wertes wird folgende Formel angewandt [vgl 3.2] [24]: atan2(2 (quat. y quat. w quat. x quat. z), 1 2 quat. y quat. y 2 q. z + quat. z) Um den nun erhaltenen Wert im Bogenmaß in Gradmaß umrechnen zu können, wird dieser mit 180/ pi 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. 23

28 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. 24

29 Da Probleme wie die Kardanische Blockade [vgl ] 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: atan2(2 (quat. y quat. w quat. x quat. z), 1 2 quat. y quat. y 2 q. z + quat. z) Um den nun erhaltenen Wert im Bogenmaß in Gradmaß um zurechnen, wird dieser mit 180/ pi 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. 25

30 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 eingegangen wird. Die Testpersonen gehen eine vorgegebene Strecke, welche im Kapitel 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. 26

31 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 27

32 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 Person 1 Person 2 Person 3 Person 4 Beinlänge Lang Kurz Lang 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 festgelegten Kurven zugeordnet werden. So konnten Statistiken zu jeder Erkennung und jeder Person erstellt werden. 28

33 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. 29

34 Abbildung 5.2: Karte mit Ergebnissen der Erkennungen je Kurve Abbildung 5.2 stellt erneut die Karte mit der Teststrecke aus Kapitel 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. 30

35 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 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 ]. 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. 31

36 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 32

37 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. 33

38 Literaturverzeichnis [1] [2] [3] [4] [5] Wikipedia (2015): Eine Tätigkeit im Flow erleben ; Online en [Stand ] [6] IOS Developer Library: Core Motion Framework Reference ; Online otion_reference/index.html#//apple_ref/doc/uid/tp [Stand ] [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 celerometerdata_class/index.html#//apple_ref/swift/struct/cmacceleration [Stand ] [10] IOS Developer Library: Getting the Rotation Rate ; Online rodata_class/index.html#//apple_ref/c/tdef/cmrotationrate [Stand ] [11] IOS Developer Library: CLLocationManager Class Reference ; Online ocationmanager_class/index.html [Stand ] 34

39 [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 tutorial-core-motion [Stand ] [14] IOS Developer Library: CMAttitude Class Reference ; Online tude_class/index.html [Stand ] [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 [Stand ] [17] Denivip Media (2013): The art of core motion in ios ; Online [Stand ] [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 [Stand ] 35

40 [21] IOS Developer Library: CMAttitude Reference Frame ; Online tude_class/index.html#//apple_ref/c/tdef/cmattitudereferenceframe [Stand ] [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 vicemotion_class/#//apple_ref/occ/instp/cmdevicemotion/magneticfield [Stand ] [24] Wikipedia (2015): Conversion between quaternions and Euler angles ; Online [Stand ] [25] Wikipedia (2015): Radiant (Einheit) ; Online [Stand ] [26] IOS Developer Library: Obtaining the Change in Attitude ; Online tude_class/index.html#//apple_ref/occ/instm/cmattitude/multiplybyinverseofattitud e: [Stand ] 36