Utilising Accelerometer and Gyroscope in Smartphone to Detect Incidents on a Test Track for Cars

Home , Accelerometer, Gyroscope

Utilising accelerometer and gyroscope in smartphone to detect incidents on a test track for cars

Carl-Johan Holst

Data- och systemvetenskap, kandidat 2017

Luleå tekniska universitet Institutionen för system- och rymdteknik LULEÅ UNIVERSITYOF TECHNOLOGY

BACHELOR THESIS

Utilising accelerometer and gyroscope in smartphone to detect incidents on a test track for cars

Author: Examiner: Carl-Johan HOLST Patrik HOLMLUND [email protected] [email protected]

Supervisor: Jörgen STENBERG-ÖFJÄLL [email protected]

Computer and space technology Campus Skellefteå

June 4, 2017 ii

Abstract

Utilising accelerometer and gyroscope in smartphone to detect incidents on a test track for cars

Every smartphone today includes an accelerometer. An accelerometer works by detecting acceleration affecting the device, meaning it can be used to identify incidents such as collisions at a relatively high speed where large spikes of acceleration often occur. A gyroscope on the other hand is not as common as the accelerometer but it does exists in most newer phones. Gyroscopes can detect rotations around an arbitrary axis and as such can be used to detect critical rotations. This thesis work will present an algorithm for utilising the accelerometer and gyroscope in a smartphone to detect incidents occurring on a test track for cars. Sammanfattning

Utilising accelerometer and gyroscope in smartphone to detect incidents on a test track for cars

Alla smarta telefoner innehåller idag en accelerometer. En accelerometer analyserar acceleration som påverkar enheten, vilket innebär att den kan användas för att detektera incidenter så som kollisioner vid relativt höga hastigheter där stora spikar av acceleration vanligtvis påträffas. Ett gyroskop däremot är inte lika vanlig som en accelerometer men ﬁnns i de ﬂesta nyare telefoner. Ett gyroskop kan detektera rotationer runt en godtycklig axel och kan på så vis användas för att detektera kritiska rotationer. Detta examensarbete kommer att presentera en algoritm för att utnyttja accelerom- etern och gyroskopet i en telefon för att detektera incidenter som inträffar på en test- bana för bilar. iv

Acknowledgements

I would like to thank the team at Data Ductus for giving me a chance to do this thesis work, and in assisting me with all the relatively trivial issues I had during the project. Thank you for putting up with me and making me feel welcome. I would also like to thank Anton Christoffersson for creating similar systems which detect events based on data from the GPS and the microphone. Once we merged our two projects together into the ﬁnal system we had a program which was not only capable, but also versatile and ﬂexible. v

Contents

Abstract ii

Sammanfattning iii

Acknowledgements iv

1 Introduction1 1.1 Goals and purpose...... 2 1.2 Background...... 2 1.2.1 Accelerometer...... 2 1.2.2 Gyroscope...... 2 1.2.3 Android phone...... 2 1.2.4 Android Studio...... 2 1.2.5 Google Go...... 3 1.2.6 Proving grounds...... 3 1.2.7 Nelson Proving Grounds Management...... 3 1.2.8 NPGM Mobile Unit...... 3 1.2.9 Rajd Systech...... 3 1.2.10 Data Ductus...... 4 1.3 Related work...... 4 1.3.1 Zaldiwar et al...... 4 1.3.2 Ali and Alwan...... 4 1.3.3 WreckWatch...... 4 1.4 Method...... 5 1.4.1 Accelerometer...... 5 1.4.2 Gyroscope...... 5 1.4.3 GPS...... 6 1.4.4 Microphone...... 6 1.4.5 Algorithm...... 6 1.5 Social, environmental and ethical considerations...... 6

2 Implementation7 2.1 Application...... 7 2.2 IncidentLib...... 7 2.2.1 Accelerometer...... 8 2.2.2 Gravity...... 8 vi

2.2.3 Gyroscope...... 8 2.2.4 Logging tool...... 9 2.3 Server...... 9

3 Result 10 3.1 Application...... 10 3.1.1 Accelerometer...... 10 3.1.2 Gravity...... 10 3.1.3 Gyroscope...... 11 3.1.4 Test-application...... 12 3.2 Algorithm...... 12 3.2.1 Parameters...... 14 3.3 Testing...... 15

4 Discussion 17 4.1 Discussing the result...... 17 4.2 Limitations...... 17 4.2.1 Hardware limitations...... 17 4.2.2 Mounting malfunction...... 18 4.3 Future work...... 18 4.3.1 Proﬁles...... 18 4.3.2 Hotspots...... 18

5 Conclusion 19 5.1 Project...... 19 5.2 Research phase...... 19 5.2.1 Accelerometer...... 19 5.2.2 Gyroscope...... 20 5.3 Implementation phase...... 20 5.4 Testing phase...... 20 1

Chapter 1

Introduction

