2012 African Conference for Sofware Engineering and Applied Computing

Indoor navigation using a mobile phone

Brett Ausmeier
Computer Science Department
University of Cape Town
Cape Town, South Africa

Thomas Campbell
Computer Science Department
University of Cape Town
Cape Town, South Africa

Sonia Berman
Computer Science Department
University of Cape Town
Cape Town, South Africa
Sonia@cs.uct.ac.za

Abstract—This paper describes the InNAVation system for
indoor navigation using a mobile phone. A tool such as this
requires a method of storing building data and routing
information on the phone, as well as the ability to automatically
track phone location as users walk around. We describe two
alternative approaches to mapping building data along with a
routing database design that make the project viable despite the
limited storage, processing power and battery life of the phone.
In particular, we compare GUI building plan annotation on a
desktop computer with pedometer-based mapping of a building
using the accelerometer on a mobile phone. Experiments indicate
that users found plan annotation usable and database size scaled
well for large buildings. The accelerometer-based approach to
mapping a building was not acceptable due to inaccurate distance
estimates; however this was adequate for tracking and directing
users through a building, since small imprecisions were easily
accommodated by users - they appreciated that directions would
not give exact distances and were able to follow instructions to
their destination in all test cases.
Keywords: indoor navigation; mobile phone; user location;
user tracking; building data capture
I. INTRODUCTION
While GPS is commonly used in numerous applications, it
is not sufficiently accurate for indoor navigation. This paper
describes an investigation into the use of a mobile phone
application to guide a user around a building or campus.
Initially designed for a firm of consultants who wanted to save
time when working at clients’ premises, it can also be used in a
variety of other useful contexts from museums to shopping
malls. Such a system has two main requirements: the ability to
store and process routing information for buildings on a mobile
phone, and the ability to track the users as they walk.
A system called InNAVation was built at UCT which
utilised the accelerometer on a phone to track users’ walking in
order to direct them to their desired destination. Two
alternative approaches to capturing route information were
implemented and compared. One used the accelerometer to
implement a pedometer-based mapping of buildings, whereby
users clicked on locations as they walked past them. The other
presented a plan of the building on a desktop computer which
users annotated by clicking on points of interest. This paper
reports on both approaches to building data capture, and the
results of our experiments investigating the viability of indoor
navigation using cellphones. Section 2 presents some
background work, followed by one section on each of the two
major components: building data capture and user tracking.
Section 5 outlines the results of our experiments using
InNAVation, and is followed by our conclusions and
suggestions for future work.
II. BACKGROUND
Possible approaches to indoor tracking of mobile phones
include the use of WiFi and Radio Frequency networks,
Bluetooth localization, image matching, ambient fingerprinting
and pedometer systems. Triangulation of a user’s location can
use readings from wireless transmitters, but this relies on their
existence in the areas of interest, and is susceptible to wall
attenuation in some buildings [1], people movement [2] and
other factors such as the weather [3]. A cheaper solution is to
set up Bluetooth transmitters in the building, and locate devices
based on proximity to these. However this is not very accurate,
and the cost of Bluetooth queries is high [4]. Cheaper still are
passive RFID tags that reflect signals transmitted to them, but
few phones have RFID readers built in [5] and they have such a
short range that users would have to touch the RFID tags with
their phone [6]. While few phones have RFID readers, most
have cameras. Users could take photographs which could be
matched up against an image database, but the database needs
to include the full extent of lighting and camera angles [7].
Since this requires too much storage and processing for a

978-0-7695-4909-5/12 $26.00 © 2012 IEEE 109

