D3.4: A Pedestrian Position Tracker - SpaceBook … Status & version ... A Pedestrian Position Tracker Prototype ... Satellite System (GNSS) is the USA’s Global Positioning System

D3.4: A Pedestrian Position Tracker

Phil Bartie, William Mackaness

Distribution: Public

SPACEBOOK

Spatial & Personal Adaptive Communication Environment:

Behaviours & Objects & Operations & Knowledge

Deliverable 3.4

31 January 2012

Project ref. no. Project acronym Project full title Instrument Thematic Start date / duration

270019 SPACEBOOK Spatial & Personal Adaptive Communication Environment: Behaviours & Objects & Operations & Knowledge STREP Priority Cognitive Systems, Interaction, and Robotics 01 March 2011 / 36 Months

Security Contractual date of delivery Actual date of delivery Deliverable number Deliverable title Type Status & version Number of pages Contributing WP WP/Task responsible Other contributors Author(s) EC Project Officer Keywords

Public M10 = 15 January 2012 31 January 2012 3.4 A Pedestrian Position Tracker Prototype Final 1.0 28 (excluding front matter) 3 UE Phil Bartie, William Mackaness Franco Mastroddi Position, Location, Orientation, GNSS, GPS, Glonass, , Transport mode, Accelerometer, Sensors, Pedestrian

The partners in SPACEBOOK are:

Umea University UMU

University of Edinburgh HCRC UE

Heriot-Watt University HWU

Kungliga Tekniska Hogskola KTH

Liquid Media AB LM

University of Cambridge UCAM

Universitat Pompeu Fabra UP

For copies of reports, updates on project activities and other SPACEBOOK-related information, contact:

The SPACEBOOK Project Co-ordinator:

Dr. Michael Minock

Department of Computer Science

Umea University ˚

Sweden 90187

[email protected]

Phone +46 70 597 2585 - Fax +46 90 786 6126

Copies of reports and other material can also be accessed via the project’s administration homepage,

http://www.SPACEBOOK-project.eu

© 2012, The Individual Authors.

No part of this document may be reproduced or transmitted in any form, or by any means, electronic or mechanical, including photocopy,

recording, or any information storage and retrieval system, without permission from the copyright owner.

mailto:[email protected]

Contents

1. Overview ......................................................................................................................................... 2

2. Positioning Solutions ....................................................................................................................... 2

2.1. Global Positioning Technologies ............................................................................................. 2

2.2. Inertial Measurement Units .................................................................................................... 4

2.3. Local Positioning Technologies ............................................................................................... 4

3. Solutions used in SPACEBOOK Pedestrian Tracker ............................................................................ 6

4. The Advantages of Using GPS + GLONASS .................................................................................... 12

4.1. Position Error Reporting ....................................................................................................... 13

5. Map matching ............................................................................................................................... 15

5.1. Position Correction Process: ................................................................................................. 17

5.2. Determining the Most Likely Road Centreline: ..................................................................... 17

6. On-board Sensors ......................................................................................................................... 18

7. Examples ....................................................................................................................................... 20

7.1. Temporal lag ......................................................................................................................... 22

7.2. Carrying position of the Smartphone .................................................................................... 23

8. Pedestrian Tracker Inputs / Outputs ............................................................................................. 25

8.1. Data inputs from Phone Server ............................................................................................. 25

8.2. Data input/output to the Interaction Manager .................................................................... 26

8.3. Connection to the City Model ............................................................................................... 26

9. Future Research Directions ........................................................................................................... 26

10. Conclusion ................................................................................................................................. 27

11. References ................................................................................................................................ 27

270019 SpaceBook D3.4 Pedestrian Position Tracker 2012 Page 1/ 28

Executive Summary

Location Based Services (LBS) require an ability to automatically track the user’s position. This can be

provided in a number of ways, with varying degrees of fidelity and restriction. The chosen platform

for SPACEBOOK is the smartphone, and these support three location methods which are cell tower,

WiFi, and satellite based positioning. While cell tower and WiFi based methods operate both indoors

and outdoors, they offer only low resolution positioning. Satellite based positioning is able to track

the user at street level, but is restricted to outdoor locations. The best known Global Navigation

Satellite System (GNSS) is the USA’s Global Positioning System (GPS), however the Russian GLONASS

system was fully restored to become an operational alternative in October 2011. In this paper we

present the findings from a comparison of a smartphone equipped with both GLONASS and GPS,

versus just GPS. In addition we look at how map matching can be used to assist in position

corrections, and how the smartphone’s sensors (e.g. accelerometer) provide useful additional inputs

to position determination. Finally the paper outlines the protocol for using the pedestrian tracker

module within the SPACEBOOK system, which performs the task of correcting position input.


1. Overview

SPACEBOOK is a location-based services (LBS) designed for use in urban areas, a primary requirement

is an ability to automatically capture the user’s position. There are a number of automated

positioning methods available, but many do not offer the fidelity required to fulfil SPACEBOOK’S

ambitions. This paper, which accompanies the D3.4 prototype, gives a summary of the positioning

challenge in urban areas, the background to the positioning solutions considered for use in

SPACEBOOK, and the methods which have been implemented in the prototype.

The paper begins with a background overview of suitable positioning solutions, before explaining

in greater detail the implemented solutions for D3.4. The paper concludes with a number of

proposed future research directions, which may be introduced in revisions of the pedestrian tracker

module at a later stage.

2. Positioning Solutions

An LBS should be able to automatically locate the user so that continuously relevant location

information may be retrieved and presented. There are many techniques for doing this, some suit

indoor controlled environments, such as museums and art galleries (Grinter et al. 2002) others are

more appropriate for outdoor expanses, such as a Global Navigation Satellite System (GNSS) of which

Global Positioning System (GPS) is the best known.

The value of precise and accurate tracking of pedestrians in indoor and outdoor environments is well

