runnerup
runnerup copied to clipboard
jonasoreland
Implement an option to smooth GPS coordinate
I run around big buildings with phone in my pocket, this results in small jumps on recorded gps coordinates due to bad precision. For instance, my usual run distance is 7km, but the recorded distance with RunnerUp is ~8.5km (pretty big difference).
I would love to have an option to smooth GPS data (real time, during recording would be a big plus), for instance using the Douglas-Peucker algorithm.
An alternative would be to add option to select the frequency of recorded data points (for instance every 1, 5 or 10 seconds), low frequency will smooth the whole route (with a loss of resolution).
BTW, thanks for the app, I'm glad to have found an open source activity tracker! (I'll have a look at the code later and try to implement this option).
i think i added such options in "advanced"... Poll interval (ms) Poll distance (m)
with those you can affect frequency of data pointer... but I don't think I ever tested this myself...
/Jonas
On Sat, May 16, 2015 at 9:31 PM, Maxime Biais [email protected] wrote:
I run around big buildings with phone in my pocket, this results in small jumps on recorded gps coordinates due to bad precision. For instance, my usual run distance is 7km, but the recorded distance with RunnerUp is ~8.5km (pretty big difference).
I would love to have an option to smooth GPS data (real time, during recording would be a big plus), for instance using the Douglas-Peucker algorithm https://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm .
An alternative would be to add option to select the frequency of recorded data points (for instance every 1, 5 or 10 seconds), low frequency will smooth the whole route (with a loss of resolution).
BTW, thanks for the app, I'm glad to have found an open source activity tracker! (I'll have a look at the code later and try to implement this option).
— Reply to this email directly or view it on GitHub https://github.com/jonasoreland/runnerup/issues/257.
FYI, I changed the "Poll interval (ms)" option from the default 500ms to 2500ms, that interferes with the auto pause detection (pause/unpause every 10 seconds). I'll try again later with auto pause disabled.
I don't understanding how the RDP algorithm would improve the path. Wouldn't we end up with just as noise, just more coarse path with less points?
I found others use Kalman filters
Is that so that poll interval/distance=0 would achieve the best precision or should I enter some small numbers there?
I do suffer from the Jaggy GPS track (https://github.com/jonasoreland/runnerup/issues/356) and it seems that while walking it will very frequently stop/resume despite moving unless I am walking very fast.
A simple filter would be to change the default values: 2s and 10m gives much better results for me. Similar values seem to be used in other running apps that gives better results for me.
@gerhardol are these "better" values for running in open spaces, around small building and/or trees, or in between tall buildings?
A filter will smooth data which improves in most situations.
Increasing GPS has the drawback that if you move faster, all points are not recorded (2s/10m should not be noticable with GPS but 60s will). For RU it also has the drawback that other data like HR will be sampled less often and that detection of pace changes will be slower. Auto-pause parameters may need adjustments.
I'd just like to add my own experience. Used runnerup to track a half marathon and it recorded a distance of 21.6km (13.4 miles), I had the GPS settings at 250ms and 3m. Using GPSVisualiser.com I smoothed the track using a Trackpoint distance threshold of 10m which brought the distance back down to the correct 21.1km. So +1 from me for using a default GPS polling distance of 10m
@iamkagy @gerhardol I have no experience with this, so let me ask a very naive question: would a longer distance/time for polling also decrease resolution as it sounds? If so, is the resolution exactly the same as polling or not? A resolution of 10m really sounds very coarse to me!
@davidedelvento Yes, it does decrease the resolution, but the accuracy of GPS is only 7.8 meter (95% Confidence Interval). On my track it had me 'zig zagging' across the road, which obviously adds up over a longer distance. you can see this in the attached image, the green track is the smoothed line (~12m between points). The orange track is the gps polling at 3m, the resolution is about 4.5m between points (averaged over the 4000+ points in my track).
@iamkagy explained it well. A track that is not smoothed will normally be too long (unless the track is twisting much more than sampling).
If the GPS driver was tuned to give "next most likely position based on previous" like Garmin GPS instead of "most likely current position" tracks the calculation will be better. Garmin GPS are mediocre but the SW compensate quite well.
It may be possible to use max sampling from the GPS driver (that is filtered already to some extent) and merge that with other sensor data (as well as GPS speed and accuracy), but there are no public algorithm I know of. Just changing the defaults should give most users a better default experience.
Ok, this is what I imagined before knowing from your kind explanation. Yet, I think a default 10m as default will be extremely coarse for most uses. Maybe 3m could be a better tradeoff between accuracy on straight courses vs winding ones?
Regarding the "secret algorithm", let me guess one.
Does the GPS speed have a direction or only an intensity? If it has both a direction and intensity, it's trivial to compute the next expected position from the polling interval (the time). Then, give this expected position a confidence interval by putting some reasonable assumptions on how much a running person can accelerate, decelerate or laterally swerve in that time interval. Then merge this point (with confidence interval) with the obtained GPS position (with confidence interval) either trivially (e.g. intersection of the two volumes in space, or maybe surfaces in the plane, if we assume a runner is at ground level and not running on the top of a skyscraper), or with some more sophisticated, but known, GPS or GPS-like algorithm, using this expected position as an additional satellite.
If the GPS speed is only intensity and not direction, we can still do the same, using vector from the previous two positions as an indication of the direction, however in this case the error would be larger because of both the doubling of the sampling, and because we are estimating position using position, instead of position using speed (less dependence of measurements errors).
Of course all of this will work with frequent polling times/distances. If we settle for 10m polling, all of this will fail miserably: in 10m I can go from stopped to almost my top speed (or vice versa). Or I can swerve 360 degrees (perhaps even more).
Since 1.57 the speed and bearing (as well as gps accuracy and sattellites) can be logged, see settings. Exported to GPX. Can be used to experiment or post process.
2s and 10m will cut off in some situations but will overall improve. The best value depends on the gps quality, surroundings and user factors(speed etc). I believe it is better to smooth harder as more users are concerned about total distance than accelrations (that will be off any way).
This is not directly related to this product, but while hiking in Harriman State Park with a Garmin GPS, I ended up with an absurd elevation gain. I am aware of the usual problems with "sawtooth" tracks (both horizontal and vertical) but thought this dataset might be useful for testing elevation algorithms. Please feel free to ignore. The main problem with the source data is likely to be GPS bounce on the very rocky landscape, with elevations changing up to 39 meters per second for a hiker (usually a fatal value). I have tried a few very basic algorithms to clean this data, but do not have enough data science/engineering to do it right. I figured I would leave this with someone that is more capable in case there was any interest in developing a scrubbing library (which may well exist -- my research is only a few hours old). Thanks. No follow up is expected. Track_2019-11-28 163608.zip
