gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary E. Miller
Subject: Re: Use gpsd and ublox-ros driver at the same time
Date: Fri, 16 Sep 2022 10:26:36 -0700

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.

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

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

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

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

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

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.

The next big problem is that code wants to control the (badly!) the
system clock.

The next big problem is they barely decode any of the u-blox data.

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?

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

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.

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

Attachment: pgpu2cGKA2Zcq.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]