kalman

[robertlipe]

• Add rudimentary Kalman filter. Work in progress. This is an over-simplified Kalman filter with hard-coded constants for process noise and measurement error. We could probably do better if we "knew" the input was from a logger that blindly recorded every N seconds or if we hedged measurement error based on gps_fix or nsats or some other lower level data. This is probably ineffective on better GPSes that do this before actually dropping trackpoints, so this is probably more helpful on a $4 ublox than a $700 Garmin.

[tsteven4]

I think a kalman filter is a nice addition. I think access to acceleration data would help, but we don't have it.

Unfortunately the kalman branch was created from the stringview branch. I think all the stringview stuff is already merged (#722, #723) Can you sync this up so I can see what is different in the kalman branch compared to master?

// sync up your master branch
git checkout master
git remote add upstream https://github.com/gpsbabel/gpsbabel.git
git fetch upstream master
git merge upstream/master
// sync your kalman branch to the updated master branch
git checkout kalman
git merge master
// accept all the upstream files with conflicts. I don't think your kalman filter work has anything to do with these files:
git checkout --theirs defs.h garmin_tables.cc gpx.cc gpx.h lowranceusr.h osm.cc pcx.cc pocketfms_fp.cc tef_xml.cc util.cc xmlgeneric.cc
git add defs.h garmin_tables.cc gpx.cc gpx.h lowranceusr.h osm.cc pcx.cc pocketfms_fp.cc tef_xml.cc util.cc xmlgeneric.cc

git commit
git push

I tried the above (without the push) on a copy of the PR, which leads me to believe all that is left is, which seems plausible:
git diff --name-only master
GPSBabel.pro
filter_vecs.h
kalmanfilter.cc
kalmanfilter.h

[tsteven4]

I think this need nvector in front of it, and the expansion to 3 variables instead of 2 (lat, lon). I expect it will fail miserably around discontinuities (the date line) and singularities (the poles) that the lat,lon representation suffer from. I have nvector implemented and tested somewhere, replacing most of the traditional formulas we have implemented.

[GPSBabelDeveloper]

Probably. I used the simplest Kalman implementation I could find on github (there was another that used four terms, adding one for accuracy or confidence or something that would have fit into our 'fix' member and another for time, allowing better interpolation. Then again, if we solved the problem everywhere except the semisphere boundaries, that would still be a good result. The two magic constants in this implementation, process_noise_err and measurement_err are magic to me (I'll readily admit this is over my head, especially now) and just offered two knobs to twist that wildly changed the shape of my test past without obvious reason to me. Bringing them out as command line options just seems like a license for support issues, but we've kind of wanted a Kalmna filter for a long time and this just adds a convenient skeleton to hang things on. Github had a number of implementations in C, Java, Matlab, and other languages where the math was pretty literal to translate and with compatible licenses. I'm not married to this one. It's also duly noted that while we used to get a few requests a month for this (usually indirectly and not by name) we haven't actually had anyone ask for this in years at this point, so it may be just wasted noise that should be put behind a gate somewhere, if merged to trunk at all. I don't know if this is because noise rejection and filtering in the receivers/loggers these days is just better (it unquestionably is) or if people just aren't using us for that kind of powerhouse manipulation like they once did. (Has the likes of ArcGIS, GRASS, QGIS and other 'real' GIS tools filled this spot, making our attempts to do so unnecessary? Dunno.)

…

On Thu, Nov 4, 2021 at 10:31 PM tsteven4 ***@***.***> wrote: I think this need nvector <https://www.navlab.net/nvector/#nvector> in front of it, and the expansion to 3 variables instead of 2 (lat, lon). I expect it will fail miserably around discontinuities (the date line) and singularities (the poles) that the lat,lon representation suffer from. I have nvector implemented and tested somewhere, replacing most of the traditional formulas we have implemented. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#742 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3VADY3XLLZ5IVXTPH4LWDUKNMZVANCNFSM5GR6RTZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.