swri-robotics / gps_umd Goto Github PK
View Code? Open in Web Editor NEWThis project forked from ros-drivers/gps_umd
License: BSD 3-Clause "New" or "Revised" License
This project forked from ros-drivers/gps_umd
License: BSD 3-Clause "New" or "Revised" License
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
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".
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,
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.
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 (https://github.com/foxglove/studio/issues/6337).
I've included this fix in my fork so it's also part of #57.
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.
Hi,
I am using:
ubuntu 18.04
ros melodic 1.14.10
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 !!!!
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?
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.
Humble is at 1.0.4. Galactic is at 1.0.5. Can Humble be bumped to 1.0.5?
The code link to the tutorial: Writing Subscriber for gpsd_client is broken as seen below:
Please update links.
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!
I found #31 issue related to opensource license.
Is there any update for it?
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.
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
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.
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.
#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 catkin_make this package, it said cannot find libgps, so how to deal with it?
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
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
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!
Why the rotation covariance is set to 99999?
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
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.
This one is hopefully easy to solve: How can one launch gpsd_client
? We are on foxy
@ Ubuntu 20.04. What I did:
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
timer_ = create_wall_timer(1s, std::bind(&GPSDClientComponent::step, this));
Creates a 1 second polling timer. This polling period should be configurable.
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
It would be nice if this were a lifecycle node to make the behavior more predictable and controllable.
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?
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;
}
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
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?
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.