Detecting “lack of movement” on GPS device

Me and my associated are having a bit of a concept problem.

We're using a GPS tracking device mounted in vehicles and later display the movements in our application. Pretty straightforward, right?

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:

• 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.

-
if you have an accelorometer integragrated into your tracker, you can exploit acceleometer data to detect if the vehicule is really moving, and you can switch off the GPS tracking if is not moving. – geogeek Oct 8 '12 at 11:33
Does your GPS device log quality of signal, number of satellites, that kind of data? Also, it sounds like you will 'later display the movements ...' so could you confirm that it's not a real-time detection issue, rather something you will filter later on during processing? – Simbamangu Oct 8 '12 at 12:54
I've edited my question to give more information. In short: the accelerometer is acting crazy, we have access to satellite count or quality info, but we're unsure how to use them, and yes, this is NOT a real-time detection issue. – Shaamaan Oct 8 '12 at 14:58
You will find some useful recommendations on the stats site related to detecting outliers and smoothing. – whuber Oct 8 '12 at 16:05
Geofence - when a vehicle is in a zone (ie garage then do no record the position) - androidzoom.com/android_applications/geofencing – Mapperz Oct 9 '12 at 13:39

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.

-
The term for this is Multipath Error – ruruskyi Jun 11 '15 at 13:25

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.

-
I do have to comment about the idea to collect voltages. It's excellent! We're having a fair bit of trouble with certain vehicles, and we're unsure why. We're currently suspecting it might be due to poor skills on part of the tech-guy who mounted the tracking devices which results in voltage problems, albeit it can also be sabotage (yes, sabotage; we're monitoring fuel levels and the drivers don't like that). If we can record the voltage on the tracking devices, that should help immensely. :) Huge thumbs up! (I'd give more than one, but sadly, I cannot...) – Shaamaan Oct 11 '12 at 7:22
It works for every vehicle that doesn't have a voltage regulator between your tracer unit. Check this link out of the configuration program of KCS, this is the unit I'm talking about, just run it and see what you can do concerning motion sensing, you'll be surprised. Download this one , that is the latest software of the revision9 units. The voltage idea is theirs. You'll see some good defaults there (truck/car/motor) – Glenn Plas Oct 11 '12 at 7:27
The number of sats is a bad indicator, you really want the number of sats used to take the last fix (That is the value you look at, it's not a current-situation indicator), although the number of sats will make you able to determine absolutely bad points, it will not help you around the grey zone,e.g. the mediocre quality samples. You need to combine different sensors. Calculating speed is in essence doing the same as your GPS chip already does now, and that quality too depends on the number of samples you take (roads aren't straight everywhere) and their accuracy. Chick-egg problem – Glenn Plas Oct 11 '12 at 7:34

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.

-
The info is still useful to determine faulty data. I do a great deal of 'correct' filtering based on it. 9 is still high, are you sure the chip doesn't repeat the last good known value, they do have this functionality on board and it's enabled most of the times. – Glenn Plas Nov 9 '12 at 8:23
The main problem is with vehicles which are stored in a shed of some sort for the night. I don't think it repeats the last know position, because vehicles WILL vanish completely if they enter / are stored in concrete garages (or anything more solid). The drop of satellites is an indicator, but it seems to be subtle and it turned out to be far easier to just tweak and use the motion sensor data. – Shaamaan Nov 9 '12 at 9:07
Not on the 3000+ vehicles I track, you need the number of sats used to take the fix, not the ones in view. Those can remain high when you have a roof that still lets something of a signal pass. But the fix is a good indicator, together with the Db gain values. – Glenn Plas Nov 9 '12 at 13:53
I can perfectly tell wich ones are inside/outside a garage of some sort. I also don't suffer from the spidering problem as the state of motion/non-motion traps it. I do aggree that the sensors give you much more to go on. – Glenn Plas Nov 9 '12 at 13:56
It's entirely possible my colleague has set up the number of visible satellites by mistake, rather than the number used for a fix (all I saw was an Excel sheet with data with column titles being filled out manually). :P In any case, as I wrote, the tuned motion sensor was our way out of this problem. – Shaamaan Nov 9 '12 at 16:18

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.

-
Since the vehicles are problematic when not moving whilst on parking lots or garages, this isn't at all useful. :( – Shaamaan Oct 9 '12 at 6:21

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.