Accurate map-based indoor navigation on the mobile

This article was downloaded by: [North Dakota State University]On: 07 December 2014, At: 17:34Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Journal of Location Based ServicesPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/tlbs20

Accurate map-based indoor navigationon the mobileJó Ágila Bitsch Link a , Paul Smith a , Nicolai Viol a & Klaus Wehrlea

a Communication and Distributed Systems , RWTH AachenUniversity , D-52074 Aachen , GermanyPublished online: 11 Jul 2012.

To cite this article: Jó Ágila Bitsch Link , Paul Smith , Nicolai Viol & Klaus Wehrle (2013) Accuratemap-based indoor navigation on the mobile, Journal of Location Based Services, 7:1, 23-43, DOI:10.1080/17489725.2012.692620

To link to this article: http://dx.doi.org/10.1080/17489725.2012.692620

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoever as tothe accuracy, completeness, or suitability for any purpose of the Content. Any opinionsand views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Contentshould not be relied upon and should be independently verified with primary sourcesof information. Taylor and Francis shall not be liable for any losses, actions, claims,proceedings, demands, costs, expenses, damages, and other liabilities whatsoever orhowsoever caused arising directly or indirectly in connection with, in relation to or arisingout of the use of the Content.

This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/tlbs20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/17489725.2012.692620

http://dx.doi.org/10.1080/17489725.2012.692620

http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/page/terms-and-conditions

Journal of Location Based Services2012, 1–21, iFirst

Accurate map-based indoor navigation on the mobile

Jo Agila Bitsch Link*, Paul Smith, Nicolai Viol and Klaus Wehrle

Communication and Distributed Systems, RWTH Aachen University,D-52074 Aachen, Germany

(Received 5 December 2011; final version received 10 April 2012; accepted 8 May 2012)

We present FootPath, a self-contained, map-based indoor navigationsystem. Using only the accelerometer and the compass readily available inmodern smartphones, we accurately localise a user on her route andprovide her with turn-by-turn instructions to her destination. To compen-sate for inaccuracies in step detection and heading estimation, we match thedetected steps onto the expected route using sequence alignment algorithmsfrom the field of bioinformatics. As our solution integrates well withOpenStreetMap, it allows painless and cost-efficient collaborative deploy-ment, without the need for additional infrastructure.

Keywords: on the mobile; indoor user localisation; inertial navigation; mapmatching

1. Introduction

While navigation systems for outdoor environments are readily available, navigationwithin buildings still poses a challenge. The main reason for this lies in the difficultyto obtain an accurate position information in an easy to set-up way with minimalinfrastructure and to create indoor maps.

Our approach to this problem is twofold: (1) We use simple step detection andstep-heading estimation. Today’s smartphones are already equipped with sensors tofulfil this task. We do not require additional hardware or infrastructure and thecomputational complexity is low. (2) We match detected steps onto the expectedroute from the source to the destination using sequence alignment algorithms.Instead of a more general localisation problem, we solve the localisation problem ona specified route. This allows us to compensate for inaccuracies and give the useraccurate turn-by-turn directions.

To allow an easy incremental deployment of our system, we integrate oursystem with OpenStreetMap (OpenStreetMap community 2011b), which alreadyhas rudimentary indoor support (OpenStreetMap community 2011a). GPS,Pseudolites, UWB, Wi-Fi access points and RFID are avoided, making thesystem useful for protected environments like historical buildings and archaeo-logical sites as well as hospitals, where additional RF gear might interfere withmedical equipment. This work is heavily based on our previous work in BitschLink et al. (2011).

*Corresponding author. Email: [email protected]

ISSN 1748–9725 print/ISSN 1748–9733 online

� 2012 Taylor & Francis

http://dx.doi.org/10.1080/17489725.2012.692620

http://www.tandfonline.com

© 2013 Taylor & Francis

Journal of Location Based Services, 2013Vol. 7, No. 1, 23-43, http://dx.doi.org/10.1080/17489725.2012.692620

Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

1.1. Contributions

Our main contributions are:

(i) Infrastructureless indoor navigation: We use simple step detection and step-heading detection, which we then map onto a route using sequencealignment algorithms. Additional infrastructures, like GPS Pseudolites,UWB, Wi-Fi access points and RFID can be avoided.

(ii) Localisation on a route: We know the route, the user intends to take. Usingthis knowledge, we reduce inaccuracy at corners opposed to furtheraccumulating errors. Path matching is precise enough to allow for accurateindoor turn-by-turn directions.

(iii) Easy incremental deployment: Deploying the system for a new buildingsimply consists of entering the floor plan into OpenStreetMap.

2. Related work

