A proof-of-concept of the audio tour guide application, SoundTracker, aimed at friends and family

(1)

Faculty of Technology and Society

Bachelor thesis 15 credits, ground level

A proof-of-concept of the audio tour guide application,

SoundTracker, aimed at friends and family.

Konceptvalidering av en ljudvandrings applikation, SoundTracker med målgruppen familjmedlemmar och vänner

Ansam Bassam Abdulhamid

Namra Jamshaid Gill

Exam: Bachelor of Science in Engineering 180 credits

Area: Computer Engineering Date of final seminar: 30-05-2018

Examiner: Arezoo Sarkheyli-Hägele Supervisor: Lars Holmberg, and Agnes Tegen

(2)

(3)

Abstract

Context-awareness can be used in tour guide applications in order to provide users with information and services. The majority of tour guide applications are usually developed for educational or historical review purposes. This paper presents a proof-of-concept of the unpublished audio tour guide application, “SoundTracker”, with the aim of improving it. The new “SoundTracker” prototype does not aim for educational or historical review purposes, instead it is aimed for recording, listening and sharing personal audio tour guides with friends and family. The proof-of-concept is limited by the defined research questions found in this paper. In summary, the accuracy of the read-in GPS coordinates of a user’s position is enhanced with Kalman filter, to give an enjoyable user experience. Addition-ally, the graphical user interface of the original prototype is improved and tested through web-surveys. As for the sharing functionality, a test application is created in order to find what necessary aspects need to be considered in the new "SoundTracker" prototype when a user wants to share a sound-walk with friends and family. The test application is tested based on responses obtained through a semi-structured interview from people in the age of 20-30 years.

The obtained results indicate that, with use of Kalman filter, the location accuracy of the user is enhanced, which results in a sound-walk with less deviations compared to lo-cation accuracy of only GPS-sensor. Regarding the improved graphical user interface, users found the new "SoundTracker" prototype easier to understand, as well as to navigate through it, than the case in the original prototype. Users also find it interesting when a sharing function is implemented with the design that is discussed in this work.

Keywords: Context-awareness, proof-of-concept, audio tour guide, location-based, friends and family, Android smart phone, Kalman filter, GUI, recording and playback, sound-walk, sharing.

(4)

(5)

Sammanfattning

Kontextmedvetenhet kan användas i turistguide applikationer för att bidra användare med information och tjänster. Majoriteten av turistguide applikationer utvecklas vanligtvis för utbildnings eller historiska ändamål. Den här studien presenterar en konceptvalider-ing av den opublicerade ljuvandrkonceptvalider-ings applikationen "SoundTracker", i syfte att förbättra den. Den nya "SoundTracker" prototypen inriktar sig inte på utbildnings eller historiska ändamål, utan den är inriktad på inspelning, uppspelning, och delning av personliga ljud-vandringar med vänner och familj. Konceptvalideringen är begränsad av de definierade forskningsfrågorna i den här uppsatsen. Det handlar i korta drag om en förbättring av noggranheten på de inlästa GPS koordinaterna från en användares position, för att förse användaren med en trevlig användarupplevelse. Dessutom är grafiska användargränssnit-tet av den originala prototypen förbättrat, och testat genom webb enkäter. Vad gäller delnings funktionaliteten, en test applikation är skapad för att hitta essentiella aspekter som behöver tas hänsyn till i den nya "SoundTracker" prototypen när en användare vill dela ett ljudspår med vänner och familj. Test applikationen testas baserat på samlade svar genom en semi strukturerad interview på människor i åldersgruppen 20-30 år.

De erhållna resultaten indikerar på att genom användning av Kalman filter, förbättras noggrannheten på användarens position, vilket resulterar i en ljudvandring med mindre avvikelser jämfört med en GPS-sensor. Vad gäller det förbättrade grafiska användargränss-nittet, det var enklare för användarna att förstå den förbättrade prototypen såväl som navigera igenom den, än fallet med den originala prototypen. Användarna finner det även intressant när en delningsfunktion implementeras med designen som diskuteras i det här arbetet.

Nyckelord: Kontextmedvetenhet, konceptvalidering, ljud guide, platsberoende, vänner och familj, Android smart mobil, Kalman filter, GUI, inspelning och uppspelning, ljudvan-dring, delning.

(6)

(7)

Acknowledgements

We would like to express the deepest appreciation to the course coordinator, Magnus Krampell, because of him being very supportive to us during the work of this thesis, from the start of it to the end. We would also like to express special thanks of gratitude to Lars Holmberg for his consistent feedback during our work of this thesis, Arezoo Sarkheyli-Hägele for her always wise comments, and Agnes Tegen for her good advices. Last, but not least, we would like to thank friends, and especially family members for their enormous support to us during the work of this thesis. Without these mentioned people, our thesis would not have been finalized within the limited time frame.

(8)

Glossary

• Context-awareness: Also called location awareness, is when the location of a device determines how its certain processes operate.

• Sound-walk: A walk that a user records, in which the audio file and the position of the user is synchronised.

• Audio tour guide: A guide in which the audio is the navigator.

• Proof-of-concept: A process that is aimed at finding the best technologies to work with in order to build a well-optimized application.

• GUI: Graphical user interface.

• UX: User experience.

• apk-file: Android package, package file format for distribution and installation of Android mobile applications.

• 3GPP: A multimedia file that uses the file extension .3GPP. It stands for "3rd Generation Partnership Project Group".

(9)

(10)

1 Introduction

This section presents the background of this thesis followed by the vision, the research aim and the research questions. The vision includes a short background of the original prototype along with the contributions, and the novelty of this thesis. Moreover, the scope and limitations, and the requirement specification are also presented in this particular section together with the thesis organization.

1.1 Background

Context-aware applications use context for different approaches. Tour guide applications are context-aware applications that present information and provide services to the users [1].

One of the very first projects on context-aware tour guide was developed during 1996. The context-aware tour guide was achieved using a wearable computer device. The name of the project is “Cyberguide” [2]. During the same year, few researchers were analysing the applications that can be developed, in order to maximize the benefit from mobility. Their understanding was that applications are able to use contextual information of a mobile environment and offer greater services to the users [2].

Some researchers working with context and context awareness want to minimize the load on visual attention in mobile situations. Therefore, the importance of non-visual modalities for a guided tour is increasing. A very promising solution of non-visual modality for a guided tour is having audio as the guide. By having audio as a navigator of a tour, the user can interact with the environment with less barriers [3].

Several audio tour guide applications have been developed since the concept context-awareness in mobile application has been introduced. Many of these audio tour guides are used as tourist guides, for educational or historical review purposes, for example audio guides mentioned in A real-world study of an audio-tactile tourist guide [3], such as Audio GPS, The Swan project, The ONTRACK, Soundcrumbs and more.

