Route Tracking Project Proposal

advertisement
Route Tracking
Project Proposal
Abstract—Take the lead from similar GPS tracking mobile
applications and provide a more detailed record of a typical
activity route, whilst incorporating elevation changes into
exercise calculations.
Index Terms—Component, API, GPS, Interface, ViewGroup
I. INTRODUCTION
A. Aim
In this paper a proposal is introduced to develop a Route
tracking Location based service targeted towards a cyberphysical system. The service will run on an android-based
phone as an app.
The time-driven app will periodically record the location of
the Android User through sensors in the phone as he/she
completes a track. This data is then processed to give a variety
of information showing the runner’s progress over time
including: timing, pacing, average speed as well as calories
burnt. Furthermore, the data can be processed to create route
visualization over a map.
B. Motivation
While there are several apps that perform similar actions i.e.
Nike+, they only take in to account the two dimensional
positioning of the user: latitude and longitude. The proposed
app has the potential to become more accurate as it takes a
third dimension of the user into account, the elevation.
The proposed app will be targeted towards a whole range of
customers. From Hikers to marathon runners, dog sled teams,
skiers & outdoor enthusiasts.
II. BACKGROUND
The proposed app should be all inclusive in a typical androidOS system. As such, in terms of hardware, the entire system
can be executed just in a single suitable cell phone with no
additional accessories. The phones available for this project
are the Nexus_S and the Galaxy SIII, both of which fulfill the
requirements discussed in the subsections below.
A. Important Hardware Requirements
GPS Sensor: This is the main sensor with which the app will
record the location of the user (latitude, longitude, elevation).
Responsive input terminal: Required to enter information
about the user, and set parameters for the app. Achieved
through touchscreen interface of the screen.
Graphic Output Interface: Interface through which user can
track his/her progress as well as viewing map visualization.
B. Important Software Requirements
Android-OS: Cell phone has to run the latest Android OS
which are compatible with the below APIs and programs.
Android API: Contains classes & methods to interact with the
Android OS
The android’s application framework is vast with a whole host
of reusable components. In this proposal we only present two
components. Further research and work in to the project may
reveal more components that might be utilized.
Google Maps API: Contains classes & methods to interact
with Google maps, which will be used in map visualization.
C. User Interface
A major concern with the development of a mobile app, is the
layout of the user interface. The Android uses an architecture
of Views grouped into ViewGroups, that the user can call by
touching the screen. Upon launching our app, a ViewGroup
“MenuScreen” will load displaying the options 'Past Maps,
Create Map, Settings'. Each of these options represents a View
that is owned by the Viewgroup “MenuScreen”. From the
View “PastMaps”, the user will be able to access altitude
representations of their routes, and access GoogleMaps with
their route laid over the map. This view will also hold
information about calories burned on previous routes, and a
graphical comparison of the stored routes. The CreateMap
View will allow the user to press a button and begin tracking a
route. This will trigger the GPS to start logging information.
After pressing the begin button, A stop button will appear that
user may press to stop the route. The last View titled
“Settings” will be used to change various settings of the app.
We will include different units to choose from (SI vs. US), and
the user will be able to input personal information to help
calculate calories burned more accurately.
D. Sensors
The main sensor used by our app is the GPS. Our main
concern in using the GPS is the accuracy of the data, and how
the usage of the GPS will drain the battery. We have found
that cell towers may provide more accurate information more
quickly, but have opted not to use tower tracking initially to
simplify our design. As the semester progresses and if time
allows, we may include tower tracking. We can control the
power usage of the GPS by limiting how often the GPS returns
data. We can set this with a time limit & also a minimum
distance traveled. This variable will also be changeable by the
user dependent upon the pace of the user’s activity. We will
have to fine tune this variable as the app becomes usable, and
we can see how it affects the quality of the maps produced.
E. Google Maps APIs
The key functionality of the application will be driven by the
use of several Android and Google API’s. Specifically, initial
investigation has highlighted the Android Location API,
Google Maps Android API, and the Google Maps Elevation
API as probable components in our application. Google’s
MapView() library for Android devices provides developers
the main UI functionality of Google Maps such as map control
and rendering, but also allows a number of Overlay types to be
drawn on top of the map. The drawing of Overlays is an
integral part of the application, as it allows for the
visualization of activity routes, both present and past. Whether
obtaining the device location through the Android Location
API or Google Maps API, the application will store an array of
latitude and coordinates for use later on. In order to get the
elevation of a given point, the Google Maps Elevation API
will be used. Using the Elevation API, coordinate pairs of
latitude and longitude are provided to the API, and the Google
Maps elevation for that point is returned. Once elevation data
is collected, an overlay of the route will be drawn on top of a
Google Maps, with variation in route color based on elevation
changes.
III. CHALLENGES
Of the challenges expected, the most outstanding obstacle
is having no previous experience with Android application,
Java, or XML development. There is a relatively short time
frame in which our group must transition from learning about
the basic Android architecture to actually implementing a
program to obtain the desired functionality. Additionally,
satellite communication will pose several issues in itself, from
signal strength to power management. Perhaps the most
significant concern here is satellite-to-phone accuracy: without
reliable accuracy, the purpose and improvements our
application is intended to provide will be greatly undermined.
.
IV. GOALS
Despite the challenges we will encounter, we are confident
that completing this project will accomplish several goals.
Upon successful completion of the project, our group will
have a solid fundamental understanding of Android
application development. This will include experience in Java
programming and XML design, both of which are skill sets
that have an extremely broad array of applications outside of
mobile application development. Altogether, a key take-away
from this project is practice in creating a simple user
experience
for
a
complex
task.
Download