DOI 10.1109/ACSEAC.2012.26
phone, a server would need to be accessed which would be co-ordinates so that they were correctly transformed when the
costly. Alternatively barcode readers on phones could be used image was manipulated by zooming or scrolling. Two modes
if barcodes were distributed around the building. None of these were needed in order to disambiguate mouse actions: one for
methods is able to pinpoint the location of a phone with great adding information to the graph (construction mode), the other
accuracy, so ambient fingerprinting [8] could be used – this for altering the graph (edit mode) e.g. by relocating several
distinguishes rooms according to sound, movement, lighting nodes at a time.
and the like. The cheapest and most promising approach
seemed to be the pedometer method, where step counts and
lengths are used to determine location – accuracy of more than
98 percent was reported in [9].
An indoor navigation system also requires that building
data is captured, so as to record the location of points of
interest and the pathways between them. Architectural plans
comprise accurate scaled 2-D representations of a building.
Modern plans are kept in digital format, and even old buildings
typically have digitized plans created when they undergo
renovation. A plan drawn on paper can be manually digitized
with a digitizing tablet by moving the cross-haired cursor and
clicking to create points or features. Alternatively, a camera
can create a digital image of a plan, but some distortion caused
by the lens needs to be eliminated [10]. An indoor GIS
application in [9] uses shape files to store building information
as polygons with associated room details, services, operational
status and personal details of occupants. A similar system [11]
Figure 1: First prototype showing Points of Interest and pathways.
characterizes routes in terms of time rather than distance, while
[12] includes access privileges with route information. In the second iteration distances were associated with edges
and the shortest paths between POI pairs computed. Larger
III. PLAN ANNOTATION FOR BUILDING DATA CAPTURE graphs were used in test cases, and the jagged look of pathways
For indoor navigation to be viable, it is vital that the started to look untidy. This occurred in the following way. If
capturing of data for a building is as cheap and simple as the user indicated there was a path from A to B and from B to
possible. For this reason we chose building plans as the starting C, the system would draw these two edges by connecting the
point, rather than require installation of RFID tags or the like. corresponding node centres. Thus, if the user had not placed A
The building plan is converted to an image that is displayed to and C equidistant from walls - which tended to be the case
the user, who then constructs a graph of points of interest or seeing as humans do not click with great accuracy - the line
POIs (nodes) and walkable pathways (edges) on top of this from A to B to C would not be straight, as shown in figure 2.
image. Each POI is associated with a name (such as the room
number) and a set of metadata keywords or tags indicating e.g.
whose office that room is, which facilities (e.g. printer or fax
machine) exist there, etc.
The image needs to be calibrated so that distances in pixels
can be converted to meters to walk. Two calibration options are
provided. One alternative is for the user to supply the distance
in meters between two POIs (nodes); this can be done using the
Tracking Component or by independently measuring the
distance between 2 adjacent POIs. By counting the pixels along Figure 2: Jagged lines resulting from poor placement by users.
the path between those two POIs, meters per pixel can be
calculated and used to convert all other pixel distances into
meters for user instructions. The simpler calibration option is
for the user to supply the image resolution (pixels per inch) and
the scale that appears on the building plan (meters per inch)
from which the pixels/meter is calculated by the system. The
GUI for building data capture was developed iteratively, and
user evaluation was included in each iteration.
A. Initial protoypes
The first prototype can be seen in figure 1. It implemented Figure 3: Automated straightening of routes.
the basic requirements of opening a building plan and, in a
layer above this diagram, allowing users to construct the graph
of POIs and routes between them. POIs were linked to pixel

