Scanner Run: An RFID Children’s Game
Christopher Good and Jared Wilkin
Department of Computer Science and Engineering
University of Washington, Seattle, WA
{good, jardw}@cs.washington.edu
Abstract
To combat inactivity in children, we
decided to come up with a children’s
game that used technology to provide a
fun and active game for kids. The
solution we implemented, Scanner Run,
is more of a suite of games loaded onto a
single wireless Ipaq than one particular
game itself. This Ipaq then
communicates with lighted “Game
Stations” to run the different games.
Each game station has a set of different
colored lights and a RFID Reader.
Depending on the game chosen, and
which lights are lit, children run to and
from the different Game Stations and
scan their individual RFID tags. The
games are administered by a single adult
using the Ipaq, but many children can
play in a game of Scanner Run. Any
number of lighted Game Stations can be
used in a game, and the more game
stations then the more children in one
game.
We believe that the technology behind
Scanner Run will catch kids’ attention.
Instead of a teacher or parent trying to
get their kids to run around and exercise
in a way that the children do not want to,
they can disguise the exercise as
“playing” with technology. Children
also get used to games quickly, so we
created a framework to add additional
games to Scanner Run (beyond the
different games already implemented).
Having a variety of different games plus
the addition of interactive technology,
we believe kids will have hours and
hours of active fun. While Scanner Run
in its current form is just the start of
what it could be, and may not be able to
currently outright compete with video
games, we believe the potential is there
to revolutionize the way games for
children are played.
1. Introduction
With the alarming amount of obesity in
children in the United States, having
active games for children has become
very important. Many hours are spent
by kids watching television or playing
video games, when otherwise they could
be involved in a game involving some
kind of exercise. Many parents combat
their televisions and computers with
regards to their kids’ attention, and try
very hard to come up with activities that
involve some kind of exercise for their
children.
It is not as easy as telling kids to run
around the block a few times however.
Kids are very good at providing
feedback about when they are not
interested in a game, and many times in
a headache causing manner. It is
important then for parents and teachers
to find active games for their children
that can keep the childrens’ interest. If a
game is interesting and fun for a child,
then they will want to continue playing
it, whether it involves exercise or not.
It’s difficult today however, to compete
with video games and computers in
general. Kids today are a lot more high
tech than they used to be, and high tech
games, gadgets, and toys are much more
appealing to kids than more
conventional alternatives. For example,
a kid might be more interested in playing
his or her favorite baseball player in a
video game, than play baseball
themselves. The key then is to produce
games for our kids that can combine
technology with exercise. If we can
keep kid’s interests with the technology,
then we can get the kids to exercise with
the games. This is the whole philosophy
behind Scanner Run.
Scanner Run is a game that can be used
by any number of kids (at least two), and
requires just one adult to administer the
game. One type of instance of someone
using Scanner Run is an elementary
school teacher using it in a gym. The
teacher would be managing the game
through a wireless Ipaq, and the kids
would be running back and forth
between several “Game Stations” that
are positioned randomly about the gym.
These game stations talk wirelessly to
the Ipaq and have different colored lights
to run different lighted games. Each
child in the class would have a unique
RFID tag, shown in figure 1, which can
be held in the child’s hand.
Figure 1. RFID tags (stickers are ~ 2 in x 2in)
As the figure indicates these tags are
small and thus inexpensive. Each child
will receive a tag and which will be
associated with a team. Then, depending
on the game chosen by the teacher, the
lighted game Stations will light different
lights, and children will run to different
stations to scan their tags for points.
Each game has different finishing goals,
but all games provide the same basic
thing, and that is they all cause kids to
run back and forth among many different
stations. Scanner Run definitely causes
kids to get a lot of exercise in a very
high tech game.
2. Related Work
The original idea of having a Children’s
game that utilized RFID technology
came from UW Industrial Design seniors
Lea Skolnik, Christine Lee and Stephen
Johnsen. Sadly we were unable to
obtain much collaboration from these
students other than the general idea. The
particular idea of Scanner Run was
original to us, but the notion of
combining this technology with a
children’s game was not. When
researching for related work, we found a
wide variety of applications for RFID
technology [4][5][6][7][8][9]. We also
discovered a lot of work related to
educating kids using physical computing
environments [10][11]. RFID technology
is just now starting to really take off.
There are already many applications
being found, but it seems that the
possibilities are truly limitless. The
closest related applications of RFID that
we found were:
1. Using RFID with Internet games.
For example, a scan could
represent opening a door in an
online game. We did not find
specific examples of
implemented games, just ideas of
the possibility.
2. Using RFID to track children. In
our game, we use RFID to track
kids to and from different Game
Stations. This scenario however
is not a game and is instead for
parents to track their kids’
locations.
While neither of these applications are
exactly what we are doing, it still
remains clear that RFID technology has
a lot of potential in this area.
3. Approach
In the most adolescent stage of this
project, we simply worked off the idea
of having lighted game stations with
RFID Readers to scan players’ tags. We
didn’t really have a concept of a
particular game, just lighted stations that
one must run to depending on what light,
what team, and what game is chosen. At
this time, the only definite component
was the RFID Reader at each game
station.
For simplicity of design and
centralization of control, we decided
against having distributed logic at each
game station, and instead decided to
have the game stations be relatively
“dumb” and have one controlling “Base
Station” to run the game from. We also
decided it was very important to run
wireless (TinyOS Active Messages)
between the stations, so there are no
wires running between the different
stations for children to trip on. We
previously had experience using
Berkeley Motes with TinyOS, and
decided to use these motes to run the
wireless at the Base Station as well as at
each of the Game Stations. These motes
are nice and small, yet still provide all
the capacities to run our lights, the
wireless, and talk to the RFID Reader.
We also decided to have a “Team
Reader Station” with a mote and a RFID
Reader to scan each of the children onto
each of the teams. This station is similar
component-wise to the Game Stations,
except for the lights.
The only big component left to
determine then was what the Base
Station was going to be comprised of.
We knew we needed a mote in there
somewhere (most likely), and we were
not comfortable trying to write the
games on the motes themselves for
usability reasons. We then learned of an
embedded mote that can be used with a
compact flash card (Camby) that we
could use in an Ipaq. We previously had
experience with Ipaqs, and knew it had
all the capacities to be the “brain” of our
games. We thought the touch pad would
also add to the usability of the game
(from the game administer’s point of
view).
With these pieces determined, the three
big implementing tasks were getting all
these pieces to talk to each other, setting
up the lighting mechanism, and writing
the actual games.
LEDs
4. Implementation
4.1
Game Stations
4.1.1 Hardware
The main platform that the Game Station
is run on is a Berkeley Mica2dot mote.
It is a circuit board about the size of a
quarter containing an Atmel mega128
microprocessor and a CCC1000 radio as
well as other components. This mote
was connected via its serial pins through
a regulator board to a Skyetek RFID
reader. These are shown in figure 2.
Figure 3. IC board containing LEDs
Along with the I/O lines, running to the
IC board are two sources of power, open
wires for a power supply hookup, as well
as a battery pack supplying 3x1.5V
(AA).
All of these components (the IC board
with the power and LEDs, and the mote)
were put inside a 3x3x3 cardboard box
for appearance and stability as shown in
figure 4.
Figure 2. RFID reader and Berkley Mote
As shown these three components are
taped together making them small and
compact.
The game Station has a total of four
LEDs that it operates and thus it needs
four I/O pins from the mote. These pins
are connected to the LEDs via a small IC
board that also contains the power
hookups for the station. Also contained
on this board are current limiting
resistors in series with the LEDs. This
board is shown in figure 3.
Figure 4. Box containing all components of
Game Station
This box has holes to allow the four
LEDs to be visible, as shown in the
picture, as well as holes for the mote’s
antenna and the power wires. Opening
the lid of the box allows you to switch
the battery pack on if that is wanted.
4.1.2 Software
This was the first of the three game
components that we implemented. It
started with the AutoScanRFID TinyOS
module that was written by our TA
Waylon Brunette. Using that as a base
we wrote the Game Station module right
above it. Essentially all AutoScanRFID
does is periodically poll the RFID reader
to see if there is a nearby tag. If there is
a tag, AutoScanRFID previously would
call to the radio stack to send a packet
containing this tag ID. We changed it so
that the AutoScan module would instead
make a call up to our module with this
same packet. We did this because we
decided there were times when we didn’t
want to clutter the airwaves with RFID
packets.
This decision about whether or not to
send packets is the only real computation
the Game Station does. This was our
first main design choice. One of our
main goals when designing this system
was to allow for new games to be
implemented quickly and easily. One of
the ways we decided to achieve this goal
was to make the Game Station module
very limited in its actions. This leaves
the Game Station with a lot of unused
cycles where it is just sitting waiting to
receive a packet. We thought about
putting more of the computation on these
stations to ease the load on the rest of the
system, but this would significantly
affect our design goal. If we put a lot of
the decision making on the Game Station
Motes, especially game specific code, it
would make adding new games much
more difficult. Instead of just making a
change at the Base Station, to implement
a new game would require an upgrade of
every game station as well. Due to this
hefty requirement we decided to keep
the Game Stations as generic as possible.
Having said all of that, the Game Station
basically has 3 functions. Initially on
power-up it sends out “here I am”
packets waiting to receive a node id
number from the base. Once the game is
playing, the base sends out commands
telling the Game Station what light to
turn on, so its second function is to turn
on the required light. Its third function
is to when appropriate send out packets
with RFID tag ID numbers. (please see
appendix for source code)
4.2
Team Reader Station
4.2.1 Hardware
The hardware for the Team Reader
Station is very similar to that of the
Game Station. The only difference it is
there is only one LED and it is also in a
smaller 3x3x2 box. Other than that it is
the same as the Game Station
4.2.2 Software
The Software side of the Team Reader
Station is essentially just the
AutoScanRFID module written by
Waylon Brunette with one minor
change. Instead of sending out a packet
every time it reads a tag, it keeps track of
the last tag read and only sends out a
packet if the tag id is different.
4.3
Base Station
4.3.1 Hardware
The Base Station’s hardware consists of
a Compaq Ipaq running UNIX, with a
compact flash card containing a Mica2
mote as shown in figure 5.
Figure 5. Ipaq containing compact flash mote
This mote is running TOSBase which
takes packets from the radio and
forwards them on the internal serial port
of the Ipaq.
4.3.2 Software
The main computational power behind
the system is the Base Station module
running on the Ipaq. This module
contains the main game engine as well
as the necessary data structures and
routines necessary for finding and
keeping track of the Game Station
nodes. The discovery of active Game
Stations initially proved to be very
difficult. In our first solution when the
Base Station received a request from a
Game Station for an ID number, the
Base Station would add the found Game
Station and just send out a few packets
telling the station what its ID number is.
Due to some power issues (which will be
discussed in greater detail later) we
found that the Game Stations regularly
dropped packets on the floor before it
could handle them. To counter this we
implemented a protocol that when a
Game Station received a packet
containing its given id number it would
reply with a packet containing its id.
This would tell the base station that it the
Game Station knew it was discovered
and making it ready to respond to further
commands.
The Base Station also contains the initial
team setup routines which put the
players on the appropriate team. To do
this it takes scanned RFID tag IDs from
the Team Reader and adds them to the
active team data structure. Currently
there is only support for 2 teams and the
user selects which team to fill.
Another task performed by the Base
Station is it implements all of the nongame-specific User Interface. This
includes the setup of teams and the
selection of which game to play.
One final thing done by the Base Station
is it implements the main game engine.
The main game engine consists of two
main components. The first is a system
alarm that each game can call if needed
to allow it to perform timed actions.
This is done by an external setAlarm
function that is visible to each game and
when called with a time value in
seconds, sets the system’s alarm
function. When the time is elapsed the
engine traps to the signal handler where
a game hook is called to allow the game
to handle the timeout. The second part
of the game engine is a big loop in
which it blocks while watching the two
possible sources of input, the stdin from
the user, or packets from the serial.
Once either of those is ready with new
data, the blocking call returns and the
appropriate action is taken. If it is a
packet, it first verifies that the source is
valid and it then calls the appropriate
game hook, which calls into the game
code to handle the packet. Once the
game code returns the loop is repeated
and it blocks once more.
4.4
Intercomponent
Communication
Figure 6 shows the communication
between each of the three major
components as well as the
communication within each component
RFID
Reader
Tag ID
AutoScan
RFID
Tag ID
packet
Game Station
RFID
Reader
Tag ID
AutoScan
RFID
Tag ID
packet
Game Station
As you can see from the figure each
station communicates wirelessly with the
base station. It does this by using
TinyOS Active Messages. It is this
communication medium that proved to
be very problematic. During our testing
we sometimes had great difficulty with
the motes not receiving the packets sent
by the Base Station. We put a lot of
time and effort trying to discover why
GS module
Game
Packet
GS module
Game
Packet
Data Flow
Diagram
TOSBase
running on
d
e
Camby
d
ar ts
rw ke
Fo pa c
game
control
packets
Game Engine
RFID
Reader
Tag ID
AutoScan
RFID
Tag ID
packet
GS module
commands
Game Station
Display data
Game
Packet
User Interface
Control
Module
User input
RFID
Reader
Tag ID
AutoScan
RFID
Tag ID
packet
Team Reader Station
TS module
Team Reader
Packet
Figure 6. Data flow between components
Ipaq
Screen with
Touchpad
this was the case. We initially thought
the packets were getting dropped
because the mote had too many other
things going on and wasn’t able to
handle the packet. This hypothesis
seemed incorrect however as we looked
at just how much the mote was doing
and saw it was actually doing very little.
A major discover came when we noticed
that the mote we had connected to our
PC was behaving differently.
This mote was forwarding packets via a
serial cable to the PC so we could view
what packets were being sent. We
noticed that this mote rarely ever
dropped any packets. We noticed one
major difference between our station
motes and this mote. The mote
connected to the PC was running on a
programming board that was powered
from an AC adapter. Our station motes
were running n battery power. We tried
hooking our station motes to a 5V power
supply and all of the erratic packet
dropping behavior vanished. We
concluded the 3V coming from the AA
batteries just wasn’t enough. We added
a third 1.5V battery in series to the pack
and as long as the batteries were fresh,
that fixed the power problems.
4.5
The Lights
For our prototypes we decided the
easiest thing we could do to implement
the station lights was to use LEDs. We
found some very bright LEDs but the
downside is they can’t be seen too well
from the side. The consequence of this
is the LEDs are oriented on the station so
that they face inward instead of being on
the top of the station. This means that if
you are in front of the station you can
see the lights very well, but if you go
more than about 40 degrees off to either
side the lights become barely visible.
We decided that this was okay however,
since this was just a prototype and the
LEDs were suited for that purpose.
4.6
The Games
Probably the biggest feature of our
system is the ease to which you can
implement new games and add them to
the platform. The main game engine
contains a structure containing three
function pointers that are the standard
entry points into the specific game code.
As long as a give game implements
these three functions, the main game
engine will correctly call into the
specific game code when needed for
game operation. These three hooks are
an init function, a signal handler for
timeouts, and a packet handler for
incoming tag reads. All a game must do
is have its functions registered in the
game engine. Currently this is done by
manually entering the names of the
functions into the correct structure and
adding the game’s include file. This
means that adding a new game requires a
new build, but it requires minimal
addition to the source code.
This ease of expansion is a main selling
point for this system. If this goes to
market someday, we would want to sell
it as a game platform much like popular
game consoles. Now the scope would be
much more limited, but once you have
the hardware, you can add new games as
they are made available. This would
make the cost of the initially hardware
much more bearable.
5. Evaluation
The evaluation for our project was for
the most part fairly subjective. There
was not really any metric we could
really test that was not subjective. It is a
real time game so most of our tests
related to verifying that the game could
work in a real-time scenario, as well as
general usability of the game. Below are
the criteria we developed that we felt
Scanner Run must pass in order to be an
effective game, and how we feel each
one passed:
1. There must be a mechanism in
place to handle lost wireless
packets. This criteria was met by
having multiple packets sent out
at a given rate as opposed to a
single packet.
2. Lights must illuminate and
change quick enough to keep
pace with a real-time game. This
criteria was met and verified with
usability tests by us.
3. The game setup must be at a
minimum. Most of this is
accomplished by having a single
executable that can be launched
from the Ipaq. The most
involved part of setup is setting
up the teams, which we feel is
acceptable.
4. Scanner Run must be able to be
extended to many different
games. This criteria is met by
having a framework in place for
additional games to be added, as
well as, having the Game
Stations being relatively “dumb”.
The only thing necessary to
change to add a game is the code
on the Ipaq itself.
5. It must be fun. This is our most
subjective criteria, but we at least
believe that this one passed. A
more solid determination would
be found by having user studies.
The most useful feedback we
received in this area, was a
response to our project idea by an
industrial design student.
Christine Lee responded to an email by us, and said they
believed it looked like a good
game. All of the concerns they
voiced were addressed in our
final implementation.
With these criteria met we feel Scanner
Run fully evaluated to our expectations.
6. Conclusions and
Future Work
At the beginning of the quarter, we set
out to create a fun and interesting
children’s game that would cause kids to
exercise. We believe we have
accomplished this goal. There is much
potential work to do however, especially
to get the game production ready.
Below, I will outline first what steps
need to be taken to get the game
production ready, and then I will explain
possible future extensions of Scanner
Run.
There are many things required to get
Scanner Run production ready.
1. Must create a better casing for
the Game Station hardware.
2. Must upgrade the LED’s used to
bright lights. This will require
independent power for the lights
(more than 5v is necessary for
production quality lights).
3. Should create a glove-like casing
to hold children’s RFID tags (so
they don’t have to hold them in
their hands).
4. Field tests should be run with
many children, and the children
should be surveyed about their
experiences with Scanner Run.
There are also many potential extensions
of Scanner Run.
1. A better User Interface for the
parent/teacher. This would
involve changing the command
line executable to a GUI version.
2. Many more games, and many
more complex games, can be
easily developed given the
framework we have created.
3. The hardware on the Game
Station side could be changed
from using the general purpose
motes with tinyOS, to a more
specific hardware solution (the
Berkley motes with tinyOS are
overkill and have a lot of
functionality we don’t need).
4. Implement a more “plug-in”
scheme for adding new games
that doesn’t require a change to
the source code.
We believe that with all of these options,
there is much potential for work with
Scanner Run. We believe we have
accomplished what we have set forth,
but there is much more that could be
done.
7. Acknowledgements
There were two main people that helped
us in the implementation and
troubleshooting of Scanner Run. These
people are:
1. Waylon Brunette – Gave us
starter code for the
communication between the
RFID reader and the mote
(AutoScanRFID). Waylon also
helped us physically connect the
motes with the readers. He also
helped us troubleshoot problems
with the compact flash mote as
well as other minor setbacks.
2. Trevor Pering - helped us
troubleshooting using the serial
forwarder application with the
Ipaq
3. Lea Skolnik:
[email protected]
Christine Lee:
[email protected]
Stephen Johnsen:
[email protected]
8. References
[1]
Research Databases. http://www.lib.washington.edu/engineering/
[2]
Mote tutorials and information. http://cs.washington.edu/466
[3]
IPAQ with Linux tutorials and information. http://cs.washington.edu/461
[4]
Danielle Wilde, Eric Harris, Yvonne Rogers, Cliff Randell. The Periscope:
supporting a computer enhanced field trip for children. July 2003, Personal and
Ubiquitous Computing, Volume 7 Issue 3-4
[5]
Kay Römer, Svetlana Domnitcheva. Smart Playing Cards: A Ubiquitous
Computing Game January 2002 Personal and Ubiquitous Computing, Volume 6
Issue 5-6
Jaime Montemayor, Allison Druin, Gene Chipman, Allison Farber, Mona Leigh
Guha. Storyrooms and playsets: Tools for children to create physical interactive
storyrooms. January 2004, Computers in Entertainment (CIE), Volume 2 Issue 1
[6]
[7]
Jonathan Green, Holger Schnädelbach, Boriana Koleva, Steve Benford, Tony
Pridmore, Karen Medina, Eric Harris, Hilary Smith, Short Talks: Camping in the
digital wilderness: tents and flashlights as interfaces to virtual worlds. April 2002
CHI '
02 extended abstracts on Human factors in computing systems
[8]
Eric Harris, Geraldine Fitzpatrick, Yvonne Rogers, Sara Price, Ted Phelps, Cliff
Randell. From snark to park: lessons learnt moving pervasive experiences from
indoors to outdoors. January 2004, Proceedings of the fifth conference on
Australasian user interface - Volume 28
[9]
Diana Africano, Sara Berg, Kent Lindbergh, Peter Lundholm, Fredrik Nilbrink,
Anna Persson Design expo case studies: Designing tangible interfaces for
children'
s collaboration. April 2004 Extended abstracts of the 2004 conference on
Human factors and computing systems
[10] Masanori Sugimoto, Fusako Kusunoki, Hiromichi Hashizume Section 01:
augmented education: Design of an interactive system for group learning support.
June 2002 Proceedings of the conference on Designing interactive systems:
processes, practices, methods, and techniques
[11] Jaime Montemayor, Allison Druin, Allison Farber, Sante Simms, Wayne
Churaman, Allison D'
Amour Interactive Design: Physical programming: designing
tools for children to create physical interactive environments April 2002
Proceedings of the SIGCHI conference on Human factors in computing systems:
Changing our world, changing ourselves
9. Appendices
The Source Code for Scanner Run is available at the project website:
http://www.cs.washington.edu/education/courses/cse477/CurrentQtr/project
webs/cse477i/