1.2 Vision of this thesis

The vision of this thesis is to provide users with an audio tour guide that is location-based, in which they both can record their own private sound-walk, and play their friends’ and families’. The sound-walks let the visitors experience interaction with the real world with the help of computational information [4].

This work will give the user an opportunity to experience his/her past experience on a specific track, and even make it possible for the user’s friends and family to experience the same. In order to fulfil this, a proof-of-concept of the original "SoundTracker" prototype is developed.

(14)

The original "SoundTracker" prototype

Holmberg, L.1, who is the developer of "SoundTracker" application2, started developing "SoundTracker" in 2016 . The prototype is for outdoor tour guiding, in which you can experience an audio tour guide using a smart mobile device. See Appendix B for the as-sociated GUI. The concept of Holmberg’s work was to record, and play own sound-walks. There was no target-group set for the "SoundTracker" prototype, neither did Holmberg put any focus on the user experience of the sound-walks.

The sound-walks are recorded while walking on a certain path and stored in a realtime database. The position of the user is located through the GPS-receiver in the user’s mobile device. The GPS coordinates of a walk are stored in sync with the recorded audio file. The audio file can only be played if the user is located on the same location where the audio file was recorded, and follow the same track3.

As mentioned in the previous paragraph, this thesis is a proof-of-concept of the origi-nal "SoundTracker" prototype. Therefore, it was important to study the problems that were needed to be considered in the proof-of-concept. In order to study the problems, the original prototype of "SoundTracker" was tested (see Appendix A for the test results).

Two main problems were experienced while testing the original "SoundTracker" proto-type. These problems are the following:

1. The accuracy of the GPS position deviates during recording and playback of the audio tour guide.

2. The GUI of the original prototype was difficult to navigate through. It was subse-quently not easy to interact with the application.

Contribution and novelty of this thesis

The contribution of this thesis is to improve the omissions of the audio tour guide applica-tion, "SoundTracker". Therefore, the omissions of the original "SoundTracker" prototype are explored. The main focus is on enhancing the accuracy of the GPS coordinates. What else that will be considered in this thesis, when improving "SoundTracker", is the user ex-perience depending on the chosen target-group: friends and family. Moreover, the function of sharing sound-walks will be explored.

The novelty of the proof-of-concept developed in this thesis is the idea to share one’s own experience with close friends and family, and not use a sound-walk as a tourist tour guide. This was to limit the audience of the new "SoundTracker" prototype. The reason is that a varying audience can have different perspectives of the GUI and the functions of an audio tour guide. A minor group, friends and family, limit the adjustments needed for the

1

https://drive.google.com/file/d/0B8ocVLBkH2YhR0ZvYTdyYkxTRU1YaUIzdUtEV0tXRmM0dTNn/view

