Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
osrf-migration opened this issue Sep 14, 2016 · 8 comments
Open

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

osrf-migration opened this issue Sep 14, 2016 · 8 comments
Labels
all bug Something isn't working major sensors

Comments

@osrf-migration
Copy link

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
Copy link
Author

Original comment by Stephan Opfer (Bitbucket: Stopfer).


  • Edited issue description

@osrf-migration
Copy link
Author

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


  • set version to "all"

@osrf-migration
Copy link
Author

Original comment by Stephan Opfer (Bitbucket: Stopfer).


Can someone confirm this issue?

@osrf-migration
Copy link
Author

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
Copy link
Author

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


  • set component to "sensors"

@osrf-migration
Copy link
Author

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 af24418 to address #1917, and merged in pull request #2085.

@osrf-migration
Copy link
Author

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
Copy link
Author

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.

@osrf-migration osrf-migration added major sensors bug Something isn't working all labels Apr 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
all bug Something isn't working major sensors
Projects
None yet
Development

No branches or pull requests

1 participant