Every winter, major car companies descends upon the Swedish city of Arjeplog to test their concept cars and prototypes for use in winter conditions. Around the city, there are multiple test-tracks, called proving grounds, located which are tracks built for the purpose of testing the performance of the cars. These proving grounds use a management system called Nelson Proving Grounds Management (NPGM). NPGM is a system in which cars contain a smartphone that is meant to act as both a tool for the managers of the track and as a device to provide added security for the drivers. This smartphone contains hardware which, in theory, can be used to detect incidents that could occur on a test track such as collisions. During car collisions, high amounts of G-forces occur which can be detected using an accelerometer, and it is also likely that the airbag deploys. Airbags are deployed using explosives, which means they are loud. By using a microphone, it is possible to detect loud noises such as an airbag deploying or even the sound of the car impacting with something else. A gyroscope which detects rotations can be used to detect if the car is rotating rapidly, e.g. spinning while sill being on its wheels, suggesting that the driver might have lost control of the car. The GPS in the phone can then be used to confirm if the car is still moving or if it is stationary. If the car is stationary after having experienced extensive amounts of G-forces and a loud noise is detected, it is highly likely that the car has crashed in which case an emergency event will generate. On the other hand, if the gyroscope detects rapid rotations while the GPS states that the car is still moving, it can be assumed that the driver has lost control and an emergency event will generate immediately. If the accelerometer and microphone then detect significant spikes in G-forces and a loud noise respectively and the GPS states that the car is stationary, a new emergency event will generate. This thesis work presents an algorithm for utilising the above-listed sensors and hardware in a smartphone to detect incidents on a test track for cars. The algorithm listens to the accelerometer, the gyroscope, the GPS, and the microphone in the phone, and by analysing the data determines if an incident has occurred. If an event has occurred, it passes the event on to the server which then handles the event. This thesis work will be focusing on the parts of the algorithm which I specifically worked on, meaning the accelerometer and the gyroscope. 2 Chapter 1. Introduction

1.1 Goals and purpose

The aim of this thesis work was ﬁrst to research the possibility of using data from the accelerometer and gyroscope inside a smartphone to detect incidents on a track such as collisions and other accidents. If it was deemed possible to detect such incidents, I was then supposed to develop a system for detecting incidents on a track and report them to a server. Once the system was completed, it would then be integrated into the NPGM Mo- bile Unit system [1].

1.2 Background

1.2.1 Accelerometer

An accelerometer works by detecting proper acceleration affecting the accelerometer to determine the G-forces affecting the accelerometer [2]. Proper acceleration means acceleration that is relative to free-fall [3]. An object in free-fall would as such have no acceleration affecting it while an object at rest on the surface of the earth would experience an acceleration of 9,81 m/s2 upwards due to the surface pushing the object upwards to negate gravity. Accelerometers in smartphones bases their functionality on micro-electromechanical-systems (MEMS), which measure electric currents based on compression of a seismic mass, often silicon, caused by acceleration [4][5].

1.2.2 Gyroscope

A gyroscope is a device which detects rotations around an arbitrary axis [6]. The gyroscope in a phone detects rotational speed around each axis of the phone in rad/s . By using a timestep and multiplying the timestep with the rotational speed from the gyroscope, it is possible to calculate how many radians the phone has rotated during the time-step to detect rotations over short periods of time.

1.2.3 Android phone

Android is a partially open-source operating-system mainly designed for smartphones and tablets. Android was created by Android Inc. in 2003 and was bought by Google in 2005 who still owns it [7]. The phone used for this project was a Samsung Galaxy S7 [8].

1.2.4 Android Studio

Android Studio is an Integrated Development Environment (IDE) with the purpose of designing and building applications for devices using the Android OS. Android Studio is the ofﬁcial IDE for developing applications for Android as of 2013 [9]. An- droid Studio uses the IntelliJ IDEA platform as its base which is developed by the company JetBrains [10]. 1.2. Background 3

1.2.5 Google Go

Google Go is a relatively new programming language developed by Google [11][12]. Go was created by Google in 2007 and ﬁrst appeared in November 2009. Go version 1.0 released in March 2012.

1.2.6 Proving grounds

Proving grounds are locations where major car companies test and develop new cars. These proving grounds exist in multiple places across the world, some of which are for testing cars for winter conditions and some of which are for testing cars for sum- mer conditions. Proving grounds have very high standards for both safety and security and as such requires systems which provide just that. Nelson Proving Grounds Management (NPGM) is one such system which aims to provide high safety and high security for these proving grounds [1].

1.2.7 Nelson Proving Grounds Management

Nelson Proving Grounds Management (NPGM) is a system for managing activities at proving grounds for cars [1]. Rajd Systech from Piteå is the company which develop NPGM [13]. NPGM involves anything between checking where cars currently are, how many cars are on one particular track and if any car has encountered an emergency as well as managing activities at an administrative level. Cars driving on these proving grounds contain a particular model of an Android smartphone that will be ﬁxated in place, meaning that the phone will, ideally, remain in the same place and orientation relative to the car at all times.

1.2.8 NPGM Mobile Unit

