Future of location services on OM

[Al Johnson]

On Saturday 10 January 2009, Gergely Imreh wrote:
> Hi,
>
>   I was wondering if there's any plan, what kind of gps positioning /
> location discovery services the OM should have or will have?
>   Right now, as much as I see there are a number of ways: the 2008.x
> releases have gpsd, the FSO has gypsy, and Android - I don't know
> whether the GPS services work on that one yet.

FSO has a combination of ogpsd which provides a dbus interface using the gypsy 
protocol, and fso-gpsd which connects to ogpsd and provides a gpsd protocol 
interface. They also take care of power control and associated housekeeping, 
powering the gps only when there's a client requesting data for example.

>   The problem with this is that it's hard to develop for this variety
> of options that are not compatible.

The combination in FSO provides both of the linux gps interfaces, so any 
existing linux software using gps should be able to use it. Code written for 
android is unlikely to run outside android.

> The IMHO best would be a d-bus 
> interaction with the userspace software, because it will put the
> burden of interpreting the NMEA  (and possible other) messages on the
> LocationProvider, so the userspace software does not have to duplicate
> the functionality (less possible points of failure).

ogpsd does exactly this. On GTA02 it reads native binary UBX format data from 
the ublox gps chipset and interprets it to produce gypsy format data on dbus. 
I think it reads NMEA from gllin on GTA01 but I haven't looked into it as I 
don't have one. 

>   Now, gpsd says it has dbus interface, just one has to check the
> source code and it is not finalized. Is the gpsd included in the
> 2008.x compiled with the dbus option? Probably most people only use
> TangoGPS or Navit, which interprets the NMEA messages themselves, so
> they didn't see the need for any other interface option. Also, gpsd
> has been tested, and seems to be reasonably reliable.
>   Gypsy was working generally alright, and could use it, but sometimes
> it had weird behaviour - maybe just not what I'd expect but otherwise
> fine.

Are you thinking of gypsy or ogpsd? ogpsd has had some regressions in 
fso-testing during December, possibly due to problems loading stored 
ephemeris data for a faster fix when powering up the gps. 

>   Also, the last gpsd release was was 11 months ago, though there
> seems to be some SVN activity[1]. The last Gypsy release was about 10
> months ago, last Git activity ~8 months ago, so not sure how much is
> that one alive...
>
>   When checked Android, they have a few interesting features in the
> positioning area. I think they have their own GPS hardware interfacing
> and interpretation, which is then supplied to the userspace. Also,
> they have a number of different location providers, like the gps
> satellites, GSM cell information, Wifi hotspots.... [3]
>   Previously, a few of us tried to make a fast positioning app based
> on GSM cell info [4-5], but we had to map the cell tower positions
> ourselves (pretty imprecise) and do the position discovery algorithm
> (I think I borked that a bit, sometimes it was good, by chance, most
> of the time it was very off).  Andorid uses Google's on cell database,
> but I'll check it out, whether we too would be able to / allowed to
> use that info. Will try to learn from them, not to clone, but to make
> less mistakes.

FSO has just gained a GetNeighbouringCellInformation command which may be 
useful in this context.

>   I was thinking, what route you think would be more advantageous for OM?
>   Gpsd / gypsy / multi-provider Android-type / other? There might not
> be a single preferred way, and you might say that it's not the core
> teams responsibility. In any case, I'd be interested in your opinion.
> (I hope I'm not replicating a previous discussion either :)

For pure GPS data the current combination works well, barring implementation 
bugs. Extra location sources would be useful for times when gps isn't 
available. I think it would be reasonable to provide this as a dummy gps 
device under gypsy to provide an interface to current programs. Some protocol 
extensions could then be used to make the non-gps aspects available to 
programs that want to use them. There would be some interesting work in 
integrating multiple data sources - another possible one would be car speed 
from a CAN bus interface. Anyone have experience with kalman filters?

So far as the cell/ap database goes I suppose an OSM equivalent is needed, 
unless OSM would be interested in the data.

>   Cheers,
>       Greg
>
>
>
>
> [1] http://svn.berlios.de/viewcvs/gpsd/
> [2] git://anongit.freedesktop.org/git/gypsy
> [3]
> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;hb=HEA
>D ("location" folder)
> [4] http://projects.openmoko.org/projects/rocinante/
> [5] http://repo.or.cz/w/CellLocator.git
>
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel