gazebo camera timestamp is 1.0/update_rate out of date

Question

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 (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.

Update

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.

---

Originally posted by lucasw on ROS Answers with karma: 8729 on 2016-03-17

Post score: 0

---

Original comments

Comment by lucasw on 2016-03-17:
If I add the time period between images to the image timestamp, it looks like the inconsistency is corrected.

Answer 1

I think I'm seeing the bug around https://github.com/ros-simulation/gazebo_ros_pkgs/blob/jade-devel/gazebo_plugins/src/gazebo_ros_camera.cpp#L91

  if (cur_time - this->last_update_time_ >= this->update_period_)
  {
    this->PutCameraData(_image);
    this->PublishCameraInfo();
    this->last_update_time_ = cur_time;
  }

and https://github.com/ros-simulation/gazebo_ros_pkgs/blob/jade-devel/gazebo_plugins/src/gazebo_ros_camera_utils.cpp#L606

  this->PublishCameraInfo(this->camera_info_pub_);
  this->last_info_update_time_ = cur_time;

which leads to

this->sensor_update_time_ = last_update_time;
this->PublishCameraInfo();

I'll make an issue and pr later.

---

Originally posted by lucasw with karma: 8729 on 2016-03-17

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by lucasw on 2016-03-19:
Issue 408 https://github.com/ros-simulation/gazebo_ros_pkgs/issues/408