NPGM Mobile Unit [1] is a smartphone which is ﬁxated in place inside the car in a vertical position. The phone will ideally always be ﬁxated in place, meaning that the phone will never move relative to the car. Because the phone does not move relative to the car, any movement that the phone experiences, the car also experiences. If the accelerometer in the phone detects a high amount of G-forces the car, as well as the driver, experienced the same amount of G-forces. However, if the phone were to drop from its mounting, the phone will naturally experience rapid rotations and G-force spikes and, subsequently, send an emergency- event to the server. This event would be considered a false-positive and needs to be averted. It is, therefore, a good idea to give the driver some way of declining the emergency event.

1.2.9 Rajd Systech

Rajd Systech [13] is a company based in Piteå and is the product owner of the Nelson Proving Grounds Management project [1]. Data Ductus [14] is currently involved 4 Chapter 1. Introduction with Rajd Systech and is working closely together to develop a speciﬁc system within NPGM.

1.2.10 Data Ductus

Data Ductus is a company which sells consulting services within IT to other companies and businesses [14]. The company employs roughly 200 people in cities around Sweden and is growing rapidly. Over the past six months, one of the teams at Data Ductus has been working on a project for Rajd Systech to create a system for the Nel- son Proving Grounds Management system in which they use smartphones to detect incidents that occur at proving grounds.

1.3 Related work

The subject of using smartphones to detect incidents on the road is not a new topic. There are completed algorithms for systems which utilise the accelerometer as well as the GPS to determine if an event has occurred with a vehicle. Some work speciﬁcally using smartphones to detect incidents dates back to 2011 [15]. Because there is already a lot done on this subject, what we decided to do was to develop an algorithm of our own, designed for the ongoing project in mind.

1.3.1 Zaldiwar et al.

In 2011, Zaldiwar et al. created a system where they used Android smart-phones and the ODB-II connection in a car [16]. ODB-II is a connection which all modern cars are ﬁtted with which transmits data about the car in real-time such as speed, acceleration, oil pressure, etc.

1.3.2 Ali and Alwan

In 2015, Ali and Alwan at the University of Baghdad Iraq developed a system which made use of the accelerometer, GPS and microphone to detect accidents [17]. Their system made use of the same sensors and hardware that the algorithm presented in this thesis work makes use of, except the gyroscope.

1.3.3 WreckWatch

WreckWatch is a program that was developed by J. White et al. in 2011 [18]. Wreck- Watch involves interpreting data from the accelerometer and acoustic data from the microphone to detect emergency events. If an emergency has occurred, the application contacts nearby emergency services and provides GPS-coordinates for where the accident took place. 1.4. Method 5

1.4 Method

The algorithm works by analysing data from the accelerometer, gyroscope, GPS and microphone to determine if an incident has occurred. If one system detects an event, one or more other systems are used to conﬁrm the event. For example, if the accelerometer detects a spike in G-forces, the GPS is used to determine if the car is still moving. If the car is still moving, the system declares the event as a false-positive and nothing happens. However, if the GPS states that the car is stationary and the microphone detected a loud noise, an event is generated. The driver then gets a chance to respond to the message and conﬁrm if it was a false-positive or not regardless. If the server does not receive a response from the driver for whatever reason, the server declares the event as an emergency.

1.4.1 Accelerometer

The accelerometer will generate an event if it detects G-forces over a speciﬁc threshold. During a head-on collision at 100 km/h which takes 0.2 seconds to reach a com- plete stop, a driver experiences roughly 14g as can be seen in equation 1.1. It is possible to calculate acceleration by dividing the starting velocity in m/s with the time it takes to reach full stop [19].

100 m/s / 0, 2s = 139m/s2 = 14, 1g (1.1) 3, 6 However, the accelerometer in the phone is limited by the operating system and cannot measure G-forces over 8g at most depending on the phone. On the other hand, 8g is not a low amount of G-forces and is more than sufficient enough to determine if a crash has occurredd or not. The accelerometer is also able to detect acceleration caused by gravity, which makes it possible to determine the orientation of the phone relative to earth’s gravity [2]. The phone is fixated in place inside the car, which means that ideally, the phone will never move relative to the car. For this reason, if the accelerometer detects a negative acceleration along the y- axis, it should mean that the phone is currently pointing down towards the centre of the earth, meaning that the car is on its roof. Similarly, if the accelerometer detects a significant acceleration along the x-axis, it assumes that the car is on its side. The GPS can then be used to check if the car is stationary to confirm or deny the event.

1.4.2 Gyroscope

The gyroscope detects rotations around the three axis [6] to determine if the car is rotating faster than is acceptable. The gyroscope compares the rotation detected with a maximum threshold to determine if an event should be generated or not. Naturally, a car driving on a ﬂat, circular track will rotate 360 degrees in total around the y-axis 6 Chapter 1. Introduction during the entire lap. Because of this, the gyroscope is set to only detect rotations over short durations, e.g. a few seconds, to determine if the car has lost control or not.

1.4.3 GPS