110
B. Aesthetic Improvements and Shortcuts
The third prototype addressed the problem of jagged lines
by detecting straight lines and corners using node co-ordinates
along a route. It implemented a smoothing function that
straightened the lines representing pathways accordingly, as
shown in figure 3. The pathway detection algorithm first
looked for nodes having X (or Y) values that differed by only a
few pixels at most, and “snapping” these nodes into a straight
line. However this had to be altered to work with links rather
than nodes to avoid situations such as those shown in figure 4.
limit the number of POI names that users had to enter. Given
that room numbers typically follow a pattern as one proceeds
down a corridor, the user only needed to name two rooms and
click the “use pattern” button to have all selected nodes
numbered automatically. The system detected which parts of
the name were changing, and how. In the test building for
example, there was a sequence of rooms named I4D2a, I4D2b,
etc. as well as rooms named CSC300, CSC301, etc. which
were correctly handled. The pattern naming system
encountered problems when users selected nodes belonging to
more than one corridor, as shown in figures 6 and 7. The first
remedy attempted was to distinguish the major and minor axes
along which nodes were linked, but this did not accommodated
circular or hairpin bend paths. The final algorithm worked by
detecting end nodes and then applying the pattern recognition
to each branch of such multiple-corridor cases, as shown in
figure 8.

Figure 6: Any 2 rooms can be named on a path for pattern detection.

Figure 4: Automated straightening has to consider not only node co-
ordinates but also links, to avoid errors as in the above example.

The fourth prototype used node colours and shapes to show

at a glance information that test subjects had requested. To
avoid making the graph too complicated, only 2 shapes and 3
colours were used. As red is the most attention-grabbing
colour, a red circle was used to indicate a node for which no
data had been supplied, not even a room number. A green
circle was used for nodes with a name but no metadata, and a
yellow star was used for a node with both name and tags Figure 7: Automated naming of nodes after applying pattern recognition.
(indicating complete). Since a user could in theory supply
metadata but no name, such nodes were represented by a red
(no number) star (contain metadata). An example showing the
different node representations can be seen in figure 5. This
prototype also introduced shortcuts for selecting multiple
nodes, and for drawing a node and an edge at the same time.
The latter is done by holding down the shift key while clicking
POIs whenever the intention is to also link a new POI to its
predecessor.

Figure 8: Using end-points to ensure patterns are applied appropriately.

The entry of tags was also considerably facilitated by

Figure 5: Fourth prototype showing the use of node colours and shapes.
The final version focused on aesthetic changes, and on
time-saving shortcuts. Firstly, pattern detection was used to
allowing import of a file containing the room metadata. Since
most organisations will have such information on a file in any
case, this avoided the need to re-enter e.g. staff name, job title,
telephone number and so on for offices, etc.
Aesthetic changes requested by users were incorporated,
such as renaming and reorganisation of buttons, and the use of

