Introducing the Freerunner Navigation Board
Dr. H. Nikolaus Schaller
hns at goldelico.com
Wed Jul 21 11:22:20 CEST 2010
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  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  by VDE Germany (sort of a local IEEE) for such a project.
: (in German) http://www.br-online.de/studio-franken/aktuelles-aus-franken/jugend-forscht-robert-schaller-sonderpreis-vde-ID1273673737606.xml?_requestid=146846
More information about the community