2_{https://play.google.com/store/apps/details?id=se.mah.iotap.soundtracker} 3

(15)

new "SoundTracker" prototype, concerning the functions and the GUI. Moreover, there is no published work until the year 2018 about a location-based audio tour guide that is specifically aimed at friends and family. This work is consequently the first work to have family and friends as the target-group of location-based audio tour guides. Furthermore, the audio guides in "SoundTracker" are stored in a realtime database and are not just pre-recorded files that are only playbacks, as in audio guides mentioned in A real-world study of an audio-tactile tourist guide [3].

The proof-of-concept of the original "SoundTracker" prototype developed in this thesis, does not aim for educational or historical review purposes, instead it is aimed for record-ing, listening and sharing personal audio guides with friends and family.

1.3 Research aim and research question

1.3.1 Research aim

The research aim of this thesis is to improve the original "SoundTracker" prototype, so that friends and family can experience an enjoyable audio guide at the same location where it was recorded, at a later time.

1.3.2 Research question (RQ)

How can a location-dependent audio tour guide be designed and what adjustments in "SoundTracker" prototype has to be done, in order to provide an enjoyable audio tour guide experience for friends and family?

Clarification of research question

RQ1 How can the location accuracy be improved in "SoundTracker" prototype during both the recording, and the playback of the audio tour guide?

RQ2 What adjustments of the graphical user interface in "SoundTracker" prototype should be made, with regard to the target-group, friends and family members?

RQ3 What aspects could be necessary to consider in "SoundTracker" prototype when a user wants to share a sound-walk with friends and family?

1.4 Scope and limitations

The work of this thesis has certain limitations, both technical limitations and system lim-itations, which are based on the original prototype, "SoundTracker". These are presented in this section. To begin with, technical limitations will be presented firstly followed by the system limitations.

(16)

1.4.1 Technical limitations

The work of this thesis is programmed in Android Studio. This indicates that the applica-tion developed in this work can only funcapplica-tion on smart-phones that have Android as the operating system. The Android version on the smart-phone that is used for testing the new "SoundTracker" prototype is Android 7.0. Though, the prototype has not been tested on lower or higher versions. The tour guide is limited to have audio as the navigator, and is location-based. Read the following subsection (1.4.2) to understand what audio-based, and location-based tour guide indicate.

1.4.2 System limitations

In order to experience the tour guide, and take advantage of the chosen sound-walk, the user should wear headphones to prevent noise during a sound-walk. The user will also have to be present at the location where the chosen sound-walk was recorded. This is what is meant by audio, location-based tour guide. Moreover, the user needs to have an internet connection in order to play and record the sound-walk. There are no limitations set for how long the recorded file can be, neither how many files a user is able to record.

1.5 Requirement specification

This section is introducing the requirements of the overall system. The requirements are divided into two types, functional and non-functional requirements.

On the one hand, functional requirements are functions the system is expected to have4. Table 1 and 2 below are presenting functional requirements. The template of the tables is inspired by Lawrence Chung et al [5].

The significance factor implies the importance of each requirement. The highest value (5) addressed to a specific requirement indicates that the requirement is of a big impor-tance and should be considered as an essential requirement to fulfil. While the lowest value (2) indicates less importance of a specific requirement and should not be considered as essential to fulfil compared to the requirements with higher values.

(17)

Table 1: Functional Requirements of the overall system

Id Requirement statement Significance Factor ä1 Record an audio file while

walking.

5

2 Give an id to the recorded file. 5 3 Upload the recorded file on

the Server.

5

4 Retrieve the recorded file from the Server.

5

5 Play the chosen audio file when near the recorded posi-tion.

5

6 Stop playing audio file when user is out of the tracked loca-tion.

5

7 Every user should be able to register and create own ac-count.

5

8 Users can choose to either save or delete their recorded sound-walk.

2

9 Every user should have their own database that other users cannot reach.

4

10 Gps coordinates should be synchronised with the recorded audio file.

5

11 Show current position of the user on Google-maps in the application.

(18)

Table 2: Functional Requirements of the overall system

Id Requirement statement Significance Factor 13 Update current position of the

user on Google-maps in the application.

5

14 Show the track of the chosen audio file on Google-maps in the application.

5

15 User should be able to zoom in/out and move around the Google-maps in the applica-tion.

3

On the other hand, non-functional requirements are requirements describing the perfor-mance and quality of the system [5]. Table 3 below is presenting non-functional require-ments. The template of this table is also inspired by Lawrence Chung et al [5]. Concerning the "Significance Factor" for non-functional requirements, it is equivalent in definition to that of the functional requirements.

Table 3: Non-Functional Requirements

Id Requirement statement

User concern Significance Factor 1 Usability The functions in the application

should be easy to find, and under-stand.

4

2 Integrity Only registered users should be able to login and see their recorded/played files.

4

3 Reliability A user should be able to record a sound-walk for as long as he/she wants to.

4

4 Efficiency The deviation of a user’s coordinates (location) during recording should be less in the new "SoundTracker" prototype than in the original one.

5

5 Flexibility A user should be able to change be-tween existing files and choose a de-sired one to play.

4

1.6 Thesis organization

The upcoming chapters of this thesis are organized systematically. Starting with chapter two, the technical infrastructure is presented containing the technical background. This

(19)

information is needed in order to grasp the following chapters. In the next chapter, chapter 3, related works to the thesis are proposed, and referred to. Thereafter comes chapter four, in which the conducted research approach is explained. In chapter five, the results and the analysis of the built-up prototype are presented. The sixth chapter presents a discussion about the obtained results. Lastly, in chapter seven, future work along with a conclusion is brought up.

(20)

2 Technical infrastructure

In this section, the technical infrastructure behind this work is presented. Only relevant information to this work is considered, and explained.

2.1 A brief intro to Android

Android is an operating system developed by Google, and based on Linux Kernel5. It is mostly found in smart-phones. Android is also used in current devices such as Android TV, Android Wear that is wearable devices, and more. As the largest and most popular operating system, Android has served widely around 200 countries. It is still expanding and reaching out to one million users daily, introducing them to the world of applications, and other digital content. With Android, developers are able to create mobile applications, based on most recent technologies. Android developers are provided the tools for developing the applications6. Regardless of what application is being developed, if neither of the GUI, or the UX are taken into account, the developed application will be deprived of attention from consumers7.

2.1.1 GUI and UX

As Patrick Neeman said in an interview with Lanoue (2016), “UI is generally about visual design and information design around screens. UX is about the complete experience and it may not be even about the screen”8. The graphical user interface (GUI) of an Android application is accordingly the first thing the user observes, when he or she starts up the application. The users are able to interact with the application and navigate through the GUI. UX, on the other hand, is as Neeman said, the experience a user gains when using and interacting with the GUI. For this work, the UX is tested through surveys. See chapter five of this report for further information about the UX of the prototype for this work, obtained from created, Before and After surveys.

Android’s Pre-built GUI

Android have already built-in GUI components for the developers. Those components exist for the developers to benefit from, when putting together the suitably GUI for their application of choice. Layouts are an example of GUI components. Besides that, there are also pop-up messages, toasts, dialogs, menus and more that are provided for certain graphical user interfaces9.

5 https://www.androidauthority.com/what-is-android-328076/ 6_{https://developer.android.com/about/index.html} 7 https://www.hyperlinkinfosystem.com/blog/importance-of-uiux-design-in-the-development-of-mobile-apps 8 https://www.usertesting.com/blog/2016/04/27/ui-vs-ux/ 9 https://developer.android.com/guide/topics/ui/index.html

(21)

2.1.2 Location awareness in Android

Android has built-in APIs that provide different features. These APIs can be implemented in the Android applications. Location awareness is seen as one of the most exceptional feature provided by mobile applications. It increases the contextual experience in the applications. Android offers location awareness by the location APIs. These APIs handle location provider and user movement automatically. The APIs utilize GPS and Android’s Network provider to receive location of the user10.

2.2 Google Firebase

Since this work is a proof-of-concept, it is important to indicate that Firebase was used as a platform for the development of the original prototype (In Android). The main aim behind the use of Firebase is because of its database for storing data in realtime. Apart from that, Firebase provides other services that are useful for the user to be acquainted with. As an enhancement of the original prototype, the authentication service is implemented in this thesis. In the upcoming subsection, a brief description of Firebase is made clear.

2.2.1 What is Firebase?

Firebase is a platform for development of applications [6]. It was published by Google in 2016 [6]. The platform is an improvement of other APIs aimed in developing applications [6]. It consists of three major parts, which are “Develop”, “Grow”, and “Earn” (Google Firebase, n.d) [6]. See figure 1 below. Each part consists in turn of multiple technologies where each technology provides unique services for users. For instance, there are services for storing data in a realtime database. In addition, there is also authentication done through different sign-in-methods, and cloud storage services for storing files [6]. These services could be integrated and functioned together resulting in an even better performance, than when functioning separately11.

10

https://developer.android.com/training/location/index.html

(22)

Figure 1: Technologies provided by Firebase. [6]

2.3 Global Positioning System (GPS)

2.3.1 What GPS is

Global Positioning System (GPS) is a navigation system developed in the beginning of the 1970s. This system was developed by the US Department. Initially, the main goal of this system was to meet US military needs. Thus, it has been available to civilians for many years now. GPS gives access to ongoing positioning and timing information all around the world, despite different weather conditions. GPS is a passive system that is used by illimitable amount of users, where the users can only receive the satellite signals [7].

2.3.2 How GPS works

GPS is a satellite-based system where the location of the GPS receiver is determined with the help of GPS satellites that are located nearest to the GPS receiver. The satellites sends a microwave signal continuously to the GPS receiver. This signal consists of two carriers, two digital codes, and a navigation message. The GPS receiver can only read this signal when it is switched on. Once the GPS receiver has picked up the signal, it processes through it using built-in software. The outcomes of the signal processing are the distances to the GPS satellites from the receiver and the satellite coordinates. These are accessed by the digital codes, also called pseudoranges and by the navigation message [7]. Figure 2 demonstrates how a GPS device calculates its position, by measuring its distance from multiple GPS satellites.

(23)

Figure 2: GPS receiver determining position (Icons are made by Freepik from www.flaticon.com).

2.3.3 GPS performance

GPS signals get affected by many types of errors and biases, also called systematic errors. These errors may occur at the satellites, at the receiver, or because of signal propagation due to atmospheric refraction. These errors affect the accuracy of GPS pseudorange and carrier-phase measurements, which affects the accuracy of GPS positioning. The GPS positioning also becomes affected by the geometric locations of the satellites read by the GPS-receiver. The accuracy is better when the satellites are spread out in the sky [7].

The GPS-receiver in smart-phones have an accuracy within 4.9 m radius under open sky, which is a standard value. However, this accuracy can get affected by random errors and different factors like satellite geometry, signal blockage, atmospheric conditions, and re-ceiver design features/quality12. Even the speed accuracy of GPS is dependant on likewise factors that affect the GPS positioning accuracy. The user range rate error (URRE) for the GPS speed measurement is of less or equal to 0.006 msec over 3 second interval, with a probability of 95%13.

Better accuracy of GPS system can be achieved by studying the errors. By reducing the errors, it is possible to receive more accurate and precise GPS signals [8].

12_{https://www.gps.gov/systems/gps/performance/accuracy/#how-accurate} 13

(24)

3 Related work

This chapter presents the works that are related to this thesis. All of the works that are presented in this section have similarities and omissions with the new "SoundTracker" prototype. A description of each work is presented, followed by the reason of why it is related to this thesis. Lastly, a summary of all the related works is demonstrated.

3.1 “Cyberguide : A Mobile Context Aware Tour Guide”

The journal, Cyberguide : A Mobile Context Aware Tour Guide [2], was published during 1997. It presents a construction of a “Cyberguide” project. The idea behind this project was to use contextual information, such as location of a user to provide better services to the user. The focus was only a limited part of the user’s context, such as the user’s current location, previous location, and orientation. With this given information, several services were implemented in the prototypes. The authors of this journal even reviewed the research issues that were experienced during the building process of the prototypes. “Cyberguide” project consists of both indoor and outdoor oriented prototypes. These pro-totypes compose mobile hand-held context-aware tour guides around specific areas.

As mentioned above, the project “Cyberguide” is built up of numerous prototypes. The build up process of “Cyberguide” lead to creation of a system architecture which the nu-merous prototypes were supposed to have. The system is made up of different independent components, which provide different services; such as map, information about sights, nav-igation system (to know user’s position) and wireless communication services.

The results obtained of “Cyberguide” project were relatively near to the goal that the researchers of the journal had. All of the prototypes contained components that fulfilled the desired services mentioned in the system architecture. One of the most important services that increased context awareness in the prototypes was the positioning system. For indoor positioning, infrared (IR) module was used. However, a Trimble GPS unit was used for outdoor positioning.

The journal is relevant to this thesis because it has same area of research as in this thesis, which is mobile context-aware tour guide. In the “Cyberguide” project, GPS coordinates are used for positioning system in the outdoor tour guide. More specific similarity is that the tour guide presented in “Cyberguide” project is location-based.

3.2 "Smart Audio Tour Guide System using TTS"

In this paper [9], the author, Jwa, presents a location-based audio tour guide system. The audio guide system is presented with a mobile application that provides realtime tour in-formation at tourist attractions. The system consists of several units forming the entire system solution. These units are the following: a tour guide service system, an information collection system, a tour information database, a server-based TTS engine, and a mobile application.

(25)

The aim of the author’s work was to enhance self-guided tours and to enhance a tourist’s travel experience. The tour guide service system selects the optimal tour information for every user, which is based on a user’s context information. This information is then pro-vided by a multilingual geotagging audio guide from the server-based TTS engine on the mobile application for the user. The users can then write their experiences as tourists information by using a wiki-based tourist information collecting system. By this, users are able to provide their travel experiences along with the path they traveled as recommended trips to other users.

The tour guide information is reviewed and updated by the administrator of a tour in-formation collection server. This updated version of tour guide inin-formation is stored as the multilingual geotagging tourist information in the tour information database. As men-tioned, the multilingual audio guide is used by the server-based TTS engine to provide audio tour guide service whenever it is requested in the mobile application, by the user.

The geotagging tourist information is generated and visualised through Geographical In-formation System (GIS). The author underlines that the presented audio guide service was used year 2017 in some tourist locations in South Korea.

The paper presented by Jwa is related to this thesis because it presents an audio tour guide system that is location-based. The aim is to enhance self-guided tours and tourists travel experience, which is the same in this thesis but with a target group of family and friends. Moreover, the proof-of-concept in this thesis does not use Geographical Informa-tion System, and is neither multilingual as the work presented by Jwa.

3.3 "Multi-sensor fusion method using Kalman filter to improve local-ization accuracy based on android smart phone"

Wang et al. [10] conducted an approach based on use of android smartphones in Intelligent Transportation Systems with the aim to obtain the position of people and vehicles. The problem that the authors were willing to solve was improving the read GPS data to retrieve an optimal position near to the actual position on street level, and achieve a path without inconstancy.

To solve the problem, the authors used an approach based on three methods, where the first method was gathering data about the position, that was reading the speed, direction, longitude, and latitude through the built-in GPS in an android smart phone. The second method was an algorithm for road matching, where two principles were taken into con-sideration. One principle was concerned about making a decision of what road was the nearest to the user. Another principle was telling what direction of the chosen road does match the direction of the user in motion.

(26)

de-viating points, and achieve gps data free of deviations, that is data near to the actual data read. As the last step, road interpolation is applied on the highest accuracy achieved during Kalman filtering in order to get a deeper understanding of the results in detail.

Related work that others have done is referred to in the journal briefly. The related works are referring to the methods used by the authors of this journal, where road matching, Kalman filter, and interpolation methods were involved.

The results the authors obtained were different depending on the method used. For the first two methods mentioned earlier, the GPS data accuracy was somewhat high. The third method, that is the Kalman filter, was the only method giving highest accuracy, resulting in a smooth path free of deviations. The authors concluded in their conclusion that their chosen approach gave them what they wanted.

This paper is relevant to this thesis by showing how Kalman filter is used to enhance the accuracy of GPS data acquired from an android smart-phone. The Kalman filter can be used for improving the location accuracy of the location obtained from the built-in GPS-sensor in the prototype of this project.

3.4 "Improving localization accuracy of Android’s Fused Location Provider API using Kalman Filter"

Gurram, and Giri [11], conducted an approach based on use of Android smart-phones. The problem that has been solved by the authors was improving the accuracy of Android’s Location API by tracking a car. The API used was specifically Fused Location Provider API. The specified approach that was applied for this aim is Kalman filter.

To solve the problem, the authors relied on two main approaches. One approach rep-resented a literature study, where Fused Location API was studied. When applying the Fused Location API, the authors considered the aspects of the API, which included lon-gitude, latitude, altitude, speed, and direction. In addition to that, a literature study of Kalman filter was also studied, giving a deeper understanding of how Kalman filter works and what mathematics are behind it.

Except for the literature studies, the authors relied on an experiment involving two smart-phones, where both of the smart-phones tracked the car at the same time. One smart-phone was running the application with only the Fused Location API without any Kalman filter implemented. The other smart-phone was running the application with the API along with Kalman filter implemented.

There are three related works that Gurram and Giri referred to briefly in their Jour-nal. One related work is very close to Gurram’s and Giri’s work, where Kalman filter and the different aspects of Fused Location API were discussed. Another related work was aimed for improving the accuracy of the read-in GPS coordinates with Kalman filter

(27)

implemented. The last related work also implemented Kalman filter, but for tracking re-altime satellites.

The experiment based on the conducted literature studies resulted in different read-in data points that were plotted in different figures. The conclusion of the obtained results and the plotted figures is that Kalman filter improved the accuracy of location resulting in a smoother path than the one with no Kalman filtering.

This paper contributes to this thesis by showing how the Kalman filter is used to en-hance the accuracy of the GPS data acquired from an Android smart-phone. The Kalman filter can be used for improving the location accuracy from the built-in GPS receiver in the new "SoundTracker" prototype. Except for that, instead of using Fused Location Provider API, a newer version will be used, which is Fused Location Provider Client API (released by Android 201714); this API provides the location information retrieved from the GPS-sensor in mobile device. Moreover, only longitude and latitude of the location will be taken into consideration in Kalman filter calculation.

3.5 "Guidelines for handheld mobile device interface design"

Gong and Tarasewich [12] have, in their work, focused on addressing the aspects and the drawbacks of modern handheld mobile device interfaces. The problem that the authors have solved, introduces design guidelines with respect to the GUI of mobile phones, based on the use of actual interface guidelines. This was done through literature studies on pub-lished research about GUI and, more specifically, the traditional GUI of desktop computers.

The actual interface guidelines referred to by Gong and Tarasewich are the eight actual interface guidelines called the “Golden Rules of Interface Design” by Shneiderman. The authors refer to these rules because they are related to their research, which is the GUI of handheld mobile devices. One of Shneiderman’s guidelines provides Informative Feedback to the user, by for example prompting a message to a user when an error has occurred. This is, according to the authors, regarded as beneficial and interesting to most users.

Other guidelines are explained by the authors and are mostly suitable for interfaces of mobile devices. One guideline concerns Design for Limited and Split Attention. It focuses on designing handheld mobile devices in a manner in which they do not have too much attention. The authors believe that mobile devices with graphical user interfaces requiring a lot of attention can be the reason of diverting attention from users of more important functionalities.

Another guideline is the use of interaction techniques which are essential in order to reduce physical restrictions. For example, speech as input or sound are examples of interaction techniques. Additional guidelines are personalization of mobile devices where users are able to personalize the device and its use, depending on the users desires.

(28)

In their conclusion, Gong and Tarasewich underlined that they have in their work presented a set of guidelines for mobile interface design, having special importance on highlighting the benefit concerns of mobile devices.

This paper is related to this thesis because it proposes a set of guidelines that are useful when designing the GUI of the new "SoundTracker" prototype. The guidelines that will be used in this thesis are mainly the ones referred to in Gong and Tarasewich’s related work. For instance, two important guidelines that will be used, among other important ones mentioned in Gong and Tarasewich’s work, are i) to focus on making the graphical user interface of the new "SoundTracker" prototype require less attention by users, and ii) to reduce physical restrictions by using suitable interaction techniques.

