|
MobiSys '05 Paper
[MobiSys '05 Technical Program]
Deploying and Evaluating a Location-Aware System
R. K. Harle
Computer Laboratory
University of Cambridge, UK
Robert.Harle@cl.cam.ac.uk
A. Hopper
Computer Laboratory
University of Cambridge, UK
Andy.Hopper@cl.cam.ac.uk
Abstract
Location-aware systems are typically deployed on a small scale and
evaluated technically, in terms of absolute errors. In this paper, the
authors present their experience of deploying an indoor location
system (the Bat system) over a larger area and running it for a period
exceeding two years.
A number of technical considerations are highlighted: a need to
consider aesthetics throughout deployment, the disadvantages of
specialising sensors for location only, the need for autonomous
maintenance of the computational world model, the dangers in
coinciding physical and symbolic boundaries, the need to design for
space usage rather than space and the need to incorporate feedback
mechanisms and power management. An evaluation of long term user
experiences is presented, derived from a survey, logged usage data,
and empirical observations. Statistically, it is found that
35% wear their Bat daily, 35% characterise their Bat as useful, privacy
concerns are rare for almost 90% of users, and users cite the
introduction of more applications and the adoption of the system by
other users as their chief incentives to be tracked.
Thia paper aims to highlight the need to evaluate large-scale deployments of
such systems both technically and through user studies.
1 Introduction
Location-aware computing is an emerging field where the location of
people and objects can be used by machines to derive contextual
information with which to enhance and assist users in all aspects of
their lives. Indoor environments are of particular interest,
potentially requiring high precision location information (of the
order of centimetres) to infer useful contextual clues from the
typically dense distribution of small objects such as computers,
telephones, and chairs. Many indoor location systems have been
implemented in attempts to achieve such high precision. Over time the
field has seen positioning solutions that utilise infrared (room-based
accuracy [12,6,13]), ultrasound (centimetre
accuracy [14,10,7]), visible light (10-100cm
accuracy [11,8]), wireless LAN (metre
accuracy [1,2,15]) and Ultra Wideband (UWB,
approximately 15cm accuracy).
Historically, deployments of high precision indoor location systems
have not involved large coverage areas due to the cost of
instrumenting the environment. The most common approach is to
instrument a single room, which then acts as a testbed for the
location technology. However, this approach fails to represent a
deployment from which usage characteristics can be reliably
derived. Usage of such a room is likely to be sporadic and not
representative of how users would use the space normally. In one
attempt to address this, AT&T Research Cambridge and the University
of Cambridge jointly developed the Bat system and deployed over a
greater area.
2 The Bat System
The Bat system is an ultrasonic location system that makes use of a
small, powered tag known as a `Bat' (Figure 1). Bats
are encased in sturdy plastic, with approximate dimensions of
8.0×4.0×1.5cm and a weight of 50g. They can be worn on a
necklace or attached to a belt clip, according to preference. Bats
emit 40kHz ultrasonic pulses on command from a 433MHz radio
channel. These pulses are received by a matrix of receivers in the
ceiling, each accurately surveyed for position. Each receiver records
the time elapsed between pulse emission and reception, thereby
allowing determination of each Bat-receiver separation and hence
calculation of the Bat position using a multilateration
algorithm. Positional accuracy has been previously determined as
within 3cm 95% of the time.
Figure 1: A ceiling receiver (left) and a Bat (right). Inset: An
installed receiver
A number of applications are presently associated with the Bat
system, the most salient of which are as follows:
- Map
- A graphical map of the coverage area designed for desktop
machines.
- Broadband Phone Map
- A privacy-oriented version of the map,
designed to run on a networked broadband phone installed on every
desk (Figure 2).
- Teleporting/hotdesking
- Users can `teleport' any of a number of
computer desktops to their nearest machine for truly mobile working.
- Access Control
- A display with a touch screen interface is mounted
at the entrance to the laboratory. Visitors are presented with a list
of tracked users who they can alert to their presence and then be
directed to the current location of their host.
- Pointing device
- Bats can be used as a three-dimensional pointing device,
analogous to a desktop mouse.
- Scanner
- The Bat system provides a convenient and intuitive
interface to a number of peripherals, including a scanner.
- Gaming
- A few simple location-based games have been developed.
- User-written
- There is a large number of small applications that
users have developed mostly for personal use. These include alerts for
people returning to the office, new email notification, fresh coffee
notification, diary reminders, etc. [9].
Figure 2: A broadband phone showing a tracking application
The initial deployment of the Bat system at AT&T Research Cambridge
covered three floors of a building and provided positioning almost
throughout the volume. In this deployment, additional applications
were available, including location-based telephone call routing and
location-based physical access control. Unfortunately, this
deployment is no longer in place.
3 Redeploying the Bat system
Following the decommissioning of the initial deployment, the Bat
system was redeployed at Cambridge in 2002. Since then the authors
have accrued some valuable general lessons in deploying a pervasive
location system over a large area, which are shared here. The lessons
are broadly classified into system and user issues. The former deals
with issues caused by installing and maintaining the system, whilst
the latter considers the experiences of the day to day users.
The redeployment covers a floor area of approximately 450m2 and
contains seventeen offices and five communal areas (Figure
3). Positioning coverage is throughout the volume, except
for within a small kitchen area and the bathrooms.
Figure 3: The deployment area of the Bat system at Cambridge
The deployment was performed as the last stage of building work, after
the structural components were installed, but before office
furnishings and users were present. Installation, configuration and
troubleshooting took approximately eight weeks, during which a
number of general issues concerned with the installation and running
of the system hardware were identified.
4 System Issues
Mistakes are expected in the deployment of any prototype hardware over
a large volume. Here we present a summary of the lessons generated
from the deployment.
4.1 Design to be aesthetically pleasing and for minimal distraction
Aesthetics are often overlooked when generating prototype
hardware. However, evaluation over a medium- to large- scale
deployment means that the hardware will penetrate into the working
area of a wide variety of people and aesthetics are vitally important
to ensure a pleasant working environment is maintained. The Bat system
receivers were designed to be installed above a false ceiling and as
such hidden from view. Thus aesthetics at design time were of
little concern and the hardware consists of open circuit board
shielded by a metal box and interconnected by blue 50-way ribbon cable
(Figure 1). These design choices proved a constraint
when deploying in the laboratory: a false ceiling had to be installed
at extra cost and even then it was required to have `egg crate'
ceiling tiles to prevent disruption of air flow in the building
(inset, Figure 1). Hence the receivers and their
interconnects are more visible than planned. Moreover, the displeasing
aesthetics of the hardware has hindered subsequent attempts to
redistribute the receivers in a more spatially homogeneous fashion.
4.2 Design for space usage rather than physical space
When deploying Bat receivers in the ceiling, selecting the ideal
spatial distribution proved very difficult. Regular geometric patterns
are not conducive to position calculation, whilst irregular
distributions have negative aesthetics. In the current deployment,
receiver locations were chosen to to avoid regular geometry and to
give a reasonable spatial distribution for a sighting at any point in
a room (Figure 4). The distributions derived from
the combination of practicalities (ceiling accessibility, cable
lengths) and the results of an optimisation simulation. This
simulation aimed to find ceiling distributions that gave good and
uniform positional coverage for the majority of the volume served. A
regular three-dimensional grid of test points was defined for each
room and the number of receivers set, based on room area. The
simulated receivers were then allowed to move, with each individual
configuration given an `energy' state based on calculating dilution of
precision metrics across the test points. To settle on a final
distribution, a simulated annealing approach was used to identify good
spatial arrangements.
Since installation, however, it has become apparent that the
distribution of sensors in the ceiling would be better deployed
according to the regular use of the space, rather than its size
and shape. For example, to achieve uniform positioning capabilities
throughout a room typically required the slight degradation of
positioning in one area to improve positioning elsewhere. Once office
furniture was installed, it became apparent that uniform coverage was
often unnecessary; users rarely use the whole of the space uniformly
and the deployment distribution would be better tailored to the usage
of the space. This favours the deployment of such a system
after the space usage has been established. This complicates
any deployment, but should improve performance.
Figure 4: Receiver distribution (compare with Figure 3)
4.3 Beware the coincidence of physical and symbolic
boundaries The Bat system was designed to be modular in operation,
distributing the positioning calculations across multiple DSPs. Since
ultrasound does not penetrate walls, a decision was made that each
room would contain an independent chain of receivers and an
independent DSP to handle any local multilateration calculations. Hence
the system was segmented according to physical boundaries. In
retrospect, however, this was a sub-optimal approach because it
hinders reliable capture of room change events (since a handover from
one receiver chain to another is necessary). Room changes are
important location events since many applications trigger events when
they occur. The per-room distribution of receiver chains effectively
forces a Bat to transition from one chain to another when visibility
of the sensors in either chain is at its lowest. Thus we observe
positioning failures near doorways, resulting in delays for room
change events (Figure 5(a)).
Abstracting from this experience, we find that it is not always ideal
to coincide physical boundaries with virtual boundaries (in this case
th physical boundary of the chains and the boundary between two
symbolic room entities). In this particular example, the issue could be
addressed by the inclusion of spatial chain mixing at transition
points (Figure 5(b)). Equally, a system redesign could
dispense with the notion of multiple sensor chains completely, but
this would require an offload of all positioning calculations to a
central processor, hindering scalability.
Figure 5: Chain mixing at physical boundaries
4.4 Incorporate autonomous maintenance
Perhaps the most difficult aspect of maintaining a working
location-aware system has proved to be maintenance of the
computational world model: a spatial database of objects from which
context is inferred from location data. A more accurate model may
allow for a less accurate location system. For example, a user and
computer both tracked to within 0.5m can be replaced with a user
tracked to within 1m, and a computer at a known location. Thus, the
creation and maintenance of an accurate world model is very important.
To keep the model synchronous with the physical world requires the
precise tracking of people, furniture, devices, books, etc. Bats (and
indeed, any powered tags) are not generally suitable for all classes
of object - the infeasibility of regular battery changes, the added
weight and cost make their deployment on truly everything prohibitive.
At present the world model used in the laboratory is hand-maintained,
with changes being incorporated into the spatial database manually
when reported or observed. Users of the Bat system have not felt it
their responsibility to update the model when they effect any changes
on the physical world, despite having software tools available to do
so. Thus, maintenance is primarily achieved by manual intervention of
the group members who make use of the location data. This manual
approach is barely practicable on the laboratory scale, and limits the
tracked objects to more bulky items that are less likely to move -
the database has the capability to model arbitrary devices and
objects, but the difficulties in maintaining it manually has resulted
in only bulky furniture and computer hosts being modelled.. Any
increase in deployment scale (without a corresponding increase in maintenance
personnel) would render the approach altogether infeasible.
Over time, then, we have observed the world model to fall out of
synchronisation with the real world and to require manual correction
since the system does not incorporate an autonomous world model
monitoring component. We have found that the loss of this
synchronisation is of great significance: users become irate with the
system, which does not perform as expected due to incorrect contextual
inferences, and rejection of the entire location system can follow
suit. Autonomous maintenance has proved to be a very difficult problem
and we have actively researched ways in which it might be performed,
identifying a number of starting points deriving from sighting
distributions [5], and analysis of the ultrasonic signals
in the system [3,4]. Future work will incorporate
different tracking technologies for different classes of object.
4.5 Design to maximise context gathering
In examining the signals within the Bat system it has become apparent
that the system could, in principle, be used to gather further
contextual information. In practice, however, its design as a
positioning system has resulted in optimisations that hinder
extraction of this data. The major optimisation is the choice of
ceiling mounted receivers: for Bats worn at chest height, this
maximises receiver visibility. The Bats have been further optimised
such that ultrasonic emissions are primarily upwards. Whilst this
increases power efficiency, the inefficiency of
allowing a Bat to emit ultrasound more homogeneously would benefit
location-aware computing since the associated increased penetration of
ultrasound into the surrounding environment allows inferences about
the locality and assists in autonomous maintenance as previously
mentioned.
Moreover, alongside more homogeneous spatial emissions of ultrasound
from a Bat, it is useful to have a more homogeneous spatial
distribution of receivers throughout a volume. It is infeasible to
locate receivers in a truly homogeneous manner throughout
three-dimensional space, but siting receivers at a variety of heights
on the walls and outskirts of a room is possible (albeit aesthetically
displeasing). The extra density may
not increase positional accuracy significantly, but may allow for
better signal penetration and positioning below objects (the
ceiling-mounted system suffers from a loss of tracking if a tracked
object lies beneath another, for example robots cannot be tracked
under tables. Receiver visibility would be dramatically improved by
receivers being placed at lower heights).
A distribution of receivers across the space rather than the ceiling
also offers the ability to more accurately estimate the
orientation of the user. At present, a coarse estimation is
made by examining ultrasonic power distributions and shadowing
(assuming users block the ultrasound to receivers behind them). A
series of receivers placed around the vertical centre of the room
would offer much better orientation estimation since it would allow
for measurement of power distributions in the horizontal plane
including the Bat. Orientation is a useful contextual clue and it is
advisable for new location systems to offer the capability to detect
it reliably.
In summary, the optimisations needed for a positioning system designed solely for
positioning may differ from those for a positioning system designed to
underpin an indoor location-aware service.
4.6 Beware false positives and false negatives
Experiences using the Bat system on a daily basis have highlighted
that the location information is rarely definitive due to an
unfortunate side effect of using a tag-based tracking system: false
negatives and false positives.
False negatives occur when an application interprets a lack of
sightings for a user as an indication of absence. For example, if a
user cannot locate another through the Bat system they may assume they
are not present. In fact they are faced with an ambiguity: is the user
away or simply not wearing their Bat? The ambiguity can only be
resolved by using traditional methods (physical sight, telephone
calls, etc) and hence most users default to these initially.
False positives are most often associated with Bats being physically
unassociated with the corresponding user location. So, for example, a
user may leave their Bat on their desk at lunchtime and the system
continues to report that they are tracked and within their
office. This is misleading data that leads to confusion and annoyance.
To combat false negatives and false positives the Bat system supports
the idea of a quiet zone - a small spatial region individual
to each user within which the user's Bat will not be tracked. Users
can thus leave their Bats in these zones if they do not wish to be
tracked or as a way to tell the system that they are not present
(although ambiguity still exists between these two states). False
positives are prevented (assuming the user either wears their Bat or
returns it to their quiet zone). False negatives still remain, since
users can forget to take their Bat out of their quiet zone. As a
by-product, Bats can be put into a sleep state when in such zones,
conserving power. Jitter switches are used to rouse Bats when next
picked up.
Initial experiences with quiet zones revealed that few users could be
relied upon to return their Bat to their personal quiet zone despite
having been the ones to locate them, making false positives an issue
once more. Users often placed their Bats outside their zone since they
had not chosen a zone with strong physical markers that allowed them
to accurately recover the zone location.
To encourage the use of quiet zones and minimise incorrect context
derivations a global quiet zone (a physically obvious communal region
within which all Bats sleep) was introduced at the exit of our
area and the system software was altered to emit a beep from any Bat
when it entered the sleep state. A noticeable reduction in the number
of Bats left outside quiet zones has occurred.
4.7 Include feedback capabilities
The introduction of a beep when Bats enter quiet zones is an example
of the importance of including feedback in applications, a concept
that has proved to be very important. The need for feedback has long
been touted by the HCI domain, but it becomes even more important in
location-aware computing, where traditional input/output devices are
not available; a location-based system performing an action such as
unlocking a door as a user approaches cannot assume there is a
convenient visual display by the door to indicate the success (or
failure) of the action. Whatever input device is used to enable,
disable or configure location-aware applications must include some
form of feedback to tell the user that input was successful. Similarly
error conditions (such as the door failing to unlock) must be reported
to give users an intuitive feeling of what is occurring and to allow
them to retain a feeling of control. The inclusion of a simple
tone-generating speaker in each Bat has been extremely useful: so much
so, in fact, that the ten pre-configured tunes in the Bat firmware are
becoming insufficient to allow communication of the many feedback
messages that now exist (each alert and error alone needs a different
tone or sequence of tones).
4.8 Include power management
In any active tag-based system, power management is a very important
issue. Current battery technology means lightweight tags may not offer
the optimum lifetime. Two approaches to battery lifetime are possible:
- Minimise power consumption.
- Reduce power consumption to
maximise battery lifetime.
- Fit recharging into human cycle.
- Many users will have a daily
cycle that allows for recharging with minimum irritation. For example,
Bats could have been designed to support a 12-hour charge, and to be
recharged overnight or when not in use. This would make them more
lightweight, but cause issues when recharging is incomplete or
accidentally forgotten about.
The Bat system as implemented opts for the former approach. In doing
so, it uses a high capacity 3.6V battery in the AA
form-factor. Regular battery changes are unacceptable, so each Bat
features extensive power saving features: jitter switches are used to
determine whether the tracked object is moving significantly, and the
polling rate dynamically adapted to avoid fast polling when the user
is seated or stationary. Very high polling rates are reserved for use
with applications that need them. This provides a battery lifetime of
approximately eighteen months for a Bat in regular and normal
use. Furthermore, an on-board voltage monitor on each Bat can be
interrogated so Bats with a dying battery can be identified and
batteries changed before a loss of service occurs. Experiences show
this to be a very useful feature and for the battery lifetime to be
sufficiently long not to cause irritation.
A down side to such a lengthy power lifetime has been that users treat
Bats as perpetual machines, assuming a hardware fault rather than a
lack of power when the Bat stops functioning properly. However, the
inclusion of a power-monitoring hardware component that can be
remotely interrogated has allowed for recent battery failures to be
pre-empted.
5 User Issues
Over the years the deployed Bat system has been available to all
members of the laboratory and many visitors. The
laboratory contains a significant mix of technical users with
different specialisations: some users work within location-aware
computing, some within high speed networking, and yet others in radio
communications. The advantage of the laboratory deployment, then, is
that the user base is not solely those who developed the system (as
is often the case). There is no reason for users to wear a Bat unless
they choose to do so: the system is purely opt-in.
Computed locations are logged and archived each day. The large number
of events that flow through the system are not logged unless a fault
diagnosis is required. This limits the conclusions we can draw from
the archived data, especially since false negatives and false
positives are both common in the logs. We have filtered the log data
to attempt to identify Bats that were stationary (minimising false
positives), but we have no mechanism to determine whether a user was
present on a particular day and chose not to wear their Bat. To
further gain insight into the usage of the system and the feelings of
its long term users, we issued a short survey to all members of the
laboratory, whether they had a Bat assigned or not (approximately 30
users). Twenty four responses to the survey were received, failing to
represent the entire population. The makeup of the members assigned
Bats is predominantly male (in the current deployment, a total of
four women have been assigned Bats), to the extent that we cannot
reasonably draw conclusions about differences between sexes.
We recognise that the survey results are not guaranteed to be
bias-free but we use them, in conjunction with the logs we have
archived, to illustrate the characteristics that have established
themselves empirically over time through informal discussions and
observations. Their use is also given in the hope it will encourage
more detailed evaluations of similar systems and their users.
The results of the small study have been divided into three major
categories; usage, applications, and user classifications.
Figure 6: User-rated comfort of wearing a Bat
Figure 7: Duration of the novelty period when assigned a Bat
Figure 8: Frequency of wearing a Bat
Since installation, all but three members of the laboratory have been
assigned Bats (the others requesting not to be). The survey revealed
that 77.3% considered wearing a Bat to be unnoticeable or an
occasional distraction, whilst 13.6% found it annoying (Figure
6). It is difficult to design a robust powered tag that
can be worn so as not to be obscured by other clothing or different
human positions. For example, attachment to a belt may be more
comfortable, but introduces problems when the tag is obscured by a
jacket, or by a table for seated users. Wearing it at chest height
(using a necklace) maintains a good visibility of ceiling receivers
but does not suit some users, who find the occasional swinging motion
annoying. One user commented that, having worn the Bat daily for some
time, he now finds it more noticeable when he isn't wearing it.
Figure 9 shows the usage of a Bat for a
frequent system user. The usage is typical, with the Bat being worn
for the majority of the day. However, not all users use their Bat in
the same way: Figure 10 shows the average number of sightings for nine (anonymised)
users, captured over a 27 month period. The actual values cannot be
taken as absolute since false positives may exist and an active user
may accrue more sightings within a given time period than a less
active colleague due to the variable polling rate. However, averaging
each point over a month should minimise the impact of such
concerns. It is apparent from the graph that Bat usage varied
dramatically for all users over the 27 months. Of particular interest is the peak
usages recorded in January 2003 - this corresponds to the full
roll-out of the current system. What we observe is a novelty
period during which the users wore their Bats religiously. A few
months later, the average sightings per day have dropped
significantly.
Figure 9: Typical usage of a Bat over one day
Figure 10: Logged system usage over 27 months
The survey revealed that users also recognise this period,
but they reported a wide range of values for the duration of it
(Figure 7). It seems reasonable to assume users will
experience at least a few days of novelty interest. This highlights the
importance of deploying a system with a wide variety of applications
immediately available. User curiosity and interest is greatest during
the novelty period and a readily available set of applications offers
a powerful opportunity to demonstrate what location-aware computing
can offer them and for them to integrate it into their routines. In
the laboratory deployment, emphasis was placed on achieving a robust
system, and not all applications were rolled out simultaneously
(indeed, some were yet to be conceived).
Following the novelty factor usage often drops: the survey indicated
only 42.1% of surveyed users wear their Bat on a daily basis and
31.5% hardly ever (Figure 8). Figure
11 shows a frequency count for the daily number of
distinct users of the system over five months in 2004 (chosen to
minimise the likelihood of holidays and excluding weekends). To reduce
false positives, a user was included only if they were observed to move more
than 1m within the day. The histogram data suggests an average of 12.2
people using their Bat daily, which is approximately 40% of the users
currently assigned Bats. This supports the survey results, but the
histogram further illustrates a high variability in usage,
Figure 11: Unique daily users in 2004
When asked to
characterise their Bat a wide variety of responses were given (Figure
12), illustrating how different users perceive its
usefulness. The majority of users appear to recognise that
location-aware computing can contribute favourably to their lives, but
these results suggest that at present not every user of the system is
able to identify an application they find useful.
Figure 12: Characterising a Bat
5.2 ApplicationsApplications are clearly crucial in any large scale system
deployment. The survey revealed a wide range in the frequency of
application usage (Figure 13); a quarter only used
location-aware applications when they felt they had to. Encouraging
users to wear Bats and use the associated applications has been the
subject of previous work [9], where specific audiences
were identified and applications tailored to them. Interestingly, some
users seemed also to associate a novelty period with new applications
targeted at them. However, Bat usage quickly returned to its previous
levels. The survey revealed that the two most popular incentives for
users to increase their Bat usage were the implementation of more
applications and for more users to wear their Bats (Figure
14).
Figure 13: Frequency of location-aware application use
Figure 14: What would encourage the wearing of a Bat? Key to
answers: A - Nothing, B - Privacy Controls, C - More
applications, D - Greater system reliability, E - More lightweight
design, F - If more lab members wore one than currently do, G - A reminder to put it on
Users commonly indicate that they want more applications, but can
rarely identify a specific application that would be useful to
them. This echoes the fact that many users are unsure about exactly
what location-aware technology can offer them and are presently keen
to explore.
The latter suggestion - that users won't wear Bats until others
choose to - leads to a pervasive application vicious cycle as
shown in Figure 15. Breaking such a cycle has proved
difficult - the most obvious methods for doing so are the
introduction of a rule that Bats must be worn (generally undesirable,
giving Bats a spy-like character) or the introduction of an
application perceived globally to be of use (an ongoing research
area).
Figure 15: The pervasive application vicious cycle
With regard to specific applications, the survey revealed that the
most popular class of applications in use were mapping
applications. These applications can be very useful for locating
colleagues and assets in a busy office environment. The general
consensus within the laboratory is that a larger deployment would
increase the usage of such applications further.
The cost in walking to a neighbouring office to see who is there is
not great enough to make it worth calling up a tracking application to
check. A coverage zone extending over many floors means that the the
cost of `manually' checking whether a colleague is in their office two
floors below seems too large in comparison to checking a
location-aware map, and we would expect adoption of mapping
applications to be much greater. It is true to say that in the three
storey building that housed AT&T Research, Bat usage was far more
common, perhaps attributable to the need to locate people quickly over
a larger volume. Similarly, three responses to the survey indicated
that a larger coverage area (or the coverage of physically separated
areas) would encourage them to wear their Bat more often. The true
worth of some location-aware applications will only become apparent
with a very large deployment, beyond any implementation so far.
One popular application quoted in the survey was an alert service for
when fresh coffee was available. This has no location aspect to it all
- it uses the ability of the Bats to provide aural feedback to use
them as wireless pagers. So it is interesting to find that the
addition of more traditional applications of wireless technology has
encouraged the adoption of Bats, simultaneously discouraging the pervasive
application vicious cycle.
5.3 User classification
Mansley et al. grouped users of the system according to their common
aims and tasks [9]. Over time it has become apparent that
users of the Bat system at any instant can be be more generally
classified according to how they both perceive and use the Bat system
and its associated services. The classifications exist within a
hierarchy (illustrated in Figure 16):
Figure 16: Classifying users of the Bat system
- Novelty Seeking
- Users in this category wear their Bat and allow
themselves to be tracked purely for novelty. Their main interest is in
discovering the system capabilities and evaluating how it can enhance
their lives, if at all.
- Group oriented
- Users in this category are concerned with all
other users in the system and can subdivided as follows:
- Adoptive users
- These users adopt the system and use its applications
on a regular basis. The majority of these are those researching
location-aware computing.
- Altruistic users
- These users derive little use from the Bat system,
but are prepared to wear their Bats regularly to increase the system
utility for other users. For example, they are willing to be tracked
so others can locate them using Bat applications, but use more
traditional methods when seeking those colleagues themselves.
- Individual oriented
- These users view the system as it applies
to them as individuals rather than group members. Within this category
we find:
- Benefit-seeking users
- These users wear a Bat if there is a personal
benefit. For example, so a particular application they find useful
will function.
- Cost-reducing users
- The inverse of benefit-seeking users, these
users will reject being tracked until a particular cost is removed,
regardless of benefits. An example might be a user who will not be
tracked because she feels she is being spied upon.
Figure 17 illustrates the difference in Bat usage
for a benefit-seeking and an adoptive user. The data was collected
across one month and clearly shows the benefit-seeker using the system
sporadically, when it suits them. This contrasts with the adoptive
user, who wears a Bat even when not using location-aware
applications. We have very few examples of cost-reducing users within
the laboratory, although a few have identified the cost of privacy to
be a major issue. Indeed, in demonstrating the system to a wide
variety of people the authors have become aware that the initial
response of many is to fear a privacy invasion. The most common
privacy fear quoted is that of the employer monitoring the employee.
Interestingly, then, the survey found that privacy concerned
laboratory users very little (Figure 18). This is
perhaps attributable to two factors: firstly, the location data is not
available outside the laboratory and so little information is
available that could not be ascertained by walking through the
laboratory; secondly, a Bat can be taken off at any time for
privacy. It is also worth noting that, as a research establishment,
working hours are not strict so there is little worry of them being
policed. In a more commercial environment this may be more of a
concern.
Figure 17: Daily sightings for two users over one month
Figure 18: How much privacy concerns users
The survey of how often users wear Bats (Figure 8) is consistent with the
empirical observation that most laboratory users are now either
adoptive or benefit-seeking in nature. The peaks observable in Figure
10 occur at significant times. In particular, we see increased usage
in late 2003, which we attribute to the roll-out of location-aware
applications on the broadband phone network, and some usage peaking around April 2004, when a further
set of location-aware applications were made available.
When questioned about whether they would wear a Bat if it benefited
their colleagues, 59% indicated that they would (Figure
19). Certainly, a higher proportion of users wear their
Bats for limited periods when so requested for research or
demonstration purposes. These facts indicate that many members can
also be classified as altruistic in their Bat usage.
Figure 19: Ascertaining whether users would wear a Bat if it made the
system more useful to others
6 Conclusions
This paper has presented a unique portrayal of the deployment and
usage of a location-aware system encompassing a medium-sized volume
and regularly available to a wide range of technical people over an
extended period.
Deployment experiences have produced a set of non-obvious guidelines
to assist future large-scale deployments:
- Design for space usage rather than physical space.
- Beware the coincidence of physical and symbolic boundaries.
- Incorporate autonomous maintenance.
- Design for maximal signal penetration.
- Beware false positives and false negatives.
- Include feedback capabilities.
- Include power management.
This paper has also presented the results of surveying members
of the laboratory that have access to Bats. The major highlights are:
- The majority (77.3%) feel comfortable wearing a 50g tag around
their neck.
- Initial assignment of a location tag often results in a novelty
period that typically lasts days.
- 42.1% now wear a Bat on a daily basis.
- The majority characterise their Bat as useful or fun.
- Applications are crucial to a good deployment
- A pervasive application vicious cycle is evident, where users
reject some applications because others do not use them.
- False negatives in tracking complicate location-aware
applications.
- Users differ in how they perceive and use the location-aware
system, and distinct classifications are apparent.
- Location privacy is rarely a concern in the deployment environment.
The survey presented cannot be taken as definitive: it represents a
small sample space and relates to a research (office) environment with
a majority of technically competent users. However it is
representative of the observed usage of the system since
deployment. It would be interesting to compare these results for a
series of deployments across areas with different typical usages, and
also to investigate whether different sexes perceive and use the
technology in different ways. The present deployment has too few
female users to draw useful conclusions (note that this is due to a male
dominance in the field rather than women opting out).
7 Future Work
The work has highlighted a need for a greater diversity of
location-aware applications to allow users to determine what the
technology can offer them. It has also underlined how important it is
to test such technology on a larger scale than a single room: new
challenges become apparent (maintaining the world model, aesthetics,
etc.) and usage can be evaluated by regular users of the space to see
what it actually contributes.
It is hoped that this paper will encourage large deployments of
location technology in spaces outside research establishments, and
lead to detailed human factors studies.
8 Acknowledgements
Many of the findings herein are the fruits of discussions with a
variety of members of the Laboratory for Communication Engineering,
who we thank for their contributions. We also wish to thank the
MobiSys reviewers and our paper shepherd, Anthony LaMarca, for their
useful comments.
References
- [1]
-
P. Bahl, V. N. Padmanabhan, and A. Balachandran.
Enhancements to the RADAR user location and tracking system.
Technical report, Microsoft Research, February 2000.
- [2]
-
A. Bystrom, T. Dahlroth, J. Eriksson, L. Fernandez, D. Holmgren, T. Johansson,
P. Larsson, I. Styf, M. Stahl, N. Varillas, and M. Wu.
Advanced Wavelan Positioning System.
SMD116 Program Project, May 2001.
- [3]
-
R. K. Harle and A. Hopper.
Building World Models By Ray-tracing Within
Ceiling-Mounted Positioning Systems.
In Proceedings of UbiComp, Seattle, Washington, US,
October 2003.
- [4]
-
R. K. Harle and A. Hopper.
Dynamic World Models from Ray-tracing.
In Proceedings of the Second IEEE International
Conference on Pervasive Computing and Communications, Orlando,
Florida (PerCom 2004), March 2004.
- [5]
-
R.K. Harle and A. Hopper.
Using Personnel Movements For Indoor Autonomous
Environment Discovery.
In Proceedings of the First IEEE International
Conference on Pervasive Computing and Communications, Fort Worth,
TX, US (PerCom 2003), pages 125-132, March 2003.
- [6]
-
A. Harter and A. Hopper.
A distributed location system for the active office.
IEEE Network, 8(1), 1994.
- [7]
-
M. Hazas and A. Ward.
A Novel Broadband Ultrasonic Location System.
In Proceedings of UbiComp 2002: Fourth International
Conference on Ubiquitous Computing, 2002.
- [8]
-
J. Krumm, S. Harris, B. Meyers, B Brumitt, M. Hale, and S.. Shafer.
Multi-Camera Multi-Person Tracking for EasyLiving.
In Proceedings of the Third International Workshop on
Visual Surveillance, July 2000.
- [9]
-
K. Mansley, A. Beresford, and D. Scott.
The Carrot Approach: Encouraging use of location systems.
In Proceedings of UbiComp. Springer, September 2004.
- [10]
-
N. B. Priyantha, A. Chakraborty, and H. Balakrishnan.
The Cricket Location-Support System.
Proceedings of the Sixth Annual ACM International Conference on
Mobile Computing Networking, August 2000.
- [11]
-
W. Rungsarityotin and T. Starner.
Finding location using omnidirectional video on a wearable computing
platform.
In ISWC, pages 61-68, 2000.
- [12]
-
R. Want, A. Hopper, V. Falcao, and J. Gibbons.
The Active Badge Location System.
ACM Transactions on Information Systems, January 1992.
- [13]
-
R. Want, B. N. Schilit, N. I. Adams, R. Gold, K. Petersen, D. Goldberg, J. R.
Ellis, and M. Weiser.
An overview of the PARCTAB ubiquitous computing experiment.
IEEE Personal Communications, 2(6):28-33, December 1995.
- [14]
-
A. M. R. Ward.
Sensor-driven Computing.
PhD thesis, Cambridge University, August 1998.
- [15]
-
M. A. Youssef, A. Agrawala, and A. U. Shankar.
WLAN Location Determination via Clustering and Probability
Distributions.
In Proceedings of the First IEEE International
Conference on Pervasive Computing and Communications, Fort Worth,
TX, US (PerCom 2003), pages 143-152, mar 2003.
|
