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

ros::Time between samples

asked 2017-06-19 03:45:39 -0500

rsmitha gravatar image

updated 2017-06-21 10:54:03 -0500

lucasw gravatar image


I am trying to calculate time difference between data in consecutive sensor messages through the subscriber callbacks. For example: I subscribe to sensor_msgs::Imu for the imu data. I get 5 samples per 100ms. So each sample should have a time difference of 20ms with respect to the previous one.

So if the first one arrived at: 20.092s from the start of simulation, I expected the second one to show me a time stamp of 20.112s. I am collecting the time information by using: 'ros::Time::Now()'.

However, the time stamp for all the five samples shows me : 20.092s. The rate at which my publish loop is running is 10Hz i.e. 100ms.

What should I be doing to improve the granularity of the time in the subscribed data?

int main(int argc, char **argv)
    ros::NodeHandle nh;
    geometry_msgs::Twist msg;
    ......//some code here

    sub_odom = nh.subscribe("odom", 100, &velCallback);

    ros::Publisher pub=nh.advertise<geometry_msgs::Twist>("cmd_vel", 100);
    ...//some other code here
    ros::Rate rate(10);


       //do some work

       //publish velocity message. 

   return 0;

void velCallback(const nav_msgs::Odometry::ConstPtr& msg)

    //do somework.

    odomfile << ros::Time::now().toSec() << ","      <-- Collecting timestamp
             << msg->pose.pose.position.x << "," 
             << msg->pose.pose.position.y << ","
             << msg->pose.pose.position.z
             << std::endl;

For example, some data from the imu is like this:

20.092, 0.517179, 0.00451321, 9.80055
20.092, -0.0139723, 0.00388159, 9.80482
20.092, -0.0058133, 0.00101918, 9.80735
20.092, 0.0031343, -0.00360347, 9.80619
20.092, 0.00066209, -0.00248975, 9.80001
20.192, 0.485803, 0.00368372, 9.80928

Please advise. Regards, rsmitha.

edit retag flag offensive close merge delete


You should put some of your code that is doing the timestamping in the question.

lucasw gravatar image lucasw  ( 2017-06-19 15:23:13 -0500 )edit

Also do you mean 20.092 ms? If it always that exact amount you could play with changing the rate that the publisher publishes- make the first two messages 20ms apart, then 30 ms before the third one- if it still shows 20.092s/ms then you have another issue.

lucasw gravatar image lucasw  ( 2017-06-19 15:23:42 -0500 )edit

Hi @lucasw, thanks for responding. I have put some code to show the timestamping. 20.092 is just the simulation time I see in that set of data. It changes with each run.

rsmitha gravatar image rsmitha  ( 2017-06-20 16:19:56 -0500 )edit

@lucasw, you are probably right in that, if I change the publishing rate to 50Hz, I might get the required timestamp, but the publishing and subscribing rates are to be different and ros::time should be able to show the difference, is what I thought.

rsmitha gravatar image rsmitha  ( 2017-06-20 16:21:27 -0500 )edit

The time stamp shows a change after 100ms which is the publishing rate.My question, is why should the subscribing timestamp be affected by the publishing rate?

rsmitha gravatar image rsmitha  ( 2017-06-20 16:23:49 -0500 )edit

I stripped out the irrelevant code to make it more readable.

lucasw gravatar image lucasw  ( 2017-06-21 10:55:27 -0500 )edit

Thanks, @lucasw.

rsmitha gravatar image rsmitha  ( 2017-06-21 17:12:06 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-06-20 19:05:56 -0500

ahendrix gravatar image

You're calling ros::spinOnce() at 10Hz, which means that it can only call the callbacks once every 100ms; in between it queues up messages until you call ros::spinOnce() again. If you need to respond to events with lower latency, you should call ros::spinOnce() more often or use ros::spin() and do your publishing with a timer or a separate thread.

It's also worth noting that there is a publish timestamp in the nav_msgs/Odometry header (in your case, msg->header.stamp ), which is the time that the data was captured or published, and that will be more accurate than using the time that your node received the message (ie ros::Time::now() ). Since there can be some transport delay between nodes, it's generally advisable to use the header timestamp whenever possible.

edit flag offensive delete link more


Thanks @ahendrix. I was thinking of using the header.stamp value to see what I get. It makes more sense, as you have mentioned to use that value. Also, I need to look into publishing using a separate thread.

rsmitha gravatar image rsmitha  ( 2017-06-20 19:13:53 -0500 )edit

Question Tools



Asked: 2017-06-19 03:45:39 -0500

Seen: 2,421 times

Last updated: Jun 21 '17