search

swift-nav / piksi_firmware

Firmware for the Piksi GNSS receiver.
swift-nav.com
GNU General Public License v3.0
109 stars 111 forks source link

Low pass filter in calculation of base station could hurt rover's estimate of base position #478

Open denniszollo opened 9 years ago

denniszollo commented 9 years ago

If a rover receives bad observations from the base station that leads to a PVT outlier in the base station position, this moving window filter could really hurt the internal estimate of base station position:

https://github.com/swift-nav/piksi_firmware/blob/master/src/base_obs.c#L144

Let's say that our first calculation of the base station's position is incorrect by a few kilometers. It will remain largely incorrect for a very very long time. I think we would be well served to tone down the time constant on this filter. I'd say we would want to reach 75% of a step change on the calculated base station position within 30 seconds (or 300 typical samples). That would make the filter value be about .0075. value of .00075 image value of .0005 image

denniszollo commented 9 years ago

@imh @fnoble

henryhallam commented 9 years ago

Might not be an issue with integrity checking? Or, sounds like a good case for a separate "survey mode" (which could be a function of the console SW) rather than continuously averaging. Or if you don't want that from a UX POV, then moving-average rather than IIR. I can't think of any good reason to use IIR here other than being cheap about memory usage (if that's really an issue, then offload to the host)

denniszollo commented 9 years ago

we have a survey mode already which doesn't use the filter. If the unit receives a base station position it doesn't use this code.

I don't really care about the exact implementation of the filter, I just don't want it to be so slow that it could never let the unit recover. can we afford a 200 point moving average or something simliar?