The localisation method is the core component of an accurate navigation system.There exists a multitude of methods, but they can be categorised into the followingthree categories: localisation based on (1) lateration (or angulation), (2) fingerprint-ing and (3) dead reckoning.

In general, special hardware or infrastructure is required for accurate positionmeasures. Additionally, maps, floor-plans or user-mobility models are utilised tofurther optimise performance. However, to the best of our knowledge, none of thesemethods make assumptions about the actual route of a user.

2.1. Lateration

In general, lateration (or angulation) techniques make use of the distance (or angle)of a user to a set of beacons, calculating the relative position with respect to thosebeacons. The accuracy of the distance (or angle) measurement directly influences thelocalisation accuracy. The most prominent example used for outdoor localisation isGPS. Unfortunately, GPS signals, transmitted at about 1.5GHz, are affectedby objects. Therefore, GPS performs reasonable well only when the satellites (i.e. thebeacons) are in line-of-sight to the receiver. Hence, to realise a precise lateration-based indoor localisation using available GPS receivers, a dense infrastructure ofbeacons, called GPS pseudolites needs to be deployed. Systems based on GPSpseudolites (e.g. Kee et al. 2001) allow for a precision of 0.01m and better. However,they require very carefully placed transmitters and an exact calibration, making widepublic deployment impractical and unfeasible for the time being.

2.2. Fingerprinting

Similarly, localisation systems based on Wi-Fi fingerprints, such as Bahl andPadmanabhan (2000), Cheng et al. (2005), collect the identities and signal strengthsof the Wi-Fi access points in the vicinity at various points in the covered area. Thiscalibration – war driving – is time consuming, and easily becomes invalidated whenphysical conditions change, e.g. the position of the access-points, the number of

2 J.A. Bitsch Link et al.24 J.Á. Bitsch Link et al.

Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

people in the vicinity or new office equipment, thereby requiring new measurementsto keep the database up to date. While efforts to reduce the required maintenance forfingerprints are promising, they still depend on exact propagation models and arerather labour-intensive to set up for specific environments. However, a systematicdrawback remains: there needs to be an adequate number of access points in thevicinity. This may be problematic in protected environments like historic buildings,archaeological sites or hospitals. Alternative approaches conduct fingerprintingbased on FM radio signals (Moghtadaiee et al. 2011) or ambient parameters such astemperature and light (Golding and Lesh 1999), able to reduce the infrastructurerequirements and costs to a minimum. While the achieved accuracy is similar toWi-Fi fingerprints, these systems still suffer from the measuring overhead to createand maintain the fingerprint database. In comparison, our approach neither dependson war driving nor on additional infrastructure. Our OpenStreetMap integrationmakes incremental deployment possible and painless.

2.3. Dead reckoning

Dead reckoning approaches (Gusenbauer et al. 2010) are based on detecting stepsand step-headings, integrating over them to estimate the current user position.Adaptive Kalman filters and activity-based map matching – e.g. resetting the userposition to the nearest elevator, if elevator like patterns are detected – improve theposition estimate. However, errors accumulate quickly. Our approach can reset theseerrors by matching the steps using sequence alignment. Thereby, it actually benefitsfrom turns, commonly found in indoor environments.

Constandache et al. (2010) estimate outdoor user location with smartphonesachieving a precision of up to 11m using only a compass, an accelerometer, and aGPS for the initial position. Detected steps are matched onto the currently closestpath derived from Google Maps, returning the best match as the user’s position.In the case of mismatch, a GPS resets the position. Our approach differs in that weneither need a GPS, nor are we restricted to outdoor navigation. Also, our pathmatching through sequence alignment algorithms (Section 3.3.2) is more robust byhandling source to destination routes in their entirety, instead of per segment.

The use of high-performance sensors mounted to the users body (e.g. to the waistor the foot) can significantly increase the accuracy of dead reckoning systems andeliminates the need of frequent re-calibrations (Goyal et al. 2011). However, weavoid the requirement for external and expensive hardware and compensate theerrors exploiting the knowledge about the users actual route she is expected to take.

3. System design

Figure 1 presents an overview of our system. We obtain map material fromOpenStreetMap. This allows easy updating and incremental deployment on a globalscale (Section 3.1). After the user selects her route, the accelerometer and compass ofthe user’s phone are used to detect steps and step-headings (Section 3.2). We thenmatch these steps onto the map using a first fit and a sequence-matching scheme(Section 3.3). Finally, we present the estimated position back to the user, together

Journal of Location Based Services 3 Journal of Location Based Services 25

Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

with turn-by-turn directions towards the destination. See Figure 13 for screen shotsof our current prototype.

