New Topic

Locus Map - help desk Topic Idea Locus Map (Android)

This object is in archive!

Category Locus Map (Android)

Tags Filter, position, Kalman

Comments 36

Subscribers 10

Votes 8

Simple implementation of GPS position filtering ( cheap pseudo Kalman )

Libor Poutnik Striz shared this idea ago

Completed

As told by Menion, Locus does not currently use filtration of GPS position. Such filtering ( ala GPS averaging ) could be useful for geocaching or terrain surveying for OSM mapping.

I got idea of optional use of such filtering, eventually triggered by speed limit, similarly as magnetic compass is.

I suggest very simple filtering, using weighted average of the measured position and the position predicted from previous 2 filtered positions - a kind of a cheap pseudo Kalman filter. Prediction supposes you are moving without acceleration, with initial position, direction and speed given by last 2 filtered positions.

N is an index of position timeline

X is weighting factor, the higher means stronger filtration. 0 means zero filtration, >>1 means very strong filtration

Note that such filtering will apply to altitude as well, as part of 3D position.

As first 2 filtered positions would be trivially taken 2 subsequent measured positions.

Edit: As a waist shoot, values X=1-4 could be a good trial values.

FilteredPosition(n+1)=(MeasuredPosition(n+1,GPS) + X * PredictedPosition(n+1))/(X+1)
PredictedPosition(n+1)= 2 * FilteredPosition(n) - FilteredPosition(n-1)

I like this idea 0

Replies (12)

Libor Poutnik Striz ●

Hm, perhaps a static initial state FilteredPosition(2)=FilteredPosition(1) would be better, as otherwise initial state could be too "jumpy".

URL

Libor Poutnik Striz ●

For low enough speed would be probably better ..

PredictedPosition(n+1)= FilteredPosition(n)

And generally the true Kalman filter.

URL

Wolfgang ●

I would need this filter to "smoothen" the speed value.

URL

Libor Poutnik Striz ●

I suppose so as well. a good solution would be double exponential smoothing,

NewEstimatedPosition = ALFA * NewMeasuredPosition + ( 1-ALFA)*( PreviousEstimatedPosition + PreviousEstimatedVelocity )
NewEstimatedVelocity = BETA * ( NewEstimatedPosition - PreviousEstimatedPosition ) + ( 1-BETA)*PreviousEstimatedSpeed

URL

Libor Poutnik Striz ●

ALFA and BETA are smoothing time constants for both position and velocity, respectively.

Both have value from 0 - total filtering - unusable till 1 - zero filtering.

Generally , the lower the ratio of speed/GPS error is, the stronger the filtering should be.

Seems like ALFA is good 0.2-0.6, BETA 0.05-0.2

URL

Libor Poutnik Striz ●

ALFA = 0.2 + 0.4 * PreviousEstimatedSpeed(m/s) / (10+PreviousEstimatedSpeed(m/s) )
BETA = 0.05 + 0.35 * PreviousEstimatedSpeed(m/s) / (10+PreviousEstimatedSpeed(m/s) )
NewEstimatedPosition = ALFA * NewMeasuredPosition + ( 1-ALFA)*( PreviousEstimatedPosition + PreviousEstimatedVelocity )
NewEstimatedVelocity = BETA * ( NewEstimatedPosition - PreviousEstimatedPosition ) + ( 1-BETA)*PreviousEstimatedVelocity

URL

Menion ●

Hi guys,

I'm just uploading on Google Play new Beta version of Locus Map application 3.26.2.9.

In this version is added a new horizontal filter for GPS locations! Needs testing anyway. To enable it, choose its strength in expert settings. After that, the best is to start track recording (with 1s/1m setup). On the map will be drawn line created by track recording service and also dashed line created from original locations!! So you may really easily compare the difference.

Let me know if this feature makes any difference for you and if set strength is usable on your devices. Thanks

URL

Josef Žajdlík ●

Hi Menione. Does it make sense to try on a phone with a built-in barometer?

URL

Menion ●

