Project Title: Indoor Pedestrian Tracking via Smart Sensors in Mobile Phones

Introduction and project motivation

In recent years, mobile phones have become increasingly sophisticated in terms of feature set and
have become an integral part of our daily lives. Due to the rapid technology advancement,
smartphones have become mainstream and are being equipped with a plethora of sensors that feed
data to the powerful operating system running in the background, hence providing various intelligent
services to the users.

Examples of sensors that are commonly found in a smartphone include proximity sensor, global
positioning system (GPS) receiver, accelerometers, digital compass and gyroscopes. The GPS
receiver, together with Wi-Fi and cellular base stations’ signals, together form a location system
known as assisted-GPS technology. This, in particular, has opened the doors to many commercial
opportunities in the form of location-based services (LBS) that present the users with relevant
localized information or advertisements.

At present, almost all of the location aware applications (LAPs) available on the smartphone markets
rely extensively on assisted-GPS technology to work. While the outdoor accuracy can be quite good,
the indoor positioning accuracy can easily be several tens of meters due to the blocking of GPS
signals by construction materials. This prevents the developers from realizing the full potential of a
location aware system.

There are many applications that could benefit from the use of an indoor positioning system (IPS).
One such example would be the use of indoor positioning to help shoppers within a mall to find their
current location as well as the route to their favorite shops. The system can also be used to serve
localized deals to the consumers and that could yield significant commercial interest for the vendors.
In other areas such as the healthcare industry, hospital could benefit from the use of IPS to monitor its
patients and allow medical response personnel to find the best route to reach their destination in times
of emergency. With the endless possibilities as to how IPS can be deployed, research into the area of
indoor localization has been very popular in recent times.

In the literature, a few techniques are being proposed for indoor localization. They can be broadly
classified into two categories, namely, infrastructure based and infrastructure-less based systems. The
infrastructure based systems typically make use of received signal strength (RSS) metric gathered
from various Wi-Fi or Bluetooth access points to compute the subject’s location by comparing the
received metrics with a database of “fingerprints” and then finding the best match. Such fingerprinting
method is cost-prohibitive and labour-intensive during the setup phase. However, it can provide a
fairly accurate continuous location estimate once the initial setup is completed. Practical
implementation of such systems is uncommon as a result.
On the other hand, the infrastructure-less based systems have low setup cost and do not depend on the
surrounding environment for them to work. The primary technique used in such systems is known as
“dead reckoning” (DR) and it is defined as the process of estimating one’s current position based
upon a previously determined position, and advancing that position based upon the estimated
displacement over elapsed time and course. It revolves around the use of pedometers as the primary
means of estimating position. The sensors used for DR are accelerometers, gyroscopes and digital
compass. With the increase in interests towards location-based applications on mobile devices,
coupled with the fact that these sensors are commonly found on smartphones today, the stage appears
to be set for practical development efforts to be channelled into IPS for mobile devices.

This report will provide an overview of the problems faced in the implementation of DR based IPS
and how it has limited the practical adoption on mobile devices. A solution will then be proposed to
solve the problems raised and details regarding the solution will be discussed and elaborated.

Problems

The two main issues that limit the development of indoor LAPs on mobile platform today are:

1. Lack of native software library support for indoor positioning

2. Most DR techniques are only tested to work in research environments and lack practical
implementation and testing on mobile phones

One of the main reasons behind the high availability of outdoor LAPs on the smartphones today can
be attributed to the mobile operating systems’ (M-OS) extensive built-in outdoor positioning software
library. The two biggest M-OS providers in the market, Apple iOS and Android OS, provide free,
built-in support for Google’s MapView APIs and LocationProvider APIs that serves as a platform that
developers can use to build their LAPs. These APIs encapsulate the heavy lifting work necessary for
map view display and the communication with phone’s sensors, i.e., GPS, digital compass, etc. As a
result, developers are not required to understand how the underlying hardware behaves and can
rapidly develop outdoor LAPs using function calls of the APIs as shown in Part 1 and 2 of Figure 1.
The univeral support of these APIs across different M-OS also mean that developers only need to
study one set of Google localization library for cross-platform development.

In contrast, the lack of similar software library for indoor positioning has severely limited its
development capabilities and attractiveness to developers. Developers interested in building indoor
LAPs will have to implement their own LocationProvider and MapView on top of the actual
implementation of the application’s logic. This would also mean that developers have to acquire
certain level of understanding towards DR algorithms to effectively implement the LocationProvider
layer. These additional effort requirements are major stumbling blocks for developers.
 Location Aware Application