understood. Though the focus has built around car navigation systems, there is a growing field of

research in providing services to pedestrians that depend on precise knowledge of their

whereabouts (Retscher and Thienelt 2004). The focus for SpaceBook is on outdoor pedestrian

spaces, though in both indoor and outdoor environments additional sensors are often fused with

GPS in order to support robust and precise navigation system (Bullock 2006).

Here we examine the technologies most suited to urban pedestrian positioning.

2.1. Global Positioning Technologies

GPS is the most common global positioning technology, able to calculate a three dimensional

location wherever the satellite’s signals can be detected. Although GPS has proved successful in

vehicle navigation devices it has a number of shortcomings when used in pedestrian LBS.

GPS has an ‘Achilles heel’ (Raper et al. 2007) struggling to operate in ‘urban canyons’ where the

direct lines of sight to the GPS satellites are occluded, and signals reach the receiver after being

reflected from nearby surfaces, known as multipath signals. The situation is often worse for

pedestrians positioned on the pavement, close to tall buildings, as satellites are occluded to a greater

extent than for motorists positioned near the centre of the street (Figure 1).


Figure 1: View of Sky (angle in degrees) based on Proximity to Buildings

In a vehicle the GPS antennae is mounted with a clear view of the sky, however pedestrian LBS

devices are more likely to be stored in bags or pockets, potentially with the antennae pointing

towards the ground, resulting in signal deterioration or loss. Furthermore the low power of satellite

signals restricts the use of GPS inside buildings, and there can be significant latency between exiting

a building and regaining a position fix. Poor positioning as a result of attenuated or multipath GPS

signals, from a reduced number of visible satellites, leads to a poor user experience. Also GPS does

not provide the means to calculate a user’s heading other than by monitoring position changes over

time. This is adequate for vehicles which require forward or reverse motion to change direction, but

not for monitoring pedestrians able to turn on the spot. For these reasons additional services and

sensors are required to improve the tracking solutions available for pedestrian LBS.

There are several strategies to improve GPS performance, of which the most successful solution

currently implemented is Assisted-GPS (A-GPS) (Cho 2004). This adds a networked service to provide

the mobile client with supporting information including relevant satellite orbital data, ionospheric

conditions, and assistance in matching fragments of GPS signal received. The benefits are a decrease

in the time taken to calculate a location, and the ability to decode weaker signals. For pedestrian LBS

this means a more robust solution, with reduced delays in gaining a location fix upon exiting

buildings.

The latest generation of High Sensitivity GPS devices are able to resolve locations in urban

canyons and, albeit at low resolution, inside some buildings (Lachapelle 2004). Additionally as new

GNSSs become available (e.g. GLONASS, Galileo) the increase in satellite numbers and improved

signal robustness regarding multipath (Fantino et al. 2008) enables higher location accuracy in the

urban environment. Such innovations allow pedestrian LBS to track the user’s movements through

an increased diversity of urban environments, and also minimise system latency.


2.2. Inertial Measurement Units

Position robustness may be improved by supplementing GNSS solutions with extra sensors

known as Inertial Measurement Units (IMUs), able to supply relative motion changes. These can be

placed on the user’s foot to exploit human walking kinematics and therefore to estimate the user’s

position (Radoczky 2007) in between GNSS updates. An IMU incorporates a number of sensors which

record movement direction and magnitude, including a combination of accelerometers able to

measure movement forces in 3 dimensions, gyroscopes able to track direction changes, and

barometers to measure elevation changes, which is particularly useful inside buildings for floor level

estimation. Magnetometers, which record the direction and strength of magnetic fields for tracking

the user’s orientation (Hightower et al. 2005), are unfortunately often unreliable in urban

environments due to magnetic disturbances around the city, such as vehicles, steel building

structures, and electronic devices.

IMUs are able to assist GPS in challenging environments (e.g. indoors, urban canyons) but

without GPS updates the positional errors accumulate over time and positional drift occurs. The rate

of this drift varies depending on the quality of the sensors in the IMU, but can be improved by

monitoring the user’s steps and performing zero velocity updates. These are when the IMU is known

to be static as the user’s foot is placed on the ground, and therefore the sensors may be re-

calibrated (Mezentsev et al. 2005). The GPS and IMU sensor inputs are integrated into a single best

estimate of location using a Kalman filter (Yang et al. 2008).

The most promising trials supporting pedestrian exploration have combined GNSS with an IMU

(Godha et al. 2005, Ott et al. 2005). Despite these augmentations location accuracy cannot be

maintained for long periods of time when the GNSS signal is weak (e.g. indoors).

The SPACEBOOK project has an ambition of wanting to base the tracking on smartphones alone,

without the need fit the user with additional hardware, and for this reason separate IMU devices are

not considered further. However in our research we have successfully used the phone’s internal

sensors (eg accelerometer) to improve the accuracy of the GPS positioning (Section 6).

2.3. Local Positioning Technologies

Terrestrial radio waves fill urban environments. Robust Surface Navigation (RNS) (Hodge 2007)

relies on using these ‘signals of opportunity’ to calculate the user’s location. Signals suitable for this

include FM Radio (Krumm et al. 2003), AM signals (McEllroy et al. 2007), cellular phone network

signals (Zhou et al. 2005, Chen et al. 2006) and other shorter range signals such as Wi-Fi (Hightower

et al. 2005).

Many of these techniques are in their infancy, but a few are suitable for further investigation.

Coarse positioning using the mobile cellular network works both indoors and outside, and is very

fast, as exemplified by the ‘My Location’ feature of Google’s Mobile Maps application. The technique

works by requesting the current cell mast identification number, and retrieving the corresponding

latitude and longitude for that mast from a central networked database (Ji and Jain 2008). If the

mobile phone also has a GNSS facility the solution will be refined when a more accurate position can

be resolved, and these data will be sent back to enhance the database of cell tower signal