The GPS regularly checks the current position of the car to calculate the cars estimated velocity and to determine if the car is moving or not [20]. The primary purpose of the GPS is to conﬁrm or deny an event generated by the other systems. The GPS will also generate an event if the car has been stationary for a certain amount of time and no other system has triggered an event.

1.4.4 Microphone

The microphone regularly listens to sound levels inside the car. If the microphone detects a loud noise, it assumes that the airbag has been deployed and generates an event.

1.4.5 Algorithm

The algorithm determines, based on events generated by the systems mentioned above if an emergency should be triggered or not. As was stated earlier, one sin- gle event generated from either of the systems is not enough to trigger an emergency. An event has to be confirmed by another system before an emergency is triggered. The algorithm requires that a certain amount of systems trigger an incident event before it sends an emergency event to the server. An incident event remains relevant for a certain amount of time before it becomes marked for removal. While an event is relevant and another event is detected, there will be two active events that count towards the threshold. A flowchart representing the algorithm can be seen in figure 3.2.

1.5 Social, environmental and ethical considerations

There are no direct social or environmental consideration we need to take for this system. One could say that the system promotes the development of cars and as such encourages producing carbon dioxides. However, that is a very naïve way to look at it. Car companies will build cars anyway, and the ultimate goal of the system presented in this thesis work is to save lives at the end of the day. By immediately report- ing emergencies that occur on a test track so that the managers can take appropriate actions, this system will hopefully save lives in the end. Car companies at proving grounds have high expectations on security, especially in regards to the position of the cars on the track. The car companies do not want anyone to be able to intercept data and as such track where speciﬁc prototypes are on the test-track. Because of this, communication between the smartphone and the server needs to be heavily encrypted. 7

Chapter 2

Implementation

2.1 Application

The Nelson application is built using Android Studio 2.3. The application can be seen in figure 2.1. The application allows the driver to message the managers directly by pressing the emergency button. However, if an incident has occurred and the driver is incapacitated, the driver can obviously not press the emergency button. This is where IncidentLib comes into the picture. When an emergency is detected, a new screen in figure 2.2 appears which indicates that in a few seconds, an emergency will be sent to the server if the driver does not deny the emergency. If the driver taps and holds the button in the image on the left in figure 2.2, the emergency event is cancelled and the image on the right in figure 2.2 appears.

2.2 IncidentLib

IncidentLib is the library that contains functionality for detecting and sending emergency events to the server. When the application starts, it accesses the accelerometer and gyroscope of the phone and registers two separate listeners who listen to data from the sensors. Data that is recorded by the listener is saved over a certain amount of time before it is considered old and irrelevant. At regular intervals, the listener sends the currently saved data to a new thread which analyses the data to detect

FIGURE 2.1: Image of the Nelson app. 8 Chapter 2. Implementation

FIGURE 2.2: Image of the Nelson app when an emergency has been triggered but then cancelled. events. If the thread detects an event, the thread sends the event to a handler which saves the event for a certain amount of time. If another event comes in from one of the other systems within that time, the handler generates an emergency event and sends it to the server.

2.2.1 Accelerometer

The accelerometer implements itself as a listener which listens to the sensor in the phone. The listener receives SensorEvents from the sensor at a constant rate based on a pre-set frequency. The higher the frequency, the more reliable the data becomes. The listener receives data from the accelerometer as acceleration along each axis. The acceleration along each axis can be represented as a vector and calculating the length of the vector returns the magnitude of the acceleration. By dividing the length of the vector with 9,81 m/s2 , the G-forces experienced is received. The acceleration is analysed to determine the G-forces experienced. If the G-forces experienced exceeds a certain threshold, the accelerometer generates an event.

2.2.2 Gravity

In some more recent Android phones, there is a sensor for detecting the acceleration caused by gravity alone, effectively ﬁltering out linear acceleration. For this reason, the data from the gravity sensor is more accurate for determining the orientation of the car. If a gravity-sensor is available in the phone, IncidentLib will make use of that sensor instead for calculating the orientation of the car. However, if a gravity sensor is not available, IncidentLib will direct the accelerometer to calculate the current orientation of the car instead.

2.2.3 Gyroscope

Similarly to the accelerometer, the gyroscope also implements itself as a listener which listens to the gyroscope sensor in the phone with a pre-set frequency. Data from the listener is received as rotational speed in rad/s along each axis. The rotational speed 2.3. Server 9

FIGURE 2.3: Figure showing the map which the managers of the track sees. is then analysed using a time-step to determine how much the phone has rotated over time.

2.2.4 Logging tool

For testing the application, it was necessary to create a tool for logging data, parse it and compile it to see what occurred. The logging tool pulls data from IncidentLib every ten seconds. If, however, any form of incident occurs, the logger will receive that event instantly and add it to the log ﬁle. Once the logger has logged all the data, it is then moved from the phone over to a PC and parsed using a simple script written in Python [21]. The parsed data will then show many incidents of each type that occurred, maximum velocity, maximum acceleration and the maximum amount of G-forces that was experienced during the test.

2.3 Server

