Unfortunately, a lack of time, as well as dedication to other projects, has lead this project to fall by the wayside for entirely too long - but work has picked up again and regular updates resumed!
During the course of script testing, one of the biggest annoyances I've come across is the tendency of the GPS fix to 'wander' across a small distance from its actual location when stationary. This seems to be exacerbated when conditions aren't ideal, such as trees/fences/hills or other obstructions between the device and the sky. Not only does this hinder the ability to detect if the device is stationary, but it also looks rubbish when output to KML:
The above is an extreme example; 484 waypoints collected over a 9.5 hour period. In reality, I doubt the payload will remain stationary for such lengths.
Fortunately, the device itself gives some clue as to how accurate we can consider a reading to be through the 'accuracy' level associated with the location - this gives us a radius within which the device is located. If we compare this with the previous GPS location, we can ensure there's no overlap between the two locations(if accuracy_previous + accuracy_current > distance_moved)and determine if a waypoint should be recorded.
Unfortunately, the above isn't always reliable; I've regularly observed the device recording movements slightly outside of the combined accuracy range of the two locations. To combat this, I've included a user-defined tolerance value (gps_accuracy_tolerance) which will add the specified percentage tolerance to the GPS accuracy value. In testing, I've found a value of 10% reduces false-positives by around half (following initial error correction).
The next check performed ensures that the accuracy range is within a user-specified value (gps_accuracy_maximum) beyond which the waypoint is discarded - I've set this to 25 meters. My device tends to report accuracy in multiples of 5; however this does vary depending on the GPS chipset employed by your device.
The result of the above checks gives us a fairly rudimentary yet effective error filtering algorithm, reducing wandering by over 98% - down to 9 waypoints from 484 in the original example:
This algorithm isn't foolproof, however. If the payload is travelling at a very low speed and the distance moved between each subsequent location update is less than the combined accuracy (usually between 10 and 25 meters), waypoints will be discarded - even if the device continues to move away from the initial location. To circumvent this, another user defined variable (kml_waypoint_distance) will force a waypoint to be recorded if the device detects movement greater than the specified distance, provided that gps_accuracy_tolerance is within the specified range.
Of course, if the device is actually moving around within a small radius, legitimate locations will be regarded as errors and discarded. This isn't the sort of movement we're expecting to see, however I have included both raw and corrected KML output functionality within the script.
No comments:
Post a Comment