boundaries. This database is not freely available, although there are a number of community projects

collating cell mast locations, such as Navizon (Navizon 2008), Yahoo’s FireEagle(Yahoo 2008), and

OpenCellID (8Motions 2008).

To more accurately position a user the dense network of Wi-Fi base stations found in cities

provides a useful alternative to cell masts. Wi-Fi equipped mobile platforms permit developers to

access signal strength information from all the surrounding access points, meaning position

triangulation is possible. Trials have shown that a median location accuracy of 30m can be achieved

in urban areas (LaMarca et al. 2005). This method requires a database of the physical locations of

each Wi-Fi base station with its corresponding unique Media Access Control (MAC) address. There

are a number of open source databases, maintained by community volunteers, which hold this

information, such as Placelab (LaMarca et al. 2005). However Wi-Fi signals may only cover a small

proportion of the city, and as the base stations are not controlled by a single operator any unit may

be moved or turned off without prior notice. A number of commercial companies offer applications

which combine the location benefits from cell tower, Wi-Fi and GPS positioning solutions, such as

Skyhook (Skyhook 2008).

Even greater positional accuracy is possible using scene-analysis methods, whereby the user

captures an image of the surrounding environment using a mobile phone camera, then sends the

image to a server which geometrically straightens it for comparison against a database of images

from known locations. Typically the key points identified in each image include corners of window

frames or doors, which change infrequently. The result is that the user’s orientation and location can

be calculated, usually to within one metre (Randerson 2004). However this technique requires

considerable computational power on the server side and frequent image database updates. A

manual equivalent exists whereby the user specifies which landmarks are visible, and the mobile

device calculates the possible locations that they may be (Kray and Kortuem 2004). There are a

couple of negative aspects to both of these methods, which are the system latency renders the

techniques unsuitable for continuous tracking, and there is an associated cost in the upkeep of

reference image material.

This tracking issue is also of interest in robotics research, referred to by the acronym SLAM which

means Simultaneous Localisation and Mapping. Until recently expensive sensor arrays which

included laser and IMUs were required to track robot movements over great distances, but new

research has shown that a single digital camera can be used to perform localisation over a 2.5km

walk (Botterill et al. 2010). Developments such as these should lead to sustained sub-meter accurate

positioning for LBS in urban environments in the near future.

SPACEBOOK intentionally does not use scene-analysis, as the ambition is a hands-free, eyes-free

platform based on a smartphone, where all interaction is by means of dialogue interaction, and there

is no need for the user to be equipped with additional sensors (eg head/body mounted camera).


3. Solutions used in SPACEBOOK Pedestrian Tracker

The solution implemented in the SPACEBOOK pedestrian tracker is based on GNSS and the inbuilt

phone sensors. GNSS offers an existing global, free to use, positioning solution which does not

require additional local data to be collected (eg street images for computer vision techniques) or the

region to be prepared or surveyed (eg signals of opportunity).

GNSS does exhibit certain issues which SPACEBOOK need to address. Position accuracy varies with date

and time as a result of the satellite orbits, and location as a result of street orientation, topography,

and building profiles. The following set of figures were produced using Trimble’s Planning tool, and

show the predicted number of satellites over Edinburgh for Monday 30th January 2012, throughout

the day at 15 minute time intervals.

Figure 2: Predicted Visibility of GPS satellites over a 24hr Period for Edinburgh, 30 Jan 2012

The current constellation of satellite vehicles (SV) in view from this location at any time determine

the potential position solution, and therefore location accuracy. The following graph shows the

expected change in the Dilution of Precision (DOP) over the course of a day (Mon 31 Jan, 2012) for a

GPS receiver in Edinburgh. DOP values range from 1 (ideal) to 50 (poor), and their transformation

into an error value in metres is device specific. However anything around values 2-3 are considered

excellent, values under 3-5 are good, while anything greater than 20 is considered unusable. The

higher DOP values around midday (Figure 3) indicate that the position solutions would be expected

to be worse, than those in the mid-afternoon to early evening.


Figure 3: Predicted Dilution of Precision GPS satellites over a 24hr Period for Edinburgh, 30 Jan 2012

These DOP values are the result of both the number of satellites available and their geometric

arrangement. If all the satellites visible are in a similar part of the sky then the triangulation

calculations are more susceptible to error, resulting in a poorer position solution. Figure 4 shows the

positions in the sky occupied by each SV during the 24hour period from midnight on the 30 January

2012 to midnight on 31 January 2012.

Figure 4: Satellite Paths in the Sky above Edinburgh over 24hrs for 30 Jan 2012

Here we see that the majority of satellite paths occur to the south, west and east, with very minimal

coverage towards the north. These data presume that the receiver has a clear view of the sky in all


directions, and do not consider sky occlusion as a result of urban form. When combined with the

occlusion introduced from urban canyons this can lead to a drastic restriction in the number of SVs in

view and a poorer geometric distribution, resulting in a lower positional accuracy. It is possible to

model this by introducing a sky occlusion mask. Figure 5 shows the situation for an imagined narrow

street which runs North-South, where the tall buildings to the side restrict the user’s view of the sky.

The blue region denotes the clear sky, while the grey regions mark where the user’s view is blocked

by buildings. In this example the view of the sky is 34% occluded by the buildings.

Figure 5: Modelling with an Urban Canyon Sky Occlusion (34% of sky occluded)

A comparison of the output from Figure 4 to that shown in Figure 6 reveals a trend of reduced

satellite visibility and a resulting poorer available constellation geometry.

Figure 6: Satellite Paths in the Sky above Edinburgh over 24hrs for 30 Jan 2012,

including the modelling of Urban Canyon Occlusion


One solution to this issue is to use a receiver which can access additional GNSSs, such as the now

fully operational Russian GLONASS solution (since October 2011). There are currently only a few

