GPS programing: I'm getting a callback every second or so with latitude and longitude. What's a good rule of thumb for calculating "current speed", and other derived values?

Question

( I think this question is platform independent, but I happen to be coding for a Nexus One).

About "current speed": I'm getting a callback every second or so telling me what my current latitude and longitude are. I can calc the distance between the current location and the previous location, so, I can keep track of cumulative distance and cumulative. With that I can say what the average speed has been for the ENTIRE trip. But how do I calc current speed? I suspect I need to use the most recent N samples, right? Am I thinking about this the right way? What's a good rule of thumb for N? (how many samples, or how many seconds back?)

About "stop time": If I'm just standing still, I can still get slightly different latitudes and longitudes reported to me, right? So, deciding that I'm not really moving means saying something like, "the previous X locs have all been within Y meters of each other", right? Am I thinking about this the right way? What's a good rule of thumb for X and Y?

Even about "distance": will I be understating it because I'm, literally, cutting corners? Is there an algorithm, a rule of thumb, for determining when I'm "turning" and should I add in a little fudge?

EDIT: I APOLOGIZE: I feel bad about wasting people's time and good will, but sadly, the device IS giving me speed. I thought it wasn't because in the emulator it wasn't, but on the real device it is. Thanks everybody. There's still some rule-of-thumb code I need to write, but speed was the biggest challenge.

EDIT: I retract the apology. In my original question I wrote that distance too is a derived value. If I just use the raw GPS data, I will be overstating distance because of the inaccuracies. I might be walking a straight line, but the raw GPS lat/long will wobble, so if I calc total distance by measuring the distance between the points, I will be overstating it. Here's some links that are related to this problem.

http://stackoverflow.com/questions/1134579/smooth-gps-data
http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html
http://stackoverflow.com/questions/1849928/how-to-intelligently-degrade-or-smooth-gis-data-simplifying-polygons
http://stackoverflow.com/questions/204184/how-to-smooth-data-and-calculate-line-gradient

Answer 1

The current speed is the difference between Position(now) and Position(previous) so to get the current speed you only need to compare the current and last position.

BUT: As this is quite vulnerable to small inaccuracies in time/position tracking it is not reliable so you have to average it over the last Positions. How many depends on the use case, the longer the time frame the less "current" the speed is but the more precise it is.

Answer 2

Remember a short history of position, going back a few seconds. 5 seconds should give you a reasonably accurate result that updates fairly quickly...

// delay is the time difference between the 2 samples you have
delay = 5;   // 5 second delay

// figure out how far along x and y we have moved since last time
dx = newx - oldx;
dy = newy - oldy;

// distance travelled
distance = sqrt(dx*dx + dy*dy);

// find the speed. if the positions were measured in metres and the time in seconds
// this will be the average speed in metres per second, over the last 5 seconds
speed = distance / delay;

The longer you can wait between samples (eg, if you keep the last 30 position samples and use a 30 second delay), the more stable your answer will be (ie, the less noisy it will be), but the slower it will be to react to any changes in speed.

Why do you need to add this delay stuff? well, the GPS unit in your phone probably isn't very accurate. If you are standing still, the position it returns each second might wobble about a fair bit. This wobble noise will make it look like you are sprinting randomly around the room and might cause you to report a moderately high speed, even though you're not moving at all. The solution I have listed will not really help when you are standing still, as the result from 30 seconds ago will be just as wrong as the position from 1 second ago. What you really need to do is average the position over a while, then compare that to the average position from a slightly earlier time. eg...

Take 10 samples of position and average them. This is position 1.
Take another 10 samples and average them. This is position 2.
Use these 2 positions with the code above to get the speed.

Again, the more samples you can take, the more accurate and stable your positions will become, but this will make your speed measurement less responsive.

Answer 3

Regarding 'cutting corners', you can always approximate a curve (using splines or for real overkill - regression), otherwise I think you are on the right track.

Regarding how many samples and standing still, instead of taking a constant N, I would look at the deviation of the samples.

Answer 4

about the current speed: most gps devices send you this information on their own

Answer 5

Your approach is not really wrong, but naive. There's a huge mathematical foundation for such tasks - called, unsurprisingly, filters. You can get much better than 'averaging last N values'.

For one, Kalman filters are easy to implement and tweak and are generally good enough for practical tasks.

Also, don't try to smooth or average GPS signal - GPS receiver does that itself. Instead, base filter on expected accelerations of the vehicle (or human).

Finally, momentary velocity can be calculated from frequency shift, if you can get that information.