Introducing the Freerunner Navigation Board

[Dr. H. Nikolaus Schaller]

Am 21.07.2010 um 10:55 schrieb Helge Hafting:

> On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote:
>> On 3 May 2010 11:04, Dr. H. Nikolaus Schaller<hns at goldelico.com>  wrote:
>>>> Having navigation work inside tunnels
>>>> would allow mapping them accurately for openstreetmap. And also have
>>>> underground navigation - some tunnels have got
>>>> intersections/roundabouts inside, with several possible exits.
>> 
>> Would navit, tangogps, etc. need a new interface to access the
>> sensors, or could the existing libraries be adapted to "correct" the
>> GPS data with additional information from the extra sensors before
>> handing it on to the GUI?
> 
> The natural place for such software seems to be in gpsd itself - it 
> already supports having several gps (position) devices. (Or possibly in 
> a front-end to gpsd - depends on what the gpsd developer wants.) But too 
> many processes / software layers is not good - it causes delays.

Well, for 1 position per second delays it may be neglectable, but you are right - having everything in one "middle-man" daemon (gpsd) appears to be the best architecture for me. So it hides the complexity from the user-applications, and should be easily expandable.

As far as I know, the kernel driver for the BMP085 barometric altimeter is already in some upstream kernel release candidate. So altitude information can be mixed between GPS and altimeter as well.

> navit, tangogps etc. should of course not need reprogramming, you can't 
> fix every program out there. Especially not the proprietary ones.
> 
> The software should simply pass through gps data as long as it arrives, 
> and the precision is sufficient. This data can be used for continous 
> calibration of the magnetic/inertial/odometer inputs.

I would even suggest to use a Kalman-Bucy filter [1] for sensor integration so that it does not switch between two modes but does a soft transition. As far as I understand, a Kalman filter can also "learn" about (linear) errors, offsets and drift of sensors while multiple sensor data is available.

It is definitively possible to write such a Kalman filter for a smartphone since a student has recently been awarded [2] by VDE Germany (sort of a local IEEE) for such a project.

Nikolaus

[1]: http://en.wikipedia.org/wiki/Kalman_filter
[2]: (in German) http://www.br-online.de/studio-franken/aktuelles-aus-franken/jugend-forscht-robert-schaller-sonderpreis-vde-ID1273673737606.xml?_requestid=146846