The server is implemented using the Google Go language. The server receives emergency events from the phone and handles them. If the server does not receive a deny response from the phone within a certain amount of time, it will declare the event as an emergency and pass the event on to emergency services. If the phone is destroyed shortly after dispatching the first message to the server and thus cannot send a confirm or deny message, the server will wait before it assumes that the phone has been destroyed and flags the event as an emergency. When the server receives an emergency from a phone, the emergency appears on a map, viewable in figure 2.3, for the managers of the track. When the map receives an emergency, the car starts flashing red on the map, indicating that something bad has occurred. Furthermore, if an event such as a critical rotation-event or a stationary event is received, the car starts flashing yellow instead. 10

Chapter 3

Result

3.1 Application

If any of the systems detects an event, they send a message to a handler which stores the event for a set amount of time before it becomes marked as outdated, viewable in figure 3.2. If the handler receives more events up to a threshold within a specific time-frame, the handler generates an emergency event. If the handler generates an emergency event, it dispatches a message to the server and a button, cancel message, appears on the UI along with a countdown, see figure 2.2. When the countdown finishes, the handler dispatches a confirm message to the server which tells the server to flag the event as an emergency. If the driver clicks to cancel, the handler dispatches a deny message to the server which flags the emergency event as a false-positive.

3.1.1 Accelerometer

The accelerometer system receives data by listening to the accelerometer in the phone and then analyses it to detect either high G-forces or bad car-orientation. The accelerometer always contains data for acceleration caused by gravity, which makes it possible to determine the phone’s orientation relative to earth’s gravity. If the accelerometer returns a negative acceleration along the y-axis, the phone is pointing down towards the centre of the earth. Because the phone is ﬁxated in place in the car, if the accelerometer returns a negative acceleration along the y-axis, it can be assumed that the car is on its roof. Similarly, if the system detects a major acceleration along the x-axis, it can be assumed that the car is on its side. In either case, an event will be generated indicating that the car is not currently on its wheels. An illustration of how the accelerometer works can be seen in ﬁgure 3.1.

3.1.2 Gravity

As was mentioned above, if a gravity sensor is present in the phone it will manage the orientation of the car instead of the accelerometer. The system works the same as the accelerometer. However, the data from the gravity sensor is more accurate for determining the orientation of the phone relative to earth’s gravity. 3.1. Application 11

FIGURE 3.1: A figure of a flowchart for accelerometer and gyroscope. The flowchart on the left represents the accelerometer. The flowchart on the right represents the gyroscope.

3.1.3 Gyroscope

The gyroscope system receives data by listening to the gyroscope in the phone and then analyses it to determine how much the phone has rotated over a certain amount of time. A flowchart representing how the gyroscope system handles and analyses data from the gyroscope can be seen in the right flowchart in figure 3.1. A timestep defined as the time between each set of data received is used to determine how far the phone has rotated over the timestep. By multiplying the timestep with the rotational speed, the rotation in radians over the timestep is received. The total rotation is then used to determine if the phone has rotated over a certain threshold. If the phone has rotated over the threshold under a pre-set time limit, the gyroscope system generates an event. An illustration of how the gyroscope works can be seen in figure 3.1. It is important to note that a critical rotation event is an event that can only be triggered by itself. If the car is rotating rapidly as if it has lost control, the accelerometer will not be able to detect any spike in G-forces, the GPS will state that the car is still moving and the microphone will not detect a loud noise from the air-bag. As such, a critical rotation-event will be reported to the server regardless if any other system has detected on event. The server will interpret this as a warning to warn the managers that the car may have lost control. 12 Chapter 3. Result

FIGURE 3.2: A figure of a flowchart for IncidentLib. The flowchart on the left represents the four incident handlers. The flowchart on the right represents the emergency handler.

3.1.4 Test-application

For the purpose of testing IncidentLib without implementing it into the NPGM Mo- bile Unit application [1], a test-app was built to directly see how each of the systems work and can be seen in ﬁrgure 3.3. This test-app includes some text views to clearly present data from the sensors and if an incident has triggered or not.

3.2 Algorithm

The algorithm is designed to analyse data from each of the systems in IncidentLib to determine what has occurred. IncidentLib can detect a total of ﬁve different types of incidents. These types of incidents are used to determine if an emergency event should trigger and sent to the server or not.

• Bad orientation. Bad orientation means that the car is no longer on its wheels and could be on either of its sides or its roof.

• Critical rotation. Critical rotation means that the car has rotated extremely quickly, suggesting that the car has spun out of control.

• G-force spike. A G-force spike is detected when the phone has detected a large amount of acceleration, suggesting that the car has collided with something. 3.2. Algorithm 13

FIGURE 3.3: Figure showing the test-app running IncidentLib.

• Loud noise. A loud noise can be detected if for example the airbag deploys or the car hits something which causes a loud noise. If the airbag deploys, the driver will most likely stop driving after that.

• Stationary. Stationary means that the car is simply not moving as of right now. This event is mostly used to conﬁrm if a spike in G-forces or a loud noise was the cause of a collision. If the car has collided with something, it probably is not going to keep driving after that.