(Part 3)
MapView (Part 2)
LocationProvider (Part 1) - Interface with - Fetch relevant - Developer
the hardware map information specified
sensors to obtain from online functional
geographic server behaviors and
location estimate - Display map and logic
and facing handles user's - Primary focus of
direction. navigation the application
- Provided by - Provided by development
Google API Google API

Figure 1. Typical LAP implementation flow chart

Proposed solution

By creating a software library package that take cares of the sensors’ data computations and the map
display for indoor environments, developers can focus their attention on the core program logic
without having to re-implement these native components. This would speed up the development
process and encourage more developers to work on indoor LAPs. However, there should be a certain
level of flexibility within the library to give developers the freedom to customize new localization
algorithms when the need arises. We have chosen to implement the software library on the Android
OS due to its openness and widespread adoption in the smartphone market.

Given the above considerations, a proposed suite of software library package is to be implemented
with the aim of addressing the problems raised earlier. Figure 2 shows the proposed software suite
consisting of two Android library packages, LocationProvider and MapView, as well as a desktop
application to perform the more computationally expensive tasks.

Location
Map View Map Prep
Provider
Encode map data into XML
Graphical user interface for
Sensors data acquisition and file for Map View
display and manipulation of
logging of data
indoor map and overlays
Compute a table of shortest
paths between any two
points nodes on the map
Interface for Location
Implementation of DR
Provider and other
algorithm to provide step Log raw sensor data from
enhancement modules to
detection and bearing Location Provider via the
be added on
local network

Figure 2. Proposed software suite

Location Provider

The location provider is a software package that can be used by developers to obtain the step detection
and user’s bearing. A basic non-adaptive dead reckoning algorithm is implemented in the package that
performs step detection by analyzing the magnitude of the accelerometer readings. This
implementation allows for fairly accurate step detection and can be used by developers for rapid
prototyping of their application. Should the developer choose to implement a more accurate DR
algorithm, he can easily do that by implementing the LocationProvider interface.

Besides providing step detection functionality, the LocationProvider is also capable of transimitting
raw sensor data over the wireless network to the Map Prep desktop application. This allows for
logging of sensor data that can be used for offline analytics and research purposes. This is a valuable
tool to researchers because now they can have access to a common mobile platform to validate and
benchmark their proposed DR algorithms.

Map View

Figure 3. Application prototype built using LocationProvider and MapView library

The map view handles the graphical interface responsible for displaying the map on the mobile phone.
It will receive step updates from the location provider and update the user location on screen. The
map view will support basic multitouch gestures for panning and scaling of the map.

Accompanying the map image, there is a map data xml file that has to be decoded by the map view
for each map that is being loaded. The xml file contains metadata of the map such as the north offset
value that will be used to compute user’s bearing relative to the map’s north reference. Additional
data can be added to the xml file to extend the map view’s functionalities. For example, developer
who wants to integrate routing path information onto the map can choose to include the shortest
paths’ look up table into the xml file. The map view will then be able to display the node overlays on
the screen and allow the user to choose a destination node for which the shortest path is to be
obtained.
 QR code
User scans QR localization plugin
code with current decodes location Update user
location information and location on the
information look up current map
encoded location on the
map

Figure 4. QR code discrete localization workflow

In addition, the map view also exposes useful APIs for developers to manipulate the user location
marker as well as to display the route taken by the user. An interesting use case for utilizing these
APIs is realized by the implementation of the QR code discrete localization plugin as shown in Figure
4. The plugin will allow the user to relocate its position using QR codes that encode location
information. A user can scan the QR code and the map view can use the decoded location information
to determine the user’s current location. The decoding process is done through looking up the location
table in the metadata file associated with the map.

Map Preparator

Figure 5. Map Preparator tool

The Map Preparator shown in Figure 5 is a desktop accompanying tool designed for developers to
create the map’s metadata file that is required by the map view. The metadata file will contain basic
attributes of the map, such as title, north offset value, and scale. In addition, developers can load a
map, insert nodes, and indicate node linkages for the software to generate the shortest path table using
Dijkstra algorithm. The resulting table will be appended to the metadata file associated with the map.

Researchers who are keen to benchmark and analyse the performance of various DR algorithms have
a choice of implementing the algorithm using LocationProvider and log the sensors’ data on the
desktop computer for offline processing via the Map Preparator tool.