smartphones1 which can access this in addition to GPS, including the Apple iPhone4s (Apple iOS),

Samsung Omnia 7 (Windows OS), Samsung Galaxy Note (Android OS). The increase in the number of

SVs available by adding the Russion GLONASS positioning solution. This adds an additional 24 SVs,

and introduces a range of different SV orbits which pass further north, as GLONASS is optimised for

the northern hemisphere. Figure 7 shows the sky plot for the same location (Edinburgh), over the

same time period (30 Jan 2012). It is clear that here the coverage in the north part of the sky is now

fuller, as well as the greater number of SVs to the South, East and West.

Figure 7: GPS and GLONASS Satellite Paths over 24hr period– Edinburgh 30 Jan 2012 (clear sky view)

As a result the total number of SVs visible at any one time increases (Figure 8) and the DOP

decreases from a peak of 5.27 (Figure 3) to a value of 3.00 (Figure 9).

1 Qualcomm Snapdragon S2 and S3 equipped phones have the necessary hardware to receive GLONASS, if later firmware updates enables

the hardware. See http://www.qualcomm.com/media/blog/2011/12/15/gps-and-glonass-dual-core-location-your-phone

http://www.qualcomm.com/media/blog/2011/12/15/gps-and-glonass-dual-core-location-your-phone


Figure 8: Predicted Visibility of GPS + GLONASS satellites over a 24hr Period

for Edinburgh, 30 Jan 2012

Figure 9: Predicted Dilution of Precision GPS + GLONASS satellites

over a 24hr Period for Edinburgh, 30 Jan 2012

It should be noted that the SVs are not geosynchronous, therefore this pattern is not in sync with the

Earth orbit, and the number of SVs and DOP values for the same location will vary each day. In other

words we would not expect the same DOP to exist at the same time of day for a given location. As an

example the Figure 10 shows the GPS+GLONASS DOP for the same location in Edinburgh on 31 Jan

2012, and can be directly compared to Figure 9 noticing not only the different daily pattern of peaks,

but also the change in the vertical scale (from max of 3.00 to max of 2.05).


Figure 10: Predicted Dilution of Precision GPS + GLONASS satellites over a 24hr Period

for Edinburgh, 31 Jan 2012

However as before these figures (6-10) present the predicated results where the receiver has a clear

sky view, without any consideration for urban canyons. Using the same obscuring template as in

Figure 5, the following DOP graph indicates the impact that urban canyons have on GNSS positional

accuracy. Notice now that there are many occasions during the 24 hour period where the DOP is very

poor, extending beyond to a value of 20.

Figure 11: Predicted Dilution of Precision GPS + GLONASS satellites over a 24hr Period for Edinburgh, 30 Jan 2012, including the modelling of Urban Canyon Occlusion

When carrying out survey quality mapping these planning tools are used to determine the optimum

time to collect ground data, based on the SV configuration. However for an LBS which may be used

at any time, the location solution will vary and the system needs to accommodate these errors and

variations.


4. The Advantages of Using GPS + GLONASS

The following section compares the performance of the data collected simultaneously by an HTC

Sensation (GPS only) and Samsung Galaxy Note (GPS+GLONASS), in a narrow street. It takes a short

while for the devices to obtain their initial position fix, but as can be seen in Figure 12 the GLONASS

enabled receiver is able to lock on significantly faster than the GPS only device, due to the increase

number of SVs. The GPS track incorrectly extends on to the far side of the road at the first corner,

while the GLONASS + GPS receiver makes the more correct right angled turn. A similar observation

may be made at the second corner. Just before the photo location marked with an asterisk (*) the

GPS receiver struggles to maintain a good fix, and the reported position wanders away from the

roadway over the buildings. The GLONASS + GPS solution does a better job of maintaining the

correct path, although small errors are still seen towards the end of the track.

Figure 12: GPS versus GPS + GLONASS logged tracks (MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))


The Samsung Galaxy Note (GPS+GLONASS) used in the trials demonstrated a number of advantages

over the HTC Desire and HTC Sensation (GPS only), which included:

faster initial (cold) position locks (typically under 10 seconds, compared to around 45

seconds)

greater time with a position lock (e.g. urban canyons, even indoors on some occasions)

better location solution across a range of environments

Similar experiences were noted by Mattos (2011), where position solutions were reported to be 2.5

times better when using GLONASS in addition to GPS.

For these reasons we propose that GLONASS+GPS enabled devices should be used in SPACEBOOK.

However despite the improvements additional steps are required to further enhance the location

solution, as the combined GNSS solution still exhibits positional errors which need to be handled.

4.1. Position Error Reporting

The following example (Figure 13) shows the simultaneous data tracks recorded on GPS and GPS

+GLONASS devices, where the radius of the line denotes the error (in metres) reported by the device.

The user walked from the east side of the map towards the north west side, always occupying the

pavement on the left side of the road, apart from when making crossing the main southern junction

diagonally (as indicated by the dotted line). The GPS solution in this case shows greater variation in

direction, and a poorer reported error, while the GLONASS+GPS solution exhibits a more stable path

it exhibits an offset to the south along the entire journey. Therefore a map matching step was

introduced to move the reported position to the more likely location on the pavement, or road.

It should be noted that the reported error values do not always convey the actual location error. For

example we noticed the HTC devices reporting errors of 4m when they were actually up to 10m

away from the correct location. Furthermore the speed in metres per second was rounded to the

nearest 0.25m/s on the HTC devices while the Samsung Note was able to report speeds to many

decimal places without noticeable rounding, and yet positional errors were rounded up to the

nearest 5 metres.


Figure 13: Error reporting - GPS versus GPS + GLONASS logged tracks (MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))


5. Map matching

A challenge of the SPACEBOOK pedestrian tracker is that the solution has to be dynamic, operating in

real time, meaning that user trajectories need to be analysed without the opportunity to look ahead

