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

[Gary E. Miller]

Yo Marco!

On Tue, 20 Sep 2022 14:50:03 +0100
Marco Camurri <marco.camurri@outlook.com> wrote:

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

From what I can tell gpsd and "the driver" are both trying to do the
same thing, in different ways.  I do not know any programs that
speak ROS, so I have no ideas on "one program".


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

Was that one not sufficient?  There are many others.

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

Your "driver" will fight all other solutions.

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

Since no one here knows anything of ROS, we'd stick with known working
solutions.

> I didn't want to 
> "pollute" the gpsd which I'm more unfamiliar with than the ROS driver.

gpsd is already polluted with many things.  What would an ROS driver
need to do?

> I know the ROS driver is not perfect, but it is small

Which in gps-land means a lot of special cases are ignored.  And it
is not "small" when it pulls in a lot of old libraries.

> and I need to
> get that data via the ROS interface for compatibility with other
> programs.

Out of our area of knowledge.

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

gpsd by design avoid options.  Don't bother looking for knobs that do
anything useful for you.

> Basically the only setting we might want to actually
> change is the output frequency.

My brief look at the "driver" code makes me think otherwise.

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

Not what I think I saw, can you point me to info on that?

> > The next big problem is they barely decode any of the u-blox data.  
> But that's the only data we actually need.

Not what I thought I saw.  But this is not the place for me to critque that
code.

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

Why duplicate what the u-blox already does internally?

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

You misread that:

"Sorry, there's no easy way to do these things through GPSD yet."

Key words: "easy way".  What the "driver" does is the "hard way".

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

You misunderstood my question.  I asked about the "RDS messages", you replied
with what you want from the receiver.  ROS != receiver.

> Each observation includes:
> - measurement time,
> - satellite ID,
> - observed frequencies,
> - carrier-to-noise density ratio (signal strength) [dB-Hz],
> - lost-lock indicator (1=lost),

In practice, you can't count on this one.

> - channel code,
> - pseudorange measurement [m],
> - pseudorange standard deviation [m],

No receiver provides that.

> - carrier phase measurement [cycle],
> - carrier phase standard deviation [cycle],

No receiver provides that.

> - Doppler measurement [Hz],

Never needed.

> - Doppler standard deviation [Hz]

No receiver provides that.

> 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

That code will only work on a u-blox 8.  Not a 7, not a 9.  So, the
bitrot is already begun.  Fix it, or ditch it.

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

gpsd will decode those same messages and provide you the data as JSON.
But it looks like the data is used at u-blox 8 scaling, which makes it
non-portable.

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

Your call, I'm not touching that.  All that work, just to duplicate
what the u-blox 8 already does inside.

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

No need, just look at "man gpsd_json" for the decoded data that gpsd
will give you.  Look in drivers/driver_ubx.c for how gpsd decoded
u-blox messages.

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

pgpPUYfZ6ROIE.pgp
Description: OpenPGP digital signature