Detecting "lack of movement" on GPS device

Question

We're using a GPS tracking device mounted in vehicles and later display the movements in our application. We're having a small issue however with vehicles when they are NOT moving.

Despite standing still, the GPS device will send information with varying positions, sometimes it'll even report the vehicle is moving (every once in a while it'll report a vehicle is moving quite fast). The end result is an ugly representation of the movement in our application, and worse, incorrect calculations with regards to how long the vehicle was moving and was standing still (we've got some statistical analysis going on as well).

I know the problem isn't new: Google Navigation on my Android phone also has trouble when I stop at a crossroad every now and again, detecting that I'm now driving in the opposite direction (when in fact, I'm standing still).

But we really need to have some method of telling the vehicle isn't moving, especially for prolonged periods of time.

The problem is compounded in some vehicles which are kept under roofs for the night, which causes the GPS to go wild due to a weaker signal (which is still strong enough to get a position however).

We can detect if the vehicle's engine is turned on or off, but we cannot assume it's not moving with the engine off (there were incidents where a damaged vehicle was towed... and of course there's a case of potential theft which also needs to be reported).

What's the best way to approach this problem?

EDIT:

To add some more information:

• The GPS device does have an accelerometer, but that only returns a binary information (moving / not moving) and it's either TOO sensitive or just plain isn't working.

• We do have access to things like number of satellites or quality, but we're unsure how to utilize that information. Thus my question. :)

• The problem isn't about detecting if a vehicle is moving or not in real-time. We collect the data, and later on do some statistical analysis and display it. We do show the current position of the vehicle, but that is of little importance. So basically we need to be able to tell a vehicle was or wasn't moving by looking at historical data.

Answer 1

The comments below your question bring up some good points, especially about interpreting satellite data quality (# of satellites, signal strength), and you could use this information either on the mobile device or on the server to filter out "bad" GPS values. The question comes down to two parts: 1) how do you define a spurious GPS reading, and 2) how do you define a stationary state.

Let's start with a couple of parameters:

• stationary_speed = if the mobile unit is going slower than this, then it's stationary
• too_fast = if the mobile unit is going faster than this, then it has given a bogus GPS reading

It's tricky to calculate these speeds with accuracy. Say that you calculate the speed as the / between the previous reading (at t0) and the current reading (at t1). If the time delta is great, and the unit goes around a curve, then the actual distance traveled will be greater than the calculated distance. Also, if you get two spurious readings in a row, and they are near enough to one another, then you can get unpredictable results.

Once you have the speed, just compare it to your parameters to see if the GPS reading is spurious or if the unit is stationary.

You can do more sophisticated filtering with Kalman filters, but that can be much more involved.

Answer 2

We've managed to tweak the motion sensor data.

Using the motion sensor data, ignition data, and speed reported by the GPS tracker we should be able to tell when a vehicle is moving or not with pretty good accuracy.

Also we've taken a look at the number of satellites, and that didn't look to well. While the number of satellites was lower for a vehicle under a roof, it was still relatively high. 9-10 is the usual value for such a vehicle, while under a roof it drops to 7 (but can occasionally get a signal and go up as well). Needless to say, the number of satellites proved to be less than useful.

Answer 3

You can to use the number of sats used to take the last fix, not the ones in view. Eg. View = 11, Fix = 5 And use the Max DB values of the signal of the strongest sat. This has to be over 30Db to get a decent signal.

The devices we use have a concept of moving/non moving, sensors are : Acceleration, vibration, input voltage, input signal (from key contact) , GPS data. To report on positions like start/stop (it's event based) and direction/distance events the device has to be in moving mode (this is a countdown counter, configurable).

Sensors have the possibility to be combined. No direction/distance events nor timers are being reported while the tracer determines not to be in moving mode. When the sensors involved stop reporting, the timer counts down to zero and then a stop-event is generated + the unit is put in non-moving mode. Until the next time. This way you can separate a starting engine acceleration values to 'put' it in moving mode, and a separate lower threshold for 'keeping' it in moving modus since both are very distinct acceleration patterns.

The units we use will report if a point is been taken with bad sat data, not sure if your hardware does that. We have either a SV_Position or an SV_KeepAlive or SV_TimeAlive. The Keepalive will repeat the exact last value since the GPS cannot update it's tables nor get a accurate fix at all, not even a bad one. The TimeAlive is what you'll see when you are crossing a tunnel or someone has parked in a garage.

One way to also monitor, albeit it's a partly making educated guesses and it depends on the kind of assets you're tracking is the voltage power supply. eg. a device operating at 12.30v is a car who's engine is not running. If you see one that reports 14.2v you know it's alternator is spinning. For 24v vehicles there is a similar pattern to spot.

Hope this gives you some idea's. It all depends a bit on how good the hardware is. The source of your data starts there and all the rest after that is only as good as it is. But I would strongly encourage you to use the units capabilities to do quality distinction instead of doing it all serverside (in hindsight). Once you do like 3000 units you'll need a beefy server to constantly analyse all tracking data, so by then you'll realize that it won't scale.

Answer 4

I've had a similar problem when using a GPS logger to track a scooter. What I did was overlay the GPS track on a road layer, and manually deleted the erroneous locations in or near an intersection or traffic light. I'm sure there are automated tools to deal with that, probably buffers around intersections, and calculating the minimum and maximum time in and out of that buffer.

Answer 5

The term of the art for this is spidering. A common approach is to simply only sample when the fix is 10m from the previous fix. For example, Garmin handhelds record fixes based on distance while the fitness watches record fixes based on time. The handhelds don't spider very much but the watches do.

Answer 6

Calculate distance between both GPS coordinates current and previous coordinates (that you have used/transmitted to server).

As per accuracy of your GPS device you can set a distance limit, like if vehicle is 100 meters away from previous location device will report activity.

We can easily calculate distance between two coordinates using math.