and implement techniques, such as corner matching (Meng Yu 2006).

Additionally SPACEBOOK is designed with the pedestrian in mind, meaning snapping to a road

centreline is not always appropriate as used in vehicle based map matching (Basnayake and

Lachapell 2003, Syed and Cannon 2004), as pedestrians can explore open spaces (eg parks). With

that in mind we developed a raster surface at 1m resolution called the Pedestrian Accessibility

Model (PAM), as mentioned in D3.3.1. This represents the likelihood that pedestrian could occupy

that space based on the land use, such that pavements are considered more attractive than roads,

and roads much more attractive than buildings. Open spaces are considered slightly less attractive

than pavements, tracks and pathways, but more attractive than road regions. Water (eg lakes, rivers)

and cliff regions are considered very unlikely. In addition interpolated values were introduced

between these regions which could be used to gently push the user’s estimated map location

towards the most likely region. This is useful if the reported location is on a building, as the aspect of

the slope indicates the most likely direction required for the correction.

The PAM is shown in perspective view and map view below (Figure 14), where the ‘elevation’ value

represents the probability of user occupancy (higher values = less likely). Therefore all buildings

appear like equal heighted ‘loaves’, and pavements appear as gutters. The user’s location could be

considered as a marble rolling around this ‘loaf world’.

In addition, to land use, a Digital Terrain Model (DTM) is used to determine the user’s current

elevation, and thereby detect nearby locations which are at noticeably different elevations. This is

used to prevent the processed location from large elevation changes across short horizontally

distances, such as incorrectly placing the user on a lower road, below a bridge. Figure 15 shows an

example of this where the candidate space to the sides of the bridge [marker 1] are assigned low

probability values due to their much lower elevation (read from the DTM). This ensures the

processed position is not permitted to fall on to this lower road [marker 2], despite being spatially

close, forcing the output to be kept at the more similar road elevation to the previous reported

locations.


Figure 14: Pedestrian Accessibility Model (PAM)

(a) perspective and (b) map views of the most accessible land uses for the pedestrian

Figure 15: Digital Terrain Model used in Bridge Track Corrections User walks across a bridge[1] passing over lower road [2]

(MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))


5.1. Position Correction Process:

The position correction process involves taking the raw data from the smartphone, and searching the

immediate surrounding area, and selecting the most likely location of the user (‘the corrected

position’) based on where they were just prior, and the type of entity they are most likely to be

walking on (definitely not on top of a building, possibly on the road, most likely on a pavement). To

determine the most likely locations in the surrounding area, the following methodology is applied at

each position update (1Hz):

Create a 60m x 60m Candidate Space of 1m x 1m cells around the GNSS reported location

Calculate the pace rate from acceleration data

Calculate the average speed over the last 1s ,2s and 3 seconds from GNSS data

Calculate the average orientation over the last 1s, 2s and 3s from GNSS data

Check the PAM to determine the most likely locations (ie not roofs, more likely pavement)

Weight locations in front of the user as more likely next locations (based on GNSS orientation)

Use average speed values to determine the maximum likely distance the user could have moved

since last GNSS update. Create Euclidean decay mask based from a point projected forward this

distance from current best guess of location

Compare the previous ground elevation value with those in candidate space, and decrease the

probability for cells which have a difference of more than 3m in a travel time of 1 second.

The function is used recursively with increasing tolerances, until a suitable location is found. In

addition the most likely road centreline location is determined, and used to seed the search when a

local minima has occurred from searches beginning from the original GNSS location.

5.2. Determining the Most Likely Road Centreline:

When a pedestrian reaches any junction, a number of candidate paths become available. A

methodology was developed that automatically identified candidate road centrelines. This

information was used to influence the selection of the most likely pavement that a pedestrian might

be on.

Prepare a RoadSnap dataset with vertices added every 2m, and load this into memory on

initialising the Pedestrian Tracker

Create a buffer of 50m around the reported GNSS location

Select all road centrelines which intersect this region

Determine the closest vertex in the RoadSnap layer for each selected road centreline

Determine the next vertex for each road, in the direction given by the GNSS orientation

Create a line segment between each set of vertices and determine the closest point along this

segment to the reported GNSS location

Calculate the road orientation at this section of the road

Weight the road segment based on the user’s orientation against the road orientation at this

point, and the distance to this road segment. Orientations which match to within 30 degrees are

given preference.


The output is a candidate space filled with values which represent the likelihood that the user is

occupying that position, as shown in Figure 16.

Legend

GNSS reported location

Most likely location

Last most likely location (previous

step)

Predicated future location based

on current speed and heading,

with margin for switch to

jogging/running

Low

Probability of Occupancy

High

Figure 16: Location Probabilities in the Candidate Space around the Reported GNSS Location (MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))

6. On-board Sensors

Smartphones are equipped with a number of onboard sensors. These are typically fairly low quality

and therefore noisy and of limited use as an IMU, but can be used in conjunction with GNSS to

provide updates at a higher frequency than the 1Hz of the GNSS updates. Typically accelerometer

values are required at rates above 30Hz in IMUs, while Android OS’s ‘normal’ setting outputs at

updates at around 5Hz, to save battery power. However the Android Sensor Manager allows has a

‘fastest’ mode whereby the smartphone will determine the maximum frequency based on the CPU.

For an HTC Desire / HTC Sensation this is in the order of 40Hz-50Hz, while a Samsung Galaxy Note

will run at around 100Hz. Android phones also include magnetometers for orientation, and some are

equipped with a gyroscope for rotation, and a barometer to assist in elevation.

Currently the pedestrian tracker uses the accelerometer to estimate the mode of transport (Figure

17), from walking, jogging, vehicle, stopped, and the pace rate (Hz). This is required in order that the

SPACEBOOK Interaction Manager can decide to use the road centreline, or processed (preferred

pavement) locations solution.

