utilising accelerometer and gyroscope in smartphone …1139911/fulltext01.pdf · ii abstract...

29
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

Upload: duongkhue

Post on 10-Aug-2018

224 views

Category:

Documents


0 download

TRANSCRIPT

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Å UNIVERSITY OF TECHNOLOGY

BACHELOR THESIS

Utilising accelerometer and gyroscope insmartphone to detect incidents on a test

track for cars

Author:Carl-Johan HOLST

[email protected]

Examiner:Patrik HOLMLUND

[email protected]

Supervisor:Jörgen STENBERG-ÖFJÄLL

[email protected]

Computer and space technologyCampus Skellefteå

June 4, 2017

ii

AbstractUtilising accelerometer and gyroscope in smartphone to detect incidents on a test

track for cars

Every smartphone today includes an accelerometer. An accelerometer works by de-tecting acceleration affecting the device, meaning it can be used to identify incidentssuch as collisions at a relatively high speed where large spikes of acceleration oftenoccur.

A gyroscope on the other hand is not as common as the accelerometer but it doesexists in most newer phones. Gyroscopes can detect rotations around an arbitraryaxis and as such can be used to detect critical rotations.

This thesis work will present an algorithm for utilising the accelerometer and gy-roscope in a smartphone to detect incidents occurring on a test track for cars.

SammanfattningUtilising accelerometer and gyroscope in smartphone to detect incidents on a test

track for cars

Alla smarta telefoner innehåller idag en accelerometer. En accelerometer analyseraracceleration som påverkar enheten, vilket innebär att den kan användas för att de-tektera incidenter så som kollisioner vid relativt höga hastigheter där stora spikar avacceleration vanligtvis påträffas.

Ett gyroskop däremot är inte lika vanlig som en accelerometer men finns i de flestanyare telefoner. Ett gyroskop kan detektera rotationer runt en godtycklig axel och kanpå 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

AcknowledgementsI would like to thank the team at Data Ductus for giving me a chance to do this thesiswork, 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 whichdetect events based on data from the GPS and the microphone. Once we merged ourtwo projects together into the final system we had a program which was not onlycapable, but also versatile and flexible.

v

Contents

Abstract ii

Sammanfattning iii

Acknowledgements iv

1 Introduction 11.1 Goals and purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Accelerometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 Android phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.4 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.5 Google Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.6 Proving grounds . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.7 Nelson Proving Grounds Management . . . . . . . . . . . . . . 31.2.8 NPGM Mobile Unit . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.9 Rajd Systech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.10 Data Ductus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.1 Zaldiwar et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Ali and Alwan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.3 WreckWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.1 Accelerometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.2 Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.3 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.4 Microphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.5 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Social, environmental and ethical considerations . . . . . . . . . . . . . 6

2 Implementation 72.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 IncidentLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Accelerometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Gravity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

vi

2.2.3 Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Logging tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Result 103.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Accelerometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Gravity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.3 Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.4 Test-application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Discussion 174.1 Discussing the result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.1 Hardware limitations . . . . . . . . . . . . . . . . . . . . . . . . 174.2.2 Mounting malfunction . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3.1 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3.2 Hotspots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Conclusion 195.1 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Research phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.1 Accelerometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2.2 Gyroscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 Implementation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.4 Testing phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1

Chapter 1

Introduction

Every winter, major car companies descends upon the Swedish city of Arjeplog totest 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 builtfor the purpose of testing the performance of the cars. These proving grounds use amanagement system called Nelson Proving Grounds Management (NPGM). NPGMis a system in which cars contain a smartphone that is meant to act as both a tool forthe 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 incidentsthat could occur on a test track such as collisions.