Based on what has happened, the algorithm may determine that a message has to be sent to the server to notify the managers what has happened. The algorithm can send three different types of events to the server.

• Critical rotation. A critical rotation event is sent to the server when the gyroscope in the phone detects a critical rotation. A critical rotation event is sent to the server regardless if another system has triggered or not. If the car starts spinning out of control, it will likely not cause the airbag to deploy, or the accelerometer to detect a spike in G-force and the GPS will report that the car is still moving in a direction. Therefore, a critical rotation-event will be reported to the server immediately. This event, however, is only considered a warning and not an actual emergency.

• Stationary. The system sends a stationary event when the car is stationary, but no other system has triggered. Similarly to a critical rotation-event, the server considers a stationary event as a warning.

• Emergency. The system sends an emergency event when multiple systems trigger within a short amount of time. An emergency event needs to be conﬁrmed 14 Chapter 3. Result

by the driver before the server considers it as an emergency. When an emergency event is triggered, a new screen appears on the phone with a countdown. When the countdown reaches zero, the server will consider the event as a con- ﬁrmed emergency and contact emergency services. If the driver presses a button to send a deny response to the server, the server discards the event and does not contact emergency services.

A ﬂowchart representing the algorithm can be seen in ﬁgure 3.2.

3.2.1 Parameters

We implemented the algorithm along with a set of parameters that can be tweaked to specify the behaviour of the algorithm and how sensitive it is.

• General

– EVENT_TIME_RELEVANCY. Determines how long it should take before the server conﬁrms an emergency event. – EVENT_THRESHOLD. Determines how many systems need to trigger before the handler generates an emergency event and sends it to the server.

• Accelerometer

– ACC_FREQUENCY. Determines the update frequency the accelerometer- listener registers itself with to the sensor. A higher frequency means more updates per second which in turn means more accurate data. However, a high frequency combined with a high age gate and a high analyse delay will signiﬁcantly impact performance. – ACC_AGE_GATE. Determines how long data from the accelerometer remains relevant before it becomes marked for removal. A lower value will increase performance but reduces accuracy. – ACC_ANALYSE_DELAY. Determines how long before data from the accelerometer is sent to be analysed in a separate thread. Lowering this value will increase the responsiveness of the application but will heavily impact performance. – ACC_G_FORCE_LIMIT. Determines how many G-forces the phone may experience before it is considered to be too high. Lowering this value will make the system more sensitive. Note however that this value cannot ex- ceed the maximum amount of acceleration that the phone can measure.

• Gravity

– GRAVITY_FREQUENCY. Determines the frequency the gravity-listener receives data at. The gravity system only cares about the last set of data that was received from the sensor, meaning that this value can be relatively high without causing a signiﬁcant impact on performance. 3.3. Testing 15

• Gyroscope

– GYRO_FREQUENCY. Determines the frequency the gyroscope-listener receives data at. A higher frequency means more updates per second which in turn means more accurate data. However, a high frequency combined with a high age gate and a high analyse delay will greatly impact performance. – GYRO_AGE_GATE. Determines how long data from the gyroscope remains relevant before it becomes marked for removal. A lower value will increase performance but reduces accuracy. – GYRO_ANALYSE_DELAY. Determines how long before data from the gyroscope is sent to be analysed in a separate thread. Lowering this value will increase the responsiveness of the application but will heavily impact performance. – GYRO_TIME_GATE. Determines the duration which the car may not rotate before it has rotated too much over too short time. – GYRO_RAD_ROTATION_THRESHOLD. Determines how much the car may rotate before the system considers it to be too much.

3.3 Testing

For the purpose of testing IncidentLib, the application we needed to expand it by creating a system to log data to a ﬁle and then read that data to see if IncidentLiv generated any events during the test. When we had completed the logging system had, we tested the application by driving around Skellefteå for about 30 minutes to see if any events triggered that should not have. The result from the test can be seen below in table 3.1.

Number of reports 180 Number of Orientation incidents: 1 Number of Acceleration incidents: 0 Number of Gyroscope incidents: 1 Number of Audio incidents: 0 Number of GPS incidents: 0 Number of Emergencies: 0

Max Velocity: 102,9 km/h Max Audio: 76,2 dB Max Acceleration (calculated): 14,8 m/s2 Max G-force (calculated): 1,3 g Max G-force (from accelerometer): 1,4 g

TABLE 3.1: Table showing the results from the test-run. Values marked with calculated are values that have been calculated based on data from the GPS. 16 Chapter 3. Result

As can be seen in table 3.1, during the test one orientation event and one gyroscope- event was generated. The results suggest that the orientation- and gyroscope system may need some tweaking before they can be considered ﬁnalised. During the test, we performed some high-speed driving as well as some hard acceleration and hard braking. The car used in testing was a Volkswagen Golf Alltrack. 17

Chapter 4

Discussion

4.1 Discussing the result

