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, 23 Sep 2022 15:25:29 -0700

Yo Marco!

On Fri, 23 Sep 2022 13:24:08 +0100
Marco Camurri <marco.camurri@outlook.com> wrote:

> >  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".  
> I meant having both functionalities into a single program, like a 
> modified gpsd.

The "UNIX Way" is many small programs, each that does one thing well.

> >>>> 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.  
> I might be missing a point here, possibly related

I suggest your leave PTP to the last, after you get NTP (Chriny or NTPSec)
working, after you get ROS working.

> >> 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?  
> 
> ROS is a collection of libraries with standardized inter-process 
> communication and message generation mechanism.
> 
> Integrating ROS functionalities into gpsd would make it dependent on 
> many libraries, as it is not as lightweight as LCM is, for example.

Then using ROS libs would not be a good fit for gpsd.

> >> 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.  
> yes I agree, I just meant that the code for the driver itself is
> shorter than gpsd's is.

I keep getting lost o nwhat you mean by "driver".  Too many unique
"drivers" in your use case.

Of you mean the u-blox "driver", then you can't make it smaller than gpsd's.


> >>> 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.  
> 
> This is actually fine because we are not really using the portion of
> the driver that configures the receiver. We just take data from it.

You don't get good data from gpsd unless gpsd or ubxtool configures
the receiver.

> The configuration is done from the official ublox program on windows 
> beforehand and stored permanently.

Bad idea.  Unless you really know how the gpsd u-blox driver works
it is hard to configure it properly.  In any case, bext to use
ubxtool for configuration.


> >> 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.  
> Same as above, all settings are not done via the driver in practice.

Well, they are done somewhere.  Your client expects rarely used messages.

> >  
> >>> 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?  
> 
> This is the program I meant:
> 
> https://github.com/HKUST-Aerial-Robotics/ublox_driver/blob/main/src/sync_system_time.cpp

I get: "Content not available!"

> it's a standalone program, not part of the driver. If I run it, it 
> breaks my PTP.

Yeah, big time.

> Did you see any other places where the system clock is touched?

I can't see anything: "Content not available!"

> >>>> 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?  
> 
> This way it is possible to tightly fuse the raw data from the GNSS
> with other sensor data (IMU, camera, etc.), instead of treating the
> ublox as a black box.

I still think you are overcompliating the problem.  IFF you have time
stamps it is easy to fuse.  If you don't, there is no way.

> If you are interested, you can have a look at this video from the
> same developers of the driver, which explains the concept:
> 
> https://www.youtube.com/watch?v=TebAal1ARnk&ab_channel=HKUSTAerialRoboticsGroup

Decent results, but they overcomplicated some things....

> >> 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".  
> I understand now, thanks.

I updated that FAQ entry.  Look at "gpssubframe".

> >  
> >>> 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.
> >  
> The link above refers to the actual definition of the ROS message.
> 
> The message is automatically converted into a data structure via a
> code generator (e.g. a C++ class) and serialized for data
> transmission over TCP in a publisher-subscriber fashion.

Which shows you still misunderstand my question.  What is the TCP look
like?

> A ROS-compatible program can subscribe to a topic where the message
> is published to, receive the message via a callback and process it.
> More info here: http://wiki.ros.org/msg

"ROS uses a simplified messages description language for describing the
data values (aka messages) that ROS nodes publish. This description
makes it easy for ROS tools to automatically generate source code for
the message type in several target languages."

Their definition of "easy" is in no way similar to mine.  I thought
XML mercifully died out years ago.

> Similar libraries that do that are LCM <https://lcm-proj.github.io/>
> or protobuf <https://developers.google.com/protocol-buffers/>.

Unless they are what you are using, they are a distraction of this
discussion.

> So to modify gpsd to send the ROS messages, I'd need to access all
> the data I've listed below from inside gpsd, then stick them into the
> ROS data structure and call the "publish" method from the ROS
> libraries.

I suggest you not touch gpsd, bloating it with anything XML related
would be a mistake.  If you look in the clineets/ directory, you will see
many gpsd clients that take gpsd JSON protocol, and change it to ofer
formats (UDP, CSV, GPX, etc.)  You could start with a simple one, like
example1.c, and the change its printf() output to whatever you want.


> >> - Doppler standard deviation [Hz]  
> > No receiver provides that.  
> 
> I'm confused:

Unavoidable when discussing gpsd.

> the ROS driver provides all this data already, so the 
> receiver must be transmitting them over serial.

Sometimes yes, sometimes no.  Or in the case of the Standard Deviations,
never.


> I'm already using the driver and it works,

We'll have to disagree on the definition of "works".

> it is simply out of sync
> with the host computer.

In what way?  If all you want it time sync, then get NTPSec or chrony
running.


> > 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.  
> The code above already works for the u-blox ZED-F9P receiver and this
> is the only one we are interested in using.

Today.  I am on many mailing lists where people are despirately trying
to get 20 year old GPS to work.  Much better to be generic, and then
you are future proof.


> >> 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.  
> I'm not sure I understand what u-blox 8 scaling is, but I'm fine to 
> handle the ZED-F9P only atm.

Change "u-blox 8 scaling" to "u-blox scaling".  Many of the number that
ubx protocol gives you are "scaled".  That is, you need to multiply them
by a constant to get SI units (s, m, m/s, etc.).

For example, u-blox tow (Time of Week) may be in seconds, or you may need
to multiply by 6, or divide by 1000, to get seconds.  I saw no such
scaling in that code.

> >> 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.  
> For the reason explained above, low level raw data fusion with other 
> sensors.

As I mentioned before, using RTKLIB is silly.  Pointless "fusion".

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


reply via email to

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