10-presentation

Download Report

Transcript 10-presentation

Tourist Tracker
a.k.a. Visit
Planner
Brent Horine
EEL6788
April 13, 2011
Program Features
 For phone users…
 Suggestions for shops and activities based upon
preferences
 Exchange reviews
 Coupons for nearby shops based upon interest
 For property owners…
 Tangible value of location based upon walking traffic
 For business owners…
 Drive consumers to store
 Site selection
 Staffing guidance
 Marketing feedback (e.g. signage)
 For chamber of commerce
 Understand value propositions
 Promote business
Key Operational Functions
 Create paths based upon sampled location
points
 Highlight locations with significant foot traffic
 Highlight locations which trigger lots of stops
Key Research Activities
 Discern mode of movement
 Driving/walking/bicycling/motorcycling/horse
carriage
 Event triggering when entering/exiting shops
Simplifying Assumptions
 Lat/Lon form a square grid at this scale
 Roads are mostly straight
 2 Dimensional (ignore altitude)
 GPS errors, once smoothed, tend to be constant,
i.e. fixed offset, with respect to map
 Errors are normally distributed so we can use
least squares (not really valid)
Major Problems
 Emulator inadequate for fully evaluating
technology
 Emulator does not send NMEA Sentences to
NMEAListener
 Cannot directly simulate number of satellites
 No direct access to road segments, so need to
create my own database of road segments
Rules for Classifying Motion
 Smooth GPS samples (e.g. MA of 3)
 Aggregate points into paths
 If max speed > SpeedThreshold then in car,
bicycle, or motorcycle
 Fit points to line using linear least squares
 Find nearest road segments
 Calculate angle between path and road
Rules Part II
 If angle is less than ANGLE_THRESH then
calculate distance between the parallel lines
 If distance is less than DIST_THRESH then evaluate
quality of fit.
 If quality of fit is better than QoF_THRESH, then
assume care or bicycle or motorcycle or horse
carriage
 Else walking
Algorithms
 Use Jama to solve the matrix algebra for LS fit
(assumes data is well conditioned. LU
decomposition or SVD might be better, but more
computationally intense)
 Angle can be found from cross product or dot
product and an inverse trig function
 We could compare slope, but would have to
normalize since slope can vary from 0 to infinity
  sin
1
ab
ab
  cos 1
ab
ab
More Formulas
 Distance between two parallel lines (if angle is
less than threshold, we assume they are perfectly
parallel. This may lead to large errors, but then
chances are we’ll fail the next test and properly
assume they are walking.)
 Line 1: y = Ax + b1
dist 
 Line 2: y = Ax + b2

abs(b2  b1 )
A 2 1
More Rules
 Handle onStatusChanged
 If state is not inside_store then
 If numSatellites < SAT_THRESH then
 Perform a SQLite query for nearby stores
 If not null then set state to inside_store
 If state is inside_store and numSatellites > SAT_THRESH
then set state to leaving_store
 Prompt user with list of N nearby stores with any
preference matches listed first
Comments

Unfortunately, this is rather difficult to test using the emulator. The logic
can work, but does the premise hold?

I.e. does the onStatusChanged get called when the number of
satellites in view changes or quality of fix otherwise changes?

Is the number of satellites a valid measure of inside vs outside
likelihood?

Alternative approach is to get the list of satellites and iterate over them.
Get the SNR and whether that satellite was used in the fix.

Perhaps examine the top 4 SNRs (assuming they’re used in the fix) and
keep track of the mean and standard deviation. Look for outliers. Low
SNR outlier means in store. High SNR outlier means exited store. Pitfall is
when satellite orbit takes it below visible horizon. Have to “hand-off”
statistics to next satellite. How to handle that in a valid manner?

This will have to wait until this summer when my contract on my Palm
Pre expires and I can buy an Android for a decent price!
Status
 User side coupon server UI logic
 GPS location processing
 Still need to aggregate points into paths
 Still need to build DB and queries to find closest
shops and road segments
 Need to calculate the variance of error from
straight line fit
 Need more test jig development