During car collisions, high amounts of G-forces occur which can be detected usingan accelerometer, and it is also likely that the airbag deploys. Airbags are deployedusing explosives, which means they are loud. By using a microphone, it is possible todetect loud noises such as an airbag deploying or even the sound of the car impactingwith something else. A gyroscope which detects rotations can be used to detect if thecar is rotating rapidly, e.g. spinning while sill being on its wheels, suggesting that thedriver might have lost control of the car. The GPS in the phone can then be used toconfirm if the car is still moving or if it is stationary. If the car is stationary after havingexperienced extensive amounts of G-forces and a loud noise is detected, it is highlylikely that the car has crashed in which case an emergency event will generate. On theother hand, if the gyroscope detects rapid rotations while the GPS states that the caris still moving, it can be assumed that the driver has lost control and an emergencyevent will generate immediately. If the accelerometer and microphone then detectsignificant spikes in G-forces and a loud noise respectively and the GPS states thatthe car is stationary, a new emergency event will generate.

This thesis work presents an algorithm for utilising the above-listed sensors andhardware in a smartphone to detect incidents on a test track for cars. The algorithmlistens 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 hasoccurred, 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 specificallyworked on, meaning the accelerometer and the gyroscope.

2 Chapter 1. Introduction

1.1 Goals and purpose

The aim of this thesis work was first to research the possibility of using data from theaccelerometer and gyroscope inside a smartphone to detect incidents on a track suchas collisions and other accidents. If it was deemed possible to detect such incidents, Iwas then supposed to develop a system for detecting incidents on a track and reportthem 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 accelerometerto determine the G-forces affecting the accelerometer [2]. Proper acceleration meansacceleration that is relative to free-fall [3]. An object in free-fall would as such haveno acceleration affecting it while an object at rest on the surface of the earth wouldexperience an acceleration of 9,81 m/s2 upwards due to the surface pushing the objectupwards to negate gravity. Accelerometers in smartphones bases their functionalityon micro-electromechanical-systems (MEMS), which measure electric currents basedon 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]. Thegyroscope 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 thegyroscope, it is possible to calculate how many radians the phone has rotated duringthe 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 smartphonesand tablets. Android was created by Android Inc. in 2003 and was bought by Googlein 2005 who still owns it [7]. The phone used for this project was a Samsung GalaxyS7 [8].

1.2.4 Android Studio

Android Studio is an Integrated Development Environment (IDE) with the purposeof designing and building applications for devices using the Android OS. AndroidStudio is the official 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 thecompany 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 first appeared in November 2009. Go version1.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 arefor 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 secu-rity and as such requires systems which provide just that. Nelson Proving GroundsManagement (NPGM) is one such system which aims to provide high safety and highsecurity for these proving grounds [1].

1.2.7 Nelson Proving Grounds Management