3.1. Generating maps

OpenStreetMap (OpenStreetMap community 2011b) is not only an effort to createand distribute free geographic data, such as street maps, but also indoor maps ofpublic buildings, albeit indoor support is still rudimentary (OpenStreetMapcommunity 2011a). OpenStreetMap allows wiki-style editing, thereby enablingeveryone to contribute easily.

Map data from OpenStreetMap can be accessed as an XML structure consistingof nodes, ways, areas and relations, which can be annotated with arbitrary key valuepairs. Indoor nodes can be annotated using a combination of the followingkeywords:

. indoor^yes marks an object as being indoors.

. level^* designates the associated level or floor of an object.

. wheelchair^yes indicates accessibility by wheelchairs.

. highway^steps denotes steps with the additional keyword stepcount^*providing its length.

. highway^elevator labels elevators, connecting different floors.

. highway^door specifies a node to be a door. building=entrance as a specialcase denotes the entrance door to a building.

. name^* is used to give an object a common name.

The popularity of OpenStreetMap allows us to make use of a variety of tools –e.g. JOSM (Scholz and OpenStreetMap community 2011) – to create and extendmaps incrementally. The OpenStreetMap community has already mapped the

Figure 1. Flow of information during navigation. (1) The application obtains map materialfrom OSM. (2) The user selects her current position and her destination. The phone calculatesthe best route. (3) The mobile phone detects steps and directions. (4) The route is transformedinto expected steps. (5) The detected steps are mapped onto the expected steps. (6) The usergets feedback about her position and her next way-points.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

vicinity of our building in great detail, easing our task to integrate our indoor maps,which we derived from floor plans with outdoor footpaths and streets.

The existing maps from the vicinity help to align photographs of floorplans onwhich the map can be drawn on to. This can be done directly on the device whilewalking through a building, taking pictures of evacuation plans. We have improvedJOSM to work with several floors, by being able to select single floors and thencreate an entire building in a single file from top to bottom. This file can be uploadeddirectly to OpenStreetMap or locally on a device for offline navigation. Multiplebuildings can be split up into single files, which are later merged on the device. In thiscase a path is split up at a node, resulting in identical nodes with a commonmerge_id^* in each file. Currently, we are working on creating maps on the deviceand then automatically refining them with a custom plug-in in JOSM.

3.2. Step detection

Modern smartphones are typically equipped with an accelerometer and a compass.These sensors typically have a comparatively low accuracy, rendering them infeasiblefor direct use in path integration. However, they are well-suited for step detectionand step-heading estimation. The accelerometer values display a characteristicregular pattern during a step (Figure 2). Therefore, we can detect a step, by matchingthe values to a sharp drop in the acceleration, attributed to the jiggling of the phone

Figure 2. Step detection with FootPath. A step is detected if there is a difference of at leastp ¼ 2 m

s2on the low pass filtered z axis of the accelerometer. The difference has to occur during

a window w of 5 consecutive readings, or 165ms. After each detected step a timeout t¼ 333msis used to avoid false detection. The user can calibrate p and t to improve performance.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

in the hand of the user while she is balancing out her steps. To further improvedetection, we initially apply a low-pass filter.

Through preliminary experimentation, we found a set of parameters that leads toreasonable performance for all users: we detect a step whenever the accelerationvalue falls by at least p ¼ 2 m

s2within a window w of five consecutive samples or

165ms. Additionally, we define a timeout t¼ 333ms within which no new step isdetected. While this parameters lead to a reasonable performance for all users, p, tand the low-pass filter parameter l can be calibrated to further improve thestep-detection performance on a per user basis. We do not differentiate betweendifferent movement patterns such as walking, running and walking stairs.

Figure 3 shows an exemplary data set where a user first stands still for 2 s andthen starts walking, while holding her phone screen facing up in front of her in herhand. We repeated this experiment with 15 users and found the parameters to berobust against body heights and walking styles.

As soon as a step is detected, the phone also records the current azimuth from thecompass and passes the detected step and step-heading to the path matchingalgorithms. For a correct step-heading it is important for the user to hold the device,such that the left-right axis (x-axis) of the device is perpendicular to the walkingdirection. Minor deviations can be compensated by our algorithms.

3.3. Path matching

Upon detection of a step, we trigger path matching. We propose two strategies formatching the detected steps onto expected steps from a map: (1) First Fit and (2) Best

Figure 3. Exemplary accelerometer raw data and detected steps. The upper plot depicts theraw data recorded from the phone’s sensor, while a user first stands still for 2 s and then startswalking. The values display characteristic jiggling pattern. In the lower plot, we performstep-detection on the low pass filtered z-axis values.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