3.6 Summary

Referring to the above mentioned related works, there are similarities and omissions with each one in relation to this thesis. The first related work is one of the first tour guides published. The similarity to this thesis is that it presents an outdoor tour guide, in which the GPS coordinates are collected based on the location of the user. The omission is that it is not an audio tour guide, which is the case in this thesis. On the contrary, the second related work is a newer work describing an audio tour guide system, in which the authors focus on the user experience. Differently to this thesis, the second related work is aimed at tourists, while in this thesis the focus is on family and friends. As for the third and the fourth related works, they are similar due to the mathematical method used in order to improve the GPS accuracy, Kalman filter. In the fourth related work, the GPS accuracy is collected from an Android smart-phone with use of an older version of Fused Location Provider API. However, in this thesis a newer version of the Fused Location Provider API is used, called Fused Location Provider Client API, to obtain the GPS-sensor location and other location features. In the fifth related work, guidelines for designing the GUI of a prototype are discussed. What is missing in this specific related work are examples of GUIs. However, based on the presented guidelines, suitable GUIs are implemented for the new "SoundTracker" prototype in this thesis.

(29)

4 Method

This section of the report explains how the research work was conducted. It raises the kind of research method and research approach used in order to answer the research questions.

4.1 Methodological background

In order to conduct this research, Nunamaker and Chen’s research methodology is used. This particular research methodology is aimed for system development [13] [14]. The main reason behind this choice of method is that it is “of an iterative nature” [13]. See figure 3 in section 4.3 of this chapter. Another reason behind this choice of method is that it can be used in combination with other research approaches [13] [14]. Research approaches that will be used for conducting this work, beyond Nunamaker and Chen’s, are two surveys, and an interview, together with a literature study (see upcoming subsection). A summary of the obtained results, from the conducted surveys and the interview, is found in chapter 5 of this thesis.