When the GNSS reported speed is high but the accelerometer indicates that the user has not been

taking any steps, then the mode of transport is most probably a vehicle. In addition to the GNSS

speed value an estimate of the user’s stride can be made from examination of the acceleration of the

phone. Jogging and running have a higher peak (g), more peaks per second, and sharper peaks. As

the accelerometer output is a secondary sensor it can be used as an additional verification of the

GNSS values.


WALKING JOGGING WALKING

Acce

lera

tio

n (

g)

Time

Figure 17: Estimating User’s Movement with an Acceleration Sensor

The following example (Figure 18) indicates how the combination of accelerometer and GNSS

location values can be combined when determining the confidence in a location solution. At point (a)

the accelerometer shows the user has stopped moving, standing still until time (b). However the

reported GNSS location indicates movement, therefore we can assume the GNSS is ‘catching’ up and

correcting errors over those 3 seconds, therefore we assign a lower confidence to those positions

until they stabilise, converging around a single position. The user then takes a few steps between (b)

and (c) which correlate to the GNSS location shift, and stands still waiting for the lights to change

from time (c) to time (d). The relatively small movement in the GNSS position between (c) and (d)

would indicate that the GNSS solution is fairly stable in agreement with the accelerometer values

and therefore we can assigned a higher confidence to this location.

Figure 18: GNSS and Accelerometer combined to indicate Location Confidence



7. Examples

The following section shows a number of examples of the processed output from the pedestrian

tracker.

The dynamic nature of the correction process means that future path positions are not available.

Therefore at each position update the Pedestrian Tracker needs to estimate which facts are the most

likely, with an option to correct this at a later stage if the estimate is found to be incorrect (i.e. to

perform a catch up ‘jump’). In Figure 19 the reported GNSS path crosses a road and passes across a

building. At this time the Pedestrian Tracker select the most likely location to be the pavement at

mark [1], which is the closest pedestrian accessible point according to the PAM. However the

subsequent GNSS update indicates the user is moving away from [1] and therefore the following

estimate jumps to [2]. All following points are then displaced east towards the pavement away from

buildings.

GNSS location

Reported better than 10m

Processed location

Dire

ction o

f trave

l[1]

[2]

Figure 19: Correcting the reported location using map matching (MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))

Figure 20 shows a GNSS track, with segments highlighted in green where the smartphone reports a

location fix to better than 10 metre error (based on DOP). In addition the processed track is

displayed, where by the user’s location has been corrected to the pavement areas. Notice in Figure

20(a) at marker 1 that the GNSS error is large enough to force the processed location to the wrong

side of the road. A similar map is shown in Figure 20 (b) for a different journey, here the additional

snapped road centreline points are displayed (marker 3). Marker 2 shows where the processed

location has jumped across a building as a result of determining the GNSS track to be closest to the

more northern road. This is corrected a few seconds later when the Pedestrian Tracker re-selects the

main road as the main candidate based on its distance and orientation.


Directio

n of travel

Direction of travel

a)

b)

GNSS location

Reported better than 10m

Processed location

1

2

3

Figure 20: User moving along pavement, with original and processed position tracks displayed (a) and

the road centreline snap point (b) (MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))


7.1. Temporal lag

To establish if there were noticeable lags in the reported position and the logged location, a simple

trial was carried out whereby the user walked a path pausing at some specified locations. At the

same time GNSS position and accelerometer data were recorded against the system clock. Through

examining these linked GNSS and acceleration data it was possible to identify the recorded positions

where the user had stopped walking, and thereby identify any spatial displacement in the reported

GNSS position solution. A comparison of these logged locations against the defined locations shows a

fairly good match, with a slight lag on occasion (eg marker 3 in Figure 21).

[1] [2] [3]

[1]

[2]

[3][3] Meadowbank Bar

[2] Bus Stop

[1] Crossroads

Acce

lera

tio

n (

g)

Time (ms)

[4]

[4] Bus Stop

[4]

Legend

Defined Location

Logged Location

GNSS track

Figure 21: Temporal Lag between Reported Location and Actual Location (MasterMap data, Ordnance Survey © Crown copyright. All rights reserved OS))


7.2. Carrying position of the Smartphone

The position of the smartphone on the user is an important factor in how well the antenna can

receive the GNSS signals, as well as the performance of the magnetometers. Trials show that when

the phone is positioned horizontally, with the screen facing upwards, either in an outstretched hand

or in the top lid of a rucksack then the tracking performs better than when positioned in a jean or

shirt top pocket, as can be seen in Figure 22. Phone designs vary but generally the antennae should

be position near the top of the device and it is important that it has a clear line of sight to the sky.

Other factors such as the side of the road the user walks down, and the side the phone is pocketed

can influence the position solution. In addition the 3D magnetometer performs much better when

the phone is held away from directly vertical.

Figure 22 shows a journey which was followed the first time carrying the phone in the user’s hand

out in front, and a second time with the phone in a shirt top pocket, so that the phone was almost

vertical. The recorded paths are fairly similar, however (b) shows a greater number of deviations

from the right angle turns, greater drift across buildings, and a greater occurrence of sparse location

solutions (larger gaps between points). In addition the magnetometer readings in (b) are unusable,

compared to the very stable values seen in (a). This may be associated to the calculations which

require the 3D magnetometer values to consider the phone’s accelerometer values (to determine

phone attitude) before orientation can be returned.


a)

b)

Figure 22: Observed differences in carrying the phone (a) in front versus (b) pocketed (insets show the magnetometer orientation values)



8. Pedestrian Tracker Inputs / Outputs

8.1. Data inputs from Phone Server

Sensor data is updated at around 30Hz, while GNSS data is updated at 1Hz. These are sent from the

Phone Server to the Pedestrian Tracker.

GNSS Data Update to Pedestrian Tracker <PedTrackv1>

