Repeated Messages from gpsd_client

[amitfishy]

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

[kriskozak]

Although we maintain this repo, we don't really use (or do much at all with) the gpsd_client. At a glance, it's not clear to me that your problem is exactly the same as the one that you referenced (ros-drivers#3).

In any case, I have a BU-353 receiver hooked up that seems to give a similar odd behavior (one extra "repeated" message for every 5), now that I look at it. I tried applying the patch suggested in the other issue, and it seemed to resolve that problem, though I haven't really looked closely at this to see whether the patch might cause other problems. Did you try out the proposed patch for yourself, and did it fix your problem?

Even with the patch, the timing of the messages (when they are produced) is a little odd. They average out to 1/second, but there is a lot of variance from message to message (actually, I think it's just every fifth message that varies). I did notice looking at xgps (a client for gpsd), that it seems to have the same behavior, so I'm not sure that the ROS node is the problem.

If you'd like to test the patch and submit a pull request, we'll take a bit closer look and I assume go ahead and merge it.

[lukehutch]

I'm also seeing this issue. Every GPS fix message is duplicated. Sometimes the altitude on every other message (or every fourth message) is NaN.

I saw this described elsewhere in the context of cgps, and the suggestion was to disable echo on the TTY:

stty -F DEVICE -echo

I don't have a working ROS system right now so can't test this.