Hi, this filter is about the location of trackpoints (latitude/longitude), not about altitude (for this already exists "altitude manager).

So yes it does. I'm testing it on Pixel 2, which has really accurate GPS, but enabled "Location filter : light" still, from time to time, catch few GPS glitches and makes tracks more smooth. On cheaper or older devices, it's usage should be even better.

URL

Andrew Heard ●

Sorry Menion & Libor I haven't had time to experiment with Libor's spreadsheet. So busy here building a new house, and the summer Audax riding season. Really looking forward to providing feedback on this new feature.

URL

Wolfgang ●

2 years ago I voted for this issue. At this time I used a LG G2 - and it was before you rewrote the positioning part of Locus (maybe one year ago?). Now I use a Samsung S7 and with your changes everything is fine (in Locus Pro 3.35.2). The speed value is "smoothened" enough.

I tested the BETA 3.26.2.9 - the dashed line is already filtered by S7 or by Locus. Even "Light filter" seems to be too much, "Medium filter" is far too much filtering. The speed value changes too slow when accelerating or braking.

URL

Menion ●

Hello Wolfgang, you use "Google Services assisted location" (in Locus GPS settings)?

URL

Wolfgang ●

Hello Menion, "Google Services assisted location" is not activated.

Today I made some additional tests - the "Light filter" filters not too much (some additional filtering) on my S7 when I move. When I stop, the "Light filter" filters glitches when I don't move. So, here it's better than no filtering. The speed value changes slowly - but this is acceptable.

"Medium filter" would filter too much (on my S7) - when changing the direction it's too slow and the speed value changes too slow when accelerating or braking.

URL

Ingo Rau ●

Why with 1m/1s setup? I overlooked this and first tried with some standard setup (10m/10s I think), where even Heavy Filter didn't seem to make a real difference. Is the filtering only supposed to work for such a fine grained recording? 1m/1s tracks get huuuuge...

URL

Ingo Rau ●

Of course, this https://help.locusmap.eu/topic/track-simplification would help with huge tracks...

URL

Menion ●

1m/1 was only recommendation for recording profile to see the real difference between original and filtered value. The filter of course consume and filter all received GPS values, no matter how frequent are.

This filter is not here to reduce the number of recorded trackpoints or to simplify tracks. It should exist to smooth received data in cases, GPS is not reliable enough. The more precise GPS in your device and better signal reception, the less useful this filter will be.

URL

Wolfgang ●

Hi Menion, I think there is an issue when filtering is enabled: In the car I use the setting Orientation/Compass: "Orientation via GPS" - so I avoid the problems of a hardware compass inside the car when I have to stop e.g. at a red traffic light. This works fine with location filter "No filtration" (and for a long time in many versions of Locus). Small "micro-movements" in position do NOT rotate the map. The rotation of the map stays in the same direction until I drive again.

With one of the location filters in BETA 3.36.2.11 activated, Locus rotates the map with every "micro-movement" of the position in the direction of this "micro-movement". The map turns and turns and turns... I think Locus should behave the way it does with the setting "No filtration" (and like it does for many versions).

I have no problems with the setting Orientation/Compass: "Auto-change", 3.0 km/h

URL

Menion ●

Thanks Wolfgang,

your last sentence confuses me a little. With this auto-change, when you stand still (so your speed should be below 3.0 km/h), then it use same values like when enabled "Orientation via GPS".

Anyway, agree this may be a hardly solvable problem. I'll try to look at it ...

URL

Wolfgang ●

Hi Menion, as I understood "Orientation via GPS" ignores the hardware compass. "Auto-change" uses "Orientation via GPS" above the selected speed (eg. 3.0 km/h) and switches to hardware compass below 3.0 km/h.

I have two presets:

For hiking+biking: my setting is "Auto-change". This works fine in BETA 3.36.2.11. During biking with normal speed Locus uses "Orientation via GPS" - when I stop biking Locus uses the hardware compass.

For car+motorbike: my setting is "Orientation via GPS". Locus doesn't use the hardware compass. With "No filtration" the behaviour is to stop rotating the map when I stop the car eg. at a red traffic light. Until now this works fine in different versions of Locus (for many years...).

But with one of the filters activated (light, medium or heavy), Locus rotates the map with every "micro-movement" of the position in the direction of this "micro-movement". So the map turns and turns and turns... I think Locus should behave the way it does with the setting "No filtration" - with this setting Locus ignores "very small movements" of the position for the rotation of the map. With "No filtration" Locus moves the position on the map, but it doesn't rotate the map! That's how it should be with filters activated.

I hope I could explain it understandably with my English language skills...

URL

Menion ●

Ah I understand perfectly, I just have to try it personally tomorrow on the bike to see it.

Sorry for my previous post, I confused myself. You are of course correct in your first sentence!

Will try it and let you know, thanks.

URL

Libor Poutnik Striz ●

Zkoušel jsem na Xiaomi MI A2 / Android 9 lehký a střední filtr. Oba dávají hladkou křivku, ale lehký filtr se mi zdá neklidný a při chůzi má tendenci ke střednědobými fluktuacím. ( úseky desítek sekund70-100 m,chůze)). Střední se zdá stabilní, silný bych asi ani nevyužil.

