ROS package containing drivers for NMEA devices that can output satellite navigation data (e.g. GPS or GLONASS).
License: BSD 3-Clause "New" or "Revised" License
ROS driver to parse NMEA strings and publish standard ROS NavSat message types. Does not require the GPSD daemon to be running.
This package has no released Code API.
The ROS API documentation and other information can be found at http://ros.org/wiki/nmea_navsat_driver
Reference: ros-drivers/nmea_gps_driver#2
Current state of affairs is that the user must choose between RMC messages (you get track and speed, but no covariance), or GGA messages (covariance, but no track or speed). This sucks—the driver should be able to make a few assumptions and do the right thing.
http://wiki.ros.org/nmea_navsat_driver
Sample Usage
To get up and running quickly, you can use the following command to start outputting your GPS data onto ROS topics. This assumes your GPS is outputting GGA NMEA sentences, is connected to /dev/ttyUSB0 and is communicating at 38400 baud.
[Example only shows for hydro and indigo.]
Velocity is reported through the linear field of a TwistStamped. What reference frame is this using? NED, ENU, ECEF? The documentation doesn't seem to indicate, and this is essential to use the data correctly.
ROS 2 uses Python entry points for executables. In order to minimize the difference between ROS 1 and ROS 2 versions of this package, it would be good to move all of the existing nodes into functions in the Python package so that each of the executable scripts just calls a single function, like an entry point does.
The quality values used to but generally no-longer reflect position solution source but rather solution quality. Mapping quality to NavSatStatus.status seems to be misleading and removes meaningful information.
For example, mapping 4 and 5 to GBAS is problematic because:
Therefore use of NavSatStatus.status can significantly mislead when we have a quality solution. For example, I couldn't rely on this value to know when to capture a measurement as a GPS datum for a world to local transform (do I have 1cm, or 100cm accuracy?)
Is there a possible resolution that uses existing messages? Do we need a new message? This might warrant a greater discussion on the importance and strategy of preserving and communicating quality data in greater detail.
I'm encountering an issue that I'm wondering if anyone else has noticed or could sanity check for me. It seems that I can't echo or subscribe to the /fix topic only when I upgrade my GPS's software. I've posted this to the GPS's forums but haven't heard anything.
Setup:
Issue:
When I run the nmea_navsat_driver's serial node, I can see the /fix topic with "rostopic list," and I can see it's being published by the serial node with "rostopic info /fix," but when I try to echo the messages or subscribe to them in another node, it hangs up indefinitely.
Workaround:
Oddly, if I downgrade Emlid's ReachView application to version 2.10 or lower, this problem resolves itself and I'm able to echo and subscribe to the /fix topic. If I upgrade to 2.11+, the issue comes right back.
Conclusion:
Uhh, I'm not really sure where this problem lives, and I've posted over at the Emlid forums (https://community.emlid.com/t/reachview-2-11-and-ros-topics/11152) and was in the middle of posting to the ROS forums when I thought it might be more efficient to post it here as an issue. I mostly wanted to see if anyone has encountered this, or if someone would be bored enough to try and replicate the issue. Also, I want to note that I'm a bit tied to the old Ubuntu and ROS versions because the robot we're using came with them and their firmware is a little too tied to ROS upgrade without breaking stuff.
Is there any possibility I can change the publishing rate of /fix?
I have noticed the frequency is approximately 1 HZ, how can I make it faster?
From what I understand nmea HDT sentences provide yaw angle in NED coordinate frame, and subsequently the driver follows to provide quaternions in the same notation.
What would be the best practice to transform to ENU to have correct input for robot_localization and similar?
When attempting to install dependencies from scratch in a clean crystal-desktop docker image, I run into some problems. To reproduce:
docker run -it osrf/ros:crystal-desktop
apt update && apt install -y python3-colcon-common-extensions
(cd /usr/bin && ln -s pip3 pip)
rosdep init
rosdep update
mkdir -p workspace/src
cd workspace/src
git clone https://github.com/ros-drivers/nmea_navsat_driver.git -b ros2
git clone https://github.com/ros-drivers/nmea_msgs.git -b ros2
cd ..
rosdep install -i --from-paths src --rosdistro crystalSince ROS Hydro, tf has been "deprecated" in favor of tf2.
http://wiki.ros.org/tf2/Migration
but nmea_navsat_driver use tf.
at line 177:
@staticmethod
def get_frame_id():
frame_id = rospy.get_param('~frame_id', 'gps')
if frame_id[0] != "/":
"""Add the TF prefix"""
prefix = ""
prefix_param = rospy.search_param('tf_prefix')
if prefix_param:
prefix = rospy.get_param(prefix_param)
if prefix[0] != "/":
prefix = "/%s" % prefix
return "%s/%s" % (prefix, frame_id)
else:
return frame_id
because i have problem to use ekf_filter with tf.
Thanks
Hello ROS developers!
I would like make use of an OXTS GPS/IMU product (i.e., a RT2000 system component) under ROS 2 Dashing Diademata. Therefore, I wonder if there exist ROS 2 Dashing Diademata drivers for OXTS GPS/IMU products.
In the review: 2010-05-31 GPS Proposal_API_Review of the NavSatFix message, the discussion appeared to initially treat HDOP as a measurement uncertainty, but late in the discussion, Chad noted, "I found a source here that claims you can use DOP to multiply the expected optimal measurement accuracy of your GPS:
http://www.pobonline.com/Articles/Column/f785817cac0f6010VgnVCM100000f932a8c0____
"As an example, let’s say the measurement accuracy is 1 meter. If DOP is 1, then the
positioning accuracy is 1 meter. What happens when the DOP is 5?
The best positioning accuracy is 5 meters." So it looks like we can take the optimal case
(DGPS, WAAS, Omnistar, etc) covariance matrix and multiply that by DOP^2. So this could still be done by the driver."
This matches what I've divined from reading. The implementation of the driver currently sets covariance to HDOP^2, but should multiply that by the measurement variance. HDOP is apparently supposed to be greater than 1.0, and the current (faulty) implementation has apparently worked well enough, possibly because the square of an HDOP of 1.0 - 2.0 is 1.0 - 4.0, which is in the ballpark of what aided GPS variance should be.
This doesn't work for RTK GPS, where the error is a few cm.
Determining the measurement error was left by the NavSatFix message architects as a detail for the driver. It has been asserted that NMEA doesn't standardize how GPS receivers should publish measurement error. Reportedly, each vendor uses proprietary ways of reporting error. However, there is a GPGST message that at least Trimble publishes. The Skytraq receiver will also publish it, so I think we should support it and use its data to compute covariance. The message definition is shown below.
An example of the GST message string is:
$GPGST,172814.0,0.006,0.023,0.020,273.6,0.023,0.020,0.031*6A
The Talker ID ($--) will vary depending on the satellite system used for the position solution:
$GP - GPS only
$GL - GLONASS only
$GN - Combined
GST message fields
Field Meaning
0 Message ID $GPGST
1 UTC of position fix
2 RMS value of the pseudorange residuals; includes carrier phase residuals during periods of RTK (float) and RTK (fixed) processing
3 Error ellipse semi-major axis 1 sigma error, in meters
4 Error ellipse semi-minor axis 1 sigma error, in meters
5 Error ellipse orientation, degrees from true north
6 Latitude 1 sigma error, in meters
7 Longitude 1 sigma error, in meters
8 Height 1 sigma error, in meters
9 The checksum data, always begins with *
I propose that covariance should be calculated using a heirarchy of inputs as follows:
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
If GST is provided, error should be taken as the greater of lattitude or longitude 1-sigma error
If GST is NOT provided, the fix quality should be mapped to 1-sigma error as follows:
0: 10^6 (This is arbitrary - the fix is invalid so Nan could be another option)
1: 4m. This is based on http://www.gps.gov/systems/gps/performance/accuracy/ wherein 2-sigma (95%) is stated as 7.5m, so 1-sigma should be half that (4m)
2: 10cm based on https://en.wikipedia.org/wiki/Differential_GPS
3: 3m based on half the 95% error of 5.9m stated here: http://www.navipedia.net/index.php/GPS_Performances
4: 2cm. I couldn't find a reference for 1-sigma for RTK so this is a proposal
5: 4m. A receiver shouldn't offer worse accuracy than SPS while it's trying to transition to RTK Fix mode - if it does (and I think the Swiftnav unit does) - I think it's broken.
6: ?? This is not estimatable. Perhaps Nan?
7: ?? This is not estimatable. Perhaps Nan?
8: 0m Perhaps a simulation should exhibit perfect accuracy
The proposals above do not reflect actual accuracy (except where provided by the receiver) - actual accuracy can be affected by the environment. They attempt to be a "best guess".
Will Nan in covariance blow-up the navigation stack? If so, perhaps a huge covariance is better.
I'm not super-experienced in this domain, and welcome better ideas. Thanks for your help.
Paul
I think that in both the Node scripts nmea_serial_driver and nmea_serial_topic_driver, there is a need for the catching of the exception caused when there is a serial error produced as there is a need to provide any errors caused to both the screen and the logging files of ROS.
Hi.
I've installed setup raspignss module that uses NV08C. (http://drfasching.com/products/discontinued/raspignss-cook/installation.html)
Attached file is nmea message after sending 'nmeaparsing' command on the host. Can nmea_navsat_driver be used in raspignss module?
I'm wondering about merging this repo with some related ones, eg:
https://github.com/clearpathrobotics/nmea_comms
https://github.com/ros-drivers/nmea_msgs
The thought would be a single repo, perhaps called nmea or nmea_navsat, which contains the three packages in subdirectories.
This causes an error when trying to run the task:
Traceback (most recent call last):
File "install/nmea_navsat_driver/lib/nmea_navsat_driver/nmea_topic_serial_driver", line 11, in <module>
load_entry_point('libnmea-navsat-driver==0.5.1', 'console_scripts', 'nmea_topic_serial_driver')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 480, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2693, in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2324, in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2330, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'scripts.nmea_topic_serial_driver'
Currently, the master branch has several PEP8 violations:
$ pycodestyle src/libnmea_navsat_driver/ scripts/*
src/libnmea_navsat_driver/checksum_utils.py:17:80: E501 line too long (80 > 79 characters)
src/libnmea_navsat_driver/checksum_utils.py:38:9: E265 block comment should start with '# '
src/libnmea_navsat_driver/checksum_utils.py:38:80: E501 line too long (83 > 79 characters)
src/libnmea_navsat_driver/checksum_utils.py:42:5: E265 block comment should start with '# '
src/libnmea_navsat_driver/driver.py:17:80: E501 line too long (80 > 79 characters)
src/libnmea_navsat_driver/driver.py:50:80: E501 line too long (86 > 79 characters)
src/libnmea_navsat_driver/driver.py:51:80: E501 line too long (90 > 79 characters)
src/libnmea_navsat_driver/driver.py:70:80: E501 line too long (89 > 79 characters)
src/libnmea_navsat_driver/driver.py:72:80: E501 line too long (82 > 79 characters)
src/libnmea_navsat_driver/driver.py:126:80: E501 line too long (87 > 79 characters)
src/libnmea_navsat_driver/driver.py:128:80: E501 line too long (91 > 79 characters)
src/libnmea_navsat_driver/driver.py:153:15: E111 indentation is not a multiple of four
src/libnmea_navsat_driver/driver.py:155:38: E703 statement ends with a semicolon
src/libnmea_navsat_driver/driver.py:157:63: E703 statement ends with a semicolon
src/libnmea_navsat_driver/driver.py:180:80: E501 line too long (84 > 79 characters)
src/libnmea_navsat_driver/driver.py:191:80: E501 line too long (92 > 79 characters)
src/libnmea_navsat_driver/driver.py:196:80: E501 line too long (81 > 79 characters)
src/libnmea_navsat_driver/driver.py:203:80: E501 line too long (80 > 79 characters)
src/libnmea_navsat_driver/driver.py:209:46: E127 continuation line over-indented for visual indent
src/libnmea_navsat_driver/driver.py:211:46: E127 continuation line over-indented for visual indent
src/libnmea_navsat_driver/driver.py:243:80: E501 line too long (85 > 79 characters)
src/libnmea_navsat_driver/driver.py:246:80: E501 line too long (81 > 79 characters)
src/libnmea_navsat_driver/parser.py:17:80: E501 line too long (80 > 79 characters)
src/libnmea_navsat_driver/parser.py:98:1: E305 expected 2 blank lines after class or function definition, found 1
src/libnmea_navsat_driver/parser.py:98:80: E501 line too long (86 > 79 characters)
src/libnmea_navsat_driver/parser.py:137:10: E231 missing whitespace after ':'
src/libnmea_navsat_driver/parser.py:138:35: E231 missing whitespace after ','
src/libnmea_navsat_driver/parser.py:139:39: E231 missing whitespace after ','
src/libnmea_navsat_driver/parser.py:147:24: W605 invalid escape sequence '\$'
src/libnmea_navsat_driver/parser.py:147:30: W605 invalid escape sequence '\$'
src/libnmea_navsat_driver/parser.py:147:36: W605 invalid escape sequence '\$'
src/libnmea_navsat_driver/parser.py:147:42: W605 invalid escape sequence '\$'
src/libnmea_navsat_driver/parser.py:147:49: W605 invalid escape sequence '\*'
src/libnmea_navsat_driver/parser.py:147:80: E501 line too long (83 > 79 characters)
src/libnmea_navsat_driver/parser.py:148:80: E501 line too long (84 > 79 characters)
src/libnmea_navsat_driver/parser.py:156:8: E713 test for membership should be 'not in'
scripts/nmea_serial_driver:19:80: E501 line too long (80 > 79 characters)
scripts/nmea_serial_driver:46:42: E231 missing whitespace after ','
scripts/nmea_serial_driver:47:42: E231 missing whitespace after ','
scripts/nmea_serial_driver:60:80: E501 line too long (250 > 79 characters)
scripts/nmea_serial_driver:62:80: E501 line too long (80 > 79 characters)
scripts/nmea_serial_driver:63:24: E261 at least two spaces before inline comment
scripts/nmea_serial_driver:63:25: E262 inline comment should start with '# '
scripts/nmea_serial_driver:65:80: E501 line too long (103 > 79 characters)
scripts/nmea_socket_driver:19:80: E501 line too long (80 > 79 characters)
scripts/nmea_socket_driver:58:80: E501 line too long (80 > 79 characters)
scripts/nmea_socket_driver:70:80: E501 line too long (90 > 79 characters)
scripts/nmea_socket_driver:73:80: E501 line too long (80 > 79 characters)
scripts/nmea_socket_driver:86:80: E501 line too long (103 > 79 characters)
scripts/nmea_socket_driver:87:37: E128 continuation line under-indented for visual indent
scripts/nmea_socket_driver:87:80: E501 line too long (124 > 79 characters)
scripts/nmea_socket_driver:88:37: E128 continuation line under-indented for visual indent
scripts/nmea_socket_driver:88:80: E501 line too long (103 > 79 characters)
scripts/nmea_socket_driver:91:80: E501 line too long (87 > 79 characters)
scripts/nmea_socket_driver:93:80: E501 line too long (107 > 79 characters)
scripts/nmea_topic_driver:19:80: E501 line too long (80 > 79 characters)
scripts/nmea_topic_driver:41:1: E302 expected 2 blank lines, found 1
scripts/nmea_topic_driver:43:80: E501 line too long (129 > 79 characters)
scripts/nmea_topic_driver:45:80: E501 line too long (238 > 79 characters)
scripts/nmea_topic_driver:47:1: E305 expected 2 blank lines after class or function definition, found 1
scripts/nmea_topic_driver:53:13: E128 continuation line under-indented for visual indent
scripts/nmea_topic_serial_reader:19:80: E501 line too long (80 > 79 characters)
scripts/nmea_topic_serial_reader:47:42: E231 missing whitespace after ','
scripts/nmea_topic_serial_reader:48:42: E231 missing whitespace after ','
scripts/nmea_topic_serial_reader:60:1: E101 indentation contains mixed spaces and tabs
scripts/nmea_topic_serial_reader:60:1: W191 indentation contains tabs
scripts/nmea_topic_serial_reader:61:1: E101 indentation contains mixed spaces and tabs
scripts/nmea_topic_serial_reader:66:20: E261 at least two spaces before inline comment
scripts/nmea_topic_serial_reader:66:21: E262 inline comment should start with '# '
Fix these and add a CI check to prevent ill-formed code from being merged to master or ros2 branches.
Is NavSatFix message status.service populated correctly?
I always have service = 1 (uint16 SERVICE_GPS=1), although I have GPGSV, GLGSV, GBGSV NMEA sentences incoming.
Please clarify if the "service" field is implemented correctly.
I received these message after I run rosrun nmea_navsat_driver nmea_serial_driver
[WARN] [1528961811.402985]: Received a sentence with an invalid checksum. Sentence was: "\x00\x00\x00\xbey\xf2\x00\x0f'\x00\x00\x12\x19&;\x00\x00\x00\x00\x00\x00\x00\x00\xf4\xa1\xb5b\x01\x04\x12\x00P\xf9;\x16\x1a\x00\x0f'\x1a\x00\x0f'\x0f'\x0f'\x0f'\xf3b\xb5b"
And then I don't find anything after I run rostopic echo -c /fix
$ ros2 launch nmea_navsat_driver nmea_serial_driver_launch.py
file 'nmea_serial_driver_launch.py' was not found in the share directory of package 'nmea_navsat_driver' which is at '/workspace/install/nmea_navsat_driver/share/nmea_navsat_driver'
I am ROS newbie trying to use the nmea_socket_driver to receive UDP packets containing NMEA sentences and re-publish parsed NavSatFix messages. I'm using Melodic.
I have the node running and talking to the master node. I augmented the script with print statements to show that it is receiving NMEA sentences.
ros-nodes_1 | [WARN] [1579139206.660089]: Receiving!
ros-nodes_1 | [WARN] [1579139207.765352]: Received '$GPGGA,014647.000,4131.46214,N,07040.11177,W,0,03,99.0,014.32,M,-34.4,M,,*66\r\n$GPVTG,0.0,T,,M,0.0,N,0.0,K,N*02\r\n$GPRMC,014647.000,V,4131.46214,N,07040.11177,W,0.0,0.0,160120,,,N*60\r\n'
ros-nodes_1 | [WARN] [1579139207.774498]: Receiving!
ros-nodes_1 | [WARN] [1579139214.165529]: Received '$GPGGA,014654.000,4131.46214,N,07040.11177,W,0,03,99.0,014.32,M,-34.4,M,,*64\r\n$GPVTG,0.0,T,,M,0.0,N,0.0,K,N*02\r\n$GPRMC,014654.000,V,4131.46214,N,07040.11177,W,0.0,0.0,160120,,,N*62\r\n'
ros-nodes_1 | [WARN] [1579139214.173671]: Receiving!
ros-nodes_1 | [WARN] [1579139220.163735]: Received '$GPGGA,014700.000,4131.46214,N,07040.11177,W,0,03,99.0,014.32,M,-34.4,M,,*64\r\n$GPVTG,0.0,T,,M,0.0,N,0.0,K,N*02\r\n$GPRMC,014700.000,V,4131.46214,N,07040.11177,W,0.0,0.0,160120,,,N*62\r\n'
ros-nodes_1 | [WARN] [1579139220.171450]: Receiving!
However, if I use rostopic echo /fix I never see any messages dumped, which suggests to me that something is breaking down. What can I do to diagnose this?
The current parser assumes $GPxxx strings only, which doesn't work with ublox 8. May I suggest to change the regular expression to '^$G[N|P].__[0-9A-Fa-f]{2}$' to fix this?
Traceback (most recent call last):
File "install/nmea_navsat_driver/lib/nmea_navsat_driver/nmea_topic_driver", line 11, in <module>
load_entry_point('libnmea-navsat-driver==0.5.1', 'console_scripts', 'nmea_topic_driver')()
File "/workspace/install/nmea_navsat_driver/lib/python3.6/site-packages/scripts/nmea_topic_driver.py", line 60, in main
Sentence, 'nmea_sentence', nmea_sentence_callback, driver)
TypeError: create_subscription() takes 4 positional arguments but 5 were given
Hello guys,
I'm having problems with the nmea_navsat_driver under Indigo since it publishes a frame_id as /gps which includes a backslash which is not allowed in tf2 standard.
I tried to launch the driver with the " _frame_id:=gps" parameter but it still continues to add the backslash to the frame name.
Is it possible to change this, please? I cannot correctly run my ROS codes since I always get this error:
Could not obtain transform from /gps to base_link. Error was Invalid argument "/gps" passed to lookupTransform argument source_frame in tf2 frame_ids cannot start with a '/' like:
Thank you!
The current version, 0.5.0, is more than three years old. There has been a number of pull requests and bug fixes since then, so it would be nice to see those in the ROS distributions...
" Received a sentence with an invalid checksum"
I found from roswiki that someone also meet this error, but unsolved.
Does anyone know how to solve it ?
Thank you.
Would be great if the driver would publish the type of fix and a rate monitor.
I can implement this if there's interest.
Hello everyone,
Don't want to be picky but shouldn't this package have launch files?
I'm willing to submit a PR if you see fit.
Thank you.
This is changed in the latest tf2 release. It gives warning when a slash is present.
Hi,
Currently when we kill the node, it throws the following exceptions / errors. Suggest handling these so that the node closes gracefully.
Traceback (most recent call last):
File "/opt/ros/kinetic/lib/nmea_navsat_driver/nmea_serial_driver", line 52, in <module>
data = GPS.readline().strip()
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 511, in read
raise SerialException('read failed: %s' % (e,))
serial.serialutil.SerialException: read failed: (4, 'Interrupted system call')
I know the navsat driver publishes a fix topic which has lat, long, alt, but my gps (hemisphere v103) contains two antennas allowing for a heading nmea string to be published as well. I was wondering if it could be possible to add a part in the fix message that also sends heading in radians. I have pretty much already written the code for it, but right now i have it publishing on its own topic /heading. I need it so that the lat, long, alt, and heading are all in one fix message, so when i receive a call back in the gps_common utm_odometry_node, i can create the odometry at the same time with the same timestamp. Would this be possible? I can fork and pull request if need be.
P.S. the v103 can be added to the verified gps list because we have been using it for about 6months now with no problems.
What are GPS sensor compatible?
There is a list?
Hi all,
Thank you for making this great parse driver. The code is clean and works well.
Recently, I have been trying to retrieve the information in GST. I found that the value of alt_std_dev is always nan, and I added some log to figure out what happened.
Here is where I put the log in parse_nmea_sentence() in parser.py:
if sentence_type == "RMC":
parsed_sentence["utc_time"] = convert_time_rmc(fields[9], fields[1])
# log for check GST
if sentence_type == "GST":
rospy.logwarn(
"nmea_sentence: %s" % nmea_sentence)
rospy.logwarn(
"parsed_sentence: %s" % parsed_sentence)
rospy.logwarn(
"fields: %s" % fields)
return {sentence_type: parsed_sentence}
And following is the output message:
[WARN] [1576155838.636761]: nmea_sentence: $GNGST,130358.60,36,,,,0.046,0.041,0.057*43
[WARN] [1576155838.638862]: parsed_sentence: {'semi_major_ellipse_std_dev': nan, 'alt_std_dev': nan, 'lon_std_dev': 0.041, 'semi_major_orientation': nan, 'ranges_std_dev': 36.0, 'semi_minor_ellipse_std_dev': nan, 'lat_std_dev': 0.046, 'utc_time': (1576155838, 600000000)}
[WARN] [1576155838.641648]: fields: ['$GNGST', '130358.60', '36', '', '', '', '0.046', '0.041', '0.057*43']
It seems like the [*CheckSum] value should be removed before the parse to get correct alt_std_dev. Or did I do something wrong? Any advice would be appreciated.
When building the package and running the driver with minimal dependencies installed, the following Python error appears because the dependency on tf is not declared in package.xml:
Traceback (most recent call last):
File "/home/ed/code/nmea_navsat_driver_ws/install/lib/nmea_navsat_driver/nmea_serial_driver", line 39, in <module>
import libnmea_navsat_driver.driver
File "/home/ed/code/nmea_navsat_driver_ws/install/lib/python2.7/dist-packages/libnmea_navsat_driver/driver.py", line 39, in <module>
from tf.transformations import quaternion_from_euler
ImportError: No module named tf.transformations
Hi,
Just requesting if this can get built for kinetic.
Thanks!
The GPS devices I want to use needs some configuration commands before spitting NMEA. Is there a way to transmit a command to the serial port used for NMEA stream?
Unlike GGA, RMC sentences do include an absolute date stamp. When using RMC sentences, this data should be used when computing the timestamp instead of simply taking the current clock time and adjusting the hours, minutes and seconds fields as is done with GGA sentences.
The use of GGA quality values greater than 5 is becoming more common. In particular, Novatel boards announce WAAS as a value of 9. In this case, the driver would report a -1 for current_fix.status.status. Our solution was to reproogram the GPS to report all quality values of 9 as 2 instead.
I believe this merits discussion on if/how the driver could be changed to be more accommodating.
My concerns are:
Hello,
I've been using this driver and it's pretty cool but I wanted to use 2 GPS units with this driver. The problem I have is when I run one driver, the other GPS driver turns off. Is there a way to have 2 GPS nodes and have them publish on their own separate topics? For example, nmea_node1 publishes to topic fix1 and nmea_node2 publishes to topic fix2. How would I go about in order to achieve this?
Thank you
I think I reported this previously, but I can't find the old ticket to wake it up. In any case, here's an example bag with some data from a ublox receiver that has no sky view.
ESR's gpsd docs offer the following:
According to UNMEA, the NMEA standard requires that a field (such as
altitude, latitude, or longitude) must be left empty when the GPS has
no valid data for it. However, many receivers violate this. It's
common, for example, to see latitude/longitude/altitude figures filled
with zeros when the GPS has no valid data.
Unfortunately, the link for the citation is broken, but it's a start. Seems nmea_navsat_driver shouldn't try to cast empty strings to numbers, or the try-block should be at the field level rather than external to add_sentence.
I have been observing that the nmea_serial_driver node pre-appends a forwardslash onto whatever frame_id is specified, even the default of "gps" becomes "/gps". This causes errors in nodes that try to use this transform. I am specifically using robot_lacalization's gps_transform_node which cannot support frame_id's starting with a forwardslash.
Edit:
According to the tf2/Migration Wiki:
Removal of support for tf_prefix
One feature which has never really worked was the tf_prefix parameter. tf_prefix was an attempt to parallel the namespacing capability of ROS but for tf frame_ids. However, without core support built in the tf_prefix languished and required a significant amount of work for all developers to implement it correctly. Only a small fraction of packages implemented tf_prefix correctly and for tf_prefix to work correctly it requires all packages interacting with the data to be fully implemented. Thus tf_prefix was only useful for very limited use cases.tf2 does not support tf_prefix. To avoid confusion tf2 asserts that all frame_ids do not start with /. To make this work tf::resolve will still work to join a tf_prefix and a frame_id, but it will no longer support escaping a frame_id which starts with '/'. tf2 will treat all frame_ids as string literals. All pass throughs from tf to tf2 will strip the leading slash.
To support multiple homogeneous tf trees. As multiple master techniques develop for ROS it is expected that there will be tools developed which will expose subsets of tf data onto foreign masters.
It seems to me the nmea_navsat_driver incorrectly calculates makes a correction for the altitude portion of the NavSatFix message. Specifically, here's the code from "diver.py"
# Altitude is above ellipsoid, so adjust for mean-sea-level
altitude = data['altitude'] + data['mean_sea_level']
current_fix.altitude = altitude
The NavSatFix message definition is the following:
# Altitude [m]. Positive is above the WGS 84 ellipsoid
# (quiet NaN if no altitude is available).
float64 altitude
The GGA sentence "ellipsoidal height" produces exactly that, height relative to the WGS 84 ellipsoid, positive up. The choice of "altitude" here to describe this quantity is probably mis-leading, but in any case, based on the NavSatFix definition, one should report the ellipsoidal height field with no correction, imo.
[I will admit, for many applications, altitude above mean sea level, as it is calculated here, is probably more intuitive. But for anyone doing any kind of precision navigation, it could be very misleading.]
Hii
Am getting below error with NEO 6M GPS MODULE, using ROS kinetic
rosrun nmea_navsat_driver nmea_serial_driver _port:=/dev/ttyUSB0 _baud:=38400
KIndly help. Thanks a lot
Hi,
We have been using the driver with ros (1) and are planning to migrate to ros2 (crystal), but it seems that nmea_navsat_driver is not supported yet (or any other gps/nmea driver by the way...).
Are there any plans to migrate it to ros2?
Not sure of the effort required to make the migration; we might give it a try if you can provide some guidance as to where we should be starting/what needs to be done.
Regards,
Javier
Hi!
I created a rosbag that contains NMEA messages (nmea_msgs/Sentence), and I would like to generate sensor_msgs/NavSatFix messages.
I am working on simulating time, so I run:
rosparam set use_sim_time true
Then, I play the rosbag thats contains the NMEA messages
rosbag play --clock nmea_gps.bag
Then, I start the nmea_topic_driver to generate publish sensor_msgs/NavSatFix on /fix topic:
rosrun nmea_navsat_driver nmea_topic_driver
Finally, when I check with rostopic if there are message on /fix topic
rostopic echo /fix
WARNING: no messages received and simulated time is active.
Is /clock being published?
Any, idea of what is going on?
I check if nmea_topic_driver was subscribed to the NMEA messages properly, and it looks fine:
rostopic info /nmea_sentence
Type: nmea_msgs/Sentence
Publishers:
* /play_1516740862743383627 (http://MS-7A15:46035/)
Subscribers:
* /nmea_topic_driver (http://MS-7A15:46775/)
I also checked if the NMEA messages were right, and they look fine too:
rostopic echo /nmea_sentence
header:
seq: 0
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPRMC,152545.80,A,3301.9913392,S,06053.0775644,W,0.12,0.00,261217,0.0,E,D*3F\r\n"
---
header:
seq: 1
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPGGA,152545.80,3301.9913392,S,06053.0775644,W,5,09,1.0,52.356,M,17.442,M,0.2,*72\r\
\n"
---
header:
seq: 2
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPGSA,A,3,02,12,24,25,29,,,,,,,,12.0,1.7,11.8,1*29\r\n"
---
header:
seq: 3
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GLGSA,A,3,75,76,86,87,,,,,,,,,43.1,15.6,40.1,2*03\r\n"
---
header:
seq: 4
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPGSV,2,1,05,02,52,107,35,12,61,145,38,24,49,007,37,25,48,217,36,1*6A\r\n"
---
header:
seq: 5
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPGSV,2,2,05,29,47,283,41,,,,,,,,,,,,,1*55\r\n"
---
header:
seq: 6
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GLGSV,1,1,04,75,42,053,37,76,75,160,36,86,72,178,39,87,41,315,35,1*7F\r\n"
---
header:
seq: 7
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPGST,152545.80,0.090,,,,0.081,0.061,0.194*78\r\n"
---
header:
seq: 8
stamp:
secs: 1514301945
nsecs: 488000000
frame_id: "GPS-RTK"
sentence: "$GPVTG,0.00,T,0.00,M,0.12,N,0.06,K,A*26\r\n"
---
The output of rosnode info /nmea_topic_driver is:
rosnode info /nmea_topic_driver
Node [/nmea_topic_driver]
Publications:
* /fix [sensor_msgs/NavSatFix]
* /rosout [rosgraph_msgs/Log]
* /time_reference [sensor_msgs/TimeReference]
* /vel [geometry_msgs/TwistStamped]
Subscriptions:
* /clock [rosgraph_msgs/Clock]
* /nmea_sentence [nmea_msgs/Sentence]
Services:
* /nmea_topic_driver/get_loggers
* /nmea_topic_driver/set_logger_level
contacting node http://MS-7A15:34339/ ...
Pid: 28973
Connections:
* topic: /rosout
* to: /rosout
* direction: outbound
* transport: TCPROS
* topic: /nmea_sentence
* to: /play_1516817666576416404 (http://MS-7A15:38155/)
* direction: inbound
* transport: TCPROS
* topic: /clock
* to: /play_1516817666576416404 (http://MS-7A15:38155/)
* direction: inbound
* transport: TCPROS
Thanks in advance
with nmea navsat driver why when i launch,,,cannot show the latitude and longitude when i use ublox 7n for this package
what should i do to reedit this package so i can use this device correctly
This is my stream from GPS:
It has more data than NMEA only (here additional UBX, RTCM streams also), and the driver seems to have trouble to do what it is good at. It does not catch NMEA sentences and there is no output in the /nmea_sentence topic.
Would it be possible to either:
(A) Put something other than nan in fields that can't be calculated due to insufficient fix quality.
(B) Add a parameter that causes the node to not report any messages until sufficient GPS fix quality is achieved.
Personally, I'd prefer the latter. Currently, any node using the data has to check the fix quality. While this is clearly do-able, it would be handy to be able to just assume that any GPS data we're getting is valid.
Hi,
I'm getting the following issue while running the nmea_serial_driver on Kinetic:
process[nmea_serial_driver-2]: started with pid [16393]
Traceback (most recent call last):
File "/home/ucmrobotics/ros_rapid_usda/src/nmea_navsat_driver/scripts/nmea_serial_driver", line 49, in <module>
GPS = serial.Serial(port=serial_port, baudrate=serial_baud, timeout=20)
File "/home/ucmrobotics/.local/lib/python2.7/site-packages/serial/serialutil.py", line 240, in __init__
self.open()
File "/home/ucmrobotics/.local/lib/python2.7/site-packages/serial/serialposix.py", line 286, in open
self._update_dtr_state()
File "/home/ucmrobotics/.local/lib/python2.7/site-packages/serial/serialposix.py", line 634, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
IOError: [Errno 110] Connection timed out
[nmea_serial_driver-2] process has died [pid 16393, exit code 1, cmd /home/ucmrobotics/ros_rapid_usda/src/nmea_navsat_driver/scripts/nmea_serial_driver fix:=fix __name:=nmea_serial_driver __log:=/home/ucmrobotics/.ros/log/501f3746-889b-11e8-b1b5-035c19e54ecc/nmea_serial_driver-2.log].
log file: /home/ucmrobotics/.ros/log/501f3746-889b-11e8-b1b5-035c19e54ecc/nmea_serial_driver-2*.log
but if I run on it on Indigo, it works. Does anybody know what is happening?
Best,
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.