4.2 Data collection

In this section, a systematic literature study is presented. This method was approached to collect theoretical information concerning the work of this thesis.

4.2.1 Systematic literature study

A systematic literature study was made in order to get a deeper understanding about this particular subject. It was important to read the related works, as it was to search information about theoretical background of the subject. The systematic literature study was also used to analyse and identify the solutions for the problems found in the original "SoundTracker" prototype, such as the solution for better location accuracy. The solutions that were found during the systematic literature study are the following:

• Differential GPS (DGPS): It is a system that provides positional correction to GPS signals. A fixed known position, a base station, is used to adjust realtime GPS signals to eliminate errors. Thus, the service that DGPS provides is restricted in two ways: (i) it has to be afforded, (ii) the receiver has to be near a DGPS station, by that it means less than 1000 km. The accuracy gained by DGPS can be of a few meters [15].

• Assisted GPS (AGPS): This system improves the performance of GPS in smart-phones that are connected to the mobile-network. The AGPS is used when the signal is weak due to surrounding of buildings or trees, leading to an inaccurate position determination by the GPS [15]. However, AGPS is integrated as a chip in mobile devices and already exists in most of the smart-phones15.

15

(30)

• Kalman filter16 _{: It is an iterative mathematical process that uses a set of}

equa-tions to predict an estimate. The filter can be used for several aspects: it supports estimations of past, present, and future states, and does not need to know the exact nature of the modelled system to calculate its estimates. The input that is required in Kalman filter is the following:

– Initial estimate, EST_k−1

– Measured value from the sensor, M EA – Initial error in the estimate, EEST

– Error in the measurement, E_{M EA}

The equations presented below are the conceptual equations used in Kalman filter. They are aimed for one-dimensional calculations.

KG = EEST EEST + EM EA

(1)

ESTt= ESTt−1+ KG[M EA − ESTt−1] (2)

EEST (t)= [1 − KG] ∗ EEST (t−1) (3)

The equation (1) calculates the Kalman Gain, KG. Kalman Gain lies between 1 and 0, and determines the priority of the measured value versus the estimated value. The second equation (2) calculates the current estimated value. The last equation (3) calculates the new estimated error. The estimated error, and the estimated value in equation (2) are used in second iteration as the initial values. This process goes on for every iteration until the estimated value is very close to the real value.

See section 3.3 for the related work in regard to this solution.

As a result from the systematically done literature study, see chapter 2 for information about technical infrastructure. For retrieved information about related works, see chapter 3. Moreover, see chapter 5 for the results of the systematic literature study in regard to the location accuracy.

16

(31)

4.3 Research approach

This section presents the research approach conducted in this thesis. A combination of three methods is used; that is a survey study, a semi-structured interview and Nunamaker and Chen’s Methodology.

4.3.1 Survey

With the reason that this work is a proof-of-concept of the original "SoundTracker" pro-totype, a Before survey17 and an After survey18 were created.

For formulating, evaluating, and analysing the survey questions, an appropriate question evaluation method was used. The method is called Usability study19, and could be used for evaluating different data collection tools, where survey studies are one of them.

The Before survey was publicly sent out to friends and family. It consisted of 7 ques-tions in total, in which 2 of them were 5-point Likert scale, 4 of them were presented with alternates, and 1 of them was for additional comments. The survey was sent out before conducting any improvements of the prototype, together with a link to the original proto-type for downloading20. In order to participate in the survey, friends and family were asked to test the original prototype at first. Concerning the After survey, it was also publicly sent out to the same target population consisting of the same questions as in the Before survey, but this time with an apk-file of the new "SoundTracker" prototype for downloading. A summary of the results is found in chapter five of this thesis, starting with an explanation about why the specific survey questions were designed.

The aim of the Usability study method (including surveys) is to collect data from users and find out whether they are happy with the product they are testing or not. The method does also help identifying the difficulties a user experiences while testing the product. This with the reason to improve the product. These aims are one of the reasons behind choosing this particular evaluation method. Another reason behind this choice of method is because it is conducted in a short period of time.

4.3.2 Semi-structured interview

According to Wilson, C. [16], a semi-structured interview is useful when the aim is to gather information about a certain topic, or a problem that is to be explored. Therefore, the reason behind the choice of this interview technique is to explore a particular problem where extra details are needed. The particular problem in this work is formulated in the third research question, which is to explore the aspects that could be necessary to con-sider in the new "SoundTracker" prototype; when a user wants to share a sound-walk with

17 https://ansnam.typeform.com/to/CQqczE 18 https://ansnam.typeform.com/to/Ec6NLQ 19 https://s3.amazonaws.com/sitesusa/wp-content/uploads/sites/242/2014/04/spwp47.pdf 20_{https://play.google.com/store/apps/details?id=se.mah.iotap.soundtracker}

(32)

friends and family, including how the design of the sharing function should look like.

The sharing function was implemented along with an appropriate design, without connect-ing to any realtime database. Instead, a local database was created for the participants to test the application during the interview.

In order to study the aspects of a sharing function and a sharing design that fulfils people’s expectations, a semi-structured interview was conducted according to the 6 steps under-lined by Wilson in his book. In summary, 10 participants were gathered in a laboratory and were given an overview of the interview, such as how long the interview would take, the topic behind the interview questions, how the collected data would be handled, and what ethical issues are taken into consideration.

The interview questions were about 7 questions21. In addition to the online attachment leading to the interview questions, see Appendix B for the questions attached as a document in this thesis. A summary of the results is found in chapter 5 of this thesis. Furthermore, the answers from the interview are discussed and analyzed in chapter 6 of this thesis, where the main aspects regarded as important by the majority are highlighted, as well as other comments from the participants.

4.3.3 Nunamaker and Chen’s methodology

The research process of Nunamaker and Chen’s research methodology consists of five stages [13] [14]. See figure 3 below. Each stage has its own research issues. The issues of each stage will be discussed under the section Method Discussion regarding the process for this thesis. If new knowledge about a specific domain is acquired by researchers, changes in already made design decisions in foregoing stages occur. The change made in foregoing stages improves the quality of the system and the research results [14]. It is why, as mentioned earlier in section 4.1, this research methodology is “of an iterative nature” [13].

21

(33)

Figure 3: Overview of Nunamaker and Chen’s research methodology.

Construction of a Conceptual Framework

This is the first stage in the research process, to formulate a research question. Since this work is a proof-of-concept, a clear picture of what is already implemented in the system had to be understood. This had to be done before any formulation of a research question. The formulation together with the research aim is found in section 1.3 of this thesis. The formulation was done through daily meetings in group and discussions with the supervisors.

Development of a System Architecture

The second stage in the research process is developing a system architecture. It was con-ducted by studying the original "SoundTracker" prototype, followed by listing down all the functions that need improvement. Also how these functions are related to each other and what functionalities they provide. Besides that, it was important to define the require-ments of the new "SoundTracker" prototype. For that aim, a problem-tree was created, in which the problems were referred to as functions (see subsection 5.1.2 for the problem-tree and the analysis of every function).

With the problems as basis, a list of both functional and non-functional requirements was created. A final system architecture and a final requirement specification were achieved

(34)

through discussions in group. See section 1.5 for the requirements of the overall system. See chapter five of this thesis for the system architecture.

Analyze and Design the System

During the third stage, the system was designed making it a blueprint when building the new "SoundTracker" prototype (in the next stage). From the defined problems in the previ-ous subsection, each problem was in this stage allocated several reasonable solutions. After analysing all of the solutions, only one solution was chosen for each problem. As a result of this stage, a use case diagram (see Appendix B) was created of the new "SoundTracker" prototype, that illustrates the user interaction with the system.

Build the (Prototype) System