Fit (Figures 4 and 5). Both algorithms respond with a position on the route, which isin turn used for user feedback (Figure 13). In the following, we describe the pathmatching strategies.

Figure 4. Matching sequences of detected steps onto sequences of expected steps using FirstFit. We detect direction changes and find the next possible match in a look-ahead. We see thatS(5) does not match M(5) and is thus collected for further evaluation. The same happens withthe following detected step-headings S(6) to S(9). In this example, look-ahead matching mode istriggered after k¼ 4 consecutive unmatched steps and the new location is M(13) after stepS(9). The matching segment from steps S(5) to S(9) is located from M(9) to M(13). StepsS(11),S(12) are handled as errors and the algorithm resumes with direct matching mode.Steps S(18),S(19) still match to the previous edge, thus First Fit waits for the user to resumewith the next edge.

Figure 5. Matching sequences of detected steps onto sequences of expected steps using BestFit. We use sequence alignment to find the best match between the sequences. Unmatchedparts correspond to overestimated and underestimated step lengths.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

3.3.1. First Fit

This algorithm – similar to CompAcc (Constandache et al. 2010) – makes use of the

assumption that the user-detected step-heading corresponds directly to the direction

of the expected edge. Upon each detected step and step heading, we try to match this

heading to the direction of the current edge and move along this edge. If this is the

case, the algorithm is working in direct matching mode. If the step-heading and the

direction of the current edge do not match for k¼ 4 consecutive detected steps,

the algorithm switches to a look-ahead matching mode, to find a position further

ahead on the path.A heading �i and an edge direction �j are defined to be matching, if the angle

between them \(�i,�j)� 42�. In direct matching mode the position is moved along

the route by increments of the initial step length estimation l, with each directly

matching step.As we progress along an edge, there are two cases:

(1) The step length l was overestimated, and the real user position is not yet at

the end of this edge. This is due to the algorithm progressing faster along an

edge than the user does in reality. In this case the location is corrected by the

algorithm by waiting at the beginning of a new edge as long as the detected

headings match the previous edge, on which the user is still located. If step-

headings match the new edge, we continue with direct matching mode along

the new edge. If the step headings match neither the current edge nor the

previous edge after k¼ 4 consecutive steps, the algorithm switches into

look-ahead matching mode.(2) However, if the step length l was underestimated, we obtain values not

matching the current edge, because the user already walks into a different

direction. This can also occur if we have consecutive headings which do not

directly match the current edge, but remain in direct matching mode due to a

directly matching step after j� k steps. In this case, values corresponding to

the next edge are regarded as errors and the look-ahead matching mode

corrects the position to a location along the next edge.

If steps do not match the expected steps, they are collected for further processing

in look-ahead matching mode. If, within k steps, a matching heading �i is detected,direct matching operation resumes. However, if no such step-heading is detected, the

algorithm will try to find a maximum amount of at least k¼ 4 steps consecutively

matching to a segment on the path.We remain in look-ahead matching mode until we find a segment on the path

which matches to at least k¼ 4 consecutive steps of unmerited steps, going

backwards from the latest unmatched step-heading. If no such segment is found,

more steps are collected to repeat this process.A matching segment is found by finding the first edge along the path with

direction �j which matches the latest step-heading �i, then move the end of the

segment along this edge for all previous headings �<i which match this edge, and

then establish the start of the segment by matching more previous unmatched steps

backwards along the path to the edge directions �<j. The location returned by

this look-ahead is the end of the matching segment which matches the latest

unmatched steps.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

3.3.2. Best Fit

Inspired from sequence alignment algorithms (Wagner and Fischer 1974), widely

used in bioinformatics and related fields (Abbot and Tsay 2000, Barzilay and

Lee 2002, Prinzie and den Poel 2006), we model the matching of detected steps

onto expected steps extracted from a map as a string matching problem. The

matching process is formalised as a dynamic programming problem, where we

punish mismatches with a penalty. The best match is therefore the one with the

smallest penalty. Underestimated and overestimated step lengths are modelled

as gaps.We define M as an array of all step-headings M(i) : 1� i� jMj on the route

subdivided into virtual steps according to the information in the given map and the

expected average step length of the user. Then, we define S as the string of all

detected step-headings S( j) : 1� j� jSj.As discussed previously (Section 3.2), each step is associated with an azimuth.

Comparing the absolute azimuth of a detected step with the absolute azimuth of a

point on the expected route, we define a score depending on the angle between them.

The closer the two directions match, the smaller this value:

scoreð�,�Þ ¼

0:0 if \ð�,�Þ � 45�

1:0 if 45� 5\ð�,�Þ � 90�

2:0 if 90� 5\ð�,�Þ � 120�

10:0 else

8>>>>><>>>>>:

As an example, Figure 6 shows in a recurrence plot, how well-detected steps line

up with expected steps, using the raw data from an indoor experiments and Figure 7

depicts expected compass directions versus measured bearings on that path

(Section 4.2).Further following the dynamic programming approach, we define a matrix D,

with D(i, j)¼ di,j:1� i� jMj, 1� j� jSj. We initialise this matrix with D(0, 0)¼ 0,

D(i, 0)¼1 : 1� i� jMj, and D(0, j)¼1 : 1� j� jSj. The other elements are

calculated using the following construction:

Dði, j Þ ¼ minfDði� 1, j� 1Þ þ scoreðMðiÞ,Sð j ÞÞ,

Dði� 1, j Þ þ scoreðMðiÞ,Sð j� 1ÞÞ þ 1:5,

Dði, j� 1Þ þ scoreðMði� 1Þ,Sð j ÞÞ þ 1:5g

Figures 8 and 9 show a visual representation of this matrix in the background.

From this definition, we derive the expected position along the path – map step posj –

after j detected steps, using this formula:

posj ¼ argmini:1�i�jMj

ðDði, j ÞÞ

As we are only interested in the current location posj, the calculation of column

D(_, j) only depends on the previous column D(_, ( j� 1)). This makes the

implementation fast and very space efficient.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

4. Evaluation

We conducted three sets of experiments to show the feasibility of our approach: (1)an outdoor experiment on a nearby parking lot, in which we compare localisationaccuracy of First Fit and Best Fit to GPS and (2) an indoor experiment, in which

users use our system for navigating through our university buildings. This secondexperiment also includes staircases around elevators and doors, further showing the

robustness of FootPath. (3) To showcase the ease of map creation, we also createdindoor maps for a trade fair.

4.1. Step length error compensation

An outdoor experiment, to be able to compare with GPS data, was conducted with15 test users to demonstrate the functionality of FootPath. In the experiment, the

same device was used for each run. During the run the sensor data, as well as theGPS location was traced. An exemplary visualisation can be seen in Figures 10and 11. Our results show that our estimate of the step length from the body height is

not very accurate. Still, FootPath is able to reset the location if it finds a better matchof the user’s position. The average accuracy of a detected step, defined as the distance

Figure 6. Recurrence plot of detected steps and expected steps. The darker parts signifyregions where the alignment between the detected real step and the expected step from the mapis very close. The lighter regions denote regions, where such an alignment is not possible. Theline with the markers from the upper left corner, to the lower right corner, represents the bestoverall matching for this particular run.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

to the Best Fit Traceback, are 11.16m for First Fit and 8.90m for Best Fit in our 15test runs.

Considering First Fit, we see that if the directions cannot be matched along thepath directly, due to a varying and/or incorrect initial step size, it jumps ahead afterfinding at least four matching steps along the path. If the step size is too large, it willwait for the user to catch up and continue when the user changes the directionaccording to the path.

A problem is that this can lead to erroneous progress along the path if there arefaulty directions read which match to the path. At this point, we have to consider thetrade-off to detect the correct position during the look-ahead phase and the amountof steps we have to wait to obtain a new position.

In comparison, Best Fit matches each direction onto the path to where itreceived the smallest penalty. Thus, it is possible that Best Fit lags behind on anedge if the assumed step length is smaller than the real one. It will respond tovalues which correspond to the following edge with locations further along thesame edge, or remain at the same position. As soon as the penalty for a locationahead on the path becomes smaller, it will jump ahead. If the directions matchbetter to a previous position on the path, it will fall back and continue fromthere.

Figure 7. Visualisation of the compass direction of the path and the measured compassbearing along the path. Despite the flawed step-heading we can see the resemblance of bothgraphs. This is exploited by both First Fit and Best Fit. The two consecutive staircases goingaround an elevator can be seen starting at about 150m to 180m, with the expected anddetected compass values moving clockwise.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

4.2. Noise compensation

A typical indoor path contains magnetic disturbances, possibly from heating

equipment or elevators, as well as many turns. Compensating these errors is

particularly difficult for dead reckoning approaches, especially without the presence

of gyroscopes. To evaluate the performance of our algorithms for indoor

environments, we selected such a challenging path containing staircases, several

Figure 9. Left-hand side: Displayed are the detected steps and their matched position on thepath. Right-hand side: The absolute differences of our matching algorithms to the Best FitTraceback match. The average location error for Best Fit is 1.6 and 5.6m for First Fit.

