0
$\begingroup$

Rosanswers logo

Hi there, I'm relatively new to ROS. I'm looking to fuse data from various sensors using robot_localization. To parse NMEA sentences from a GPS reciever, I'm using the 'nmea_navsat_driver' package. I noticed that the timestamp it affixes to position and velocity messages is the system timestamp (by that I mean it uses the time of the computer running the package) rather than the time contained in the NMEA sentence. It seems to me that to fuse GPS data with, say, IMU data, it would be better to use the time contained in the NMEA sentences. I can timestamp the IMU data using a real time clock (RTC is synchronised to GPS time using a PPS signal) in a Teensy before sending it to the computer which runs robot_localization. Therefore, I'm about to modify the nmea_navsat_driver python code to do this. Am I missing something? Is there another way to deal with this. I'm using ROS kinetic.


Originally posted by SamM on ROS Answers with karma: 11 on 2018-12-21

Post score: 0


Original comments

Comment by SamM on 2019-04-26:
Finally, I used the time_ref topic published by 'nmea_navsat_driver' package. It has the same timestamp as the fix messages (fix and time information are contained in the same NMEA line) but the time message contained within is slightly earlier and starts on the second and at intervals corresponding to the frequency at which the GPS is outputting data.

I wrote a node which matches fix messages with time_ref messages and outputs the fix messages over a new topic with the time given by the GPS module as the timestamp. This node also saves the GPS fixes.

Comment by SamM on 2019-04-26:
This is the gist of it:

def matchGPStime(timeref, fixwithcov):
   assert timeref.header.stamp == fixwithcov.header.stamp
   #rospy.loginfo(rospy.get_caller_id())
   Fixsynch=NavSatFix()
   Fixsynch.latitude=fixwithcov.latitude
   Fixsynch.longitude=fixwithcov.longitude
   Fixsynch.altitude=fixwithcov.altitude    
   Fixsynch.position_covariance=fixwithcov.position_covariance
   Fixsynch.header.stamp=timeref.time_ref
   Fixsynch.header.frame_id=fixwithcov.header.frame_id
   publisher3.publish(Fixsynch)


time_sub = Subscriber("/time_reference", sensor_msgs.msg.TimeReference)
fix_sub = Subscriber("/fix", sensor_msgs.msg.NavSatFix)
publisher3 = rospy.Publisher("/fixsynch", NavSatFix,queue_size=10)

rospy.init_node('GPS_synchro', anonymous=False)
ats = ApproximateTimeSynchronizer([time_sub, fix_sub], queue_size=5, slop=0.01)
ats.registerCallback(matchGPStime)
rospy.spin()

Comment by Tom Moore on 2019-05-15:
So is your question answered at this point?

Comment by SamM on 2019-05-15:
Yes, your first message answered my question. Thank you. I couldn't find an easy way to modify nmea_navsat_driver so I dealt with it as above. Moreover, it's nice to be able to tell the lag between my system clock and GPS time.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

r_l is going to use that time stamp, and if the clocks are wildly out of sync, it could definitely have strange effects on your state estimate. At most, if you're going to submit a PR to nmea_navsat_driver, I'd add a new parameter to let users decide on the behavior.


Originally posted by Tom Moore with karma: 13689 on 2019-01-30

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

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