The tests performed have shown that IncidentLib is working as intended. Tweaking the parameters makes IncidentLib not detect incidents during a normal drive. The gyroscope-incident which triggered during the test occurred while perform- ing a full lap of a roundabout. The parameters for the gyroscope at the time was 90 degrees limit over 3 seconds. E.g., during 3 seconds, the phone rotated more than 90 degrees along the y-axis which caused an event to trigger. From this result, it was apparent that the time-limit needs to be lower than 3 seconds and probably more like 2 seconds. An orientation-incident also triggered during the test, which is believed to have been the cause of human error by holding the phone more horizontal than it is supposed to be. Looking at the timestamp from the log indicates that it was early in the test where the phone was in a more horizontal orientation than a vertical orientation.

4.2 Limitations

There are some limitations to IncidentLib which are important to note. IncidentLib still works regardless of these limitations, but they can cause issues and some inaccu- racies when the program is running.

4.2.1 Hardware limitations

IncidentLib can be heavily limited based on the hardware present in the phone it is running on. To make use of systems such as the gyroscope, a relatively recent phone is required. Some components of IncidentLib will still work even if some pieces of hardware is not present. For example, if the gravity sensor is not available, the accelerometer will perform the gravity sensors task. The data from the accelerometer will not be as accurate as the data from the gravity sensor, but it will be sufﬁcient to determine if the car is on its wheels or not. 18 Chapter 4. Discussion

4.2.2 Mounting malfunction

As was stated earlier, if the phone were to drop from its mounting in the car, In- cidentLib will most likely generate a false-positive. For this reason, an emergency event needs to be conﬁrmed before it is considered an actual emergency. However, a driver who is only interested in driving fast along a track might not care about the phone dropping from its mounting and would as such not deny an emergency event that could be considered to be a false-positive.

4.3 Future work

4.3.1 Proﬁles

One way to expand IncidentLib could be to use some form of machine learning to tweak parameters based on the track currently being driven on. The server could then save the parameters as a proﬁle for each track. When a driver starts driving on a new track, the proﬁle for that track could be loaded automatically from the server.

4.3.2 Hotspots

Because IncidentLib is meant to run on predetermined tracks that are very predictable, it is possible to use the data from IncidentLib to create hotspots on each track which could be used to test certain conditions more accurately and scientifically. For example, if a specific corner is prone to generating a great deal of G-forces during the turn, IncidentLib could detect this form of a hotspot. These hotspots could then be used to scientifically test the grip of the car to see which G-forces the car experiences during the turn without the car losing grip of the road. 19

Chapter 5

Conclusion

5.1 Project

In conclusion, this project has been a success. IncidentLib works as it was intended and allows for easy tweaking to make sure that the algorithm detects actual incidents and not false-positives. The project was originally meant only to include the accelerometer and not the gyroscope. The gyroscope was added halfway through the project because there was going to be a lot of extra time otherwise. For that reason, IncidentLib was expanded to include the gyroscope as well to make it more capable and able to detect other forms of incidents that the accelerometer cannot.

5.2 Research phase

The research phase involved a great deal of learning how making applications for Android work and how the systems involved works. As someone who has not made applications for Android before, this was relatively simple and did not take a lot of time to get a basic understanding of how it works. The documentation for Android was well written and made it easy to understand how to gain access to the systems in the phone that was necessary to make IncidentLib work.

5.2.1 Accelerometer

The initial idea was only to analyse the G-forces from the accelerometer to determine if an incident has occurred. Analysing G-forces is very trivial to do; however, the research phase showed that the accelerometer returns acceleration as a vector along the phones axis in local space. Meaning that if the phone rotates but does not move the values from the accelerometer looks very different but the acceleration in world space will be unchanged. The acceleration from the accelerometer always includes acceleration caused by earth’s gravity. Because of the ways mentioned above that the accelerometer operates, it becomes possible to determine the orientation of the phone relative to earth’s gravity. Since the phone will be ﬁxated in place inside the car when IncidentLib is running, one can assume that if the accelerometer returns an acceleration which would indicate that the phone is pointing down towards the 20 Chapter 5. Conclusion centre of the earth, the car is on its roof. This system essentially makes it possible to detect if the car has vaulted or is currently on either of its sides or its roof.

5.2.2 Gyroscope

As was stated previously, the gyroscope was added halfway through the project, but some research still needed to be done. Similarly to the accelerometer, the gyroscope returns data relative to the phones local axis. However, instead of returning acceleration, the gyroscope returns rotational speed in rad/s around each axis. By analysing the rotational speed, it is possible to determine how much the phone has rotated over a certain amount of time. This system makes it possible to detect if the car has lost control and has started spinning.

5.3 Implementation phase

Before we implemented IncidentLib into the NPGM Mobile Unit [1], IncidentLib was built into a test-app to make it easy to test everything. This test-app was very simplis- tic and allowed us to very easily learn how each of the systems worked and what kind of data we were dealing with, without worrying about the various systems in NPGM. Creating a test-app also allowed us to have full control over the different versions of the application without interference from the ongoing project. Creating a test-app also taught us a lot about how it works to make applications for Android which was of great beneﬁt later on. Once IncidentLib was considered working, we implemented a logging tool to test the application properly. Once the logging tool was completed, we implemented In- cidentLib into the NPGM Mobile Unit application, as IncidentLib was working as intended.