Figure 8. Left-hand side: Displayed are the detected steps and their matched position on thepath. Best Fit and First Fit are our matching algorithms. Best Fit Traceback is the best tracerun on the matrix D (Section 3.3.2), which is visualised in the background. Right-hand side:The absolute differences of our matching algorithms to the Best Fit Traceback match.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

doors and metal structures to have a distribution of error sources along the path.For example, a user will have to abandon walking directly along the path whenopening doors. We chose such a route to compare the design of our matching

Figure 11. The distribution of detected locations along the path for each run. We see stepsmatched consecutively as segments forming a horizontal connected line along the graph. Eachsquare is a step. Red slightly elevated squares depict segments starting with a backwards jumpusing Best Fit. We see each algorithm jumping forwards along the path from the gaps betweentwo segments. First Fit does this with the use of a look-ahead, and Best Fit by choosing theposition with the smallest penalty. The compass failed during run 1, and during run 14the application was accidentally closed.

Figure 10. During the experiment each of the 15 users walked along a predefined path.In both figures we see the detected steps and their position corresponding to the matchingalgorithms. GPS was tracked for comparison and is displayed in both figures.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

algorithms and show that our proposition of providing an accurate indoornavigation system is justified.

Looking at the distribution of the estimated locations for Best Fit and First Fit(Figure 12), we see that Best Fit deals better with inaccuracies compared to First Fit.The latter algorithm looses accuracy, especially around the elevator, as the metalstructures found in this staircase disturb the compass. Here, the detected compassvalues are considered as noise as the compass values change rapidly within few steps,whilst walking around the elevator in the centre of the staircase.

In Figure 12 we can see how First Fit uses the look-ahead matching mode toreestablish a location around corners of the path. This works as intended, as cornersare anchor points which produce distinguishable compass headings which aredetectable by both algorithms. With more corners, i.e. with a more complex routethrough an environment, our algorithms have a higher accuracy, as there are morepoints to reset location errors. Still, narrow staircases around metal structures pose aproblem to First Fit, as the changes in the compass directions happen too fast andare considered noise. This leads to fewer established locations during navigation.

In this experiment, we have an average accuracy of 1.6m for Best Fit and 5.6mfor First Fit. Due to the design of Best Fit, which consists of constantly updating thepenalty for each location along the path, this algorithm performs better and morestable than First Fit. The impact of noisy compass values is tolerated and consideredagainst all positions along the whole route. Thus, this algorithm can recover a

Figure 12. In this experiment, the user had to navigate our university building using FootPath.We chose the path to pass by two staircases and several doors to show the robustness of ourapproach. While both First Fit and Best Fit work reasonably well, Best Fit deals withinaccuracies inherently arising in human mobility more robustly. For both algorithms thecalculated positions are plotted along the path.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

location estimate after noisy compass headings, where First Fit would regard thesenoisy compass values as errors, and would not use these later along the path.Walking around the elevator produces more distinctive penalties, and thus a higheraccuracy (Figures 6 and 9).

4.3. Instant deployability

To support our claim of easy incremental deployability of FootPath, we looked intopossible use cases. While public buildings, such as universities, malls, airports andhospitals, are obvious use cases for indoor navigation, we also consider trade fairsand conference venues. Visitors attend these venues typically without extensive pre-knowledge about the locality in cities they are unfamiliar with. Also, the exact setupbetween specific trade shows changes, even when they take place at the sameexhibition centre, making easy and fast deployability all the more important.

As a proof of concept, we created a map for a trade fair in a nearby city(Figure 13), and a demo for the International Conference on Indoor Positioning andIndoor Navigation, in Guimaraes, Portugal. The trade fair organiser providedreference floor plans covering over 20,000m2 on his website. With those plansavailable, it took a single person less then two hours to enter the plan intoOpenStreetMap, including the necessary labels by which users can look for anexhibitor. User experience was good, but we were not able to run repeatedexperiments for logistical reasons. Therefore, we have only isolated measurements(not shown).

The demonstration at the IPIN conference consisted of navigating along a loop inthe conference hall. As the map was created before visiting the venue, we did notconsider sofas and booths obstructing this path. Additionally, many conferenceattendants in the conference hall further disturbed the demonstration. Still, the userswere able to successfully navigate along the predefined path. We were given muchpositive feedback on the quality of our system, and recommendations on how tofurther improve our algorithms.

As this anecdotal evidence suggests, we provide a system which is ready to bedeployed fast, not depending on additional infrastructure. Collabouratively workingon map creation can further scale this process such that we obtain a fast deploymentfor even larger or complex environments.

5. Discussion