Nelson Proving Grounds Management (NPGM) is a system for managing activities atproving grounds for cars [1]. Rajd Systech from Piteå is the company which developNPGM [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 emer-gency as well as managing activities at an administrative level. Cars driving on theseproving grounds contain a particular model of an Android smartphone that will befixated in place, meaning that the phone will, ideally, remain in the same place andorientation relative to the car at all times.

1.2.8 NPGM Mobile Unit

NPGM Mobile Unit [1] is a smartphone which is fixated in place inside the car in avertical position. The phone will ideally always be fixated in place, meaning that thephone will never move relative to the car. Because the phone does not move relativeto the car, any movement that the phone experiences, the car also experiences. If theaccelerometer in the phone detects a high amount of G-forces the car, as well as thedriver, experienced the same amount of G-forces.

However, if the phone were to drop from its mounting, the phone will naturallyexperience 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 beaverted. It is, therefore, a good idea to give the driver some way of declining theemergency event.

1.2.9 Rajd Systech

Rajd Systech [13] is a company based in Piteå and is the product owner of the NelsonProving 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 specific system withinNPGM.

1.2.10 Data Ductus

Data Ductus is a company which sells consulting services within IT to other compa-nies and businesses [14]. The company employs roughly 200 people in cities aroundSweden and is growing rapidly. Over the past six months, one of the teams at DataDuctus 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 detectincidents 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 asthe GPS to determine if an event has occurred with a vehicle. Some work specificallyusing 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 todevelop 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 andthe ODB-II connection in a car [16]. ODB-II is a connection which all modern cars arefitted 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 whichmade use of the accelerometer, GPS and microphone to detect accidents [17]. Theirsystem made use of the same sensors and hardware that the algorithm presented inthis 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 themicrophone to detect emergency events. If an emergency has occurred, the applica-tion contacts nearby emergency services and provides GPS-coordinates for where theaccident took place.

1.4. Method 5

1.4 Method

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

1.4.1 Accelerometer

The accelerometer will generate an event if it detects G-forces over a specific thresh-old. 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 pos-sible to calculate acceleration by dividing the starting velocity in m/s with the time ittakes to reach full stop [19].

100

3, 6m/s / 0, 2s = 139m/s2 = 14, 1g (1.1)

However, the accelerometer in the phone is limited by the operating system andcannot 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 ifa crash has occurredd or not.

The accelerometer is also able to detect acceleration caused by gravity, whichmakes 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 phonewill 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 ofthe earth, meaning that the car is on its roof. Similarly, if the accelerometer detects asignificant acceleration along the x-axis, it assumes that the car is on its side. The GPScan 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 isrotating faster than is acceptable. The gyroscope compares the rotation detected witha maximum threshold to determine if an event should be generated or not. Naturally,a car driving on a flat, 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 overshort 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 estimatedvelocity and to determine if the car is moving or not [20]. The primary purpose of theGPS is to confirm or deny an event generated by the other systems. The GPS will alsogenerate an event if the car has been stationary for a certain amount of time and noother system has triggered an event.

1.4.4 Microphone

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

1.4.5 Algorithm

The algorithm determines, based on events generated by the systems mentionedabove 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 be-fore it sends an emergency event to the server. An incident event remains relevantfor a certain amount of time before it becomes marked for removal. While an eventis relevant and another event is detected, there will be two active events that counttowards the threshold. A flowchart representing the algorithm can be seen in figure3.2.

1.5 Social, environmental and ethical considerations

There are no direct social or environmental consideration we need to take for this sys-tem. One could say that the system promotes the development of cars and as suchencourages producing carbon dioxides. However, that is a very naïve way to lookat it. Car companies will build cars anyway, and the ultimate goal of the system pre-sented 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 appropriateactions, this system will hopefully save lives in the end.

Car companies at proving grounds have high expectations on security, especiallyin regards to the position of the cars on the track. The car companies do not wantanyone to be able to intercept data and as such track where specific prototypes areon the test-track. Because of this, communication between the smartphone and theserver 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 seenin figure 2.1. The application allows the driver to message the managers directly bypressing the emergency button. However, if an incident has occurred and the driver isincapacitated, the driver can obviously not press the emergency button. This is whereIncidentLib comes into the picture. When an emergency is detected, a new screen infigure 2.2 appears which indicates that in a few seconds, an emergency will be sent tothe server if the driver does not deny the emergency. If the driver taps and holds thebutton in the image on the left in figure 2.2, the emergency event is cancelled and theimage on the right in figure 2.2 appears.

2.2 IncidentLib

IncidentLib is the library that contains functionality for detecting and sending emer-gency events to the server. When the application starts, it accesses the accelerometerand gyroscope of the phone and registers two separate listeners who listen to datafrom the sensors. Data that is recorded by the listener is saved over a certain amountof time before it is considered old and irrelevant. At regular intervals, the listenersends 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 beentriggered but then cancelled.

events. If the thread detects an event, the thread sends the event to a handler whichsaves the event for a certain amount of time. If another event comes in from one of theother systems within that time, the handler generates an emergency event and sendsit to the server.

2.2.1 Accelerometer

The accelerometer implements itself as a listener which listens to the sensor in thephone. The listener receives SensorEvents from the sensor at a constant rate basedon 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. Theacceleration along each axis can be represented as a vector and calculating the lengthof the vector returns the magnitude of the acceleration. By dividing the length of thevector with 9,81 m/s2 , the G-forces experienced is received.

The acceleration is analysed to determine the G-forces experienced. If the G-forcesexperienced 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 accelerationcaused by gravity alone, effectively filtering out linear acceleration. For this reason,the data from the gravity sensor is more accurate for determining the orientation ofthe car. If a gravity-sensor is available in the phone, IncidentLib will make use of thatsensor instead for calculating the orientation of the car. However, if a gravity sen-sor is not available, IncidentLib will direct the accelerometer to calculate the currentorientation of the car instead.

2.2.3 Gyroscope

Similarly to the accelerometer, the gyroscope also implements itself as a listener whichlistens to the gyroscope sensor in the phone with a pre-set frequency. Data from thelistener 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 tracksees.

is then analysed using a time-step to determine how much the phone has rotated overtime.

2.2.4 Logging tool

For testing the application, it was necessary to create a tool for logging data, parseit and compile it to see what occurred. The logging tool pulls data from IncidentLibevery ten seconds. If, however, any form of incident occurs, the logger will receivethat event instantly and add it to the log file. Once the logger has logged all thedata, it is then moved from the phone over to a PC and parsed using a simple scriptwritten in Python [21]. The parsed data will then show many incidents of each typethat occurred, maximum velocity, maximum acceleration and the maximum amountof G-forces that was experienced during the test.

2.3 Server

The server is implemented using the Google Go language. The server receives emer-gency events from the phone and handles them. If the server does not receive a denyresponse from the phone within a certain amount of time, it will declare the event asan emergency and pass the event on to emergency services. If the phone is destroyedshortly after dispatching the first message to the server and thus cannot send a con-firm or deny message, the server will wait before it assumes that the phone has beendestroyed and flags the event as an emergency.

When the server receives an emergency from a phone, the emergency appears ona map, viewable in figure 2.3, for the managers of the track. When the map receivesan emergency, the car starts flashing red on the map, indicating that something badhas occurred. Furthermore, if an event such as a critical rotation-event or a stationaryevent 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 storesthe event for a set amount of time before it becomes marked as outdated, viewablein figure 3.2. If the handler receives more events up to a threshold within a specifictime-frame, the handler generates an emergency event. If the handler generates anemergency 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 countdownfinishes, the handler dispatches a confirm message to the server which tells the serverto flag the event as an emergency. If the driver clicks to cancel, the handler dispatchesa 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 phoneand then analyses it to detect either high G-forces or bad car-orientation. The ac-celerometer always contains data for acceleration caused by gravity, which makes itpossible to determine the phone’s orientation relative to earth’s gravity. If the ac-celerometer returns a negative acceleration along the y-axis, the phone is pointingdown towards the centre of the earth. Because the phone is fixated in place in the car,if the accelerometer returns a negative acceleration along the y-axis, it can be assumedthat the car is on its roof. Similarly, if the system detects a major acceleration alongthe x-axis, it can be assumed that the car is on its side. In either case, an event will begenerated indicating that the car is not currently on its wheels. An illustration of howthe accelerometer works can be seen in figure 3.1.

3.1.2 Gravity

As was mentioned above, if a gravity sensor is present in the phone it will managethe orientation of the car instead of the accelerometer. The system works the sameas the accelerometer. However, the data from the gravity sensor is more accurate fordetermining 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 andthen analyses it to determine how much the phone has rotated over a certain amountof time. A flowchart representing how the gyroscope system handles and analysesdata 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 deter-mine how far the phone has rotated over the timestep. By multiplying the timestepwith the rotational speed, the rotation in radians over the timestep is received. The to-tal 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 gyroscopesystem generates an event. An illustration of how the gyroscope works can be seenin figure 3.1.

It is important to note that a critical rotation event is an event that can only be trig-gered by itself. If the car is rotating rapidly as if it has lost control, the accelerometerwill not be able to detect any spike in G-forces, the GPS will state that the car is stillmoving and the microphone will not detect a loud noise from the air-bag. As such, acritical rotation-event will be reported to the server regardless if any other system hasdetected on event. The server will interpret this as a warning to warn the managersthat the car may have lost control.

12 Chapter 3. Result

FIGURE 3.2: A figure of a flowchart for IncidentLib. The flowcharton 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 systemswork and can be seen in firgure 3.3. This test-app includes some text views to clearlypresent 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 IncidentLibto determine what has occurred. IncidentLib can detect a total of five different typesof incidents. These types of incidents are used to determine if an emergency eventshould trigger and sent to the server or not.

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

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

• G-force spike. A G-force spike is detected when the phone has detected a largeamount 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 deploysor the car hits something which causes a loud noise. If the airbag deploys, thedriver 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 confirm if a spike in G-forces or a loud noise wasthe cause of a collision. If the car has collided with something, it probably is notgoing to keep driving after that.

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

• Critical rotation. A critical rotation event is sent to the server when the gyro-scope in the phone detects a critical rotation. A critical rotation event is sentto the server regardless if another system has triggered or not. If the car startsspinning out of control, it will likely not cause the airbag to deploy, or the ac-celerometer to detect a spike in G-force and the GPS will report that the car isstill moving in a direction. Therefore, a critical rotation-event will be reportedto the server immediately. This event, however, is only considered a warningand not an actual emergency.

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

• Emergency. The system sends an emergency event when multiple systems trig-ger within a short amount of time. An emergency event needs to be confirmed

14 Chapter 3. Result

by the driver before the server considers it as an emergency. When an emer-gency 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-firmed emergency and contact emergency services. If the driver presses a buttonto send a deny response to the server, the server discards the event and does notcontact emergency services.

A flowchart representing the algorithm can be seen in figure 3.2.

3.2.1 Parameters

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

• General

– EVENT_TIME_RELEVANCY. Determines how long it should take beforethe server confirms an emergency event.

– EVENT_THRESHOLD. Determines how many systems need to triggerbefore 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 moreupdates per second which in turn means more accurate data. However, ahigh frequency combined with a high age gate and a high analyse delaywill significantly impact performance.

– ACC_AGE_GATE. Determines how long data from the accelerometer re-mains relevant before it becomes marked for removal. A lower value willincrease performance but reduces accuracy.

– ACC_ANALYSE_DELAY. Determines how long before data from the ac-celerometer is sent to be analysed in a separate thread. Lowering this valuewill increase the responsiveness of the application but will heavily impactperformance.

– ACC_G_FORCE_LIMIT. Determines how many G-forces the phone mayexperience before it is considered to be too high. Lowering this value willmake 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-listenerreceives data at. The gravity system only cares about the last set of datathat was received from the sensor, meaning that this value can be relativelyhigh without causing a significant impact on performance.

3.3. Testing 15

• Gyroscope

– GYRO_FREQUENCY. Determines the frequency the gyroscope-listenerreceives data at. A higher frequency means more updates per second whichin turn means more accurate data. However, a high frequency combinedwith a high age gate and a high analyse delay will greatly impact perfor-mance.

– GYRO_AGE_GATE. Determines how long data from the gyroscope re-mains relevant before it becomes marked for removal. A lower value willincrease performance but reduces accuracy.

– GYRO_ANALYSE_DELAY. Determines how long before data from thegyroscope is sent to be analysed in a separate thread. Lowering this valuewill increase the responsiveness of the application but will heavily impactperformance.

– GYRO_TIME_GATE. Determines the duration which the car may not ro-tate before it has rotated too much over too short time.

– GYRO_RAD_ROTATION_THRESHOLD. Determines how much the carmay 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 bycreating a system to log data to a file and then read that data to see if IncidentLivgenerated any events during the test. When we had completed the logging systemhad, we tested the application by driving around Skellefteå for about 30 minutes tosee if any events triggered that should not have. The result from the test can be seenbelow in table 3.1.

Number of reports 180Number of Orientation incidents: 1Number of Acceleration incidents: 0Number of Gyroscope incidents: 1Number of Audio incidents: 0Number of GPS incidents: 0Number 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 markedwith 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 systemmay need some tweaking before they can be considered finalised. During the test,we performed some high-speed driving as well as some hard acceleration and hardbraking. 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. Tweakingthe 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 90degrees limit over 3 seconds. E.g., during 3 seconds, the phone rotated more than 90degrees along the y-axis which caused an event to trigger. From this result, it wasapparent that the time-limit needs to be lower than 3 seconds and probably more like2 seconds.

An orientation-incident also triggered during the test, which is believed to havebeen the cause of human error by holding the phone more horizontal than it is sup-posed to be. Looking at the timestamp from the log indicates that it was early in thetest 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. IncidentLibstill 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 itis running on. To make use of systems such as the gyroscope, a relatively recentphone is required. Some components of IncidentLib will still work even if some piecesof hardware is not present. For example, if the gravity sensor is not available, theaccelerometer will perform the gravity sensors task. The data from the accelerometerwill not be as accurate as the data from the gravity sensor, but it will be sufficient todetermine 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 emergencyevent needs to be confirmed before it is considered an actual emergency. However,a driver who is only interested in driving fast along a track might not care about thephone dropping from its mounting and would as such not deny an emergency eventthat could be considered to be a false-positive.

4.3 Future work

4.3.1 Profiles

One way to expand IncidentLib could be to use some form of machine learning totweak parameters based on the track currently being driven on. The server couldthen save the parameters as a profile for each track. When a driver starts driving on anew track, the profile 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 whichcould be used to test certain conditions more accurately and scientifically. For exam-ple, 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 toscientifically test the grip of the car to see which G-forces the car experiences duringthe 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 intendedand allows for easy tweaking to make sure that the algorithm detects actual inci-dents and not false-positives. The project was originally meant only to include theaccelerometer and not the gyroscope. The gyroscope was added halfway through theproject 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 capableand 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 forAndroid work and how the systems involved works. As someone who has not madeapplications for Android before, this was relatively simple and did not take a lot oftime to get a basic understanding of how it works. The documentation for Androidwas well written and made it easy to understand how to gain access to the systems inthe 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 determineif an incident has occurred. Analysing G-forces is very trivial to do; however, theresearch phase showed that the accelerometer returns acceleration as a vector alongthe phones axis in local space. Meaning that if the phone rotates but does not movethe values from the accelerometer looks very different but the acceleration in worldspace will be unchanged. The acceleration from the accelerometer always includesacceleration caused by earth’s gravity. Because of the ways mentioned above thatthe accelerometer operates, it becomes possible to determine the orientation of thephone relative to earth’s gravity. Since the phone will be fixated in place inside thecar when IncidentLib is running, one can assume that if the accelerometer returnsan 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 todetect 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, butsome research still needed to be done. Similarly to the accelerometer, the gyroscopereturns data relative to the phones local axis. However, instead of returning accelera-tion, the gyroscope returns rotational speed in rad/s around each axis. By analysingthe rotational speed, it is possible to determine how much the phone has rotated overa certain amount of time. This system makes it possible to detect if the car has lostcontrol and has started spinning.

5.3 Implementation phase

Before we implemented IncidentLib into the NPGM Mobile Unit [1], IncidentLib wasbuilt 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 kindof 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 ofthe application without interference from the ongoing project. Creating a test-appalso taught us a lot about how it works to make applications for Android which wasof great benefit later on.

Once IncidentLib was considered working, we implemented a logging tool to testthe application properly. Once the logging tool was completed, we implemented In-cidentLib into the NPGM Mobile Unit application, as IncidentLib was working asintended.

5.4 Testing phase

The testing phase was very simple and also very brief. The phase simply involved us-ing the test-app that we had created earlier and drove around for 30 minutes aroundSkellefteå. During the test, we had the application log data from IncidentLib to afile that we could then parse and extract data from. This test gave us a great deal ofinsight on how the parameters for IncidentLib should work, particularly the param-eters for the gyroscope. We could determine that the parameters for the gyroscopewere 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 (visitedon 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: Scientific 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 builtfor 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 on05/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 Devicesand 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 MobileComputing 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).