Investigate improving Kalman filter response

[davecraig]

The KalmanFilter which filters our incoming location data uses the same code and sigma values as the iOS app (sigma = 3.0). When I'm using the app, the callouts always feels slightly laggy e.g. announcing "intersection 25m ahead" but in fact it's perhaps only 15m ahead. I do walk fairly fast, but it's worth spending a little time looking at the underlying data to try and see what the delay is. There's also a delay in the calculation and rendering (speaking) of the callouts, but that's a seperate issue to look at.

As an initial piece of work towards this, I've got some code which saves to a file the raw Location data straight out of the LocationProvider. This can then be read back in and analyzed in a unit test. On a very simple walk down a street, the accuracy reported for the Location was in the range 5m to 18m. With the Kalman filter sigma set to 3.0, the largest distance from the filtered location to the location was 11.21m at which point the accuracy was 15.5m and the speed was 1.46m/s. That distance is often 'behind' the travel, though as can be seen from this plot, it's sometimes off to the side. Each line in this plot connects the location from the LocationProvider with the filtered location calculated from it. I was walking in up one side of the street and back down the other with my phone in my pocket.

Increasing sigma from 3.0 to 6.0 halves the lag to 5.61m (~4 seconds at 1.46m/s):

Of course the location inaccuracy is less strongly filtered - this image shows both filtered traces, the smoother being with sigma 3.0:

On this very simple case it looks like we could bump up the sigma value and the lag would be much improved without too much impact on accuracy. Large inaccuracies in Location are still filtered much more strongly even with a higher sigma, but obviously more testing is required.

Another approach according to Wikipedia would be to look at using the Extended Kalman Filter which apparently is the de facto standard for location filtering. We should take a look around other open source projects to see what they use.

[davecraig]

I reduced the amount of filtering by changing the sigma to 9.0. The lag is much less which is good. The downside is that getNearestRoad() is more likely to pick the wrong road which results in intersection descriptions being given from the wrong road. Perhaps part of the road stickiness issue (#318) would be to use a more filtered version of location for the getNearestRoad() call than for normal location usage? Although that would be lagging further behind (when accuracy was low), that would be to our advantage as it would be closer to the road that we come in on. The callout could still happen earlier (as it wouldn't be using the less filtered value) and the distance measurement would also use the less filtered value.