I get a latitude and longitude callback, how can I best calculate the "current speed" and other derived values?

Question

(I think this question is platform independent, but I happen to code the Nexus One).

About "current speed": I get a callback every second or so, telling me what my current latitude and longitude are. I can calculate the distance between the current location and the previous location, so I can track the cumulative distance and cumulative time. With this, I can say that the average speed was for the whole trip.

But how can I determine the current speed? I suspect that I need to use the most recent N samples, right? Am I thinking about it right? What is a good rule for N? How many samples or how many seconds ago?

About the “second”: if I just stop, I can still get several different latitudes and longitudes, informed me, right? Therefore, deciding that I really am not moving, you say something like: "the previous X locs were all in Y meters from each other," right? Am I thinking about it right? What is a good rule of thumb for X and Y?

Even about the "distance": will I underestimate this because I literally cut corners? Is there an algorithm or rule of thumb to determine when I am “turning” and should I add a little fiction?

EDIT: I OPPOSE: I feel bad when I spend people and goodwill, but, unfortunately, the device gives me speed. I thought that this was not because in the emulator it wasn’t, but on a real device. Thanks to everyone. There is still some thumb rule code I need to write, but speed was the biggest problem.

EDIT: I cancel the apology. In my original question, I wrote that distance is also a derived value. If I just use raw GPS data, I will exaggerate the distance due to inaccuracies. I could go in a straight line, but the raw GPS lat / long will fluctuate, so if I calculate the total distance by measuring the distance between the points, I will overestimate it. Here are some links related to this issue.

GPS smooth data
http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html
How to intellectually degrade or smooth out GIS data (simplifying polygons)?
How to "smooth" the data and calculate the gradient of the line?

Answer 1

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

Answer 2

Remember the short history of the position, returning for a few seconds. 5 seconds should give you a fairly accurate result, which is updated 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 (for example, if you save the last 30 positions and use a 30 second delay), the more stable your answer will be (i.e. the less noise will be), but it will respond more slowly to any changes in speed .

Why do you need to add this delay? well, the GPS unit in your phone is probably not very accurate. If you stop, the position that he returns every second may fluctuate relatively honest. This wobble noise will make it look like you are randomly running around the room and can report a moderately high speed, even though you are not moving at all. The solution that I listed will not really help when you stop, as the result from 30 seconds ago will be as wrong as the position from 1 second ago. What you really need to do is average the position over a period of time, and then compare it with the average position from a little earlier time. eg,...

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

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

Answer 3

Your approach is not entirely wrong, but naive. There is a huge mathematical basis for such problems - called, not surprisingly, filters. You can get much better than "averaging the latest N values."

For example, Kalman filters are easy to implement and configure, and are usually good enough for practical tasks.

In addition, do not try to smooth or average the GPS signal - the GPS receiver does this on its own. Instead, the base filter is at the expected accelerations of the vehicle (or person).

Finally, the instantaneous speed can be calculated from the frequency shift, if you can get this information.

Answer 4

As for the "cutting angles", you can always approximate the curve (using splines or for real regression), otherwise I think that you are on the right track.

As for the number of samples and standing, instead of taking a constant N, I would look at the deviation of the samples.

Answer 5

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

BUT: Since this is quite vulnerable to minor inaccuracies in the time / position, it is unreliable, so you should average it over the last positions. How many of them depend on the use case, the longer the time interval, the lower the "current" speed, but the more accurate.