asked 2012-09-17 09:57:09 -0500
Stefan Kohlbrecher 
Hi everyone,
it looks to me like the publish rate of sensors in the currently installed gazebo version from .debs (1.4.15-s1338549736~oneiric) is broken. For instance, if I start the hector quadrotor indoor SLAM demo using
roslaunch hector_quadrotor_demo indoor_slam_gazebo.launch
on electric, I get:
stefan@SKdell:~$ rostopic hz /scan
subscribed to [/scan]
average rate: 40.052
min: 0.000s max: 0.046s std dev: 0.01142s window: 32
average rate: 40.000
min: 0.000s max: 0.050s std dev: 0.01219s window: 68
average rate: 40.000
min: 0.000s max: 0.050s std dev: 0.01249s window: 101
^Caverage rate: 40.012
min: 0.000s max: 0.050s std dev: 0.01245s window: 134
The scans are published at a rate of 40Hz, as intended. If I do exactly the same on fuerte (with the updated stack for fuerte, but the urdf and plugin settings are the same), I get this:
stefan@SKdell:~$ rostopic hz scan
subscribed to [/scan]
average rate: 12.923
min: 0.000s max: 0.166s std dev: 0.04591s window: 30
average rate: 12.276
min: 0.000s max: 0.243s std dev: 0.05389s window: 60
average rate: 12.182
min: 0.000s max: 0.243s std dev: 0.05367s window: 90
average rate: 12.599
min: 0.000s max: 0.243s std dev: 0.05274s window: 120
The LIDAR is mounted to the quadrotor in quadrotor_hokuyo_utm30lx.urdf.xacro, using the hokuyo_utm30lx.urdf.xacro macro. It appears the gazebo plugin settings there are read correctly, but the update rate is off. Note that "use_sim_time" is set correctly on the parameter server. Simulated SLAM also works fine on electric, but basically not at all on fuerte currently.
I observed similar problems with camera plugins publishing at a too low rate, making this a very severe problem. Any explanations/suggestions (also as to where to put a ticket ;) Trac or bitbucket ) would be helpful.
/edit: Also tested using the simulated Kinect on the Turtlebot, same story:
Electric:
stefan@SKdell:~$ rostopic hz /camera/depth/points
subscribed to [/camera/depth/points]
average rate: 20.000
min: 0.050s max: 0.050s std dev: 0.00000s window: 8
average rate: 20.000
min: 0.050s max: 0.050s std dev: 0.00000s window: 18
average rate: 20.000
min: 0.050s max: 0.050s std dev: 0.00000s window: 28
average rate: 20.000
min: 0.050s max: 0.050s std dev: 0.00000s window: 38
average rate: 20.000
min: 0.050s max: 0.050s std dev: 0.00000s window: 48
Fuerte:
stefan@SKdell:~$ rostopic hz /camera/depth/points
subscribed to [/camera/depth/points]
average rate: 12.195
min: 0.082s max: 0.082s std dev: 0.00000s window: 2
average rate: 8.746
min: 0.082s max: 0.148s std dev: 0.02696s window: 4
average rate: 7.767
min: 0.082s max: 0.172s std dev: 0.03419s window: 5
average rate: 7.830
min: 0.082s max: 0.172s std dev: 0.02803s window: 8
average rate: 7.484
min: 0.082s max: 0.175s std dev: 0.03053s window: 9
average rate: 7.931
sorry, this must have fallen off the treadmill at some point. I took a brief look, and SensorManager::Update() inlines image rendering update with the laser sensor update. I think splitting up the two updates into separate thereads should solve this issue.
See ticket.
Asked: 2012-09-17 09:57:09 -0500
Seen: 135 times
Last updated: Sep 18 '12
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
I hope this question can help the trouble shooting.... Is the output "consistent" over time, i.e. if you run "rostopic hz" and then cancel it and run it again, do you observe the same min, max and std deviation? (I noticed in-run consistency, but between-run inconsistency).
trinighost ( 2012-09-18 09:40:38 -0500 )editYes the output always has the same qualitative difference (close to desired update rate with electric, no jitter vs. far below desired update rate with fuerte - high jitter).
Stefan Kohlbrecher ( 2012-09-18 15:32:20 -0500 )edit