111
different colouring for nodes so that the overall effect was
easier on the eyes and gave a more professional look to the
tool. An example of the final version of the system can be seen
in figure 9.
Figure 9: Final version of building plan annotator.
C. Porting routing data to the phone
The Building Capture Component exported routing data to
a SQLite3 database for use by the Navigation Component. This
database initially comprised a relation Nodes, containing the
co-ordinates of each node, a relation Tags containing metadata
associated with nodes, and a relation Routes containing the
shortest path from each node to every other node. An
additional relation Links contained each edge and its distance
in meters, so that the Navigation Component could give
appropriate instructions such as how far to walk before turning.
The database was subsequently modified so as to limit storage
space and processing time on the mobile device. The Node and
Tag relations were combined so that all node information could
be accessed by the mobile device at the same time, and the
Links relation was abandoned since it was faster to calculate
distances (from node co-ordinates) on the device itself. The
database was sufficiently small for use on a mobile phone, and
once database accesses were batched rather than individually
executed, performance was not a problem.
IV. ACCELEROMETER-BASED INDOOR NAVIGATION
A pedometer-based approach to tracking the location of a
walking user requires a method of detecting steps and a method
of determining someone’s stride length. The subsections that
follow consider each of these in turn. An overview of the
Android application can be seen in figure 10.
112
Figure 10: Overview of the subsystem residing on the Android phone.
A. Step detection
The accelerometer on a phone measures the acceleration of
the device. Assuming a mobile phone that is giving someone
directions will be held face up, only acceleration up and down
on the z axis is needed to detect steps. The first step detection
method identified peaks (see figure 11) by finding points P
such that P was greater than both its predecessor and its
successor. A threshold to distinguish noise from steps was
needed, but unfortunately this differed from one person to the
next. To overcome this problem, peaks that differed by more
than one standard deviation from the mean were regarded as
noise. Unfortunately, experiments showed that steps taken
from a standstill differ from those taken after walking for a
while. A fourth attempt thus looked instead for peak-trough
pairs, but this doubled the error rate rather than reducing it.
Finally approximate peak volume was used for step detection,
as this was essentially a combination of the merits of all the
previous algorithms and gave the greatest accuracy.
Figure 11: Accelerometer readings when walking with a phone.
Initially users were asked to walk a given number of steps
and the algorithm attempted to find exactly that number of
peaks in the data; however this was not robust as users were
found to mis-count and then off-by-one errors meant the peak
thresholds were affected. A hybrid approach was then adopted
– the application does automatic step detection using peak
volume and then compares this with the number of steps the
user was told to take.
B. Determining step length
GPS was first used to determine distance walked and then
this was divided by the number of steps taken to calculate the
user’s average stride length. Unfortunately the best accuracy
achieved using GPS on the phone was 4 meters. Clearly this is
unacceptable for indoor navigation. Hence users were asked to
walk a pre-measured distance instead, and this was divided by
the number of steps taken to get average stride length for that
user.
A user’s location is tracked by having them indicate which
entrance they use to the building, and then using the phone to
detect distance walked and orientation. To overcome any error
in step detection or stride length, a technique called “corner
snapping” is employed: when orientation changes close to 90
degrees, users have clearly turned right/left and hence their
location can be adjusted/snapped to the corresponding
corner/junction. This is done only if there is a passage at that
point, to avoid snapping when someone is simply changing
direction to e.g. walk round an obstacle or look at a notice on
the wall. To optimize the corner-snapping, rather than choose a
set distance from a possible junction this threshold is a
percentage of the corridor length.
Initially we anticipated that step calibration would be a
once-off operation for a user, after which the system would Figure 12: Simple interface for directions, which shows remaining distance
only be engaged in tracking the user’s location as s/he moved to go in the current step.
through the building. InNAVation was later changed to
continually update stride length during the tracking phase so as
to improve accuracy. This was particularly necessary because V. SYSTEM EVALUATION
people tended to exaggerate their steps during the calibration
The mobile system was implemented on an Android phone
stage instead of walking normally. Also, users tend to slow
using SQLite3 for data storage. The building plan annotation
down on the final step and the last peak is thus lower than the
system was developed using JUNG and GraphML. The
others.
scalability of the system was tested using incrementally larger
Pedometer calibration has a simple interface where one sections of a building, and finally by using the plan of the
simply pushes a button at the start and again at the end of the largest shopping mall in the Southern Hemisphere, namely the
walk. The navigation interface shows estimated current Gateway Mall in Durban, South Africa (see figure 13). It
location in an (editable) “From” box, and the user enters only contained over 300 nodes and the growth of the database was
the destination (e.g. “fax machine” or “Joe Soap’s office”). The studied by incrementally adding these in batches of 10. The
route to take is shown as a sequence of instructions along with database grew from 50 nodes (1225 routes) requiring 79Kb to
a “distance remaining” value for the current instruction (see 300 nodes (22350 routes) requiring 2654Kb. Each floor and its
figure 12). When this reaches 0 the instruction disappears and associated shortest routes are stored separately, hence the
2
the next instruction becomes current. For initial usage, the user growth of order N applies to N being the number of nodes per
has to indicate where s/he is in the “From” box, which defaults floor (150 in the case of Gateway). No lag was experienced
to Main Entrance. while using the system to construct the graph of the Gateway
Mall, and even the calculation of shortest routes took less than
a second to complete.

113

