Distance calculation : Integrating incremental gps data

Question

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?

Answer 1

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 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:

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.

Answer 2

It sounds like you need to a for structure, this will enable you to make the readings relevant if you have moved more than (Example 20m), if you have not moved more than 20m, it will save the gps data as a non point, and not add the errors to the odometer counter. Still this solution will not be 100% accurate. The more you stop, the more errors could be added. (Say you stop 5 times on a journey, the total Miliage may be out by 5*20m= 100m. Over a 20km trip that is an up to 0.5% error. Should be good enough seeing that most vehcle speedometers have more than 0.5% error.)

Cell phone Gps are not that accurate, in agriculture they have a temporary beacon (Usually on a tripod close to the field somewhere, so the exact position can be triangulated for an accurate positioning system.