Revision history [back]

Late, but:

I would think that the correct way to use it is to adjust the header of the message to contain the ROS time when the GPS message was received, and put the GPS time in the message.

I would say this is indeed correct.

Messag fields and comments (from sensor_msgs/TimeReference):

# Measurement from an external time source not actively synchronized with the system clock.

Header header    # stamp is system time for which measurement was valid
                 # frame_id is not used 

time   time_ref  # corresponding time from this external source
string source    # (optional) name of time source

So this states:

• header.stamp: system time for which measurement was valid (ie: when you received the data)
• time_ref: time from this external source

Taking these two together: header.stamp tells us when the ROS node received the data from the external time source, and time_ref is the actual timestamp, decoded (if needed) from the data received from the time source.

Late, but:

I would think that the correct way to use it is to adjust the header of the message to contain the ROS time when the GPS message was received, and put the GPS time in the message.

I would say this is indeed correct.

Messag fields and comments (from sensor_msgs/TimeReference):

# Measurement from an external time source not actively synchronized with the system clock.

Header header    # stamp is system time for which measurement was valid
                 # frame_id is not used 

time   time_ref  # corresponding time from this external source
string source    # (optional) name of time source

So this states:

• header.stamp: system time for which measurement was valid (ie: when you received the data)
• time_ref: time from this external source

Taking these two together: header.stamp tells us when the ROS node received the data from the external time source, and time_ref is the actual timestamp, decoded (if needed) from the data received from the time source.

sensor_msgs::TimeReference gps_time_ref_msg;
gps_time_ref_msg.source = "gps";
gps_time_ref_msg.header.stamp = stamp;
g_gps_utc_time = ros::Time(toUtcTime(packet->chan.chan0.gps_minutes, packet->time));
gps_time_ref_msg.time_ref = g_gps_utc_time;
pub_gps_time_ref.publish(gps_time_ref_msg);

Late, but:

I would think that the correct way to use it is to adjust the header of the message to contain the ROS time when the GPS message was received, and put the GPS time in the message.

I would say this is indeed correct.

Messag fields and comments (from sensor_msgs/TimeReference):

# Measurement from an external time source not actively synchronized with the system clock.

Header header    # stamp is system time for which measurement was valid
                 # frame_id is not used 

time   time_ref  # corresponding time from this external source
string source    # (optional) name of time source

So this states:

• header.stamp: system time for which measurement was valid (ie: when you received the data)data).If you have some way of compensating for the time the data was in transit, sat in a buffer or was in any other way delayed, you could intelligently compensate for that time (fi how NTP compensates for travelling time), but I've not seen any nodes doing that
• time_ref: time from this external source

Taking these two together: header.stamp tells us when the ROS node received the data from the external time source, and time_ref is the actual timestamp, decoded (if needed) from the data received from the time source.

Edit: there aren't that many packages using this message (or at least: not that I could find). Dataspeed is using it in their driver for Oxford GPS devices. This is how they initialise the message (from here):

sensor_msgs::TimeReference gps_time_ref_msg;
gps_time_ref_msg.source = "gps";
gps_time_ref_msg.header.stamp = stamp;
g_gps_utc_time = ros::Time(toUtcTime(packet->chan.chan0.gps_minutes, packet->time));
gps_time_ref_msg.time_ref = g_gps_utc_time;
pub_gps_time_ref.publish(gps_time_ref_msg);

Where stamp is the current ros::Time passed in at the beginning of the "update loop" (ie: when reading out the data coming from the Oxford GPS).