The fourth stage is about building the prototype based on the design made in the foregoing stage. To conduct this stage, the analysed solutions in the foregoing stage were verified separately. Each allocated solution to each problem was tested and verified differently with regard to the requirement specification in section 1.5. The software for the new "SoundTracker" prototype was programmed. A complete problem-tree with the verified allocated solutions is found in chapter 5 along with the results and the analysis of the solutions.

Observe and Evaluate the System

During the fifth and the last stage, an overall evaluation of the system was made, relying on surveys, a semi-structured interview, and system testing. The aim of this stage was to validate the verified solutions in the foregoing stage. For the improvement of the location accuracy, this was done through developed system tests (found in Appendix A). The tests were made on the mobile device Samsung Galaxy S7.

In order to test if the user experience and the graphical user interface of the new "Sound-Tracker" prototype fulfils the requirement specification, the obtained results from the con-ducted surveys (see 4.3.1) and the semi-structured interview (see 4.3.2) were analysed. Only then was the new "SoundTracker" prototype confirmed as a proven prototype of the original one.

(35)

5 Results and analysis

This chapter is presenting the results and analysis of the new "SoundTracker" prototype. The chapter starts with presenting the system architecture along with the problem-tree. Furthermore, the results of the new "SoundTracker" prototype are presented, that is the results obtained from answering the research questions (see subsection 1.3 for the research questions) relying on different methods brought up in the previous chapter. Moreover, the analysis of the obtained results is brought up.

5.1 Designing and building the new "SoundTracker" prototype

A complete problem-tree together with a diagram illustrating the system architecture of the new "SoundTracker" prototype are presented in this section. In the upcoming chapter (6), a discussion regarding the results is raised.

5.1.1 System architecture of the new "SoundTracker" prototype

Figure 4 below is showing the system architecture of the new "SoundTracker" prototype, where the relations between the involved components are described with arrows. In short, an authenticated user is holding a smart-phone in which a GPS receiver is reading signals from the satellites. It is for the user to see his/her own position on the map when he/she wants to record a sound-walk, or play one from the own realtime database (Authentication process and data storage are explained more in subsection 5.3 ).

(36)

Figure 4: System architecture (Icons are made by Freepik from www.flaticon.com).

5.1.2 Problem-tree

The problem-tree was constructed in the second stage of Nunamaker and Chen’s method-ology. This was done to obtain an overview of the different functions in the new "Sound-Tracker" application, as well as to identify the problems in each function. For that aim, 5 functions were indicated.

• Recording: The recording function is required so that the user can record a sound-walk.

(37)

• Playback: In order for a user to play a recorded sound-walk, the playback function is needed.

• Tracking: In order for a user to follow a sound-walk free of GPS deviations, a realtime reading of GPS coordinates is needed. How this function is implemented is explained in the complete problem-tree with solutions, found in this chapter.

• GUI: The first thing the user observes is the GUI of the application. If it is not designed to ease a user’s navigation through the application, the user will not be happy. Moreover, it is also important for a user to share sound-walks with friends and family.

• UX: A user should be able to interact with the GUI and have a good experience when navigating through the application.

With regard to the new "SoundTracker" prototype, the functions were divided into sub-functions. The sub-functions were associated to the problems experienced on the original prototype (see Appendix A for the test-results). These sub-functions were allocated to the functions as follows:

• Synchronising Sound and Location: In order to experience a recorded sound-walk with less deviations, it was important to synchronise the audio file and the location of the user. To obtain this, three different functions were used: recording, playback, and tracking.

• Reading GPS coordinates: In order to track the user, it was necessary to input the users current position obtained through the built-in GPS-sensor in the mobile device. • Sharing: Since the new "SoundTracker" prototype is aimed at friends and family;

the sharing function and its GUI were analysed.

• Design: The graphical user interface of the original "SoundTracker" prototype needed modifications. Therefore, the design of the original prototype was improved.

Each sub-function was analysed and studied in order to create the solutions. See next subsection for the complete problem-tree with the implemented solutions.

Complete problem-tree

Figure 5 below is illustrating the core problem with its functions, and subfunctions, along with the verified solutions. From the problem-tree below, it is clear that for a user to expe-rience a sound-walk without deviations, Kalman filter was used together with mathematical conditions. The method was applied on recording, playback, and tracking functions. As for the graphical user interface, authentication was implemented, and integrated with the Firebase realtime database to allocate unique id to each user so that they have access to own database. The design was tested through a Before and an After survey. The possible aspects of a good sharing function, and design was verified through interviews. More of the results of each solution is found in this chapter.

(38)

Figure 5: Complete problem-tree with verified solutions.

5.2 The enhancement of location accuracy

The solution to improve the location accuracy for the new "SoundTracker" prototype was to implement Kalman filter on the location determined by GPS-sensor. The analysis of why Kalman filter was the chosen solution is presented later in this section. The results and the analysis are presented below.

5.2.1 Kalman filter

As presented in the related works (see chapter 3), there are proven works that have im-plemented Kalman filter on GPS values to achieve better accuracy of a user’s position. In this thesis, Kalman filter was implemented to enhance the accuracy of the GPS position (obtained from the satellites). The reason of why Kalman filter was the chosen solution to achieve better location accuracy than the GPS, is analysed later in this section.

There are four input values that were required in Kalman filter. The first input is the initial estimate. To determine the initial estimate for the filter, several tests were made. The initial estimate can be any value, thus it was better to have an initial estimate that is not too far from the true value, especially if only some iterations were made in order to

(39)

find the current state.

The method to determine the initial estimate was as following:

1. Find five reference locations (accessed by Google Maps) in different places in Malmö that have different surroundings, open area, dense area etc. .

2. Read GPS-sensor locations for these places.

3. Calculate the difference between the real coordinates of the location and the location determined by the GPS-sensor.

4. Calculate the average of these differences.

See figure 6 below for the five different locations, pinned with markers, in which the tests were made.

Figure 6: Test locations to determine the initial estimate.

With the average of how much the GPS-sensor deviates from the real locations, a very close initial estimate to the real location was determined. By getting the user’s current position through the GPS-sensor and subtracting it with the average of the GPS deviation, the initial estimate was determined, as presented in the equations below. In which, the presented numerical values, 0.00012764, and 0.0000798, are the deviation between the GPS location and the real location.

initialEstimateLatitude = location.getLatitude() − 0.00012764; initialEstimateLongitude = location.getLongitude() − 0.0000798;

(40)

The second input for Kalman filter is the measured value from the sensor. It is the position obtained from the GPS-sensor in the mobile device, and is retrieved through the Fused Location Provider Client API. The user’s current location retrieved by the GPS-sensor, current location accuracy, and several different methods in regard to the user’s location is provided by the Fused Location Provider Client API in the new "SoundTracker" prototype.