URL

Libor Poutnik Striz ●

Just to add, I have not almost noticed any significant difference of the solid and dashed line, except for an intentional stop during my walk .

So, it is possible the Xiaomi firmware has already applied some Kalman filter.

URL

Josef Žajdlík ●

First test. Samsung A3, android 8, recording settings: 7/2/45. Walking 7 km. Filtering: weak.

The filter has greatly counseled the weaker signal after the GPS restart with Auto-off. See scr autooff.jpg.

He creates sharp angles in the corners, but at the same time he is well advised to filter the GPS failure after entering the church. See scr kostel.jpg

CZ: První test. Samsung A3, android 8, nastavení záznamu: 7/2/45. Chůze 7 km. Filtrování: slabé.

Filtr si skvěle poradil se slabším signálem po restartu GPS pomocí Auto-off. Viz scr autooff.jpg.

V zatáčkách vytváří ostré úhly, ale současně si výborně poradil filtorváním výpadku GPS po vstupu do kostela. Viz scr kostel.jpg

Files:

URL

Menion ●

Josef, thanks for tests. It looks maybe too good in your case :).

Libor, it is possible (Xiaomi). Also in case of enabled "Google Services assisted location" (in Locus GPS settings), Google most probably also apply some filtering on computed location. Anyway, generally light or medium filter seems to give usable results. Thanks.

And Andrew, no need to sorry. Btw. filtering is using Kalman filter, not exponential smoothing suggested by Libor some time ago.

URL

Libor Poutnik Striz ●

I see. Your confusion of myself was succesful, putting it into this thread.

I have hesitated to believe my filter would be as good, and additionally I have missed the exponential behaviour patterns.

I do agree and congratulate to use the Kalman filter.

Perhaps the future nice to have improvement could go from 2D to full 3D,

Processing predicted and measured altitudes as well. The predicted ones may be based on both previous values and SRTM values.

URL

Andrew Heard ●

Could full 3D also improve this thorny topic?

URL

Menion ●

It should be doable, I just not yet tested it. Will increase the dimension of the filter and check if it will correctly apply also on vertical value. If so (expect positive result), then it should really "fix" these huge spikes that appear in altitude. Good point ...

URL

Libor Poutnik Striz ●

I would point out, the ideal approach differ for on the fly filtering and for post filtering, as the latter has available future values and can eventually afford to process more data.

In fact, the mentioned post process Savitzsky Golay filtering for 5-25 points is very good,

and may provide an advantage to Kalman rather local filtering .

As we are not purists, we may realize the universal approach with the

Kalman filter can be good enough for the recording, without need of the postprocessing.

URL

Josef Žajdlík ●

Second test. Samsung A3, android 8, recording settings: 7/2/45. Walking 7 km. Filtering: MIDDLE.

I'm putting SCR. In most cases, the filter works correctly - see scr "right". Sometimes it filters out unwanted sections - see scr "not set". But this can be also caused by setting the point record to 7 m. If I set the 1/1/45 setting it would be better, but again the trail would have a lot of points recorded. In any case, it would be good to have this filter in the future also in the PRO version.

