The frame_id is currently not set but is required for use with e.g. robot_localization. So please allow to set the frame_id by parameter or just default to "gps".

There's about one year of changes that haven't been tagged and pushed to the buildfarm. Can we get a ROS1 release that includes those changes?

when I catkin_make this package, it said cannot find libgps, so how to deal with it?

It would be nice if this were a lifecycle node to make the behavior more predictable and controllable.

#78 fixed compatibility issues between this software and new versions of GPSD. We need to make the equivalent change in the ros2-devel branch.

When I use utm_odometry_node, it tells 0.823 that I moved,but actually I moved about 9 meters.So,what's the scale between UTM odom and real distance?

Hi,

When attempting to compile gpsd_client (via the gentoo package, https://github.com/ros/ros-overlay/issues/279), I get an undefined isnan() in client.cpp. The fix is to:

# include <cmath>

Cheers,

Fred

I see <license>BSD</license> in the package.xml files, but the BSD license has many variants. Can you provide a clear license and copyright for the project?

The code link to the tutorial: Writing Subscriber for gpsd_client is broken as seen below:

Please update links.

I tried to run gpsd_client inside a component via the component manager.
Sincce the component does not have launch file nor does it have main.. it needs to be started like this:

First in terminal 1 start:

$ ros2 run rclcpp_components component_container

so we run component container. Then in terminal 2 run:

$ ros2 component load /ComponentManager gpsd_client gpsd_client::GPSDClientComponent
$ ros2 component load /ComponentManager gps_tools gps_tools::UtmOdometryToNavSatFixComponent
``
When I ran the gpsd , we were unable to get any echo from the /fix topic

with file: gpsd_client/src/client.cpp: I get compile errorss:

gpsd_client/src/client.cpp:88:11: error: no match for ‘operator!’ (operand type is ‘timespec_t’ {aka ‘timespec’})
   88 |       if (!p->online)
      |           ^~~~~~~~~~
gpsd_client/src/client.cpp:88:11: note: candidate: ‘operator!(bool)’ <built-in>
gpsd_client/src/client.cpp:88:11: note:   no known conversion for argument 1 from ‘timespec_t’ {aka ‘timespec’} to ‘bool’
gpsd_client/src/client.cpp: In member function ‘void GPSDClient::process_data_gps(gps_data_t*)’:
gpsd_client/src/client.cpp:156:27: error: cannot convert ‘timespec_t’ {aka ‘timespec’} to ‘gps_common::GPSFix_<std::allocator<void> >::_time_type’ {aka ‘double’} in assignment
  156 |         fix.time = p->fix.time;
      |                    ~~~~~~~^~~~
      |                           |
      |                           timespec_t {aka timespec}
gpsd_client/src/client.cpp:178:22: error: ‘struct gps_data_t’ has no member named ‘epe’
  178 |         fix.err = p->epe;
      |                      ^~~
gpsd_client/src/client.cpp: In member function ‘void GPSDClient::process_data_navsat(gps_data_t*)’:
gpsd_client/src/client.cpp:200:50: error: no matching function for call to ‘isnan(timespec_t&)’
  200 |       if (use_gps_time && !std::isnan(p->fix.time))

last version where it is buildable is 3.18
but with 3.20 got errors related to changes in gpsd
for example:
as mentioned here https://fossies.org/linux/gpsd/gps.h
gps_data_t has changed and has no more a member epe

This one is hopefully easy to solve: How can one launch gpsd_client? We are on foxy @ Ubuntu 20.04. What I did:

• Install gps_umd and gpsd_client via rosdep
• ros2 run gpsd_client gpsd_client -> No executable found
• ros2 launch our.launch.yaml (see below) -> long stack trace and eventually: launch.substitutions.substitution_failure.SubstitutionFailure: package 'gpsd_client' found at '/opt/ros/foxy', but libexec directory '/opt/ros/foxy/lib/gpsd_client' does not exist

Am I missing something abvious? The readme does not mention the node name so maybe that's just what is wrong.

The file our.launch.yaml is very short:

launch:
  - node:
      pkg: gpsd_client
      exec: gpsd_client
      name: gpsd_client_node

I am having exactly the same issue as shown here, which this repository was forked from (I am using this repo only).

The problem is that the gps /fix topic messages are duplicated and they mess with the timestamps on the working system (does not come to 1Hz).

Here's what the fix data looks like (The time at which the message is received by the system is given by 'TIME-----------------', the header time is different from this):

/fix
TIME-----------------: 1519982239 . 626596119
header: 
  seq: 59
  stamp: 
    secs: 1519982229
    nsecs:         0
  frame_id: "gps"
status: 
  status: 0
  service: 1
latitude: 13.123290517
longitude: 77.917043073
altitude: 895.262
position_covariance: [43.209, 0.0, 0.0, 0.0, 27.453, 0.0, 0.0, 0.0, 88.439]
position_covariance_type: 2


/fix
TIME-----------------: 1519982240 . 627275740
header: 
  seq: 60
  stamp: 
    secs: 1519982230
    nsecs:         0
  frame_id: "gps"
status: 
  status: 0
  service: 1
latitude: 13.123289658
longitude: 77.917025039
altitude: 895.669
position_covariance: [43.209, 0.0, 0.0, 0.0, 27.453, 0.0, 0.0, 0.0, 88.439]
position_covariance_type: 2


/fix
TIME-----------------: 1519982241 . 963729516
header: 
  seq: 61
  stamp: 
    secs: 1519982230
    nsecs:         0
  frame_id: "gps"
status: 
  status: 0
  service: 1
latitude: 13.123289658
longitude: 77.917025039
altitude: 895.669
position_covariance: [43.209, 0.0, 0.0, 0.0, 27.453, 0.0, 0.0, 0.0, 88.439]
position_covariance_type: 2


/fix
TIME-----------------: 1519982242 . 75940615
header: 
  seq: 62
  stamp: 
    secs: 1519982231
    nsecs:         0
  frame_id: "gps"
status: 
  status: 0
  service: 1
latitude: 13.123291235
longitude: 77.917014092
altitude: 894.921
position_covariance: [43.209, 0.0, 0.0, 0.0, 27.453, 0.0, 0.0, 0.0, 88.439]
position_covariance_type: 2


/fix
TIME-----------------: 1519982242 . 625682541
header: 
  seq: 63
  stamp: 
    secs: 1519982232
    nsecs:         0
  frame_id: "gps"
status: 
  status: 0
  service: 1
latitude: 13.123290376
longitude: 77.916996058
altitude: 895.329
position_covariance: [43.209, 0.0, 0.0, 0.0, 27.453, 0.0, 0.0, 0.0, 88.439]
position_covariance_type: 2

Have a look at the messages with seq 60 and 61, they have exactly the same data, and yet 2 messages are generated. It would not be a problem if the ros time stamp would be the same in the duplicate message, however it is and it affects the synchronization of the gps data properly.

Please note that the time stamps I have generated here are the same as the header time stamps in the /extended_fix topic. I've just displayed this time stamp using the python rosbag api on the /fix topic.

Thanks

I am ROS Humble and have installed gps_umd using apt install. I ran the command

ros2 component standalone gpsd_client gpsd_client::GPSDClientComponent -p use_gps_time:=false -p check_fix_by_variance:=false -p frame_id:="gps" -p publish_rate:=5 -p host:="127.0.0.1" -p port:=2947 on terminal 1 and on another terminal I ran gpsmon. Please see the result in the attached video. The gpsd_client version shows no change in lat/long values whereas the other shows some changes in the 4th or 5th decimal point (as I was not moving much).
I tried check_fix_by_variance:=true as well but the same. Is this expected?
ros_vs_gpsmon.webm

I found #31 issue related to opensource license.
Is there any update for it?

Why the rotation covariance is set to 99999?

This package is currently failing to build on Rolling: https://build.ros2.org/view/Rbin_uN64/job/Rbin_uN64__gpsd_client__ubuntu_noble_amd64__binary/ .

However, trying to build it locally succeeds, so I suspect we just need a new release into Rolling of 2.0.3. Thanks in advance!

Currently the gpsd_client package doesn't compile on Ubuntu 16.04 due to API changes in libgps-dev. Should be an easy matter to fix it.

timer_ = create_wall_timer(1s, std::bind(&GPSDClientComponent::step, this));

Creates a 1 second polling timer. This polling period should be configurable.

The GPSFix message has the fields pitch, roll, dip and corresponding uncertainty fields (err_pitch, etc.).

These fields do not appear populated anywhere by the code in this repository.

These are non-standard names for what I think are supposed to be Euler angles (pitch, roll, yaw). This is especially confusing since "dip" is almost a synonym for "pitch" or maybe "roll".

This is called out in at least one other place.

Can this be documented and these fields be renamed or removed in a future version of ROS?

Hi,
I am using:
ubuntu 18.04
ros melodic 1.14.10

I download to my catkin_ws folder your github, i catkin_make, but compilation doesnt work.
It fails when looking for gps_common/GPSFix.h. I attach the fail:

catkin_ws/src/gps_umd/gpsd_client/src/client.cpp:2:10: fatal error: gps_common/GPSFix.h: No such file or directory
#include <gps_common/GPSFix.h>
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gps_umd/gpsd_client/CMakeFiles/gpsd_client.dir/build.make:62: recipe for target 'gps_umd/gpsd_client/CMakeFiles/gpsd_client.dir/src/client.cpp.o' failed
make[2]: *** [gps_umd/gpsd_client/CMakeFiles/gpsd_client.dir/src/client.cpp.o] Error 1
CMakeFiles/Makefile2:2783: recipe for target 'gps_umd/gpsd_client/CMakeFiles/gpsd_client.dir/all' failed
make[1]: *** [gps_umd/gpsd_client/CMakeFiles/gpsd_client.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 1%] Built target _ublox_msgs_generate_messages_check_deps_RxmSVSI
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j2 -l2" failed

Any body knows where the problem is?

Thanks !!!!

I didn't find the launch flie which include :

<node name="gps_conv" pkg="gps_common" type="utm_odometry_node"> 
    <remap from="odom" to="vo"/>
    <remap from="fix" to="/gps/fix" /> 
    <param name="rot_covariance" value="99999" />
    <param name="frame_id" value="base_footprint" />
</node>

so where is it?
thanks

When check_fix_by_variance is disabled, you can get NaN covariance values, but the position_covariance_type is still COVARIANCE_TYPE_DIAGONAL_KNOWN. Downstream receivers of this may not like that (foxglove/studio#6337).

https://github.com/rgov/gps_umd/blob/b680df6142d7dfbc8a63224116b9a4a56e964c5b/gpsd_client/src/client.cpp#L297-L299

I've included this fix in my fork so it's also part of #57.

Hi,

The lastest release was made in September 2023. There's been a bug fix since and no new releases.

Could you please make a new release?

We need gps_msgs for Space ROS, which we are releasing in a few days (tomorrow is our build day), so it'd be great to depend on a version that includes the very latest bug fixes. Thanks!

In case the receiver is multi-constellation (most are in these days), having PRN fields as int16 becomes impractical, as multiple satellites from different constellations can have the same PRN.

Sometimes, this is resolved by prepending a character like 'E' for Galileo etc. But that's not doable here without breaking compatibility.

Other solutions define some base PRN offsets for different constellations (discussed e.g. here: https://gis.stackexchange.com/questions/163912/is-there-an-industry-standard-official-mapping-of-galileo-satellites-to-global ). I think this would be the only viable solution keeping compatibility.

Would you be inclined to specifying in comments what this mapping should be? If there'd be the defined mapping, it would be easy for users to convert between the numerical and alphanumeric PRNs. The only danger I see here is if some tools check the PRNs and use them further, but do not know about the convention, they would probably fail with unknown PRN errors.

In the client.cpp source file for gpsd_client we see this:

void stop() {
      // gpsmm doesn't have a close method? OK ...
    }

The documentation for libgpsmm reads

libgpsmm is a mere wrapper over libgps. Method names are the same as
the analogue C functions. For a detailed description of the functions
please read libgps(3). open() must be called after class constructor
and before any other method (open() is not inside the constructor since
it may fail, however constructors have no return value). The analogue
of the C function gps_close() is in the destructor.

Do you think that simply delete the gps pointer can solve this or is too naive?

void stop() {
      delete gps;
    }

Release 1.0.10 is marked as the latest release on github but, unless I'm misunderstanding something, I think 2.0.3 should be marked as the latest.

I am running gpsd_client on ROS Noetic / Debian 10 "buster". However, NatSavFix messages do not get published. There is nothing in the rosout / stdout of the gpsd_client node.

I can confirm that gpsmon shows up to date GPGGA and GPVTG messages being received. If I manually connect to gpsd's socket, I see:

$ nc localhost 2947
{"class":"VERSION","release":"3.17","rev":"3.17","proto_major":3,"proto_minor":12}
?WATCH={"enable":true,"json":true}
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"udp://192.168.13.255:22335","driver":"NMEA0183","activated":"2022-04-22T20:56:34.300Z","flags":1}]}
{"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
{"class":"TPV","device":"udp://192.168.13.255:22335","mode":3,"lat":41.524765833,"lon":-70.669887167,"alt":-2.970}
{"class":"TPV","device":"udp://192.168.13.255:22335","mode":3,"lat":41.524765833,"lon":-70.669887167,"alt":-2.970}
{"class":"TPV","device":"udp://192.168.13.255:22335","mode":3,"lat":41.524765833,"lon":-70.669887167,"alt":-2.970}
...

I am launching gpsdclient like so, and rosnode info confirms it (should be) publishing to /gps/fix as desired.

    <node name="gps" pkg="gpsd_client" type="gpsd_client">
        <remap from="/fix" to="~fix" />
        <remap from="/extended_fix" to="~extended_fix" />
    </node>

It looks from the output of lsof that maybe the connection was interrupted, but not automatically re-established.

COMMAND     PID USER   FD      TYPE  DEVICE SIZE/OFF    NODE NAME
gpsd_clie 20886 ifcb   10u     IPv6 1908883      0t0     TCP localhost:36308->localhost:gpsd (CLOSE_WAIT)
gpsd_clie 20886 ifcb   11u     IPv4 1909129      0t0     TCP ifcb152:56593->localhost:41384 (ESTABLISHED)
gpsd_clie 20886 ifcb   12u     IPv4 1983298      0t0     TCP ifcb152:56593->localhost:45266 (ESTABLISHED)
gpsd_clie 20886 ifcb   13u     IPv4 1908903      0t0     TCP ifcb152:56593->localhost:41214 (ESTABLISHED)
gpsd_clie 20886 ifcb   14u     IPv4 1908907      0t0     TCP ifcb152:56593->localhost:41216 (ESTABLISHED)
gpsd_clie 20886 ifcb   15u     IPv4 1908920      0t0     TCP ifcb152:56593->localhost:41232 (ESTABLISHED)
gpsd_clie 20886 ifcb   16u     IPv4 1908510      0t0     TCP ifcb152:56593->localhost:41234 (ESTABLISHED)

Is the node expected to handle this error condition? I am surprised it would not attempt to re-connect or at least log something and/or crash.

Note based on the file descriptor numbers this means that the connection to gpsd died almost immediately, before any of the other nodes were able to subscribe.

From the gpsd logs, it looks like it hit an error trying to open /dev/ttyUSB0 (which is not a GPS receiver). I disabled USBAUTO in my /etc/defaults/gpsd in the hope that this will avoid this error in the future and maybe prevent gpsd_client's connection from failing.

What are the GPS parameters that affect the odometry values?
odometry msg values:
x:492873.313
y:5527538.68483

I am using the hector_gazebo gps plugin in the simulation environment.
How can I get the gps odometry values close to the wheel odometry values?

Thanks in advance.

As pointed out in #62, many of the fields in the GPSFix and GPSStatus are not populated, poorly named, or have other problems. We don't want to break compatibility, so instead we should create new messages that better represent the data stream we're getting from GPSD.

Rather than checking the status field for the fix validity, we should be looking at the mode field. These fields are described here: https://gpsd.gitlab.io/gpsd/gpsd_json.html. Currently, the checks on the status field will work correctly with basic GPS receivers, but may not work with RTK, DGPS, or other receivers, and may report that we do not have a fix, even if the receivers are working correctly. This change will bring us closer to how GPSD is intended to be used, and will also help resolve issues with the status values changing between gpsd releases that we're continuously putting ifdef statements in for.

This will become especially important around gpsd v3.23 gets released, as the status fields have significantly changed, and the conditionally compiling around them will be quite ugly. It will also allow us to remove many of the ifdef statements that are littering the code and making it challenging to read and maintain.

With the latest Foxy release of this package, the build has started failing: https://build.ros2.org/view/Fbin_uF64/job/Fbin_uF64__gpsd_client__ubuntu_focal_amd64__binary/83/

See #61 (comment) for a report of the offending commit and suggestions for fixing it.

I'm planning to do a Foxy sync soon (maybe next week). If this is not fixed before then, the binary package will be removed from the distribution.

Hi,
We have an underwater robot which operates long time periods without GPS fixes. The "no fix" info messages from the utm_odometry_node fill up our log files. This would be equally problem some for robots that operate indoors for a long time.
If noone has an objection, I suggest changing the line to ROS_DEBUG.
If this is acceptable I can submit a PR.

Would you mind releasing these packages also for the newest distribution ROS Noetic? :)

Hi,

I noticed that gpsd_client reports -1 as status on the /extended_fix topic when status reported by gpsd is Real-Time Kinematic fixed or float.

I also noticed that the RTK-types are missing in the GPSStatus-message. Any preference for the integer values for RTK-fixed and RTK-float before I try to patch gpsd_client?

Because I wonder where the 18 and 33 did come from:

int16 STATUS_DGPS_FIX=18 # Fixed with DGPS
int16 STATUS_WAAS_FIX=33 # Fixed with WAAS

Humble is at 1.0.4. Galactic is at 1.0.5. Can Humble be bumped to 1.0.5?