The third input for Kalman filter is the error in the measurement, which is the current location accuracy that is determined by a feature, a method called location.getaccuracy in Fused Location Provider Client API, which retrieves the accuracy in meters. This accuracy is non-linear and is updated frequently for every measured value.

The last input in the Kalman filter is the initial error in estimate. This value is determined by the following method:

1. Determine a random error in estimate value.

2. Use Kalman filter on a few GPS coordinates as measure values and check the error estimate values at the end of all iterations.

3. Calculate the average of all these error estimates.

4. The average calculated in step 3 is the starting value for error in the estimate.

With the input values inserted in the Kalman equations (see Systematic literature study in chapter 4 for the equations), the estimated positions of the user were calculated.

The estimated values of both latitude and longitude of the current positions were calcu-lated separately with Kalman filter, and then put together to provide the location. These estimated positions were used to create the track that a user walks, while recording his/her sound-walks. The recorded files are 3GPP files, in which the audio and the location of the user are stored. The comparison of how accurate the location provided by Kalman filter than the location provided by the GPS-sensor was, is presented in figure 7 below. The red line represents the GPS track, the blue line represents the track with Kalman filter, and the black line is the reference track with the real positions.

(41)

Figure 7: Figure A is illustrating the comparison of Kalman filter location and GPS-sensor location with real coordinates of a walked path in a street. Figure B is illustrating the same, but in an open area.

The obtained results of Kalman filter are shown in figure 7 above. As shown in both of the figures of figure 7, the location provided by Kalman filter is closer to the reference position compared to the position of the GPS-sensor. However, figure B is showing that the estimated location with Kalman filter has only one direction even if the user changed his/her walking direction. This is analysed furthermore later in this section.

The calculation of the user location with Kalman filter was integrated in the new "Sound-Tracker" prototype.

Reason of Kalman filter implementation

As mentioned in chapter 4, a systematic literature study was made in order to find the method to solve the location accuracy problem. Three notable solutions could be found in the literature, which were Differential GPS (DGPS), Assisted GPS (AGPS), and Kalman filter. These were studied and analysed.

DGPS required a base station to minimize the errors in the location provided by the GPS-sensor. Meanwhile, Assisted GPS was already implemented on most of the

(42)

smart-phone devices, and is implemented internally on the mobile device. The device on which the system tests were made both for the original "SoundTracker" prototype, the new "SoundTracker" prototype, and the tracks in figure 7 did not include AGPS. If AGPS was implemented on these mobile devices, the location accuracy of both the GPS track and the Kalman filter track would have been better than the tracks shown in figure 7. If the DGPS was implemented to improve the location accuracy, the improvement of the location accuracy would have been dependant on the base stations, that can be located both near and far from the user’s location. This could affect the location accuracy, depending on the distance of the user to the base station. Moreover as mentioned in section 4.2.1, DGPS needs to be afforded, which makes it an expensive solution. Both DGPS, and AGPS were not accurate to use for improving the location accuracy of the user in the new "Sound-Tracker" prototype.

Kalman filter was a method that was easy to implement and test. Moreover, there are proven works that have implemented Kalman filter to improve location accuracy, such as the works, Improving localization accuracy of android’s Fused Location Provider API using Kalman Filter, and, Multi-sensor fusion method using Kalman filter to improve localization accuracy based on android smart phone, presented in chapter 3. The results presented in both the related works confirmed that Kalman filter does improve location accuracy ob-tained by the GPS sensor in mobile devices. Therefore, the Kalman filter was a realistic method to use.

Kalman filter vs GPS

The results after the implementation of Kalman filter, shown in figure 7, indicate that Kalman filter implemented on the GPS coordinates gives better location accuracy than with only the GPS-sensor. As seen in figure 7, the GPS values deviate differently based on the location of the user. In figure A of figure 7, the user is walking on a path in a street surrounded with buildings. Due to the dense area, the GPS location is deviated up to 30 meters. This deviation can also be more than 30 meters, depending on the weather condition. However, in figure B of figure 7, the GPS location has less deviation compared to figure A. The reason is that the user walked a path in an open area in figure B. As seen in figure B, the location determined by the GPS sensor does change direction when the user does, but it deviates more when the user is changing direction than if the user is walking in the same direction. However, Kalman filter does not change the direction when the user does; the reason of this is analysed in the following section.

Kalman filter in the new "SoundTracker" prototype

Initially the idea was to implement Kalman filter on the user’s location both while record-ing and durrecord-ing playback. Thus, after testrecord-ing the Kalman filter in the new "SoundTracker" prototype, some disadvantages of Kalman filter were experienced. Therefore, the usage of Kalman filter was limited for the recorded sound-walk. Only the main disadvantage experienced in Kalman filter estimation is analysed in the next paragraphs.

(43)

Main disadvantage of Kalman filter: The calculations of the location determined by the Kalman filter only consider the latitude and longitude of the user and do not take the speed of the user into account. Therefore, a location determined by the Kalman filter is a slower process than the regular GPS position. Moreover, several iterations are needed to determine the user’s position by Kalman filter and this makes the location determination process even more slower. The more iterations Kalman filter makes to determine the lo-cation, the more accurate it is compared to the real user’s location. Consequently, it is a trade-off between the speed of location estimation and the location accuracy.

The slow process is the main disadvantage of Kalman filter implementation and had ef-fected the user’s current location on the playback in the following manner:

• When the user starts the playback of a sound-walk, he/she needs to find the start point of the sound-walk track. The user can be located anywhere when he/she starts the playback of the sound-walk. Therefore, there is likelihood that the user is located far from the track. If Kalman filter was implemented on the user’s location, it would not take the speed of the user in consideration. It would update the user’s position that had been nearer to the user’s previous location located by Kalman filter, than the current user position measured by the GPS. As a result of this, the Kalman filtered position of the user can be located far away from the user’s current position, and takes time to update. Meanwhile the GPS position updates whenever the user’s location is changed. It calculates the current position of the user and does not take the user’s previous location in consideration.

Since Kalman filter estimates the position of the user without considering the user’s speed; the current location of the user is most of the time near to the previous location of the user, compared to the measured value of the GPS-sensor, as seen in figure 8 presented below. To prevent the effect of this during the sound-walk, a method was implemented: when the user wants to end the recording, the last location determined by the GPS-sensor is set as the end position of the sound-walk. This solution is not accurate, because the end position can have more deviation than the rest of the track. However, this worked for the new "SoundTracker" prototype in order to play the whole recorded sound-walk by the user, while walking on the track.