<GeoData> <ClientID>CLIENT_ID</ClientID> <TimeStamp>TIMESTAMP</TimeStamp> <UTCTime>UTCTIME</UTCTime> <Latitude>LATITUDE</Latitude> <Longitude>LONGITUDE</Longitude> <Altitude>ALTITUDE</Altitude> <Speed>SPEED</Speed> <Bearing>BEARING</Bearing> <Accuracy>ACCURACY</Accuracy>

</GeoData> </PedTrackv1>

Sensor Data Update to Pedestrian Tracker <PedTrackv1>

<SatelliteStatusChanged> <ClientID>CLIENT_ID</ClientID> <TimeStamp>TIMESTAMP</TimeStamp> <SatellitePRN>SATELLITE_PRN</SatellitePRN> <Azimuth>AZIMUTH</Azimuth> <Elevation>ELEVATION</Elevation> <SignalNoise>SIGNAL_NOISE</SignalNoise>

</SatelliteStatusChanged>

<Orientation> <ClientID>ANDROID_CLIENT_ID</ClientID> <TimeStamp>TIMESTAMP</TimeStamp> <Azimuth>AZIMUTH</Azimuth> <Roll>ROLL</Roll> <Pitch>PITCH</Pitch> <Accuracy>ACCURACY</Accuracy>

</Orientation> <Gyroscope>

<ClientID>ANDROID_CLIENT_ID</ClientID> <TimeStamp>TIMESTAMP</TimeStamp> <Azimuth>AZIMUTH</Azimuth> <Roll>ROLL</Roll> <Pitch>PITCH</Pitch> <Accuracy>ACCURACY</Accuracy>

</Gyroscope> <Accelerometer>

<ClientID>CLIENT_ID</ClientID> <TimeStamp>TIMESTAMP</TimeStamp> <Lateral>LATERAL</Lateral> <Longitudinal>LONGITUDINAL</Longitudinal> <Vertical>VERTICAL</Vertical> <Accuracy>ACCURACY</Accuracy>

</Accelerometer> </PedTrackv1>


8.2. Data input/output to the Interaction Manager

The Interaction Manager connects to the Pedestrian Tracker and may request position updates for a

user when desired.

Update Request <PedTrackv1>

<GetPosition> <ClientID>AndroidValue</ClientID> <CandidateSpace>yes or no</CandidateSpace> --optional

</GetPosition> </PedTrackv1>

Update Reply <result>

<ClientID>CLIENTID</ClientID> <TimeStamp>TIMESTAMP</TimeStamp> <PaceRate>PACES PER SECOND</PaceRate> <GuessTransportMode>WALK, JOG, VEHICLE, STOPPED</GuessTransportMode>

<OSGB36_userpt>PROCESSED USER LOCATION</OSGB36_userpt> <userpt_DTM>GROUND ELEVATION OF USER</userpt_DTM> <userpt_confidence>CONFIDENCE OF USER POINT</userpt_confidence> <OSGB36_roadsnappt>ROAD CENTRELINE SNAP POINT</OSGB36_roadsnappt>

<Speed>SPEED</Speed> <Bearing>BEARING</Bearing>

<cspace>LOCATION ARRAY WITH OCCUPANCY LIKELIHOOD VALUES</cpsace> </result>

8.3. Connection to the City Model

The Pedestrian Tracker connects to the City Model (D3.3.1) to log the GeoData (from Phone Server)

in raw form. It also logs a copy of the processed output at each IM request. These logs are intended

for use by the other system components to look at location histories, and determine what the user

may have already visited or seen.

9. Future Research Directions

There are many other associated investigations which have not been included in the current

pedestrian tracker, due to time restrictions, but may be included at a later date. These include the

user of Satellite Based Augmentation System (SBAS), such as EGNOS, which are not typically available

on smartphones but may be provided by the mobile network. RTK-GPS for increased position

accuracy when the SV constellation is suitable, and Kalman filters to smooth the path.

By combining GNSS with accelerometer data it is possible to determine various modes of transport.

This and other aspects of the pedestrian tracker will be further developed in the second iteration of

the project.


10. Conclusion

Pedestrian tracking is a much more difficult task than vehicle tracking, due to the freedom that

pedestrians enjoy. As a result a pedestrian tracker has to allow enough freedom for the user to

perform rapid turns, depart from road regions, and turn or stop frequently. The research conducted

here indicates there are significant benefits in using a combined GPS + GLONASS GNSS solution. In

addition map matching provides a means to limit erroneous results, and reduce the number of

incorrect locations logged. Furthermore the pedestrian tracker is able to use additional smartphone

sensor data in the processed location output, and assign a confidence to that location. The

surrounding candidate space and road snapped locations are also available.

11. References

8Motions. (2008). OpenCellID. Retrieved 20 September 2008, from http://www.opencellid.org

Basnayake, C. & Lachapell, G., (2003) Accuracy and Reliability Improvement to Standalone High Sensitivity

GPS Using Map Matching Techniques. ION 59th Annual Meeting/CIGTF 22nd Guidance Test

Symposium. 23-25 June 2003, Alburquerque, NM.

Botterill, T., Mills, S. & Green, R. (2010). Bag of words driven, single camera simultaneous localization and

mapping. Journal of Field Robotics, 28(2), 204-226.

Bullock, J. B., Foss, M., Geier, G. J., and King, M. (2006) Integration of GPS With Other Sensors and Network

Assistance. In Kaplan, E. D. (ed.) Understanding GPS: Principles and Applications, Mobile

Communication Series. Artech House Publishers.

Chen, M. Y., Sohn, T., Chmelev, D., Haehnel, D., Hightower, J., Hughes, J., LaMarca, A., Potter, F., Smith, L.

& Varshavsky, A. (2006). Practical metropolitan-scale positioning for GSM phones. Lecture Notes in

Computer Science, 4206, 225-242.

