0
$\begingroup$

Rosanswers logo

Hey everyone!

I'm running into an issue that I've previously resolved and have seen posted in a few different places, so apologies if it's a duplicate. This weekend, I started getting this problem again where I run the nmea navsat driver ROS package to read in GPS strings via USB, and can see the serial messages via "$ cat /dev/", but when I try to echo the "/fix" topic it just hangs.


Goal: Have the robot read GPS data via USB from a GPS unit.


Setup:

  • OS - Ubuntu 14.04
  • More OS info - Linux CPR-J100-0057 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28 19:17:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
  • ROS - Indigo 1.11.20
  • GPS Package - nmea_navsat_driver 0.4.2
  • GPS unit - Emlid Reach RS, ReachView app 2.11

Walkthrough:

  • With the robot powered on, the ROS core is started with the following env vars using the robot's IP address:

    export ROS_MASTER_URI=http://192.168.131.11:11311

    export ROS_IP=192.168.131.11

  • GPS device is plugged into the robot's USB port, I see the device shows up in /dev:

    ls /dev/ttyA*

    Listed devices: /dev/ttyACM0 /dev/ttyACM1

  • I'm able to display the serial data coming into the robot:

    cat /dev/ttyACM1

    Example printout:

    $GPGSA,A,3,07,08,09,11,23,48,51,,,,,,3.1,1.7,2.6*3D $GLGSA,A,3,67,68,77,78,88,,,,,,,,15.2,4.7,14.4*2A $GPGSV,2,1,07,07,44,322,48,08,79,128,45,09,55,248,45,11,27,170,37,1*65 $GPGSV,2,2,07,23,39,190,42,48,26,246,37,51,45,220,43,,,,,1*58 $GLGSV,2,1,05,67,22,239,41,68,22,296,44,77,49,019,38,78,27,317,38,1*7B $GLGSV,2,2,05,88,36,166,37,,,,,,,,,,,,,1*4D $GNGST,173725.20,1.220,,,,4.514,4.529,10.741*5C $GNVTG,,T,,M,0.09,N,0.17,K,A*32 $GNRMC,173725.40,A,3128.5281612,N,08331.7091448,W,0.04,,300418,,,A*4A $GNGGA,173725.40,3128.5281612,N,08331.7091448,W,1,12,0.0,108.391,M,-28.500,M,0.0,*61

  • Next, I try running the nmea navsat driver ROS package and match the GPS settings for port and baud rate. It seems like these settings being wrong is a classic way for this not to work, but given step 3 above, it seems like that isn't the issue here.

    rosrun nmea_navsat_driver nmea_serial_driver _port:=/dev/ttyACM1 _baud:=4800

    NOTE: I get this warning when I run the package, but I think it's only temporary at startup. I've had this same warning a week ago when everything was working. The warning:

    [WARN] [WallTime: 1525110076.762267] Received a sentence with an invalid checksum. Sentence was: '$GPGSV,2,1,08,07,45,323,43,08,80,117,46,09,54,245,45,11,28,169,$GNRMC,174116.80,A,3128.5283079,N,08331.7093528,W,0.17,,300418,,,A*49'

  • I can see the /fix and /vel topics after running the nmea package when I run rostopic list.

  • Finally, when I try to echo the topic value, it just hangs.

    rostopic echo /fix

    Output: Nothing, it just hangs there. Ctrl-C brings the prompt back.

    NOTE: After the ctrl-c command, the print out for the process running the nmea package says:

    [WARN] [WallTime: 1525110085.955421] Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details.



Things I've tried:

  • In the past, I was able to echo the topic while logged into the robot, but not able to echo it if I were on a remote computer. This was fixed by editing the /etc/hosts files for the remote computer and robot. In the file, the IP and hostname of the robot were added.

  • Checking that the user is added to the dialout group (it is), and that the GPS device's group is set to dialout (it is as well).

  • Checked the privileges of GPS device in case the user didn't have permissions. Doing a quick ls -l /dev/ttyA* shows me that the user has RW access to the GPS device (access settings: crw-rw---).

  • Tried plugging the GPS device into a different computer and run the same procedure laid out above, which gives me the same issue with the topic echo hanging.



Any help on things to try, or if you need any additional information, just let me know! I'm starting to run out of ideas.



Nick

Originally posted by popenc on ROS Answers with karma: 26 on 2018-04-30

Post score: 0

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

Rosanswers logo

For my particular situation, this doesn't seem like a ROS issue and ended up being an issue on the Emlid Reach RS GPS unit side.

As I mentioned in the OP, the problem described in this post didn't happen until after updating the GPS unit's control/monitoring software, ReachView. Given that I was able to verify the serial data (i.e., GPS strings) coming into the robot, I really didn't expect the GPS software update to be a factor in the issue at all. The only reason I was suspicious of the upgrade causing any issues was that it was the only thing changed between it working and not working.

When I downgraded my ReachView app version from 2.11 back to 2.10, and ran the same setup described above, I get the /fix and /vel topics echoing again.

I'd like to attempt to recreate this exact same behavior before fully committing to the idea that the ReachView upgrade caused an odd bug with ROS, the NMEA driver, or something along the chain.

Originally posted by popenc with karma: 26 on 2018-05-02

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by tryan on 2018-09-15:
The command stty -F /dev/ttyACM1 may help you troubleshoot. I used it when I had a problem with a ROS node and serial port configuration. I had a serial-to-USB adapter, so I used stty -F /dev/ttyUSB0 to see the working and non-working configurations and find the difference.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.