Re: Use gpsd and ublox-ros driver at the same time

[Marco Camurri]

On 16/09/2022 18:26, Gary E. Miller wrote:
> Yo Marco!
>
> On Fri, 16 Sep 2022 11:37:55 +0100
> Marco Camurri <marco.camurri@outlook.com> wrote:
>
> > I have a robotic application where I need to sync my u-blox ZED-F9P
> > receiver with other sensors (cameras, lidars, etc.) on a host
> > computer.
> Easier said than done.
yeah, I know :(
> > At present, I'm using PPT to sync the devices to the computer's
> > clock. The computer is not synced with anything else.
> What is PPT?  Computer clocks are not known for stability.
>
> > Now I want the computer clock to be synced with the GNSS receiver and
> > leave the other devices to be synced to the computer's clock via PTP.
> Oh, you meant PTP.
Sorry, typo.
> > The main idea would be that gpsd provides updates to chrony, which in
> > turn provides updates to linuxptp4l.
> https://gpsd.io has many hoowto's on how to sync you system to GNSS.
> Getting linuxptp4l to work is out of scope here.
Yes my focus is on the access to the receiver's data from both gpsd and 
the driver or from one program that provides both functionalities.
> > Following the instructions I could find here
> > <http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php> for
> > another receiver, it should be possible to connect the PPS and NMEA
> > wires to the serial port of the computer, then set up gpsd to use
> > them, then configure chrony to be updated by gpsd,
> Or use our howtos, like this one:
>
> https://gpsd.io/gpsd-time-service-howto.html
>
> We cant help you with other peoples instructions, and certainly would not
> recommend a Garmin receiver.
Yes that was just one example I found.
> > and finally
> > configure PTP to use chrony as source.
> What you do is sync PTP to your system clock, and leave chrony out of it.
if there's a plug and play way to do this I'm happy to leave chrony out. 
I just found this pipeline online.
> > The communication between these three programs would be via shared
> > memory, if I understand correctly.
> Yes, taht is one way to do it.
>
> > The problem is that I also need to access the raw date from the
> > receiver and publish them over ROS, using this driver:
> > https://github.com/HKUST-Aerial-Robotics/ublox_driver
> Can't really help you with that.  Only one program con control the
> u-blox.  You have to choose, or get that program to accept data from
> gpsd.  After a quick look at that code, I'd avaoid it.
>
>
> > Because there can't be two programs accessing the same serial port, I
> > can't run gpsd and the ublox driver at the same time, so I'm looking
> > for a minimally invasive solution (i.e. with smallest code
> > development possible) to let the ROS driver process the data from the
> > receiver while it is being used by gpsd.
> gpsd can pass on the raw data from u-blox, but changing that program to
> handle it, will be a lot of work.

More work than editing gpsd to send data over ROS? I didn't want to 
"pollute" the gpsd which I'm more unfamiliar with than the ROS driver.

I know the ROS driver is not perfect, but it is small and I need to get 
that data via the ROS interface for compatibility with other programs.

> Easy to see the raw data when gpsd is running: "gpspipe -R"
>
> The next bigger problem is that both gpsd and that thing want to
> reprogram the u-blox.  That's not gonna work.
Yes but this might be solved by finding the right combination of 
arguments for gpsd to replicate the settings that the ROS driver will 
want to put. Basically the only setting we might want to actually change 
is the output frequency.
> The next big problem is that code wants to control the (badly!) the
> system clock.
That's a optional standalone program which we will not run.
> The next big problem is they barely decode any of the u-blox data.
But that's the only data we actually need.
> The next big problem...
>
> > I know from the FAQ that gpsd does not provide a way to extract raw
> > data directly, but I saw a low level API is provided.
> Then the FAQ is out of date.  Which types of "raw" data?  Where did you
> see that?

So by raw data I mean: pseudoranges, carrier phase observation, doppler 
measurements, and ephemeridis.

I read the pseudoranges are not available from this FAQ page: 
https://gpsd.gitlab.io/gpsd/faq.html#almanac

> > Is that at least possible to use such API to interface with gpsd to
> > extract the binary blob which the ublox ROS driver would normally get
> > from serial directly?
> Evertyhing from u-blox is a binary blob.  Easy to get the "super raw",
> As above: "gpspipe -R".  Or set a WATCH for it.
Thank you, I will try that.
> But that program does not look it it handles much raw at all.
>
> > If so, I could modify the driver to get the data
> > from gpsd instead of the serial port.
> Possible, but good luck with that.  You are opening a big can of worms.
>
> > Is there a better strategy than the one I've described?
> If you can figure out what the "ROS messages" are, it migh be easier to
> patch gpsd to send those.

So the data we need to extract from the receiver is a vector of 
observations. Each one of them is defined here:

https://github.com/HKUST-Aerial-Robotics/gnss_comm/blob/main/msg/GnssObsMsg.msg

Each observation includes:
- measurement time,
- satellite ID,
- observed frequencies,
- carrier-to-noise density ratio (signal strength) [dB-Hz],
- lost-lock indicator (1=lost),
- channel code,
- pseudorange measurement [m],
- pseudorange standard deviation [m],
- carrier phase measurement [cycle],
- carrier phase standard deviation [cycle],
- Doppler measurement [Hz],
- Doppler standard deviation [Hz]

the data captured from serial is converted from binary into a cpp data 
structure here:

https://github.com/HKUST-Aerial-Robotics/ublox_driver/blob/64f39fa54a4405f0bcf90387002ca12e95627a21/src/ublox_message_processor.cpp#L50-L135

and in particular the raw GNSS data structure is filled in here:

https://github.com/HKUST-Aerial-Robotics/ublox_driver/blob/64f39fa54a4405f0bcf90387002ca12e95627a21/src/ublox_message_processor.cpp#L284-L380

the data structure is then converted into a ROS data structure (aka a 
ROS message) here:

https://github.com/HKUST-Aerial-Robotics/gnss_comm/blob/a2035fec1cc427bba184d25ff1fde8dcf23c9ce1/src/gnss_ros.cpp#L169-L195

My initial idea was to call these functions on binary data provided from 
gpsd instead of serial directly, as it looked like the less invasive way 
to do it.

But, if the same data is already decoded by gpsd I'm fine to do the 
opposite (i.e. call the above functions from within a custom version of 
gpsd).

If I could get just a pointer or a hint on where these conversion 
operations are carried out from inside gpsd for the ublox that would be 
really helpful.

> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>         gem@rellim.com  Tel:+1 541 382 8588
>
>             Veritas liberabit vos. -- Quid est veritas?
>      "If you can't measure it, you can't improve it." - Lord Kelvin