Cho, D. J. (2004). An assisted GPS acquisition method using L2 civil signal in weak signal environment.

Journal of GPS, 3(1-2), 25-31.

Fantino, M., Mulassano, P., Dovis, F. & Lo Presti, L. (2008). Performance of the proposed Galileo CBOC

modulation in heavy multipath environment. Wireless Personal Communications, 44(3), 323-339.

Godha, S., Petovello, M. G. & Lachapelle, G. (2005). Performance analysis of MEMS IMU/HSGPS/magnetic

sensor integrated system in urban canyons. Proceedings of ION GPS-05, 1977–1990.

Grinter, R. E., Aoki, P. M., Hurst, A., Szymanski, M. H., Thornton, J. D. & Woodruff, A., (2002) Revisiting the

visit: Understanding how technology can shape the museum visit. Proceedings of the ACM Conference

on CSCW. 146-155.

Hightower, J., Consolvo, S., LaMarca, A., Smith, I. & Hughes, J., (2005) Learning and recognizing the places

we go. UbiComp 2005. 11 September 2005, Tokyo, 159-176.

Hodge, N. (2007). US military looks to fill gaps in GPS navigation. Jane's International Defence Review, May.

Ji, Z. & Jain, R. (2008). Google enables Location-aware Applications for 3rd Party Developers. Retrieved 24

September 2008, from http://googlemobile.blogspot.com/2008/06/google-enables-location-aware.html

Kray, C. & Kortuem, G., (2004) Interactive Positioning Based on Object Visibility. 6th International Symposium

on Mobile Human-Computer Interaction: MobileHCI 2004. Glasgow, UK, Springer, 276-287.

Krumm, J., Cermak, G. & Horvitz, E., (2003) RightSPOT: A Novel Sense of Location for a Smart Personal

Object. UbiComp 2003: 5th International Conference on Ubiquitous Computing. Seattle, WA, USA,

Springer, 36-43.

Lachapelle, G. (2004). GNSS Indoor Location Technologies. Journal of Global Positioning Systems, 3(1-2), 2-

11.

LaMarca, A., Chawathe, Y., Consolvo, S., Hightower, J., Smith, I., Scott, J., Sohn, T., Howard, J., Hughes, J.,

Potter, F., Tabert, J., Powledge, P., Borriello, G. & Schilit, B. (2005) Place Lab: Device Positioning

Using Radio Beacons in the Wild. Pervasive Computing. Munich, Springer.

Mattos. (2011). Consumer GPS/GLONASS Accuracy and Availability Trials of a One-Chip Receiver in

Obstructed Environments [Electronic Version]. GPS World, Dec 2011. Retrieved 14 Dec 2011 from

http://www.gpsworld.com/gnss-system/receiver-design/consumer-gpsglonass-12359.

McEllroy, J., Raquet, J. F. & Temple, M. A. (2007). Opportunistic navigation. GPS World, 18(7), 44-49.

Meng Yu, Z. L., Yongqi Chen, and Wu Chen. (2006). Improving Integrity and Reliability of Map Matching

Technique. Journal of Global Positioning Systems, 5(1-2), 40-46.

http://www.opencellid.org/

http://googlemobile.blogspot.com/2008/06/google-enables-location-aware.html

http://www.gpsworld.com/gnss-system/receiver-design/consumer-gpsglonass-12359


Mezentsev, O., Lachapelle, G. & Collin, J. (2005). Pedestrian Dead Reckoning–A Solution to Navigation in

GPS Signal Degraded Areas. Geomatica, 59(2), 175–182.

Navizon. (2008). Peer to Peer Wireless Positioning. Retrieved 9 June 2008, from http://www.navizon.com/

Ott, B., Wasle, E., Weimann, F., Branco, P. & Nicole, R. (2005) Pedestrian Navigation in Difficult

Environments: Results of the ESA Project SHADE. Geo-information for Disaster Management.

Radoczky, V. (2007) How to design a pedestrian navigation system for indoor and outdoor environments.

Location Based Services and TeleCartography. Berlin, Springer.

Randerson, J. (2004). Photo recognition software gives location. Retrieved 24 June 2008, from

http://www.newscientist.com/article/dn4857-photo-recognition-software-gives-location.html

Raper, J., Gartner, G., Karimi, H. & Rizos, C. (2007). A critical evaluation of location based services and their

potential. Journal of Location Based Services, 1(1), 5-45.

Retscher, G. & Thienelt, M. ( 2004). NAVIO – A Navigation and Guidance Service for Pedestrians. Journal of

Global Positioning Systems 3(1-2), 208-217.

Skyhook. (2008). Location you can trust. Retrieved 14 October 2008, from http://www.skyhookwireless.com/

Syed, S. & Cannon, M. E., (2004) Fuzzy Logic Based-Map Matching Algorithm for Vehicle Navigation System

in Urban Canyons. ION National Technical Meeting. January 26-28, 2004, San Diego, CA.

Yahoo. (2008). FireEagle. Retrieved 20 September 2008, from http://fireeagle.yahoo.net/

Yang, Z. S., Wang, W., Dong, S., Zhu, W. Q. & Shen, J. H. (2008). Information fusion technology of GPS/DR

integrated positioning system. Journal of Jilin University (Engineering and Technology Edition), 38(3),

508-513.

Zhou, J., Chu, K. M. K. & Ng, J. K. Y. (2005). Providing location services within a radio cellular network using

ellipse propagation model. International Conference on Advanced Information Networking and

Applications, 1, 559-564.

http://www.navizon.com/

http://www.newscientist.com/article/dn4857-photo-recognition-software-gives-location.html

http://www.skyhookwireless.com/

http://fireeagle.yahoo.net/

Documents

D3.4: A Pedestrian Position Tracker - SpaceBook … Status & version ... A Pedestrian Position Tracker Prototype ... Satellite System (GNSS) is the USA’s Global Positioning System