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 :
- The distance calculation is not considering altitude.
- 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?
Best 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)
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 https://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:
The GPS may be subject to unusually erratic conditions, such as those that might be faced by a unit traveling deep within urban clutter.
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.)
The "correct" distances may have been calculated on a map using a projection with substantial scale error.