Figure 13: The ground floor of the Gateway shopping mall.
The usability of the plan annotation approach to building
data capture was evaluated using constructive interaction and
post observation. In constructive interaction users work in pairs
and are encouraged to talk to each other as they carry out the
given tasks, so that the users’ thinking and understanding is
more readily apparent. This method was used with 6 subjects
working in 3 pairs, and with a further 4 subjects working with
the system developer himself. In the latter case the developer
was careful not to give any hints, and was able to question the
subject if they did something without explaining why. In all
cases the subject who was least confident and knowledgeable
as regards computer usage was given control of the mouse, and
this led to a great deal of communication in each pair. In the
post observation phase, users were interviewed about anything
that had arisen during their session and to elicit overall
opinions and ideas.
The tasks that the subject pairs were given were designed to
gradually introduce system functionality. In the first task they
were shown an example of a building that had been completely
captured, and were asked to do likewise for a fresh, small plan.
In the second task they were asked to name the nodes and told
that patterns would be automatically detected. In the third task
they were asked to calibrate and to enter metadata, and finally
they were asked to check the metadata of a few nodes to ensure
this had worked correctly. The 10 subjects were all in their
20’s, and included males and females, with technical expertise
ranging from “terrible with computers” to those hinting that
they were very knowledgeable. Overall they found the system
usable and were able to complete all but one of the tasks easily.
Some users experienced difficulty at first in trying to insert
name and metadata information, and took some time before
right-clicking on the node; others immediately right-clicked.
On a scale of 1 (poor) to 5 (good) the majority rated the first
task a 5, with some choosing 4. In the second task a lot of
difficulty was experienced using pattern naming – users would
click on that button before entering any names at all, some did
so after entering only one name, and some entered several
names but then clicked on the button without selecting any
nodes to apply this to. It appeared that pattern recognition was
not understood by participants, and a help function or wizard
was needed. Alternatively a “next” button that is clicked
114
repeatedly could be used. Whichever of these options is
selected for novices, the existing procedure should be retained
as it is quickest for experienced users. The overall score for this
task was 3 (average). In the third task users rated the
calibration step as 4 out of 5, while metadata entry and
checking was rated 5 by most, and 4 by a few. Some users
disliked that all metadata for a node is displayed in one line
rather than having each item (e.g. staff name, telephone
number, printer, etc.) on a separate line, and one pointed out
that this would be inconvenient for editing when people moved
office.
To test pedometer-based distance measuring, 20 users were
asked to walk from A to B and the distance calculated by the
Tracker System was compared to the actual distance walked,
which was 28meters. The Tracker returned between 25.8m and
28.7m , with an average of 27.1m over the 20 tests, which is an
accuracy of 97%. Since indoor navigation is unlikely to involve
very long distances, a 3 percent error is acceptable, but
illustrates the need for the corner-snapping employed by the
Tracker (since in the worst of the 20 cases the error was as high
as 2.2m).
All 20 users were given a number of locations to visit in the
building using the Tracker system, and all were able to find
their way as directed every time – if the Tracker showed e.g.
that they had no further to go before turning right, but in fact
they had a wall on their right, they simply walked the extra
meter or so and then turned.
VI. CONCLUSION
Experiments showed that a cellphone pedometer is a viable
method of tracking a user and directing him or her to pre-
defined locations within a building. A cellphone is able to store
shortest-path data even for large buildings such as the largest
shopping centre in the southern hemisphere. Even a simple
interface was sufficient for users to correctly navigate a
building using such a mobile application.
The accuracy of the pedometer-based approach was
however not adequate to map out a building layout; it is only
suitable for navigation purposes when common sense is able to
deal with small errors. When slight inaccuracy became evident
to those users whose steps or stride length were not perfectly
calibrated, they remained happy to follow directions on the
understanding that distance remaining (to next instruction) was
approximate rather than exact. In an experiment involving 20
users, each was always able to follow directions correctly. Two
adjacent pathways right next to each other may however cause
navigation problems for those users whose step calibration was
not precise; fortunately such buildings are relatively rare.
The plan annotation method - capturing nodes and
pathways in a building by clicking over an image of the
building plan - and importing a file of information for each
node/room did prove to be a viable method for capturing
location and routing information. In our experiments most
usability ratings were 4 or 5 out of 5, with the exception of the
automated room-naming facility which was rated average. This
appears to be a fault of the interface design however, rather
than a problem with the pattern recognition method of
automatically naming rooms for entire corridors at a time.
 Storing node and shortest route data in a SQLite database
