Re: [gpsd-dev] Using multiple location sources to improve accuracy and reliability

[Thorsten Höger]

Hi,

a collegue wrote his thesis on this topic.
It was called Smart GPS.

He describes some mathematical models to merge GPS sources.

You can find it under this link but it is only available in German.
http://elib.uni-stuttgart.de/opus/volltexte/2009/4023/index.html

Regards,
Thorsten

Am 09.07.2012 16:17, schrieb Eric:
> Olivier Cornu <address@hidden>:
>> What did i expect? Put simply: more than basic multiplexing.
>> I expected to gain something from device redundancy: either improved
>> accuracy (reduced statistical error using several measures) or improved
>> reliability (if one device starts behaving incorrectly), or both. It seems
>> i get none.
> That is correct.  The design philosophy of GPSD is that is intended to
> pass through clean data identified by device.  The only postprocessing
> we do is to compute velocities and error bars from the skyview
> covariance matrix if the device doesn't report them.
>
> This is a "mechanism, not policy" design.  You want to add a policy 
> layer preferring a particular policy - merge and average.  Or maybe
> merge and average after deciding to ignore a device that is "behaving
> incorrectly". But what criterion are we to use to decide "incorrectly"?
> That's another kind of policy.
>
> There are several reasons not to go this route.  One is the very fact
> that GPSD is designed to be a device multiplexer for multiple
> applications - we can't know in advance that all applications using
> the daemon at any given time will want the same policy.
>
> Another is...if we add one policy, we'll immediately come under pressure
> to add policy switches to enable lots of others. The code would bloat,
> and there would be lots of new places for bugs to lurk.
>
> Here is what I think you should do.  Pick a scripting language with
> JSON support.  Write a proxy daemon that launches GPSD reporting to
> a private port, reads the JSON from that, does whatever averaging
> or other policy you want, and ships results to port 2947 as if it
> were GPSD.  
>
> I might be interested in carrying such a daemon in the distribution.