Gazebo is setting "sensor's last update time" to 0

[osrf-migration]

Original report (archived issue) by Stephan Opfer (Bitbucket: Stopfer).

---

Hi all,

I found this issue, using ROS, AMCL, TurtleBot Simulation etc. I traced it back to line 191:

this->depth_sensor_update_time_ = this->parentSensor->LastUpdateTime();

in gazebo_ros_openni_kinect.cpp. The parentSensor->LastUpdateTime() is 0 at 50% of the time.

I am using Ubuntu 16.04 LTS and ROS Kinetic with corresponding Gazebo Version 7.0.0. Here is how I reproduced the bug:

roslaunch turtlebot_gazebo turtlebot_world.launch

This starts gazebo with one turtlebot. For the kinect plugin to send data, you need to subscribe to its ROS topic, because it uses lazy publishing:

rostopic echo /camera/depth/image_raw/header

This subscribes only to the header of the image message. There you should see, if you can reproduce my issue, that the time stamp is 0 in ~50% of the time. I would expect it to be always the simulation time.

I hope someone could help here, because I didn't want to setup the whole gazebo project from source, in order to further debug it.

Greetings, Stephan

[osrf-migration]

Original comment by Stephan Opfer (Bitbucket: Stopfer).

---

• Edited issue description

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by Stephan Opfer (Bitbucket: Stopfer).

---

Can someone confirm this issue?

[osrf-migration]

Original comment by guihome (Bitbucket: guihome).

---

Hi, [edit] I can confirm the same issue here with the turtlebot camera plugin. I would not say 50% of the time but I can see zeros passing in the header maybe 10% of the time, but not a clearly repeating pattern) [/edit]

I also have issues with time extracted from the protobuf contacts message within the gazebo_ros_bumper. It appears to be 0sec,0nsec all the time. I only had one gazebo start when the time was correctly set in the plugin output. The topic visualization within gazebo shows correct time all the time.

#!c++
common::Time gazebotime = this->world_->GetSimTime(); // is OK
common::Time meastime = this->parentSensor->GetLastMeasurementTime(); // Is OK
msgs::Time contacts_time = contacts.time(); // extracted from the ContactSensor with GetContacts,    is ZERO
// individual contact inside contacts have correct time again.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

• set component to "sensors"

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

This looks like it is caused by the code in Sensor::NeedsUpdate, which sometimes calls Sensor::ResetLastUpdateTime, which sets the lastUpdateTime to zeros.

It looks like the call to ResetLastUpdateTime was added in af24418eccb4c0c75becbf5454a03dedaf04f2e3 to address #1917, and merged in pull request #2085.

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

some time ago LastMeasurementTime was introduced it should be now be used instead of LastUpdateTime for rendering sensors to get the correct timestamps. gazebo_ros_pkgs has a pull request to fix this

[osrf-migration]

Original comment by Danylo Malyuta (Bitbucket: dmalyuta).

---

I can confirm this issue on Ubuntu 14.04.5 with Gazebo 7.8.1. sensor type="camera" outputs 0 timestamp for me about 1-5% of the time, the rest of the time it's the correct simulation time.