Parsing GPGSV logs with 0 satellites fails

[mrgransky]

I tried both serial and pcap connection types in my following launch file:

<?xml version="1.0"?>
<launch>
  <node name="novatel"
        pkg="nodelet" type="nodelet"
        args="standalone novatel_gps_driver/novatel_gps_nodelet">
    <rosparam>
      verbose: false
      <!--connection_type: pcap
      device: /home/xenial/catkin_ws/src/novatel/Highway.pcap-->
      connection_type: serial
      device: /dev/ttyUSB0      
      publish_novatel_positions: true
      publish_clocksteering: true
      publish_imu_messages: true
      publish_nmea_messages: true
      publish_novatel_utm_positions: true
      publish_novatel_xyz_positions: true
      publish_novatel_heading2: true
      publish_novatel_velocity: true
      publish_range_messages: true
      publish_time_messages: true
      frame_id: /gps
      imu_frame_id: /imu
    </rosparam>
  </node>
</launch>

But I get the following error for serial with all three /dev/ttyUSB0 , /dev/ttyUSB1 , /dev/ttyUSB2:

[ERROR] [1575570561.170998323]: Error reading from device <serial:/dev/ttyUSB0>: Expected GPGSV length = 20 for message with 4 satellites, actual length = 8
GPGSV,1,1,00,,,,

and the following error for pcap:

[ERROR] [1575570352.028343228]: Error reading from device <pcap:/home/xenial/catkin_ws/src/novatel/Highway.pcap>: Parse failure extracting sentences.

Is there anything I am missing in my setup?

Device: pwrpack7
PC: ubuntu 16.04

Cheers,

[pjreed]

I think this is probably a bug in the GPGSV parser. For some reason if the number of satellites in the message is 0, it assumes it's actually 4 and tries to parse it accordingly... I'm actually not sure why the code in the parser would do that; I didn't write that originally and there's no comment indicating why it's being done. I wonder if maybe there was some receiver producing GPGSV logs that indicated they had 0 satellites but actually had 4?

In any case, I'll change that -- although for what it's worth, you're not going to get any useful information out of that log, anyway.

[pjreed]

I see what was going on; if a GPGSV message has 0 satellites, it still has enough blank fields for 1 satellite (4), but the code was then incorrectly expecting 4 blank satellites rather than 4 blank fields. Should be an easy fix.

[mrgransky]

but I get the same error with sample pcap file, downloaded from the net.

It might sound kinda dumb, but do I always have to connect my GPS antenna to the receiver for not seeing such errors?

I added output="screen" to my .launch file to produce more info and now I get two extra warnings besides previous errors:

[ERROR] [1575632249.502649116]: Error connecting to device <serial:/dev/ttyUSB1>: Error opening serial port </dev/ttyUSB1>: Permission denied
[ERROR] [1575632250.503182969]: insufficient data rate <Novatel GPS (/dev/ttyUSB1)>: 0.000000 < 20.000000
[ WARN] [1575632250.503277611]: publish rate failures detected <Novatel GPS (/dev/ttyUSB1)>: 1
[ WARN] [1575632250.503311500]: No GPS status data.

My web UI still works (showing no useful info) even though antenna is disconnected!

[pjreed]

Yes, if you don't have an antenna connected to your GPS, it is unlikely that you'll get any useful data. Do you know if the pcap file you're using has valid data in it? If you point me at it, I can take a look at it.

If you are seeing an error like Error opening serial port </dev/ttyUSB1>: Permission denied, probably the user you are running the driver as does not have permission to open that device. Run ls -l /dev/ttyUSB* and make sure you have read/write access to it; on a normal Ubuntu system, you may need to add your user account to the dialout group.

[mrgransky]

Oh yeh, thanks. I guess the problem is fixed with pcap and serial with the following screenshot:

However, I get the following warning stream now when my GPS antenna is connected to pwrpack7 receiver:

Is this an unexpected behaviour although $ rostopic echo /bestpos or $ rostopic echo /gprmc commands work quite alright?
Thanks,

[pjreed]

The publish rate failure is probably to be expected as long as you're using ASCII format logs. Try switching to binary logs and see if that helps.

The status code is a bit field that indicates the receiver status; you can find a table with all of the possible values here: https://docs.novatel.com/OEM7/Content/Logs/RXSTATUS.htm#Table_ReceiverStatus

If ROS diagnostics are enabled, the driver also publishes all of those values as part of its diagnostics, so it's easiest to use something like rqt_runtime_monitor to see why it's reporting that status.

[mrgransky]

So use_binary_messages: true in my launch file returns this:

and $ rosrun rqt_runtime_monitor rqt_runtime_monitor returns the followings:

[pjreed]

The Unexpected binary message id warning is because binary CLOCKSTEERING logs aren't currently being parsed: #64 It should be pretty easy to add, but nobody has gotten to it yet.

Although it looks like the status code you're seeing is because clock steering is currently disabled. You can manually use the CLOCKADJUST command to fix that, or just ignore the warning if you don't care about it.