For comparing fuerte and groovy I'm looking at the scenario described here. The vehicle used there is equipped with a LIDAR that is supposed to produce scans with a update rate of 40Hz. It also has a camera that runs on a 10Hz update rate. The LIDAR update rate in fuerte, groovy and drcsim do not seem to be correct, being worst in fuerte and sort of "ok" in groovy and drcsim.
There are bug reports concerning this already: Bitbucket gazebo ticket #22, Thread on ROS Answers
/edit: More test data using "rosbag info --freq" on Bitbucket
What are the plans regardings this? Will the fuerte bug be fixed at some point or should we try switching to groovy right away? Also, does "rostopic hz" correctly consider sim time, or can this also be a source of confusion?
Measurements:
Directly after spawning the vehicle I get the following in groovy (with a 1.00 realtime factor):
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 29.364
min: 0.024s max: 0.052s std dev: 0.01059s window: 19
average rate: 32.283
min: 0.021s max: 0.052s std dev: 0.00869s window: 43
average rate: 32.508
min: 0.021s max: 0.052s std dev: 0.00869s window: 64
average rate: 32.617
min: 0.021s max: 0.052s std dev: 0.00856s window: 86
average rate: 32.646
min: 0.021s max: 0.052s std dev: 0.00840s window: 107
average rate: 32.829
min: 0.021s max: 0.052s std dev: 0.00815s window: 129
After also subscribing to an image I get (also 1.00 realtime factor):
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 32.864
min: 0.022s max: 0.050s std dev: 0.00804s window: 22
average rate: 32.114
min: 0.022s max: 0.050s std dev: 0.00835s window: 44
average rate: 31.857
min: 0.022s max: 0.058s std dev: 0.00915s window: 65
average rate: 31.332
min: 0.022s max: 0.058s std dev: 0.00944s window: 85
average rate: 31.538
min: 0.022s max: 0.058s std dev: 0.00896s window: 107
average rate: 31.844
min: 0.022s max: 0.058s std dev: 0.00853s window: 130
After additionally subscribing to point cloud data (0.76 realtime factor):
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 25.111
min: 0.022s max: 0.074s std dev: 0.01444s window: 18
average rate: 26.163
min: 0.022s max: 0.074s std dev: 0.01451s window: 37
average rate: 27.496
min: 0.022s max: 0.074s std dev: 0.01385s window: 58
average rate: 27.126
min: 0.022s max: 0.074s std dev: 0.01385s window: 75
average rate: 27.043
min: 0.022s max: 0.076s std dev: 0.01455s window: 95
The same done on fuerte:
Just after robot spawn (~4.6 realtime factor, reduces to ~1.3 on subscribing to scan ):
kohlbrecher@opstation:~$ rostopic hz /scan
subscribed to [/scan]
average rate: 29.257
min: 0.000s max: 0.071s std dev: 0.01958s window: 40
average rate: 30.924
min: 0.000s max: 0.071s std dev: 0.01948s window: 84
average rate: 30.866
min: 0.000s max: 0.071s std dev: 0.01980s window: 124
average rate: 29.967
min: 0.000s max: 0.084s std dev: 0.02007s window: 163
average rate: 30.062
min: 0.000s max: 0.084s std dev: 0.02003s window: 205
Additionally subscribing an image (~4.6 realtime factor, reduces to ~2.0 on subscribing to scan). Funny thing is, subscribing the image actually increases gazebo's realtime factor (But I fear that won't always work ;) ).
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 16.639
min: 0.000s max: 0.141s std dev: 0.04271s window: 31
average rate: 15.531
min: 0.000s max: 0.257s std dev: 0.05586s window: 68
average rate: 15.851
min: 0.000s max: 0.257s std dev: 0.05606s window: 102
average rate: 16.068
min: 0.000s max: 0.257s std dev: 0.05377s window: 137
average rate: 15.941
min: 0.000s max: 0.257s std dev: 0.05492s window: 171
This seems somewhat random, I also got this once:
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 8.981
min: 0.000s max: 0.361s std dev: 0.10495s window: 21
average rate: 9.218
min: 0.000s max: 0.424s std dev: 0.10675s window: 44
average rate: 9.208
min: 0.000s max: 0.424s std dev: 0.10233s window: 66
average rate: 8.812
min: 0.000s max: 0.475s std dev: 0.11525s window: 90
average rate: 8.959
min: 0.000s max: 0.475s std dev: 0.11449s window: 113
Subscribing to both image and pointcloud from the camera (~2.2 realtime factor):
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 12.605
min: 0.000s max: 0.216s std dev: 0.07182s window: 28
average rate: 12.455
min: 0.000s max: 0.226s std dev: 0.06549s window: 56
average rate: 13.164
min: 0.000s max: 0.226s std dev: 0.06237s window: 87
average rate: 13.433
min: 0.000s max: 0.226s std dev: 0.06072s window: 116
Finally, looking at the Atlas model in drcsim:
kohlbrecher@opstation:~$ rostopic hz scan
subscribed to [/scan]
average rate: 33.613
min: 0.024s max: 0.051s std dev: 0.00883s window: 21
average rate: 32.122
min: 0.024s max: 0.051s std dev: 0.01005s window: 39
average rate: 33.165
min: 0.024s max: 0.051s std dev: 0.00924s window: 60
average rate: 32.981
min: 0.022s max: 0.051s std dev: 0.00947s window: 79
This seems to be pretty consistent, even when subscribing to stereo point clouds, the realtime rate of gazebo drops, but the "rostopic hz" rate stays consistent.
I believe that you are looking at the wrong information.
rostopic reports a Hz rate according to the wall clock time that a message is received. Gazebo on the other hand generates sensor data based on simulation time, which can be much slower than real time.
The best way to measure hz rate for a laser or camera message is to look at the time stamp associated with the message. The can be done with:
gztopic view <laser_or_camera_topic>
Note that the above command will only work with Gazebo 1.4+.
As a test, I create a world with 4 cameras, 1 PR2, and an additional hokuyo. The total topics include 14 cameras streams, 3 laser streams, 7 contact streams, and more. I subscribe to them all, and they all produce data at the specified Hz rate - according to simulation time.
We are working on making Gazebo run faster. However, right now we have to simulate a physical world, simulate sensor data, and (optionally) run ROS on a single PC.
Shouldn't gztopic hz consider simulation time? And rostopic hz reports the same rate for 1.0 real-time factor and 0.85 real-time factor ... with a 1.0 real-time rate every tool should report 40Hz according to your post, but none do (well, the gztopic view jumps between 38 and 43).
Nope, it's not that easy. See additional test on Bitbucket: https://bitbucket.org/osrf/gazebo/issue/20/laser-scan-ray-sensor-updates-erratic-and
Stefan Kohlbrecher ( 2013-01-17 23:58:24 -0700 )editThis is a comment and not a reply but comments only allow for short unformatted posts:
I just measured time using rostopic hz, gztopic hz, and the Laser View plugin. Independent of real-time rate (0.85 and 1.0) rostopic reported ~35Hz and gztopic ~33Hz while Laser View jumped between 35 and 41 for 0.85 RT rate and between 38 and 43 for 1.0 RT rate. rostopic also reports crazy high numbers of 31k-41k every other measurement.
0.85 rt rate: http://i.imgur.com/RPFUX.png
1.0 rt rate: http://i.imgur.com/wN1me.png
Clearly, none of the measurements are what they're supposed to be (except the ones of Laser View that jump to 40Hz and beyond sometimes).
Asked: 2013-01-17 07:56:13 -0700
Seen: 96 times
Last updated: Jan 18
Copyright Askbot, 2010-2011. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
