Ask Your Question

gazebo camera timestamp is 1.0/update_rate out of date

asked 2016-03-17 14:46:32 -0500

lucasw gravatar image

updated 2020-11-21 12:06:30 -0500

How confident should I be that the timestamp from a gazebo camera image is actually consistent with the tf state of the world at that same time?

It seems like it ought to be perfect, but what I'm seeing indicates that if I move objects rapidly then observed position of objects in the image either lags or leads the tf lookup (via tf transfromPoints in C++) of those objects using the image timestamp.

It's possible I'm doing something wrong in my ros nodes to introduce an offset, but can anyone speak to the correctness of the gazebo + gazebo_ros parts of the system?

The timestamps coming out of gazebo seem nearly perfect- if I set the <update_rate> and <updaterate> (does one override the other?) to 1.0 then I see nsecs = 0 followed by nsec = 0 for the next, though and occasionally nsecs = 1000000.

Everything is passing through the gazebo_ros plugin, though if it were assigning timestamps wrongly when it receives the image or a joint position rather than when it was produced I would expect to see some noise digits in the timestamps (unless gazebo_ros is in control of the sim time, but not truly synced to the actual simulation?).

rostopic hz on /gazebo/link_states and the joint_states derived from them are exactly even- suggesting they are better integrated with the simulation than the camera image, which hovers around the desired update rate but does not match it (which is consistent with that occasional 1 ms offset in the timestamp).

Could the published image be exactly one frame period ahead the timestamp assigned to it? (I'll test this by offsetting the timestamp before tf lookup) When I lowered the frame rate to 1.0 to avoid dropped frames the mismatch effect is extra dramatic.

To debug I can try to eliminate my code from the system, or eliminate gazebo from the system (I have a crude software renderer), but it will be a lot of effort so any insight is appreciated.


I've done some experiments with the rrbot gazebo example and lowered the update_rate to 0.1, or 1 image every ten seconds. If I rostopic echo the clock and /rrbot/camera1/camera_info/header/stamp/secs I see that every ten seconds a new image is published with a timestamp 10 seconds behind the current time, but a current image.

This using Ubuntu 14.04, jade, and gazebo 5.0.1, and the gazebo_ros_pkgs from apt.

edit retag flag offensive close merge delete


If I add the time period between images to the image timestamp, it looks like the inconsistency is corrected.

lucasw gravatar image lucasw  ( 2016-03-17 15:42:18 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-03-17 16:55:15 -0500

lucasw gravatar image

I think I'm seeing the bug around

  if (cur_time - this->last_update_time_ >= this->update_period_)
    this->last_update_time_ = cur_time;


  this->last_info_update_time_ = cur_time;

which leads to

this->sensor_update_time_ = last_update_time;

I'll make an issue and pr later.

edit flag offensive delete link more


lucasw gravatar image lucasw  ( 2016-03-19 08:50:19 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-03-17 14:46:32 -0500

Seen: 461 times

Last updated: Mar 17 '16