on a phone is practical in terms of both space and processing
requirements, and required only 2.6M for capturing the largest
shopping centre in the southern hemisphere.
Future work is recommended given our promising findings
with the prototype. An obvious improvement would be to show
the building plan on the mobile device as people navigate, but
space- and processor-efficient mechanisms would need to be
developed for this. The system could also be modified to assist
disabled people, for example by having voice input-output for
blind users along with phone vibration when a turning point is
near.
Additional capabilities could enhance the convenience of
deploying our application, such as having building-detail
databases stored on the Web. Using the phone’s GPS to
identify one’s location, this could then be automatically
downloaded on entering a building. Facilities for easily editing
information when changes take place in a building are needed.
In addition, the tradeoff in replacing the Routes relation with
one that saves space but requires more processing should be
investigated.
REFERENCES
[1] P. Bahl and V.N. Padmanabhan, “Radar: an in-building rf-based user
location and tracking system,” Proc. INFOCOM 2000, 19th Annual Joint
Conf. , IEEE, 2000,pp.775-784.
115
[2] M. Youssef and A. Agrawala, “The horus wlan location determination
system,” Proc. 3rd Int. Conf. on Mobiles Systems, Applications and
Services, ACM 2005,pp.205-218.
[3] R. Elias and A. Elnahas, “An accurate indoor localization technique
using image matching”, Proc. 3rd IET Int. Conf. on Intelligent
Environments, IET, 2007, pp. 376-382.
[4] K. Lin, A. Kansal, D. Lymberopoulos and F. Zhao, “Energy-accuracy
tradeoff for continuous mobile device location,” Proc. 8th Int. Conf. on
Mobile Systems, Applications and services, ACM 2010,pp.285-298.
[5] L. M. Ni, Y. Liu, Y. C. Lau and A. P. Patil, “Landmarc: indoor location
sensing using active rfid,” in Wireless Networks, vol. 10, pp. 701-710,
2004.
[6] J. Candy, “A mobile indoor location-based gis application,” Proc. 15th
Int. Symp. on Mobile Mapping Technologies, Padua, Italy, 2007.
[7] N. Ravi, P. Shankar, A. Frankel, A. Elgammal and L. Iftode, “Indoor
localization using camera phones,” {rpc/ 7th IEEE Workshop on Mobile
Computing Systems and Applications, IEEE 2006,pp.49-59.
[8] M. Azizyan, I Constandache, and R. Choudhury. “Soundsense: mobile
phone localization via ambience fingerprinting,” Proc. 15th Annual Int.
Conf. on Mobile Computing and Networking, ACM, 2009, pp. 261-272.
[9] D. K. Cho, M. Mun, U. Lee, W.J. Kaiser and M. Gerla, “Autogait: a
mobile platform that accurately estimates the distance walked,”
Proc.PerCom 2010, Int. Conf. on Pervasive Computing and
Communications, IEEE, 2010,pp.116-124.
[10] Z. Zhang, “A flexible new technique for cmera calibration,” in
Constraints, Microsoft 1998, pp.1-19
[11] M. Meijers, S. Zlatanova and N. Pfeifer, “3D geoinformation indoors:
structuring for evacuation,” Proc. Next Generation 3D City Models,
2005,pp.21-22.
[12] P. Y. Gillieron, D. Buchel and I. Spassov, “Indoor navigation
performance analaysis”, in Context, 2004, pp.1-9.