CODEWITHSUNDEEP
c#algorithmgps
Michael Mankus
Michael Mankus

Reputation: 4788

Calculating Speed Based on Randomly-Timed Received Position Coordinates

I'm writing an application that has a need to know the speed you're traveling. My application talks to several pieces of equipment, all with different built-in GPS receivers. Where the hardware I'm working with reports speed, I use that parameter. But in some cases, I have hardware which does NOT report speed, simply latitude and longitude.

What I have been doing in that case, is marking the time that I receive the first coordinate, then waiting for another coordinate to come in. I then calculation the distance traveled and divide by the elapsed time.

The problem I'm running into is that some of the hardware reports position quickly (5-10 times per second) while some reports position slowly (0.5 times per second). When I'm receiving the GPS position quickly, my algorithm fails to accurately calculate the speed due to the inherent inaccuracies of GPS receivers. In order words, the position will naturally move due to GPS inaccuracy, and since the elapsed time span from the last received position is so small, my algorithm thinks we've moved far over a short time - meaning we are going fast (when in reality we may be standing still).

How can I go about averaging the speed to avoid this problem? It seems like the process will have to be adaptive based on how fast the points come in. For example if I simply average the last 5 points collected to do my speed calculation, it will probably work great for "fast" reporting units but it will hurt my accuracy for "slow" reporting units.

Any ideas?

Upvotes: 3

Views: 2207

Answers (5)

Denise Skidmore
Denise Skidmore

Reputation: 2416

You probably have an existing data point structure to pull a linq query from?

In light of the note that we need to account for negative vectors, and the suggestion to account for known margins of error here is a more complex example:

class GPS
{
    List<GPSData> recentData;
    TimeSpan speedCalcZone = new TimeSpan(100000);
    decimal acceptableError = .5m;

    double CalcAverageSpeed(GPSData newestPoint)
    {
        var vectors = (from point in recentData
                       where point.timestamp > DateTime.Now - speedCalcZone
                       where newestPoint.VectorErrorMargin(point) < acceptableError
                       select new
                       {
                           xVector = newestPoint.XVector(point),
                           yVector = newestPoint.YVector(point)
                       });
        var averageXVector = (from vector in vectors
                              select vector.xVector).Average();
        var averageYVector = (from vector in vectors
                              select vector.yVector).Average();
        var averagedSpeed = Math.Sqrt(Math.Pow(averageXVector, 2) + Math.Pow(averageYVector, 2));

        return averagedSpeed;
    }
}

But as pointed out in comments, there is no one magic algorithm, you have to tweak it for your circumstances and needs.

Upvotes: 1

AlexWien
AlexWien

Reputation: 28757

Use a simple filter:

Take a position only if it is more than 10 meters away from last taken position.

Then caluclate the distance between lastGood and thisGood, and divide by timeDiff.

Your further want to ignore all speeds under 5km/h were GPS is most noisy.

You further can optimize by calcuklating the direction between last and this, if it stays stable you take it. This helps filtering.

Upvotes: 1

Sten Petrov
Sten Petrov

Reputation: 11040

You're looking for one ideal algorithm that may not exist for one very simple reason: you can't invent data where there isn't any and some times you can't even tell where the data ends and error begins.

That being said there are ways to reduce the "noise" as you've discovered with averaging 5 consecutive measurements, I'd add to that you can throw away the "outliers" and choose 3 of the 5 that are closest to each-other.

The question here is what would work best (or acceptably well) for your situation. If you're tracking trucks moving around the continent a few mph won't matter as the errors will cancel themselves out, but if you're tracking a flying drone that moves between buildings the difference can be quite significant.

Here are some more ideas, you can pick and choose how far you can go, I'm assuming the truck scenario and the idea is to get most probable speed when you don't have an accurate reading: - discard "improbable" speeds - tall buildings can reflect GPS signal causing speeds of over 100mph when you're just walking, having a "highway map" (see below) can help managing the cut-off value - transmit, store and calculate with error ranges rather than point values (some GPS reports error range). - keep average error per location - keep average error per reporting device - keep average speed per location, you'll end up having a map of highways vs other roads - you can correlate location speed and direction

Upvotes: 0

Ivan
Ivan

Reputation: 1256

I'd try using the average POSITION over the last X seconds.

This should "average out" the random noise associated with the high frequency location input....which should yield a better speed computation.

(Obviously you'd use "averaged" positions to compute your speed)

Upvotes: 1

Becuzz
Becuzz

Reputation: 6857

I would average the speed over the last X seconds. Let's pick X=3. For your fast reporters that means averaging your speed with about 20 data points. For your slow reporters, that may only get you 6 data points. This should keep the accuracy fairly even across the board.

Upvotes: 1

Related Questions