The previous results show that FootPath performs accurate enough to help the userfind her way in indoor environments. The closest related approach, CompAcc,depends heavily on GPS for resynchronisation and it is difficult to create indoormaps for use with it.

PDR, on the other hand, also works without the use of GPS, but depends onescalators or elevators to reset an erroneous position. Dead Reckoning also suffersfrom high sensitivity with respect to compass inaccuracies and step length variations,which are very common in indoor navigation. Although you can achieve highaccuracies with state-of-the-art sensors, at the time of writing, the cost factor for


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

such a sensor lies several times above the cost of a low-budged smartphone or tabletPC running an Android OS.

We summarise these characterisations in Table 1 with respect to the aspects ofindoor deployability, outdoor deployability, the need for additional infrastructure,initial setup or maintenance, and how they reset errors and the source of themap data.

Comparing FootPath to the other localisation systems (Section 2), like GPSPseudolites, Wi-Fi fingerprinting and Google Maps, we see that they either dependon war-driving or significant calibration effort. Furthermore, their dependency onadditional infrastructure can limit their area of applicability.

Figure 13. We created a map to navigate in an indoor environment consisting of twotrade fair halls at an exhibition centre covering 20,000m2. The process of aligning referencepictures, drawing the paths and labelling nodes to be selected by the user, took less than twohours.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

Table

1.

Comparison.ofFootPath

withitsclosest

relatedwork.

Feature

FootPath

CompAcc

PDR

GPS

Pseudolites

Wi-FiF.print.

Google

maps

Indoor

3�

3�

33

3(G

PSneeded)

(norouting)

Outdoor

33

33

�3

3(G

PSavailable)

Noinfrastructure

3�

3�

��

�(G

PSneeded)

(Wi-Fi/GSM/G

PS)

Noinitialsetup

33

3�

��

�(C

alibration)

(War-driving)

(War-driving)

Nomaintenance

33

3�

��

�(C

alibration)

(War-driving)

Errorresetting

33

3�

��

�(R

oute)

(Route,GPS)

(Elevators,stairs)

Mapbasis

3�

��

��

�(O

penStreetM

ap)

(Proprietary)

(Proprietary)

(Proprietary)

(Proprietary)

(Proprietary)

(Proprietary)


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

For instance, in hospitals, the use of mobile wireless equipment is oftenforbidden, as it might interfere with medical equipment. The prohibitive cost of GPSpseudolites in terms of equipment and calibration also make them feasible only forvery specific use cases. FootPath, on the other hand, can be easily deployed campuswide, in hospitals or on archaeological sites, where additional hardware may bedamaging.

To the best of our knowledge, none of the discussed approaches properly addressthe task of creating indoor maps in a generic way, to be used in any way as in ourapproach. Making use of OpenStreetMap and its associated tools allowed us tocreate maps over the course of 2 h for a complete trade fair, making FootPath almostinstantly deployable. Rapid changes in the environment, for example a trade fairchanging the floor layouts on a weekly basis are not a problem, as the changingenvironment can be quickly incorporated with the distribution of a map update.

We implemented our system designed for infrastructureless indoor navigation asan Android application with the source code available at https://github.com/COMSYS/FootPath. Android is one of the most popular mobile phone operatingsystems and allows easy prototyping, while the devices typically feature all sensorsneeded for our algorithms. Figure 14 shows screenshots of our prototype. However,porting FootPath to other operating systems running on mobile devices, such as theiPhone running iOS or other devices running Windows Phone, is easily possible.

5.1. Future work

Deviating from the route currently leads to undefined behaviour. We are currentlyworking to lift this restriction by matching to multiple paths concurrently.The position with the highest probability is used for navigational instructions.However, other positions are still considered and we can switch opportunistically toa different one.

Automatically learning the average step length, or model the different steplengths around corners and on stairs would further improve the accuracy. Also,integrating other localisation methods will further enhance robustness of ourapproach. While we do not want to depend on the presence of Wi-Fi beacons orGSM beacons for the reasons mentioned above, we can benefit from them, if they areavailable. We expect that integrating them into our scoring function in Section 3.3.2will boost the accuracy further.

To further improve the availability of indoor maps, we are building moresupporting tools for their creation and maintenance. This not only includes anIndoor Plugin for JOSM, but also mechanisms for creating maps directly on thedevice.

6. Conclusions

We presented FootPath, a self-contained, map-based indoor navigation system anddemonstrated its feasibility in terms of indoor localisation accuracy and incrementalglobal deployability. We demonstrated this in three experiments: an outdoorexperiment to measure accuracy, an indoor run to show robustness against typicalindoor hazards and a trade fair scenario.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

