[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
pgpu2cGKA2Zcq.pgp
Description: OpenPGP digital signature