Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I am trying to build a GPS based odometer based on android.

Currently , I am calculating incremental distance changes very frequently ( < 5 meter movement). The distance calculation in android is using the WGS84 ellipsoid.

Currently on test runs, The gps calculations overshoots by 3 - 5% depending on route taken and duration of travel.

There are two problems I am facing :

  1. The distance calculation is not considering altitude.
  2. When the vehicle is stationary, gps starts injecting errors due to position changes which even though the device is stationary gps does calculation errors. This is the source of most of the error.

Details for error 2 :

Typically, when in a traffic signal / just plainly stopped on road. The android api tells me the new lat long pair when there is a displacement of minimum 5 meters. The problem is the api informs me of even the "drifted" lat long to be 5m away and hence I increment the odometer value which keeps accumulating errors because device did not move.Hence if the device is stationary it keeps accumulating this error.

An example "error" data when device is stationary

Device  Latitude    Longitude   Accuracy    Speed   Altitude    Heading
gps 13.0311466666667    77.5577383333333    41.5    1.9193991   894.7   295.77
gps 13.0311516666667    77.557795   38.8    0.99907583  892.8   294.88
gps 13.0311616666667    77.55784    38.4    0.5883275   886.4   294.88
gps 13.031175   77.5578866666667    37.5    0.74892086  886.1   294.88
gps 13.0311816666667    77.5579383333333    32.5    0.6552414   886 294.88
gps 13.0311516666667    77.557975   27.6    0   885.9   294.88
gps 13.0312016666667    77.5579733333333    32.4    0.7175228   885.9   294.88
gps 13.0312316666667    77.5579366666667    31.8    0.5610472   885.9   294.88
gps 13.031235   77.557885   30.4    0.9028228   885.9   294.88
gps 13.031245   77.5578366666667    30.5    0.81634945  885.8   294.88
gps 13.0312416666667    77.55779    27.9    0.5559  885.8   294.88
gps 13.0312233333333    77.5578433333333    23.9    0.43236667  886 294.88
gps 13.0312066666667    77.5578883333333    23.6    0.43905807  886.2   294.88
gps 13.03119    77.5579366666667    23.6    0.49258918  886.3   294.88
gps 13.0311666666667    77.5579983333334    24.9    0.77208334  886.7   294.88
gps 13.0311316666667    77.557945   22.4    0.3958214   887.8   241.89
gps 13.03113    77.5578416666667    25.2    0.24089 890.5   269.19
gps 13.0311133333333    77.5579 20.7    0.40663055  891.2   221.69
gps 13.0311116666667    77.5578516666667    21.9    0.47302973  891.3   251.03
gps 13.03104    77.55787    26.7    0.40199804  891.3   134.23
gps 13.0311033333333    77.5579333333333    23.6    0.5193547   891.6   332.92
gps 13.0310766666667    77.557985   19  0.38346806  893 118.18
gps 13.0311333333333    77.557945   27.9    0.3381725   896.9   287.31

Full data set is available here . It has > 5000 data points corresponding to a round trip from my home to office and back. From the start about ~800 data points are error beyond that the device starts moving.

Also adding raw nmea strings..

$GPGGA,191215.557,1301.8784,N,07733.4765,E,0,0,,912.5,M,-88.1,M,,*68

$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,1.00*01

$GPGSV,3,1,11,29,53,169,18,21,49,005,,18,44,334,17,15,34,037,*76

$GPGSV,3,2,11,14,31,211,,22,27,284,,09,27,107,,27,22,087,*76

$GPGSV,3,3,11,25,10,183,,06,09,318,,30,04,261,*42

$GPRMC,191215.557,V,1301.8784,N,07733.4765,E,0.009,0.00,160712,,N*68

$GPVTG,0.00,T,,M,0.009,N,0.017,K,N*3D

$GPACCURACY,27947.3*04

$GPGGA,191216.557,1301.9128,N,07733.4723,E,0,0,,911.4,M,-88.1,M,,*6A

$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,1.00*01

$GPGSV,3,1,11,29,53,169,18,21,49,005,,18,44,334,18,15,34,037,*79

$GPGSV,3,2,11,14,31,211,,22,27,284,,09,27,107,,27,22,087,*76

$GPGSV,3,3,11,25,10,183,,06,09,318,,30,04,261,*42

$GPRMC,191216.557,V,1301.9128,N,07733.4723,E,0.001,0.00,160712,,N*60

$GPVTG,0.00,T,,M,0.001,N,0.002,K,N*31

$GPACCURACY,27942.6*04

$GPGGA,191217.557,1301.8573,N,07733.5089,E,0,0,,909.4,M,-88.1,M,,*6F

$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,1.00*01

$GPGSV,3,1,11,29,53,169,18,21,49,005,,18,44,334,18,15,34,037,*79

$GPGSV,3,2,11,14,31,211,,22,27,284,,09,27,107,,27,22,087,*76

$GPGSV,3,3,11,25,10,183,,06,09,318,,30,04,261,*42

$GPRMC,191217.557,V,1301.8573,N,07733.5089,E,0.068,0.00,160712,,N*63

$GPVTG,0.00,T,,M,0.068,N,0.126,K,N*39

$GPACCURACY,19781.4*0A

Also, I am finding it very hard to visualize this data using excel, can anyone suggest better tools ( I use a MAC )