Figure 14. Screen shots of the calibration screen and during navigation. While calibrationparameters allow to tune step detection parameters, path matching itself is robust enough,even without tweaking. The current Android prototype during navigation displays back-ground tiles from OpenStreetMap with an overlay of the calculated path and the user position.In addition we show internal status information, like the exact measured bearing, and thecurrently assumed bearing.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

Furthermore, we showed the feasibility of sequence alignment for localisation on

a route in our Best Fit algorithm. This scheme is easy to implement and has only

minimal memory requirements, making it appropriate for smart phones and other

highly embedded devices.

References

Abbot, A. and Tsay, A., 2000. Sequence analysis and optimal matching methods in sociology.

Sociological Methods & Research, 29 (1), 3–33.Bahl, P. and Padmanabhan, V.N., 2000. RADAR: an in-building RF-based user location and

tracking system. In: Proceedings. IEEE, INFOCOM 2000. Nineteenth annual joint

conference of the IEEE computer and communications societies, Vol. 2. Tel Aviv, Israel:

IEEE, 775–784.Barzilay, R. and Lee, L., 2002. Bootstrapping lexical choice via multiple-sequence alignment.

In: Proceedings of the ACL-02 conference on empirical methods in natural language

processing, EMNLP ’02, Vol. 10. Philadelphia, PA, USA: Association for

Computational Linguistics, 164–171. Available from: http://dx.doi.org/10.3115/

1118693.1118715 [Accessed 29 May 2012].Bitsch Link, J.A., et al., 2011. FootPath: accurate map-based indoor navigation using

smartphones. In: 2011 international conference on Indoor Positioning and Indoor

Navigation (IPIN), Guimarses, Portugal.Cheng, Y., et al., 2005. Accuracy characterization for metropolitan-scale Wi-Fi localisation.

In: Proceedings of the 3rd international conference on mobile systems, applications, and

services, MobiSys ’05. Seattle, WA, USA: ACM, 233–245. Available from: http://

portal.acm.org/citation.cfm?id=1067195 [Accessed 29 May 2012].

Constandache, I., Choudhury, R.R. and Rhee, I., 2010. Towards mobile phone localisation

without war-driving. In: Proceedings IEEE, INFOCOM, 2010, San Diego, CA, USA,

1–9. Available from: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber¼5462058

[Accessed 29 May 2012].Golding, A.R. and Lesh, N., 1999. Indoor navigation using a diverse set of cheap, wearable

sensors. In: The third international symposium on wearable computers, 1999. Digest of

Papers. White Plains, NY, USA: IEEE, 29–36.Goyal, P., et al., 2011. Strap-down pedestrian dead-reckoning system. In: 2011 international

conference on Indoor Positioning and Indoor Navigation (IPIN), September 2011,

Guimarses, Portugal, 1–7.

Gusenbauer, D., Isert, C. and Krosche, J., 2010. Self-contained indoor positioning on off-

the-shelf mobile devices. In: 2010 international conference on Indoor Positioning

and Indoor Navigation (IPIN), Zurich, Switzerland,1–9. Available from: http://

ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber¼5646681 [Accessed 29 May 2012].Kee, C., et al., 2001. Centimeter-accuracy indoor navigation using GPS-like pseudolites. GPS

WORLD, 12 (11), 14–23.Moghtadaiee, V., Dempster, A. and Lim, S., 2011. Indoor localization using FM radio signals:

a fingerprinting approach. In: 2011 international conference on Indoor Positioning and

Indoor Navigation (IPIN), September 2011, Guimarses, Portugal, 1–7.OpenStreetMap community. Indoor Mapping – OpenStreetMap Wiki, March 2011a. Available

from: http://wiki.openstreetmap.org/wiki/Indoor_Mapping [Accessed 29 May 2012].

OpenStreetMap community. OpenStreetMap, The Free Wiki World Map, March 2011b.

Available from: http://www.openstreetmap.org/ [Accessed 29 May 2012].


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

Prinzie, A. and den Poel, D.V., 2006. Incorporating sequential information into traditionalclassification models by using an element/position-sensitive sam. Decision SupportSystems, 42 (2), 508–526.

Scholz, I. and OpenStreetMap community. 2011. Java OpenStreetMap Editor, March 2011.

Available from: http://josm.openstreetmap.de/ [Accessed 29 May 2012].Wagner, R.A. and Fischer, M.J., 1974. The string-to-string correction problem. Journal of the

ACM, 21, 168–173.


Dow

nloa

ded

by [

Nor

th D

akot

a St

ate

Uni

vers

ity]

at 1

7:34

07

Dec

embe

r 20

14

Documents

Accurate map-based indoor navigation on the mobile