taleblazer: indoor positioning
TRANSCRIPT
TaleBlazer: Indoor Positioning
by
Eugenio Robert Fortanely
Submitted to the Department of Electrical Engineering and Computer Science
in partial fulfillment of the requirements for the degree of
Master of Engineering in Electrical Engineering and Computer Science
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
November 2015 ( f'<..b<.A.'4r") 'lo\ 6]
© Eugenio Robert Fortanely, MMXV. All rights reserved.
The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document
in whole or in part in any medium now known or hereafter created.
Signature redacted
JUL 1 9 2016
LIBRARIES
Author ...................... O." ...... .................... 't!7' .......... . Department of Electrical Engineering and Computer Science
November 16, 2015
Signature redacted Certified by ................ -:--.. ·~· .................................. .
Professor Eric Klopfer Director, MIT Scheller Teacher Education Program
Thesis Supervisor
Signature redacted Accepted by ..................... · r · ~~~~~; c;;,;~;,;;,i,;, :i T;,~;,;~;,
Chairman, fvlastcrs of Engineering Thesis Committee
2
TaleBlazer: Indoor Positioning
by
Eugenio Robert Fortanely
Submitted to the Department of Electrical Engineering and Computer Scienceon November 16, 2015, in partial fulfillment of the
requirements for the degree ofMaster of Engineering in Electrical Engineering and Computer Science
Abstract
TaleBlazer is a platform that allows for the design and play of iOS and Androidlocation-based augmented reality games. Until recently, TaleBlazer games could onlybe played outdoors. Indoor positioning is an active area of research. This thesis willexplore and evaluate a variety of more sophisticated alternatives to an existing, simpleindoor positioning scheme for TaleBlazer. None of the explored indoor positioningtechniques were satisfactory as a replacement scheme. In lieu of completely replacingthe existing scheme, a number of improvements were made to TaleBlazer's indoorpositioning.
Thesis Supervisor: Professor Eric KlopferTitle: Director, MIT Scheller Teacher Education Program
3
4
Acknowledgments
Thanks to Eric Klopfer for the opportunity to work on this project and the work he
has done in augmented reality games.
Thanks to Lisa Stump for all the work she has done getting TaleBlazer to where
it is today and all the help she gave me in adding my own piece to TaleBlazer.
Thanks to Judy Perry for keeping me project managed and from straying too far
off course.
Thanks to my fellow MEng students Ellen Finch, Jacqueline Hung, Manali Naik,
Sarah Edris, and Arjun Narayanan, as well as UROPs Elaine Gan, Kevin Chen, Sin
Kim, Mary Ann Jin, and Zachary Neely.
Thanks especially to Ellen Finch for laying the groundwork for TaleBlazer Indoor,
as well as for her support throughout my entire time at MIT. I can't believe the work
we did in this field.
Thanks to David Karger, Erik Demaine, and Constantinos Daskalakis for pushing
me into the depths of computer science further than I thought I was capable of
traveling.
Thanks to my family and friends for their support. I can't imagine where I would
be without them.
Finally, thanks to Fangfei Shen. Without her unending kindness and encourage-
ment, I absolutely would have never completed this undertaking.
5
6
Contents
1 Introduction
1.1 M otivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Background
2.1 Previous Augmented Reality Games
2.1.1 Environmental Detectives
2.1.2 Outbreak L the Institute .
2.1.3 Mystery at the Museum .
2.2 TaleBlazer . . . . . . . . . . . . . .
2.2.1 TaleBlazer Infrastructure . .
2.2.2 TaleBlazer Game Structure
3 Indoor Positioning Technology
3.1 Positioning vs Wayfinding . . . . . .
3.2 State of the Indoor Positioning Field
3.3 Overview of iBeacon Technology . . .
3.3.1 Distance finding . . . . . . . .
3.4 Indoor Positioning in TaleBlazer . . .
3.5 Positioning Techniques . . . . . . . .
3.5.1 Linear Least Squares . . . . .
3.5.2 Weighted Least Squares . . .
7
15
16
17
19
19
19
19
20
. . . . . . . . . . . . . . . . . . . 2 0
. . . . . . . . . . . . . . . . . . . 2 0
. . . . . . . . . . . . . . . . . . . 2 1
25
25
25
27
27
28
29
29
31
3.5.3 Positioning using Accelerometers, Gyroscopes, and Magnetome-
ters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.4 Pedestrian Dead Reckoning . . . . . . . . . . . . . . . . . . . 34
3.5.5 Augmenting Pedestrian Dead Reckoning with Bluetooth Low
Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.6 Other explored indoor positioning technologies . . . . . . . . . 37
4 Evaluation of Positioning Technologies 39
4.1 Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Evaluation Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Evaluation of Linear Least Squares . . . . ... . . . . . . . . . . . . . 39
4.4 Evaluation of Weighted Least Squares . . . . . . . . . . . . . . . . . . 40
4.5 Comparison to Random . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Evaluation of Inertial Sensors . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Evaluation of Step Detection . . . . . . . . . . . . . . . . . . . . . . . .44
4.8 Evaluation of Augmenting Pedestrian Dead Reckoning with Bluetooth
Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.9 Evaluation of AnyPlace . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Improvements to TaleBlazer 49
5.1 Distance Estimation Using iBeacons on Android . . . . . . . . . . . . 49
5.2 Customizable Proximity Thresholds . . . . . . . . . . . . . . . . . . . 50
5.3 Automated Beacon Sniffing . . ... . . . . . . . . . . . . . . . . . . . 51
6 Future Work and Conclusion 55
6.1 Future W ork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.1 Indoor Positioning . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.2 Beacon Management . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A Tables 57
8
B Pseudocode
9
59
10
List of Figures
2-1 TaleBlazer Editor Agent Dashboard . . . . . . . . . . . . . . . . . . . 22
2-2 TaleBlazer outdoor game at Boston Common . . . . . . . . . . . . . 23
3-1 Screenshot of Google Maps showing absolute user position . . . . . . 26
3-2 PDF and Gaussian of P(d), d = 5 meters, p - = 80.19, - = 1.383 . . . 28
4-1 Screenshot of Linear Least Squares prototype . . . . . . . . . . . . . 40
4-2 CDF of distance error of linear least squares . . . . . . . . . . . . . . 41
4-3 Screenshot of Weighted Least Squares prototype . . . . . . . . . . . . 42
4-4 CDF of distance error of weighted least squares . . . . . . . . . . . . 42
4-5 PDF of distance between two random points . . . . . . . . . . . . . . 43
4-6 CDF of distance between two random points . . . . . . . . . . . . . . 44
4-7 Linear acceleration over time while walking . . . . . . . . . . . . . . . 45
4-8 16 m walk using PDR and BLE augmented PDR. . . . . . . . . . . . 46
4-9 CDF of error of 16 m walk using PDR and BLE augmented PDR. . . 47
5-1 Beacon Distance Settings . . . . . . . . . . . . . . . . . . . . . . . . . 51
*5-2 TaleBlazer beacon tool during scanning . . . . . . . . . . . . . . . . . 52
5-3 TaleBlazer beacon tool after scanning . . . . . . . . . . . . . . . . . . 53
11
12
List of Tables
A.1 Mean of inertial sensors ... . . . . . . . . . . . . . . . . . . . . . . . 57
A.2 Standard deviation of inertial sensors . . . . . . . . . . . . . . . . . . 58
13
14
Chapter 1
Introduction
Mobile devices are integral to modern life. TaleBlazer is a software platform that
allows users to play and create their own location-based augmented reality (AR) mo-
bile games. TaleBlazer is developed by the MIT Scheller Teacher Education Program
(STEP) lab. TaleBlazer games augment the real world environment with a game via
mobile devices so that players become active participants in their environment, rather
than passive observers.
TaleBlazer's current main use case is outdoor games. TaleBlazer detects the user's
location while outdoors using GPS. GPS is not suitable for finding the user's location
indoors. This is because GPS works best when there is a clear line-of-sight from the
device to GPS satellites, but indoor environments attenuate and scatter signals used
for accurate trilateration. As a result, GPS typically has accuracy of 12 m in indoor
environments [251. The goal is to instead have an indoor positioning system with
sub-meter level accuracy. TaleBlazer currently supports basic indoor functionality, in
which games can detect if players are approximately within a certain radius of radio
wave emitting devices. This thesis will detail research to replace TaleBlazer indoor
functionality with more sophisticated indoor positioning techniques, as well as the
design, testing, and execution of improvements to it.
15
1.1 Motivations
The basic building block of a TaleBlazer game is an agent. An agent is an entity
that, when interacted with, executes a block of code that alters the state of the user's
game. When a player triggers an agent interaction, that agent is said to be bumped.
In outdoor games, an agent is bumped by GPS detecting that the player is close to
some specified coordinates. Until recently, indoor games were not possible, as GPS
does not function accurately indoors. Previous research has been conducted on aug-
menting TaleBlazer with the ability to play games indoors using one or more radio
wave emitting beacons [7]. These beacons use Bluctooth low energy, also known as
BLE or Bluetooth Smart. In the current system, agents could be configured to be
bumped when a player moves close to a radio wave emitting beacon. This technique
was sufficient for game designers and players for determining when to bump a particu-
lar agent ("positioning"), but not for guiding players through the space ("wayfinding").
In player feedback from the first indoor TaleBlazer pilot, players expressed a desire
to have the player's location constantly and accurately displayed on screen, similar
to the blue dot wayfinding design pattern commonly found in GPS-using wayfinding
applications like Google Maps. The development of TaleBlazer games is targeted
largely at educational institutions. These institutions have constraints on the in-
frastructure, setup, and gameplay of TaleBlazer indoor games. TaleBlazer's current
indoor positioning solution mostly delivers on the points of cost and visual impact,
but not adequately on the points of mobile platform independence, accuracy, and
ability to passively detect player location. Here passive player detection means the
player doesn't have to go out of their way for the game to detect their location, such
as by scanning a QR code. The goal of this thesis work is to meet the needs of
TaleBlazer game developers for indoor games that are as yet unfulfilled by existing
indoor functionality. As a result of this work, indoor gameplay for TaleBlazer is now
a shipping feature in TaleBlazer 3.0.
16
1.2 Chapter Summary
* Chapter 2 will describe previous work done by the STEP lab in augmented
reality games and its current main project in augmented reality: TaleBlazer.
* Chapter 3 will give an overview of the state of indoor positioning, as well as
present a sampling of techniques used in the field, many of which are based in
part on Bluetooth low energy technology. For some of these techniques, I will
make a proof of concept prototype, and others will be discarded as not suitable
for TaleBlazer.
* Chapter 4 will evaluate the accuracy of techniques described in chapter 3, as
well as their applicability to use for indoor TaleBlazer games.
* Chapter 5 will discuss other improvements made to TaleBlazer Indoor.
* Chapter 6 will suggest future work and conclude.
17
18
Chapter 2
Background
2.1 Previous Augmented Reality Games
The MIT STEP lab has been making augmented reality (AR) games since Environ-
mental Detectives in 2002 [18] [151.
2.1.1 Environmental Detectives
Environmental Detectives was an outdoor game that used an external GPS module for
positioning. Players attempted to locate the source of a ground water contaminant.
GPS was used as a mechanism for allowing players to sample ground water at various
locations.
2.1.2 Outbreak the Institute
Outbreak 0 the Institute was an indoor AR game that occurred in 2004 [27] [161.
Players took on the roles of doctors, medical technicians, and public health experts
seeking to contain an outbreak by understanding the model for how the disease spread
and by using that information to identify the disease's source. Players could become
infected by other game entities with a probability that was a function of what disease
the other entity had and how long the two spent in contact with one another. Each
room where Outbreak took place had a known Wi-Fi access point. Outbreak's po-
19
sitioning had approximately room-level accuracy, which was achieved by measuring
Wi-Fi access point signal strength.
2.1.3 Mystery at the Museum
Mystery at the Museum was an indoor AR game in 2008 [17]. Players assumed
the role of a technologist, biologist, or detective tracking a band of thieves who had
absconded with a priceless artifact from a museum. Mystery had a finer granularity
than Outbreak, as players interacted with their environment on both a room and
sub-room level. Room-level positioning was implemented using Wi-Fi signal strength,
while sub-room level interactions, such as identifying fingerprints on an exhibit case,
was implemented using infrared tags on items in the museum. Both Outbreak and
Mystery suffered from high setup cost for their positioning infrastructure.
2.2 TaleBlazer
TaleBlazer, which has been in development since 2011, is a software platform that
allows users to play and create their own location-based augmented reality mobile
games.
2.2.1 TaleBlazer Infrastructure
TaleBlazer has two main user-facing components: a mobile app available on iOS and
Android for playing TaleBlazer games and an online editor for creating TaleBlazer
games. TaleBlazer's backend consists of two main components: a server that hosts
the editor website, user accounts, and games, as well as an analytics server, which
records data about user behavior during mobile games. TaleBlazer mobile is devel-
oped in Appeclerator Studio, a platform allowing applications to be written in a single
Javascript codebase and then compiled into native iOS or Android apps.
20
2.2.2 TaleBlazer Game Structure
The basic building block of a TaleBlazer game is an agent, which is an entity that
players interact with. In outdoor games, players trigger interaction with agents by
moving close to specified coordinates, as detected by GPS. For example, suppose the
game designer wants a player to interact with a statue during an outdoor game. The
game designer would mark the statue on a map. When GPS detects that the player
is very close to that statue, the game interaction with the statue would trigger. In
indoor games, players trigger interaction with agents by being in proximity to a radio
beacon. Triggering such interactions is referred to as bumping. When an agent is
bumped, a block of code written by the game designer, or bump script, is executed.
It is also possible to allow players to tap agents on the game map to bump, both
in indoor and outdoor games. TaleBlazer games are created in the TaleBlazer web
editor.
21
t.4
$.4
control
Agont Dashboard
.i n N rro at Aqnt
two
Location
Accessibit,OF N", "gnWrded 0 ofhicv w 1dwhnR t
Agent :a idde -,M s .3Agent: . NO.T inldda ta
mantor SetttngsCan b pickEd jp Ca o d-p;
AQNgnaabearIar I I n !
'I"ch a n it45 s th'" plajer to bumrp '.r; agort?
Hwc Ie to the beacon doe5 'he piit yer avet bL to
immed ae atahm apprum anQl 0 5 Me r 1.e,-r !m*.hin p r m ey4mtrs
A a "M apr o mweNy 2o Mau
-oe h p yr ve tis be n th:e s,3me v regio A-s 1he
agenin.n s'derbsattrirger .hI nge -
On te dewas mlset yi defaI
S ype _Lmn Visibef
rJ'rup taitoickup Li'
Li ____
V 3450' IL
tis np iit-rn trop
hamrs
Ctnrte csnb'irn sot: difads
Value Vlsi hi
Figiur 2-1: TaleBlazer Ed.L itor iAgenit Daslioard
nit i
Wht -An.;s?
r Map ~
II
~i
'1'IA [~4r~ j
1 ~1 III
F [
I! [[II
u~n 22: icL [ zc( lli(o )O'giii 't B( )st(t Cntr I
24
Chapter 3
Indoor Positioning Technology
3.1 Positioning vs Wayfinding
Positioning as described in this paper is finding the location of a user's mobile device,
either absolute location or relative to another object. Wayfinding refers to the user's
ability to orient themselves and navigate the game space. Positioning and wayfinding
are well established in many GPS outdoor navigation apps, such as the one showcased
in Figure 3-1, which uses a blue dot to show a user's position overlayed on a map.
Indoor positioning and wayfinding, however, remain active areas of research. The goal
of this research is to achieve continuous and accurate indoor positioning to enable easy
user wayfinding and placement of agents in indoor games for Taleblazer.
3.2 State of the Indoor Positioning Field
Indoor positioning is far from a solved problem. There are a range of factors that
influence how applicable an indoor positioning technique is for a given use case, in-
cluding cost, required accuracy, visual impact, allowable power consumption, use of
dedicated infrastructure, security, and privacy. No current indoor positioning tech-
nique excels at all of these needs. All compromise between them. In this section, I
outline the techniques I implemented and explored for use in TaleBlazer.
25
Figure 3-1: Scrcenshot of Google Maps showing absolute user position
26
3.3 Overview of iBeacon Technology
iBeacon is a protocol specifying a data format sent by Bluetooth low energy devices.
The protocol specifies three fields: universally unique identifier (UUID), major, and
minor'. The devices that transmit data in this format are called beacons 11]. Dis-
tance from a given beacon may be estimated. Using these distance estimations from
beacons at known locations, it is possible to do approximate positioning for a de-
vice using various models. This thesis is a proof of concept for how accurate these
techniques utilizing beacons are in an indoor game environment. Beacons expose a
simplified interface for applications running on devices equipped with BLE receivers
to find distances from specific beacons. There are three proximities: immediate, near,
and far. Immediate represents that the user's device is very close to a beacon, likely
within one meter. Near represents approximately between one and three meters from
a beacon. Far represents greater than three meters, but still within range to receive
packets.
3.3.1 Distance finding
The radio signal emitted from a Bluetooth beacon is received by the Bluetooth re-
ceiver. The power of the signal is measured in the form of received signal strength
indication (RSSI). A common model for the relationship between RSSI and distance
is the logarithmic attenuation model:
dP(d) = P(do) - 10a log + X
do
where d is the distance at which power is measured, do is a known reference distance,
P(d) is the power measured at distance d, X is a normally distributed random variable
with mean 0, and a is a parameter dependent on the environment. [10] Figure 3-2
shows a density plot of experimentally obtained RSSI readings from a beacon at
'The UUID, major, and minor fields are editable, and the device owner may change them to anyvalue. This means that neither the UUID, nor the triple of UUID, major, and minor are necessarilyunique |ill.
27
Figure 3-2: IPDF an.d Gaussian of PTd), d = 5 meters, p
0.3
0.2
0
-S4 -82 -80 -78 -76
R.SSI IdBini
a dista1ce of 5 itieters deiimonstratiig the loiSO in 1 SSI readings T s in
tille rtlatioiiship betwveell (listan1e I 1(ad RSSI in indoor environinmeits is (11-w to the
111litjIatl effeCt3
.
3.4 Indoor Positioning in TaleBlazer
Taiewlazer cirrently supports basic Idbor positioiiing ulsing baconis. Gam1e design-
ers that wish to 11se T'al3lazwr indoors first ned to pur(ase beacons. They may
puri ast beacons froml ally beacon 1aiufActurr. T( (esier then inputs ch1 bea-
coi's UIID, major, and minor into the TaleBlazer editor, adl gives each beacon a
Inickname. A bacon's JUUID, Iajor. and lifol nmay )e mtodified by the designer
1using tlat bt iac inaiiufacture s proprietary app. TEi1hBlazer ageuts call )0 set to
trigger when a p1ayer is withi o1 of the three proxiit.ies of aIy specific beacoii.
2 1oi, lit dIisity f nctioiis will appear frequenly inl this paper. LOt X be a rinlodm Variable
sipht that th IixKists a 411o14 egativ fuinction f defined on -11 rcals ;I F ( ) satisiug that, forany set B or real nmbers, { L c } / ,I (x)L. f is t he probability density 11uiction 4.' X, and
X is thtii said to be a cionti-nuos rando vairiable 128|.31The1 multipath effect referns to Ohat a wkav'e, dulrinlg tranlsil betweenl two point~s, mlay take 1m1it iple
pat Is dli it Ole (lvir4lmn lt w t ra tvels through. This my result ill colistlictive initerflrnc1(14stil r ive inuttrfernit lit phase shiftin" of* the received si"Il 21
28
7F.
/// ___
/
S3/ 5/
8.9, (-T= 1.383
3.5 Positioning Techniques
Suppose there are several beacons transmitting from known positions. There are
many techniques for how to use this information to find the position of the receiving
device. I will focus first on techniques that use only beacons, then on fusion techniques
that combine beacon data with other sensor sources.
3.5.1 Linear Least Squares
Linear least squares is a technique for minimizing error. Suppose the device lies at
an unknown location in a plane, and there are distance estimates from the device to
some number of beacons. The device could be estimated to be anywhere, so a metric
to gauge the goodness, or error, of an estimate is needed. The error metric will score
a high value for unlikely estimates and a low value for likely estimates. Here, the
error metric will be the sum of the squared distances between the device's estimated
position and the closest point of a circle of radius r around each beacon, where r
is the estimated distance to that beacon. This means that several small deviations
are less costly in terms of error metric than one very large deviation. Linear least
squares is a closed form technique for computing the point that minimizes this error.
More formally, suppose there are n beacons labeled 1 ... i ... n. These beacons have
a position (xi, yi, zi) E R3 Vi. Let the receiver have a position (xO, Yo, zo) E R'. The
distance di between the receiver and beacon i can be expressed as
X=(xi - xo)' + (yj - yo)' + (zi - zo)'Vi-
Subtracting the nth equation, the reference transmitter 4 , from all the other equations,
4Any of the n equations could be chosen as the reference. The choice of the nth is to make theequations appear cleaner.
29
Rearranging terms, this system of equations can be expressed as the matrix
Ax = b
2(xi - x,)
2(x 2 - x,)
2(x,_1 - x,)
X2 X2 +9Y
2- 2 2
2 2 2'nI-i X'n +n i- I
2 (y, - y,)
2(y2 - y,,)
Yrt2(s1- ysf)
(40x=jo
The actual distances dis between the receiver and beacons are not known exactly,
but subject to noise. Using the estimated distances di, the system is reformulated as
Ax b
2 2X2 x 2 + Y 2
2 n 2
Y 2 Z.2~ -d2I' n I1Z ~ '
2 +z I2 + d2-d 2Y'nt + 2 Zn I
Let E R3 be the estimation of the position of the receiver. The estimated position
x with minimum error is desired. Let
= A - >.
30
2(zi - z,)
2(z 2 - Zn)
2(z,_- - z.)
-y + z- z.! + d"-dI
- y+ z - z 2+di - d 2
The choice of i that minimizes the error of the system defined to be E 1 is 1301
= (ATA)-'ATb.
In terms of computational complexity (A T A)IAT need only be computed once, which
requires one matrix inversion and three matrix multiplications. Matrix multiplication
of square matrices can be done in 0(n') time, which at time of writing w < 2.373
[341. However, the matrices being multiplied here are rectangular with at least one
constant dimension and are very small, so naive matrix multiplication, which takes
O(n3 ) for square matrices, is sufficient. ATA multiples matrices of size 3 x n - 1 and
n - 1 x 3, which takes O(n) time. Inverting AT A, which is of constant size, takes time
0(1). For matrix inversion, here Gauss-Jordan elimination is used in both linear and
weighted least squares, since the matrices to be inverted are small, although matrix
inversion can be done in 0(n'). Multiplying (ATA)- by AT, which are of dimensions
3 x 3 and 3 x n - 1 takes O(n) time. This matrix, the Moore-Penrose pseudoinverse,
need only be computed at the beginning of the algorithm and can be reused for
every set of distance estimates at all future time steps. During each time step, the
Moore-Penrose pseudoinverse is multiplied by b, of sizes 3 x n - 1 and n - 1 x 1
respectively, which takes time O(n). If m is the number of time steps the algorithm is
run for, the runtime of linear least squares is time O(nm). While linear least squares
is computationally light, it has low expected accuracy. Linear least squares is very
sensitive to outliers, which can cause large changes in estimated position.
3.5.2 Weighted Least Squares
If the estimated distance to a beacon is very small, then it is likely that such a distance
estimate has less error than an estimated distance to a beacon which is very large.
Weighted least squares leverages this by, in its error metric, weighting error from
small distance estimates more heavily than error from larger distance estimates. The
31
closed form for - in weighted least squares is
=(ATS-A)-ATS-b
where Ji is the square matrix of all Is of dimenion i, and S is the covariance matrix of
6 after noting that xi and yj are constants and the dis to other reference transmitters
are independent. S can be expressed as
l 0 0 ... 0
0 c 0 ... 0
S= 0 0 ci ... 0 +J_1d
0 0 0 1
[29].
Weighted least squares is much more computationally costly than linear least
squares. (ATS-lA)-ATS-1 must be recomputed during every time step, since S
has a dependence on the dis. This requires two matrix inversions and three matrix
multiplications. Note that ATS-1 appears twice in the computation and need only
be computed once. Here the computation is dominated by inverting S, which is of
size n - 1 x n - 1. Gauss-Jordan elimination is used, since n is small (typically no
larger than 10 due to the number of beacons placed a game space), which takes time
0(n3 ). If m is the number of time steps the algorithm is run for, linear least squares
runs in time O(n3 m). Weighted least squares is expected to be more accurate than
linear least squares. This is because it is less susceptible to outliers and leverages that
a beacon estimated to be close has a more accurate distance estimate than a beacon
estimated to be very far away.
32
3.5.3 Positioning using Accelerometers, Gyroscopes, and Mag-
netometers
Suppose the device was at a known position x E R' with noiseless 5 , world axis-aligned
accelerometers. It would be possible to double integrate the acceleration to find the
change in position. This is not a realistic model. Accelerometers on commercial
devices are subject to considerable noise. Double integrating this noise would yield
unusable position data.
Furthermore, the accelerometers of the device are not world axis aligned, but de-
vice axis aligned6 . Therefore, the device needs to know its orientation in the world's
coordinate system to give useful accelerometer data. Gyroscopes, which measure
rotation, can be used to find the rotational difference between two device orienta-
tions at different times. Magnetometers, which measure the magnitude and direction
magnetic fields, can be used to detect Earth's magnetic field in order detect the ap-
proximate declination of the device with respect to magnetic north7 . In conjunction,
these sensors can be combined in various sensor fusion models to get a more accurate
device orientation and acceleration information, but double integration techniques
yield insufficient accuracy.
Sensor Fusion Algorithm for Device Orientation
Device orientation can be approximated using accelerometers, gyroscopes, and magne-
tometers. Modern smartphones typically come equipped with these sensors. Android
has a sensor called rotationvector which returns the device's rotation vector as
(cos E, x sin e, y sin E, z sin 8).
5Here, noiseless means that acceleration is registered by the device's accelerometers only whenthe device experiences actual acceleration.
6The coordinate system of the device is defined as follows with respect to the screen on the device.The X axis points to right of the screen. The Y axis points to the top the screen. The Z axis isdefined by vector product X x Y, which point out of the screen 1121.
7Magnetic declination is the difference in angle between magnetic north and true north. Bostonhas magnetic declination -14'47'.
33
These last three components are the last three components of a unit quaternion.
The Y axis points to magnetic north, the Z axis points towards the sky, and the X
axis is the formed by the vector product Y x Z and points approximately east [121.
This rotation vector can be used to get the device's orientation by remapping onto
the device's coordinate system. rotationvector works by using a sensor fusion
algorithm known as a Kalman filter on accelerometer, gyroscope, and magnetometer
data. [32] [231
3.5.4 Pedestrian Dead Reckoning
People typically move around indoors by walking. Suppose the user at time step t - 1
has a position Xt- 1 and holds their device at a fixed height. Let 8 t be the walking
direction and Lt be the length of the step taken at time step t. The new position at
time t can be expressed as
[sin (el)1Xt = Xt-1 + Lt i Et
cos (EGt)
[131.
Step Length
A simple model for step length is that Lt is a fixed function of height. Weinberg [31]
showed that step length between various people at a fixed walking speed can vary
by as much as 40%. Furthermore, as people take smaller steps when walking slowly
and larger steps when walking quickly, step length for a given person can vary by as
much as 50%. Weinberg posited a more complex step length model to account for
this. During step t, let aran be the maximum acceleration measured and ami be the
minimum. Weinberg showed that the model
Lt = K(ariax- arrj.1 ) j ,
34
where K is a constant for unit conversion, approximates step length to within 8% of
true step length in 90% on steps taken I1.
Step Detection
Step detection can be done effectively with a threshold method [5]. First, the accel-
eration in the local reference frame of the device is remapped to the global reference
using the orientation sensor. Then, the vertical component of the acceleration is
extracted, and further computation is only done using this value. When vertical ac-
celeration exceeds a positive threshold, the user may currently be in a step. If the
user then reaches the negative threshold, then a step has occurred. If the user reached
the negative threshold too quickly after the positive threshold, faster than a person
could reasonably take a step, then a step is not considered to be taken. The user must
have negative acceleration exceeding the negative threshold before too much time has
passed (longer than a person could be taking a step) to have been considered as hav-
ing taken a step. If the user doesn't reach the negative threshold soon enough after
reaching the positive threshold, the user is no longer considered to be taking a step.
Pseudocode can be found in Appendix B.
Issues with Pedestrian Dead Reckoning
Pedestrian dead reckoning is subject to considerable drift without a means to update
the position model with additional environment details.
3.5.5 Augmenting Pedestrian Dead Reckoning with Bluetooth
Low Energy
Chen [41 proposed a Sequential Importance Resampling fusion algorithm for pedes-
trian dead reckoning where beacons can be used to correct drift. Let there be a sparse
beacon deployment in the positioning area, say less than one beacon per 64 m2 of
gameplay area. Let Xt be the estimated position of the user at time t. Let there
be K particles. Each particle i has a location X' and a weight wi, representing a
35
probability for how likely the device is to be at that location. The user begins with
their device at position X 0 E R2 . Let X' be the position of the ith particle at the tth
time step. Initialize the particles such that
X' N(Xo, u2 ), i = 0,1, K - 1.
Let w' be the weight of the i particle at the tth time step, with
1m ,i = 0, 1, ... , K - 1.0 K
After each time step, update each particle
.sin (Et)Xt = Xt-1 + Lt
cos (E)
Then, if one beacon is estimated to be within some threshold distance, 4 m in this
algorithm, perform the following steps. Let dt be the estimated distance from the
device to the beacon, based on RSSI. Let d" = I|P - XI11, where P is the position of
the known beacon and I I is the Euclidean norm. Let
P~dtctD= 1 (dt -d4 )2
P(dl| ) =- _ e 2a2
V/27ro.2
The new, un-normalized particle weights are
f%= 'witP(dtldt)-
t t I
The new, normalized particle weights are then
=
i= 1
36
Finally, whether or not the weights were changed, set the new estimated user position
to beK
Xt Vi=1
Pseudocode can be found in Appendix B.
Over an execution of the pedestrian dead reckoning with Bluetooth low energy
SIR algorithm, let m be the number of vertical acceleration samples taken, p be the
number of steps detected, and K be the number of particles. The time complexity of
this algorithm is O(m + pK).
3.5.6 Other explored indoor positioning technologies
Ubicarse
Ubicarse is a technology developed by Kumar at MIT investigated for integration into
TaleBlazer. Ubicarse claims low tens of centimeters of accuracy with no area map-
ping or calibration overhead. A device outfitted with a large array of antennae can
accurately detect the direction of incoming signals. [35] [141 Using this information, a
device could localize its position using Wi-Fi routers at known locations from public
databases [33], without requiring additional infrastructure. Multiple-input multiple-
output wireless cards are becoming more and more common. Ubicarse leverages this
change in hardware by using in-place rotation of a device with multiple receiving
antenna to simulate a large, circular antenna array. This is done with Translation
Resilient Synthetic Aperture Radar (SAR). As the antenna on the wireless card are
always a fixed distance apart, they are fixed relative to each other even during a rota-
tion of the device that isn't a perfect circle, and thus can be used to emulate a circular
array with one antenna rotating around the other. [211 However, this technique is
not yet viable for mobile devices because Ubicarse relies on channel state information
(CSI), rather than RSSI. Tools for retrieving this information from the wireless card
only currently exist publically for Intel 5300 series wireless cards [9]. These wireless
cards can be used on tablet computers, but not on modern smartphones. The CSI tool
used for this and similar research was done by former Intel employees while working
37
at Intel with access to proprietary code, tools, and documents. It is not expected to
support any significant new features or be made available for similar wireless cards
in the future [8]. At this time, Ubicarse does not seem suitable for indoor positioning
on mobile devices.
AnyPlace
AnyPlace is a crowdsourced indoor positioning technology by Zeinalipour and the
University of Cyprus. It aims to avoid dependence on calibration to a particular user
device, which plagues many other indoor positioning technologies. AnyPlace uses
RSSI differentials to make its map of an indoor space. That is, rather than dealing
in absolute RSSIs, readings that users submit are recorded as the difference between
the RSSI recorded and the RSSI recorded from a reference node, for each access point
besides the reference. Using submissions from a number of users recording RSSIs in
an indoor space, AnyPlace combines this data into a "radio map," a n by m matrix
where n is the number of distinct points in R2 with fingerprints and m is the number
of Wi-Fi access points. The fingerprints in the radio map correspond to a measure
of RSSI from a particular Wi-Fi access point at a particular location [20]. The
distance metric from the user's observed fingerprint V, is the Euclidean norm, that
is, di = ||V1 - Ku|Vi E 1 ... n. K-nearest neighbors8 or weighted k-nearest neighbors
is used to determine device location. In the unweighted case, the estimated location
is the convex combination of the k-nearest points, where all nearest neighbors have
weight 1. In the weighted case, their weight is inversely proportional to the Euclidean
norm of the difference between V, and the fingerprint. That is, wi oc tIv-111, This
is because, in the unweighted case, points included in the position calculation may
be very far from the actual location, and are given the same weight as very near
points. In the weighted case, very far points have a low weight, and do not affect the
position calculation much. This allows for greater expected accuracy at the cost of
minor additional computation. [31 [19j
'K-nearest neighbors is a classification algorithm that returns the k closest (by some distancemetric) points in a feature space to a given point.
38
Chapter 4
Evaluation of Positioning
Technologies
4.1 Evaluation Criteria
The core evaluation criteria are accuracy, cost, visual impact, mobile platform in-
dependence, and passively device location detection. Accuracy will be the primary
focus.
4.2 Evaluation Methods
The primary device used was an Android Nexus 7 Tablet, 2013 model. Secondary
evaluation was done using an iPhone 6.
4.3 Evaluation of Linear Least Squares
Linear least squares is not robust to error. Figure 4-1 shows the prototype linear least
squares app I implemented running. Solid red circles are beacons. The solid blue circle
is the device's estimated position. The black rectangle is the room in which the test
occurs. The concentric black circles surrounding the solid red circles are the estimated
distance between that given beacon and the device. All the distances estimated to
39
Figure 4-:Screenshot of' Lincar Least Squares prototype
beacons are w(ightcd equally i the position estimatio. NotW how the m idle b(acon
OIL tHi left Side has a Ver(l simall (sim aled distan1( but the estimated devicc position
is far from thaf beacon. T1his is (1u1 to linii1ar east sqars tiatilg a very small
distance estilite and a. vry large distanc estimate frm . )cacon as beingi cqally
MUliMl. Figure 4-2 shows a culiulative distribution fluCtiol Of its distance (r1or
Linear lpast Squares had a IIlediai1 error of 1.1 iii.
4.4 Evaluation of Weighted Least Squares
WX'eighted least squiares addisses one of the critical issues with linear least squares,
which is that very smiall distance estimates are treated to be as reliable as very far
distance estinatts. Figure 4-3 shows the weightcd least sqilares prototype I imiple-
iented. Notice how the veCry simall circehs along the l upper left edge of the room are
givenore weight due to the small estimated distance to the dovicc. Figure 1-i shovs
a lmulative distribution fuiction ot its istaIe (rrOr. WYCighItCd lCaSt s(1tarTes ha(d
r- o raldonil variable X, the fiction b! delind by F(x) = P X < .,- < < is ISCAledthe cim nh ive distribuhion funtmion of X 128| .
Mt
Beacon Test
Figure 4-2: CDF of distance error of linear least squares
0.8
0.6 F0.4 [0.2
0-0 1 2 3 4
Distance [m]
a median error of 1.4 m.
4.5 Comparison to Random
To gauge how effective the previous techniques were, compare them to a positioning
technique which gives no information. Suppose the device is at a position in a rect-
angular room chosen at random, and the positioning technique is to choose a position
in the room, with random uniform probability. With what probability will the device
be within a given distance of the randomly chosen position? Let the distance between
the two points be v and the dimensions of the rectangular room be a, b, a < b. In this
case, linear and weighted least squares as well as comparison to a random guess was
done in a room of dimensions a = 4.14 m, b = 5.51 in. The pdf of t is g,(v) = 2vg(v2 ),
41
-o
5 6
-. ........ .....
I,
4 0 U
lvt -i-3: Scivensliot, of XX~eigltt((I Lea4s Scluaes prMlotypt.yj
Fiigurve 1- 1: E'DI of dist811ic( eirror of \veigllted( lerist Sj~l'
U .6
6.2
6
' /
Listaiucc Iinj
,I2-
ils ;BeqcOnTeqt
Figure 4-5: PDF of distance between two random points
0.11
U 00 1 2 3 4
Distance [m]
-2 -~ 2A + 7r + sa2b ~ab2 ab a2
b2
-2 v'* a2b
1 + 2 arcsin () + -vs - a2
-b-+ arcsin (/) + 2vs - a2
-I + 1 arcsin ( )
+ - s -b 2 - -E - s
0 < s < a 2
a2 < s < b2
b2< s < as + b2
Figure 4-5 shows the pdf and 4-6 shows the cdf of a random guess. This shows that,
as noisy and error prone as linear and weighted least squares are, they represent a
significant step beyond nothing.
4.6 Evaluation of Inertial Sensors
The device's inertial sensors are critical to pedestrian dead reckoning. The mean
and standard deviation of the accelerometer, magnetometer, gyroscope, and linear
43
0.3
0.2
-o0
C''
5 6
where [261
g(s)
... ... ... ... ... ... .... ... ... ... ... ... .. ... ... ... ..I
Figure 4-6: CDF of distance between two random points
0.8
S0.6-
0.2
010 1 2 3 4 5 6
Distance [m]
acceleration sensors on an Android Nexus 7 I collected can be found in Appendix A,
tables A.1 and A.2. The most problematic sensor was the magnetometer. Earth's
magnetic field's magnitude ranges from 25 to 65 pT. The Earth's magnetic field is
relatively weak compared to the magnetic fields induced by electronic devices present
in a typical indoor game environment. As a result, frequent, large, and disorienting
spikes in magnetometer reading occur. This means that getting an accurate reading
on device orientation is not realistic. The orientation sensor is subject to considerable
variance due this inaccuracy in magnetometer readings. Under typical conditions, the
orientation sensor has a standard deviation of 12.8420. Abbe error, or error in angle
measurement, is magnified by traveling over a distance. This make positioning that
relies on accurate orientation readings unrealistic.
4.7 Evaluation of Step Detection
The step detection algorithm needs to know the user's height in advance. Figure
4-7 shows vertical acceleration data over the course of seven steps in a prototype I
implemented. The step detection algorithm was tested with 5 sessions of 100 steps
each, starting from a standing position. The number of detected steps were 98,
44
Figure 1-7: Linear accelcration Ov&I. time while walking
6IT1
Lo ED I
0 1 1000 2 ,000 3.000 10()0 5,000 6,()0(
Time insj
99, 99, 100, an11d 100 steps. This outprforiled oiiirn1ericial [2d1t s [24I. This
ilmprovemnit seems mnto sthy (lilt to proctssing global vertical a ccler(ation. as opp)std
to inre!y the nIagmitude of acceleration. The step detection algorithm was roblIst to
large and repuatel non-vertical ioviemits not 1eing detected as sttps. Furthermnor.
vertical muovemnirits that were too fast o1 too slow to be actual steps were 1iot detected.
Th critical issue with the step detectioi as part of an in(loor game as opposed to
a dediited I wayfinting execcist is tlt a tytical 11(10azer indoor gane occurs in
a IseIm-like setting an1(d involves txploring the game space. Trins means frequent
ij) arid down imoveienit while observing exIhibits at various height level and false
positives for step detection. Also, this mi ieans players are likly to amble or shuffIC
as they it ok around, rather than taking full strides. Finally, an issue with the step
detect!iIon for TaleBlazer ganes is that it requires taking stps. Players whoi are not
capable of walking would not be able to play, which is an issue for an educational
setting.
45
Figure 4-8: 16 In walk using PDR and BLE augmented PDR
6-Augmtented Pcdcstrialn Dead Rcckonling
5 Pedestrian Dead ReckoningActu al Walked Path
1
-2 0 2 1 6 8 10 12
x-distaniic 111
4.8 Evaluation of Augmenting Pedestrian Dead Reck-
oning with Bluetooth Low Energy
Figure 1-8 shows a walk using v1illa pcdestriat dead reckolnig (red). pedestir ial
dead reckoning allgnlted with Bluetooth low energy SIR (1bdue). and the actual
patll walked (green), whilk figure 1-9 shows the CIDF of the wroi (luring that ,qule
walk. Pedestrian dead reckoning is subject to considerali drift. BLE SIR was
able to correct for the drift somnewhat. iniprovIg the median 1rr1 by 0.73 in. This
iniproveinct is still not sufficient to mak pedestr ian dead reckoning a viable indoor
positioning ti chinique for use in TaleBlazer.
4.9 Evaluation of AnyPlace
Anylate rived second place in the first annual Microsoft Indoor Localization
Competition at the International Conference on Information Processing in Sensor
Networks (IPSN) 2014, boasting 1.93m of accuracy (m11 average ini a 300w1 area using
10 Wi-Fi access poiiits |2. AnyPlace relies on significant, iuscr-contributed data to
Figurc -19: CDF of ('ror of 16 ill walk using PDR antd BLE iigiiented PDR
0.8
0.6
0.41
0.2
0>0 1
Dis
A nedPedestrisr DiadD Rec[kei ingPccdc strian Dead Reckoning
2 3
tanice [,111
iake a radio miap of any indor location. No)st of thes well-I1apped locatioin a'
in Cyprus, wihe're tIn alithors of AnyPlace are. At finle of writing, the only two
locationls1 with AnyPlace calibration in the United States are in New York City. I
tested AnyPlate in both locations: Ole Museum of AModern Art (MoMA.) ad B&1ki1,
a11 electroiics slperstore. Ill both} locations, the results Were siinilar to pedestrian.1
(leafl relkoning with a randoni heading. Even signifiant imovemnent frnn oe corner of
a. building to the opposite cormier barely restlted in much met I1oXv3 nent in A ityPlac
Front tlie originaI posit ion.
7K
//
//
48
Chapter 5
Improvements to TaleBlazer
In addition to experimenting with various indoor positioning technologies, I made
several improvements to existing TaleBlazer Indoor functionality.
5.1 Distance Estimation Using iBeacons on Android
Previously, TaleBlazer Indoor functionality was supported on iOS but not Android.
This was because the distances at which a beacon packet was considered to be at the
immediate, near, and far proximities were different. The most egregious difference
was that the near/far threshold in practice was at 7.5 meters for iOS devices and
at 22.5 meters for Android devices [7]. The immediate/near boundary was around 1
meter on both devices. TaleBlazer uses the beacon library for Android, which relies
on an erroneous distance finding model. I corrected that model, and TaleBlazer now
uses that corrected version. For a given beacon, let r be the RSSI received by the
device from that beacon, p be the factory-programmed constant of the power that
a device should receive from that beacon at a distance of 1 meter, and d be the
estimated distance of the beacon as a function of p and r. Previously, beacon library
for Android on Appeelerator Titanium, liferay-android-beacons [61, had calculated d
by
49
d(r,p) =
0.89976(-)7-795 + 0.111 1
The model
d(r,p) = 9.92908786(,) 2.56957405 - 7.91675857
was found to have error with a mean of 0.2787 meters and a standard deviation of
1.045 meters. This model was chosen for having the minimum mean squared error,
over all models of the form d(r, p) = a( r)b + c for 10,000 packets received over the
course of an hour at distances from 0.25 meters to 9 meters. Using this model,
Android devices reliably triggered immediate agents at distances less than 1 meter,
near agents at less than 3 meters, and far agents otherwise. Now that the distance
finding model has been corrected, distance finding using beacons delivers same results
on Android devices as it does on iOS devices. Now TaleBlazer users can expect to
have a platform independent game play experience.
5.2 Customizable Proximity Thresholds
The proximities of near, immediate, and far are a function of distance estimation.
Distance estimation from a beacon is affected by the real distance between a beacon
and receiving device, the disturbances from the environment carrying the beacon
packets (such as walls, furniture, and moving bags of water known as people), and
the power level at which the beacon broadcasts. The proximity thresholds for near,
immediate, and far behave differently between iOS and Android. These thresholds
(which were fixed constants) are not one size fits all, as different games may have
different proximities at which they want to engage the user from a point of interest.
Immediate might be too close for some games, while near may be too far for others.
In order to give the game designer maximum configurability over their game, these
distance thresholds can now be specified by the game designer. These thresholds can
be made in the TaleBlazer editor.
50
Beacon distance estimation during ganelay is imprecise. It the default settings are not right foryour garne in your space, adjust the settings and retest until you are satisfied.
Think of these values as approximrate and relative to each other instead of absolute measurementsof distances.
For best results, all beacons in your game should be the same make and model and have the samehardware settings.
Consider beacon proximity to be immediateWhlen beacon reports itself to be within 1 met rs,
Consider heacon proximity to he near
when beacon reports itself to be within 3 Meters.
Suppress far beacon signalswhen beacon reports itself to be farther than 20 meters
OK Cancel
Fiur1 1 5-1: Beacon Distance Settings
Addlititia1Iy, AidrItoidi dviCes mayd l gnize lleals fro1 as fr awy Oas far 4t0
meters in open s)aees. At this distanil. promipting the pliyr with itifornatiOni
reari ding somlie spec tin loptol1lL) to 40 iieters awa would be distracting at best
and disorientiing at worst. Tiherefore., the game desigiier flow tins the optioll. which is
C)11 1A default, to supprss tar proxii ity )ll.lk('ts from 20 imeters or more away froin
the 5user's deviCC'.
5.3 Automated Beacon Sniffing
Adding bie1acons to TaeBIlazer was previou"siy a tedious process. It involvedl using
ai extrlntal app to get a, beacon's UUID, iajor, and iiinor. Th n, tHie sr needed
[!o mianually transcribe that nforniation in the TaleBlazer editor. There was no
effective means of dliffereiitia-ting betweei bearclnts. This I)F1ess was very er or prone,
esj)ecill since the UUID was a sequence of 16 i exaldecaimal digits. Now, IaleBlazer's
iolnit'le app includes the fuionaljty to detect I1tacons a111 alidd then to tdaeBlZier s
(tdit r.
51
F-gin 5-2: TdtC3Ol'e Ihecwoll t,()() (Illtlllgl Sc 1,111111i)
52
Place one beacon at a time next to yourdevice. Rescan to detect the beacon. Enter anickname to identify the beacon later. Emailthe results so you can copy and paste intoyour TaleBlazer game.
0)Rescan Emi
5 beacons found.
Nickname
UUID: b9407f30-f5f8-466e-aff9-25556b57fe6dMajor: 40424Minor: 57920Proximity: immediate
Nickname
UUID: f7826da6-4fa2-4e98-8024-bc5b71 e0893eMajor: 32949Minor: 34361Proximity: immediate
Fitgure 5-13: TalI1bLazr beacoin tool after scanning
5 .
54
Chapter 6
Future Work and Conclusion
6.1 Future Work
6.1.1 Indoor Positioning
Indoor positioning is still a very active field of research. This thesis explored the
current state of indoor positioning and its applicability for use in TaleBlazer. Cur-
rently, TaleBlazer can detect if a player is approximately within a certain radius of a
beacon. The techniques explored in this thesis achieved median accuracy in the 1.5
m to 2 m range. No current technique for continuous device positioning technique
was suitable enough to merit inclusion in augmenting TaleBlazer's current indoor
positioning scheme. As the state of indoor positioning improves, a solution that sat-
isfies the cost, visual impact, mobile platform independence, accuracy, and constant
positioning needs may replace the current TaleBlazer indoor.
6.1.2 Beacon Management
Beacons are currently difficult to manage for TaleBlazer game designers. Once bea-
cons are added to a game designer's list of beacons in the editor, the game designer
has no easy means to detect which beacons are still present or missing, which bea-
cons are low on power, and how to replace their beacons for a consistent experience
across all their games. Improving beacon management for TaleBlazer indoor may be
55
a future MEng project for the STEP lab.
6.2 Conclusion
The TaleBlazer platform allows for the design and play of iOS and Android location-
based augmented reality games, both indoors and outdoors. This thesis explored a
variety of alternatives to an existing, simple indoor positioning scheme. None of the
explored indoor positioning techniques were satisfactory as a replacement scheme,
and further improvements were made to the existing TaleBlazer indoor functionality.
Indoor positioning is an active field of research. Future advancements in the field
may drastically improve TaleBlazer's indoor game playing functionality.
56
Appendix A
Tables
mean UnitSensor
x y z
Accelerometer -1.2699 x 10-1 6.3121 x 10- 9.7415 x 100 ,92
Magnetic Field 2.3569 x 101 2.9373 x 101 -8.3211 x 100 pT
Linear Acceleration 3.6328 x 10-5 6.6845 x 10- 5 -1.1976 x Io5 M
Gyroscope 3.4481 X 10- 4 2.0380 x 10- 4 8.5678 x 10-6 rad
Table A.1: Mean of inertial sensors
57
Sensor std dev Unit
x y z
Accelerometer 5.8624 x 10~ 9.3360 x i0-3 1.1650 x 10-1 r2
Magnetic Field 5.4890 x 10-1 7.4940 x 10-1 2.9834 x 10-1 pT
Linear Acceleration 4.8069 x 10-4 4.3963 x 10-4 3.6144 x 10-4
Gyroscope 1.7061 x 10-2 2.0448 x 10-2 3.1214 x 10-2 rad
Table A.2: Standard deviation of inertial sensors
58
Appendix B
Pseudocode
59
Algorithm 1: Step Counting Algorithm
f +- frequency of vertical acceleration sensor (in 1)
t +- step threshold (in n)
a +- lower step frequency threshold (in )
a +- upper step frequency threshold (in )
stepCount +- 0
takingStep +- false
stepInterval +- 1 (# of vertical acc readings during current step)
m +- # of readings a[,..., m - 1] +- vertical acceleration readings (in g)
for i = 0 to 7n - 1 do
if not takingStep and a[ij > t then
L takingStep +- true
stepDuration - stepInterval
if takingStep then
if stepDuration < a then
L stepInterval + +
else if stepDuration > / thentakingStep +- false
stepInterval +- 1
else
if a[i] < -t thenstepCount + +
takingStep <- false
stepInterval +- 1
else
L stepInterval + +
60
Algorithm 2: Pedestrian Dead Reckoning with Bluetooth Low Energy SIR
q +- # of steps taken
K +- # of particles
T +- calibration range threshold (in m)
o r- std dev of particle distribution (in m)
Oble +- std dev of distance estimation of beacon (in m)
X[O, 1] *- (x, y) E R2 known initial device position
X[0, .. , K - 1][O, 1] +- N(Xo, O2)K
m[0, ... , K - 1] +- [ , ]
for t = 1 to q do
L +- length of step (in In)
e +- angle of step (in rad clockwise from magnetic north)
d +- es'timated distance of closest beacon based on RSSI (in m)
P[O, 1] +- position of closest beacon E R2
for i= 0 to K - 1 do
X [i] [0] = X[i] [0] + Lt sin (Er)
X[][1] X[i][1] + Lt cos (6t)
if d < T then
d[0, .. ., K - 1], P[0, ... ., K - 1],,&[0,1.. ., K - 1] + [0, 1 0]
'tbSu'm +- 0
for i 0 to K - 1 do
P[i] +- 1 eK ,2, e 2'-bI,
for i = 0 to K - 1 doK t[i] +- w[i] x p[i]
tbSum+ = z[i]
for i = 0 to K - 1 do
X[0, 1] +- [0, 0]
for i = 0 to K - 1 do
for j=0 to 1 do
L X[j] = w[i] x X[i][j]
61
62
Bibliography
[1] D. Alvarez, R.C. Gonzalez, A. Lopez, and J.C. Alvarez. Comparison of steplength estimators from weareable accelerometer devices. In Engineering inMedicine and Biology Society, 2006. EAIBS '06. 28th Annual International Con-ference of the IEEE, pages 5964-5967, Aug 2006.
[2] Thomas Callaghan, Nicolai Czink, Francesco Mani, Arogyaswami Paulraj, andGeorge Papanicolaou. Correlation-based radio localization in an indoor environ-ment. EURASIP Journal on Wireless Communications and Networking, 2011(1),2011.
[3] G. Chatzimilioudis, A. Konstantinidis, C. Laoudias, and D. Zeinalipour-Yazti.Crowdsourcing with smartphones. Internet Computing, IEEE, 16(5):36-44, Sept2012.
[4] Zhenghua Chen, Qingchang Zhu, Hao Jiang, Han Zou, Yeng Chai Soh, LihuaXie, Ruoxi Jia, and Costas Spanos. An ibeacon assisted indoor localization andtracking system. In Industrial Electronics and Applications (ICIEA), 2015 IEEE10th Conference on, 2015.
[5] Zhenghua Chen, Han Zou, Hao Jiang, Qingchang Zhu, Yeng Chai Soh, and LihuaXic. Fusion of wifi, smartphone sensors and landmarks using the kalman filterfor indoor localization. Sensors, 15(1):715, 2015.
[6] James Falkner. liferay-android-beacons. https: //github. com/j amesfalkner/liferay-android-beacons, 2015.
[7] Ellen Yongin Finch. Taleblazer: Using ibeacons for indoor location-based aug-mented reality games. Master's thesis, Massachusetts Institute of Technology,June 2015.
[8] Daniel Halperin. Linux 802.11n csi tool: Faq, things to know,and troubleshooting. https://developer.apple.com/ibeacon/
Getting- Started-with- iBeacon. pdf, 2012. [Online; accessed 20-September-2015].
[9] Daniel Halperin, Wenjun Hu, Anmol Sheth, and David Wetherall. Predictable802.11 packet delivery from wireless channel measurements. In Proceedings of theACAM SIGCOMM 2010 Conference, SIGCOMM '10, pages 159-170, New York,NY, USA, 2010. ACM.
63
[101 M. Hatay. Empirical formula for propagation loss in land mobile radio services.Vehicular Technology, IEEE Transactions on, 29(3):317-325, Aug 1980.
[111 Apple Inc. Getting Started with iBeacon version 1.0. https://developer.apple. com/ibeacon/Getting-Started-with-iBeacon.pdf, 2014. [Online; ac-cessed 11-September-2015.
[121 Google Inc. Using the rotation vector sensor. https: //developer. android.
com/guide/topics/sensors/sensorsmotion. html, 2015. [Online; accessed
25-October-20151.
[131 Yunye Jin, Hong-Song Toh, Wee-Seng Soh, and Wai-Choong Wong. A robust
dead-reckoning pedestrian tracking system with low cost sensors. In Pervasive
Computing and Communications (PerCom), 2011 IEEE International Confer-ence on, pages 222-230, March 2011.
[141 Kiran Joshi, Steven Hong, and Sachin Katti. Pinpoint: Localizing interferingradios. In Proceedings of the 10th USENIX Conference on Networked SystemsDesign and Implementation, nsdi'13, pages 241-254, Berkeley, CA, USA, 2013.USENIX Association.
[151 E. Klopfer, K. Squire, and H. Jenkins. Environmental detectives: Pdas as awindow into a virtual simulated world. In Wireless and Mobile Technologies inEducation, 2002. Proceedings. IEEE International Workshop on, pages 95-98,2002.
[161 Eric Klopfer. Augmented learning: Research and design of mobile educationalgames. Mit Press, 2008.
[171 Eric Klopfer, Judy Perry, Kurt Squire, Ming-Fong Jan, and ConstanceSteinkuehler. Mystery at the museum: A collaborative game for museum ed-ucation. In Proceedings of th 2005 Conference on Computer Support for Collab-orative Learning: Learning 2005: The Next 10 Years!, CSCL '05, pages 316-320.International Society of the Learning Sciences, 2005.
[181 Eric Klopfer and Kurt Squire. Environmental detectives-the development of anaugmented reality platform for environmental simulations. Educational Technol-ogy Research and Development, 56(2):203-228, 2008.
[191 A. Konstantinidis, G. Chatzimilioudis, D. Zeinalipour-Yazti, P. Mpeis,N. Pelekis, and Y. Theodoridis. Privacy-preserving indoor localization on smart-phones. Knowledge and Data Engineering, IEEE Transactions on, PP(99):1-1,2015.
[20] A. Konstantinidis, G. Nikolaides, G. Chatzimilioudis, G. Evagorou,D. Zeinalipour-Yazti, and P.K. Chrysanthis. Radio map prefetching for indoornavigation in intermittently connected wi-fi networks. In Mobile Data Manage-ment (MDM), 2015 16th IEEE International Conference on, volume 1, pages34-43, June 2015.
64
[211 Swarun Kumar, Stephanie Gil, Dina Katabi, and Daniela Rus. Accurate indoorlocalization with zero start-up cost. In Proceedings of the 20th Annual Interna-tional Conference on Mobile Computing and Networking, MobiCom '14, pages483-494, New York, NY, USA, 2014. ACM.
[22] Dimitrios Lymberopoulos, Jie Liu, Xue Yang, Romit Roy Choudhury, VladoHandziski, Souvik Sen, Filip Lemic, Jasper Buesch, Zhiping Jiang, Han Zou,Hao Jiang, Chi Zhang, Ashwin Ashok, Chenren Xu, Patrick Lazik, NiranjiniRajagopal, Anthony Rowe, Avik Ghose, Nasim Ahmed, Zhuoling Xiao, HongkaiWen, Traian E. Abrudan, Andrew Markham, Thomas Schmid, Daniel Lee, Mar-tin Klepal, Christian Beder, Maciej Nikodem, Szymon Szymczak, Pawel Hoff-mann, Leo Selavo, Domenico Giustiniano, Vincent Lenders, Maurizio Rea, An-dreas Marcaletti, Christos Laoudias, Demetrios Zeinalipour-Yazti, Yu-Kuen Tsai,Arne Bestmann, Ronne Reimann, Liqun Li, Chunshui Zhao, Stephan Adler, Si-mon Schmitt, Vincenzo Dentamaro, Domenico Colucci, Pasquale Ambrosini, An-dre Ferraz, Lucas Martins, Pedro Bello, Alan Alvino, Vladica Sark, Gerald Pirkl,and Peter Hevesi. A realistic evaluation and comparison of indoor location tech-nologies: Experiences and lessons learned. In The 14th A CM/IEEE Conferenceon Information Processing in Sensor Networks (IPSN '15). ACM - Associationfor Computing Machinery, April 2015.
[23] Michael Johnson Mathias Agopian, Max Braun. Fusion.cpp. https://android.googlesource.com/platform/frameworks/native/+/b398927/services/sensorservice/Fusion.cpp, 2011. [Online; accessed 25-October-20151.
[24] M. Oner, J.A. Pulcifer-Stump, P. Seeling, and T. Kaya. Towards the run andwalk activity classification through step detection - an android application. InEngineering in Medicine and Biology Society (EMBC), 2012 Annual Interna-tional Conference of the IEEE, pages 1980-1983, Aug 2012.
[25] S. Pandey and P. Agrawal. A survey on localization techniques for wirelessnetworks. Journal of the Chinese Institute of Engineers, 29(7):1125-1148, 2006.
[261 Johan Philip. The probability. distribution of the distance between two randompoints in a box. In TRITA MAT v7' i10, 2007.
127] Eric Rosenbaum, Eric Klopfer, and Judy Perry. On location learning: Authenticapplied science with networked augmented realities. Journal of Science Educationand Technology, 16(1):31-45, 2007.
[28] Sheldon Ross. First Course in Probability, A (8th Edition). Prentice Hall, 8edition, January 2009.
[291 P. Tarrio, A.M. Bernardos, J.A. Besada, and J.R. Casar. A new positioning tech-nique for rss-based localization based on a weighted least squares estimator. InWireless Communication Systems. 2008. ISWCS '08. IEEE International Sym-posium on, pages 633-637, Oct 2008.
65
[30J Paula Tarrio, Ana M. Bernardos, and Jos6 R. Casar. Weighted least squarestechniques for improved received signal strength based localization. Sensors,11(9):8569, 2011.
[311 Harvey Weinberg. Using the ADXL202 in Pedometer and Personal NavigationApplications, Analog Devices, Rev.0 edition.
[32] Greg Welch and Gary Bishop. An introduction to the kalman filter. Technicalreport, Chapel Hill, NC, USA, 1995.
[331 WiGle. Database. https://wigle.net/, 2015. [Online; accessed 06-November-20151.
134J Virginia Vassilevska Williams. An overview of the recent progress on matrixmultiplication, 2012.
[351 Jie Xiong and Kyle Jamieson. Arraytrack: A fine-grained indoor location system.In Proceedings of the 10th USENIX Conference on Networked Systems Designand Implementation, nsdi'13, pages 71-84, Berkeley, CA, USA, 2013. USENIXAssociation.
66