ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Properly timestamping GNSS data

asked 2018-12-21 12:41:42 -0500

SamM gravatar image

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.

edit retag flag offensive close merge delete

Comments

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.

SamM gravatar image SamM  ( 2019-04-26 17:34:31 -0500 )edit

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()
SamM gravatar image SamM  ( 2019-04-26 17:39:44 -0500 )edit

So is your question answered at this point?

Tom Moore gravatar image Tom Moore  ( 2019-05-15 03:09:41 -0500 )edit

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.

SamM gravatar image SamM  ( 2019-05-15 05:18:48 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-01-30 04:59:00 -0500

Tom Moore gravatar image

updated 2019-01-30 05:00:27 -0500

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.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2018-12-21 12:41:42 -0500

Seen: 891 times

Last updated: Dec 21 '18