Re: [gpsd-users] gpsd and shared memory

[Jon Schlueter]

Yes the shared memory segment is reasonable to read from but you probably want to add a bit of filtering and processing on top of the raw GPS data for best guess position, heading and trajectory.  GPS is know to drift and not be exact every measurement.  In a prior project we had a kalman filter on the GPS input along with IMU and if available wheel-mounted pulse transducer input to give a reasonable best guess location for the vehicle based on the information available.  If you don't want to go to that level then picking a value out of the stream is about as good as any other.  There are variations on this that can provide varying levels of accuracy for getting data out.  As a note the shared memory segment as well as the TCP Stream interface are designed to be read as input to a process that will filter and buffer/track the location info vs time.  If the GPS is running at 10 hz update, GPSD should be emitting them at the same frequency, there will be a little bit of delay but it should be less than the cycle.  What type of tolarance are you looking to get for matching up position with time/current vehicle position?

Jon

On Thu, Oct 1, 2015 at 1:38 AM, Roger Oberholtzer <address@hidden> wrote:

I have an application that currently parses NMEA strings it reads from a serial port. Amongst other things, it uses the locations discovered there to decide when a moving vehicle is as close as it is going to get to a pre-determined location. When it it determined that the vehicle is at the location (or as near as it will be based in the current trajectory), it initiates some activity. Our goal is to have this action be as close as possible to the location as it can be.

This application has been modified to obtain NMEA strings via the gpsd RAW stream (chrony and Navit are also clients of gpsd). This seems to be working as expected. But I am wondering...

Our application has a heart beat. Each meter of vehicle movement (from a wheel-mounted pulse transducer) it decides if it should initiate said activity. So the decision is really based on the last GPS idea of how far we are from the location, combined with meters of vehicle movement.

Would I be wasting my time to use the gpsd shared memory segment each meter to decide where the vehicle is? I have these concerns:

  -  When parsing a 10 Hz NMEA stream (i.e., GGA records at 10 Hz), what kind of delay might there be from when the NMEA record became available on the serial port and when information about location is updated in shared memory? Would there be an update pretty much at the frequency of the GGA records? I know that gpsd looks at a number of records when deciding some things.

 - Even though I could read the shared memory segment each meter, I guess I would need to know the UTC time that the location in memory applies to. Are the locations and UTC time so connected in memory? I am not totally certain I need to know this. But I would imagine if there is a location in memory, I need to know when that location applies to. It is not when I read it. OTOH, if the shared memory location is updated at the frequency of the GGA records, perhaps I don't need to worry about the time. Our current NMEA solution considers the last GGA record to be 'now'.

I often read that the JSON stream is the preferred one. In my application, using the JSON stream would not really get me much over the existing NMEA method that is working. I have been interested in the shared memory approach because the application would not need to parse the GPS data (NMEA or JSON).

Roger Oberholtzer

 

RST Systems

 

Office: +46 (0)10-615 6020

Mobile: +46 (0)70-815 1696

address@hidden

________________________________________

 

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se