5.4 Testing phase

The testing phase was very simple and also very brief. The phase simply involved using the test-app that we had created earlier and drove around for 30 minutes around Skellefteå. During the test, we had the application log data from IncidentLib to a ﬁle that we could then parse and extract data from. This test gave us a great deal of insight on how the parameters for IncidentLib should work, particularly the parameters for the gyroscope. We could determine that the parameters for the gyroscope were too generous and needed to be a bit more restrictive. 21

Bibliography

[1] Rajd Systech. Nelson PGM. 2017. URL: http : / / www . rajdsystech . se / nelson-pgm/ (visited on 04/10/2017).

[2] Dimension Engineering LLC. A beginner’s guide to accelerometers. 2017. URL: https: //www.dimensionengineering.com/info/accelerometers (visited on 04/10/2017). [3] Edwin F. Taylor & John Archibald Wheeler. “Spacetime Physics”. In: 1st ed. Vol. 1. 1. San Francisco: W.H. Freeman, July 1966. Chap. 1, pp. 97–98. ISBN: 071670336X. [4] Paresh Gujarati. What is Accelerometer and how does it work on smartphones. 2016. URL: http :/ /www . techulator. com/ resources /8930 - How - does- smart-phone-accelerometer-work.aspx (visited on 04/11/2017). [5] James B. Angell & Stephen C. Terry & Phillip W. Barth. “Silicon Micromechan- ical Devices”. In: Scientiﬁc American 4.4 (Apr. 1983), pp. 44–55. URL: https:// pdfs.semanticscholar.org/ca1d/2e4e638dc70da85615757a5c5c50bd61eed3. pdf.

[6] Cef (Terry) Pearson. Gyroscopes - Everything you needed to know. 2017. URL: http: //www.gyroscopes.org/how.asp (visited on 04/24/2017).

[7] PhoneArena. Google’s Android OS: Past, Present, and Future. 2011. URL: http:// www.phonearena.com/news/Googles-Android-OS-Past-Present- and-Future_id21273 (visited on 04/11/2017).

[8] SAMSUNG. Samsung Galaxy S7 and S7 edge. 2017. URL: http://www.samsung. com/se/smartphones/galaxy-s7/overview/ (visited on 05/21/2017). [9] Xavier Ducrohet & Tor Norbye & Katherine Chou. Android Studio: An IDE built for Android. 2013. URL: https : / / android - developers . googleblog . com / 2013 / 05 / android - studio - ide - built - for - android . html (visited on 04/25/2017).

[10] JetBrains. JetBrains: Development Tools for Professionals and Teams. 2017. URL: https: //www.jetbrains.com/ (visited on 04/25/2017).

[11] The Go Programming Language. 2017. URL: https://golang.org/ (visited on 05/21/2017).

[12] Go Community. golang/go Wiki. 2017. URL: https://github.com/golang/ go/wiki (visited on 05/21/2017). 22 BIBLIOGRAPHY

[13] Rajd Systech. Proving Ground Management System. 2017. URL: http://www. rajdsystech.se (visited on 04/10/2017).

[14] Data Ductus. Data Ductus | Ahead of the curve since 1989. 2017. URL: http : //www.dataductus.se (visited on 04/10/2017). [15] Jorge Zaldivar & Carlos T. Calafate & Juan Carlos Cano & Pietro Manzoni. “Providing Accident Detection in Vehicular Networks Through OBD-II Devices and Android-based Smartphones”. In: Workshop On User MObility and VEhicu- lar Networks 5 (2011), pp. 817–823. URL: https://pdfs.semanticscholar. org/ca1d/2e4e638dc70da85615757a5c5c50bd61eed3.pdf.

[16] B&B Electronics. ODB-II Background information. 2011. URL: http : / / www . obdii.com/background.html (visited on 04/11/2017). [17] Zainab S. Alwan Hamid M. Ali. “Car Accident Detection and Notification Sys- tem Using Smartphone”. In: International Journal of Computer Science and Mobile Computing 4.4 (Apr. 2015), pp. 620–635. URL: http://ijcsmc.com/docs/ papers/April2015/V4I4201599a40.pdf. [18] J. & Dougherty B. & Albright A. & Schmidt DC Chris T. & White. “WreckWatch: Automatic Traffic Accident Detection and Notification with Smartphones”. In: Journal of Mobile Networks and Applications manuscript (2011). URL: https:// www.dre.vanderbilt.edu/~schmidt/PDF/wreckwatchj.pdf.

[19] Steven Holzner. How to calculate acceleration. 2017. URL: http://www.dummies. com/education/science/physics/how-to-calculate-acceleration (visited on 05/05/2017).

[20] U.S. Air Force. GPS: The Global Positioning System. 2017. URL: http://www. gps.gov (visited on 05/04/2017).

[21] Python Software Foundation. Welcome to Python.org. 2017. URL: https://www. python.org (visited on 05/17/2017).