CZ: Druhý test. Samsung A3, android 8, nastavení záznamu: 7/2/45. Chůze 7 km. Filtrování: STŘEDNÍ.Příkládám SCR. Ve většine případů filtr pracuje správně - viz scr "spravne". Někdy odfiltruje i nežádoucí úseky - viz scr "nezadouci". To ale může být způsobeno i nastavením záznamu bodu na 7 m. Pokud bych dal nastavení 1/1/45 bylo by to jistě lepší, ale zase by trasa měla hodně zaznamenaných bodů. V každém případě by bylo dobré mít tento filtr v budoucnosti i ve verzi PRO.

Files:

URL

Menion ●

Hi Josef,

I just tested it yesterday with 1m/1s recording interval and have similar positive results. In case of GPS jumping while standing still, results are not ideal, but this have to be covered by some minimal distance, that prevents incorrect recording of this jumping GPS.

Perfect, thanks!

URL

Libor Poutnik Striz ●

I can confirm my Xiaomi with the Google location improvement turn off is fluctuating somewhat, i.e good for texting.

But still, light or medium filters are very good, the original and filtered paths are distinguishable and the filter behaviour is fine.

URL

Josef Žajdlík ●

Kolísání záznamu při použití filtrace.

I používat nastavení restartovat GPS po 10 minutách auto-off, pak se změní záznam a Kalmanův filtr opraví správně. Všiml jsem si však, že záznam trasy je pak v nadmořské výšce fluktuace. Pokud se filtr vypne, nejsou tam žádné výkyvy. Přikládám SCR a GPX.

CZ: Výkyvy v záznamu při použití filtrace. Používám nastavení auto-off k restartu GPS po 10 minutách, v těchto místech pak dojde k rozkolísání záznamu a Kalman filtr to správně zkoriguje. Všiml jsem si ale, že v záznamu trasy je pak v těchto místech výkyv v nadmořské výšce. Pokud filtraci vypnu tak tam výkyvy nejsou. Přikládám SCR a GPX.

Files:

URL

Menion ●

Hello Josef,

interesting mainly because this new filtering should have absolutely no effect on elevation (yet). I think it should be more a coincidence then result of filtering. It is most probably related to the known problem mentioned by Andrew with jumping altitude values right after GPS is turned on.

URL

Josef Žajdlík ●

Bylo by skvělé, kdyby to měl ještě někdo jiný možnost otestovat. Projevuje se to totiž pouze při pomalém pohybu - chůze. V sobotu jsem to zkoušel při jízdě na kole a záznam je v pořádku. Dnes ráno jsem u záznamu chůze změnil nastavení na 4/1/35 a filtraci na "slabý". Výsledek je ale opět špatný. Mimo výkyvu v nadmořské výšce dochází i k nárůstu rychlosti. Určitě to souvisí s restartem GPS pomocí Auto OFF protože je to vždy přesně po 10 minutách. Dá se tedy předpokládat, že se problém bude vyskytovat i při výpadku GPS třeba v lese, budově atp. Když ale vypnu filtraci tak je záznam v pořádku. Osobně mi to moc nevadí, jen chci abys o tom věděl protože po uvolnění verze PRO by se mohli ozvat další se stejným problémem. Z toho GPX souboru se nedá nic vyčíst? Omlouvám se za češtinu.

URL

Al Klecks ●

One comment from derived from a hike across the alps 2 years ago - yes, in serpentines, or tight corners the track was off and filtering could have improved the track. But what was completely off and I didn't even bother attempting to correct is the z-axis adjustment. This needs definitely some filtering. Sometimes I was wondering if a manual input of a known elevation would be advised. Anyway, what I am suggesting is to have the option to apply different filter settings to x/y coordinates compared to elevation filtering.

URL

Libor Poutnik Striz ●

If Menion implements full 3D Kalman filter, ( currently is 2D for positions), it may help a lot. such a filter would suppose you are moving an the 3D space linearly with supposed 3D velocity, with corrections from 3D inputs.

URL