Introducing the Freerunner Navigation Board

[Al Johnson]

On Wednesday 21 July 2010, Dr. H. Nikolaus Schaller wrote:
> 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.

It looks like gpsd has support for magnetometer, accelerometer and gyro 
readings in its ATT (vehicle-attitude) object. The object also contains device 
name, so each sensor should appear as a different device. Now we need a gpsd 
driver for each device.

http://gpsd.berlios.de/gpsd.html

> 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.

This would come under gpsd's TPV object as altitude and/or climb rate I guess, 
unless they can be persuaded to add pressure to the object. I don't know what 
the best way to deal with altitude offset due to weather would be.

> > 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.

That's what the ground vehicle strapdown systems I was looking at several 
years ago did. They took GPS, a pulse input for vehicle speed and a compass, 
used a Kalman filter to estimate position, heading and velocity, and gave a 
single NMEA output.

It's probably worth a look at the IMU work from the guys doing DIY UAVs. 
They're combining gps, magnetometer, accel and gyro signals on small 
processors. 

http://diydrones.com/forum/topics/has-anybody-achieved-a

AFAIK there's nothing in gpsd for combining signals like this. It may be 
possible to make gpsd driver for a virtual device that takes input from other 
gpsd devices and combines them. Another option is to do the combination in 
something implementing the geoclue API, but that doesn't include orientation 
yet.

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