Can some one give me ideas to reduce the errors , perhaps a better algorithm to consider even altitude?

share|improve this question
1  
Is there something that limits your ability to incorporate altitude? –  mhoran_psprep Jul 16 '12 at 12:29
    
@mhoran_psprep I needed an algorithm to incorporate altitude. ALso the altitude data fluctuates and is not very accurate. –  srinathhs Jul 16 '12 at 17:28
    
Because speed does not correlate at all well with differences in latitude and longitude, could you please explain what the speed means and how it is measured? There's a similar question about headings, but I also want to add that they are systematically wrong: they appear to have been computed from unprojected coordinates using Euclidean calculations. This alone will account for up to 2.5% of the error at latitudes of 13 degrees. –  whuber Jul 16 '12 at 18:43
    
The data is been calculated inside android internally and this is all I get from it. Android is handling the calculations. I sense it is better to calculate them myself using raw NMEA data ? –  srinathhs Jul 16 '12 at 18:53
    
I am beginning to think you are much better off with the raw NMEA data, because the Android calculations do not appear to make the most basic corrections for using geographic coordinates. Moreover, it will be more reliable to identify the noise in the raw data than to try to filter it out of data that have been processed according to some unknown algorithm. –  whuber Jul 16 '12 at 19:07
show 3 more comments

1 Answer

This is a fascinating problem where a little analysis can be most revealing.

First consider the effects of elevation. When a mapped unit distance is traversed, and the elevation changes by an amount dz (which for ground-based vehicles is always small compared to the map distance), then the actual distance traversed is very close to sqrt(1 + dz^2). (This would be perfectly accurate when the motion is made perfectly in a straight line. For actual motions over short distances that's usually a good approximation.) Because dz is presumed small, dz^2 is very small and dz^4 is incredibly small. This allows us to approximate the square root by 1 + dz^2/2, because the error made is proportional to dz^4.

Let's run some numbers to get a handle on the sizes of these errors. To make computation easy, choose our units of distance so that the vehicle traverses one unit between each GPS reading. Over the course of n readings, the mapped distance totals n*1 = n and neglects the additional distance from the elevation changes totaling about n * dz^2 / 2. How big might that be? Because dz determines the slope, the error depends on typical slopes. Approximately, a slope of t degrees translates into a value of dz of about t/60. The error relative to the mapped distance therefore equals (approximately)

(n * (t/60)^2 / 2)  /  n = t^2 / 7200.

For instance, for typical slopes of t = 10 degrees (fairly steep for most vehicles), the relative error equals 10^2 / 7200 = 1/72 = 1.5%.

Notice that this error should be thought of as negative: calculations from the mapped GPS coordinates would underestimate the true distance by this amount.

A similar analysis shows how one could correct a GPS reading based on an appropriate average of slopes encountered during a trip.

What about the other source of error, the measurement error in the GPS itself? This can be thought of as a random "drift" in the discrepancy between the observed GPS coordinates (X,Y) and the correct coordinates (x,y). The drift is a usually manifest as a gradual change in (X-x, Y-y) over time. It does indeed introduce some error, but it usually is not as great as one would think. In an answer at http://stats.stackexchange.com/a/2497, I report a typical 0.5% overestimate of total trip length. It would be difficult to produce an error that not only cancels out the negative error due to ignoring elevation, but also adds 3-5%.

These errors typically do not depend on duration of travel, but they do depend on the route. Normally, though, as a route becomes more tortuous, the GPS readings tend to replace "wiggles" with line segments, once more underestimating the distance. Again it is difficult to see how the GPS could be introducing a net 3-5% overestimate. Several possible alternative explanations are:

  1. The GPS may be subject to unusually erratic conditions, such as those that might be faced by a unit traveling deep within urban clutter.

  2. The distance believed to be correct might actually be incorrect. (For example, a car's tires can wear by 3% - 5% of their diameter during their usable lifetimes, resulting in a 3 - 5% increase in odometer readings. If the odometer is calibrated for a new fully inflated tire but the car is run on worn partly inflated tires to measure a route, it conceivably could overestimate the distance by 5% or more.)

  3. The "correct" distances may have been calculated on a map using a projection with substantial scale error.

share|improve this answer
    
Great answer !!.. however let me tell you why I am facing a overestimate.. Typically, when in a traffic signal / just plainly stopped on road.. the android api tells me the new lat long pair when there is a displacement of minimum 5 meters.. The problem is the api informs me of even the "drifted" lat long to be 5m away and hence I increment the odometer value which keeps accumulating errors because device did not move.. Hence if the device is stationary it keeps accumulating this error.. I can send you actual gps data for you to have a look.. –  srinathhs Jul 16 '12 at 17:42
    
srinathhs, Posting the data would be welcome. (A short excerpt showing the structure and the first few and last few records for one dataset might suffice. You could also post a longer dataset elsewhere and link to it.) Your clarification is extremely helpful: could you please edit the question to include it? Given a reasonable understanding of the causes of the increases, I think it will be possible to identify a good procedure to smooth the data in a way that eliminates most of the unwanted "noise" and thereby reduces the bias in the distance estimates. –  whuber Jul 16 '12 at 17:49
    
I have edited the question with all info. –  srinathhs Jul 16 '12 at 18:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.