Re: [gpsd-users] gpsd and shared memory

[Roger Oberholtzer]

---

From: Jon Schlueter address@hidden

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

We use high-end receivers like the Applanix Pos/LV or the OxTS RT series. All these have an IMU (typically a 3-D gyroscope, inclinometer(s) and a wheel pulse transducer) and employ a Kahlman filter.  The GPS is the weakest data point in these systems. Some systems have multiple antennas as well. The OxTS units have a stated latency of a millisecond or so (I would have to check the docs again) from when the NMEA fix arrives into the OxTS and when a modified NMEA record from the Kahlman filter is emitted over the serial port. These units also provide a PPS, which we use. We use these rather precise locations in post-processing to locate data. The use I was referring to in my question was for an additional use of the data during collection.

I think my only question now is how one would best determine if the shared memory changes while being read (since so many values cannot be written in an atomic fashion). A typical method is to read a value, and if it changes, read again. When there are multiple items to read, the value that is known to be written last can be used for this purpose. Is these any such 'this is always the value that gets written last' logic in the shared memory?

I realize that the D-Bus method would perhaps serialize this data. But I am trying to move the logic here so that I only explore the GPS data each meter. I would imagine that the D-Bus data arrives once for each NMEA record? In that case, I would not perhaps gain so very much from using the shared memory.

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