Mark Griffith

							                                                                            Mark Griffith
                                                                         Tyrus DeJarnette
                                                                        February 12, 2003
                                   Project Proposal

   I.      Introduction
Title: Positionally “AWearable” System

        Most of the uses of GPS so far have been limited to showing a user maps of
streets and buildings. We want to take advantage of positional and temporal data to
provide relevant information to the end user. In addition, personal augmentation and
augmented reality are interesting topics, which we believe will become more important as
computing power continues to increase. We want to concentrate on design itself, and
knowing that we have access to a working GPS receiver and an iPAQ is encouraging. We
believe that our project has the potential for a lot of conceptual depth, with many
implications as well as applications. Perhaps most important is that we think the project
will be immediately useful, and we intend to put it to experimental use. This is mainly
due to the high “cool-factor” we think our feature set will provide. Beyond being simply
a useful tool for the technologically inclined, our project may be adaptable to help people
whose representation of the world is challenged in some way. Contextual data can help
the blind or just those of us who can’t remember everything that we would like.
        Tyrus has experience writing programs for handheld computers with database
back-ends. We have experience in embedded systems programming using iPAQs from
ECE 311, but those iPAQs were running Linux. We believe the Windows environment
on the iPAQ will be friendlier and more conducive to software development.

Objectives:

         Our main focus is to provide a means for pertinent information retrieval, and to
present the data in a useful and friendly manner. This will involve writing software for
the IPAQ which will use position and time data to query a populated database of
contextually useful information. We will use NMEA data from a GPS receiver over a
serial interface to the IPAQ, which we already own. For example, maps and other data
can be downloaded to the unit via cradle synchronization. Possible applications include
campus navigation with streets, landmarks, building and assorted drill-down information
such as floorplans and schedules. Messages can be left like sticky notes associated with a
place and/or time. A possible extension, time allowing, would be the addition of a
wireless communication system, possibly Ethernet, which would allow for outside
persons to contribute to user data in real-time. Applications include adding map
information or leaving personal messages on the fly. Additionally, positional and other
data could be transmitted to a website or program for remote monitoring (e.g. parents
monitoring their children).
Benefits:

   -Basic GPS and beyond – information is not limited to streets and buildings
   -Associates arbitrary information with place and or time – get info when you need it,
   where you need it
   -Provides detailed, up to date info about any data that can be stored in a database
   -Creates non-intrusive augmentation to reality – things can be presented in the
   program that do not necessarily appear in real life
   -Shared knowledge base – applicable data can be updated and retrieved by a large
   group of users

Features:

   -Positional data from GPS to within 50 feet and precise time data
   -Wearable design, made to be taken everywhere the user goes
   -Graphical visualizer to display contextual text and image data in addition to basic
   maps
   -Time and/or location specific messaging
   -Locally stored database, updatable from handheld or synchronized to base computer


   II.      Design

Block Diagram:




Block Descriptions:

GPS/Serial communication

         This block obtains data from GPS satellites and provides the data to the parser via
a serial connection. This data is the “context” that allows our system to be considered
contextually aware. Movement and passage of time determine the output of this block.
Parser

        This block parses text strings from the serial interface to the GPS receiver. It puts
temporal and positional data in an easy-to-use format for the query builder. This is
important for the modularity of the query builder, which can then operate on higher level
data, and also allows for the input of test data distinct from actual data output from the
GPS.

Query builder

       The query builder produces queries for the database. It uses user input and data
from the parser to formulate a request. This block is the brains of the system’s contextual
awareness, and as such is responsible for asking the right questions.

Database

        This is the storehouse of arbitrary information (e.g. images, text, messages).
Along with the query builder, it associates information with certain places and/or times.
The stored data ultimately determines the nature and degree of augmentation that the
visualizer can provide.

Visualizer

         The visualizer, in a general sense, is the user interface for the entire system. It not
only displays basic GPS information such as streets and buildings on a map, but also
provides access to contextual information from the database in the form of images and
text. In addition, the visualizer gives the user the ability to influence the query builder
and tailor the contextual data to the user’s specifications.

Performance Requirement:

        Our only true performance requirement is that all data is still valid by the time it is
retrieved. That is, the unit cannot change its position faster than the query that depends on
that position can execute. We elaborate on this further in the Tolerance Analysis below.



    III.     Verification

Testing Procedures:

        Due to the human aspect of our project, it does not lend itself well to the standard
quantitative measures of performance that would apply to many electronic devices. How
well it performs will be determined mainly by conducting field tests. In order to quantify
a performance measure, we propose that volunteers use the system and complete a
survey, and the data collected could be analyzed. Questions would be aimed towards
determining whether the user was satisfied with the various features. For example,
possible questions could include: Do you feel you can do more with the system than
would be possible without it? This question is aimed at the personal augmentation feature
of the system. Such questions could form a reliable measure of the success or failure of
the system in achieving its intended goals.

Tolerance Analysis:

        As mentioned in our Performance Requirement, an important component that
most affects the performance of the overall system is the query speed. Specifically, the
query at the highest level establishes what information is relevant to a given time and
place. Since our GPS receiver is accurate up to only about 50 feet, if the unit travels 50 or
more feet in the time it takes to perform a query of points of interest, the data will not be
valid when it is retrieved or valid data may be missed entirely. In other words, we don’t
want the unit to “outrun” its querying speed. We can test this later by simply timing
queries with different instances of the database. If results are unsatisfactory, we can
establish an upper limit on the size of the database or try to optimize querying methods.


   IV.      Cost and Schedule
Cost Analysis:

Labor:
         Tyrus DeJarnette ($100/hr) * 2.5 * 100 hours = $25,000
         Mark Griffith ($100/hr) * 2.5 * 100 hours = $25,000

         Subtotal                      $50,000

Parts:

         iPAQ                      $500                already own
         Garmin 12XL GPS Receiver $300                 lab equipment
         iPAQ to 12XL serial cable $25                 must purchase

         Subtotal                      $825

Total Cost: $50,825

Schedule:

Week             Task (Group Member)
2/10     Decide on specifications and necessary hardware components(both).
2/17     Order parts(Tyrus). Write parser code(Mark).
2/24     Test serial interface using parser(both). Design basic database structure(both).
3/03     Code basic map and position display portion of visualizer(Tyrus).
3/10   Specify (both) and code query builder(Tyrus). Create test data to populate
       database(both).
3/17   Code visualizer display of contextual information from database(Mark).
3/24   Prepare mock-up demo(both).
3/31   Debug(both). Polish user interface(both).
4/07   Add additional data to database(both).
4/14   Begin preparing for demo(both). Make sure features are in place(both,
       respectively). Survey for usability(both).
4/21   Prepare demo and presentation(both).
4/28   Demo(both). Prepare final paper(both).