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<[email protected]> 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 _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
