Home | Tutorials | Wiki | Issues
Ask Your Question
0

Laser scanner update rate on fuerte (completely broken) and groovy (incorrect) and drcsim (incorrect)

asked 2013-01-17 07:56:13 -0700

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher flag of Germany
293 12 15 23

updated 2013-01-18 00:28:26 -0700

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.

delete close flag offensive retag edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2013-01-17 21:44:40 -0700

nkoenig gravatar image nkoenig
4540 5 20 38
http://gazebosim.org/

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.

link delete flag offensive edit

Comments

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

ThomasK ( 2013-01-17 22:20:26 -0700 )edit

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 )edit

gztopic hz doesn't know the type of message it receives, so it can't find out the simulation time. There is no guarantee that a message on a topic has a timestamp.

nkoenig ( 2013-01-19 15:28:54 -0700 )edit
0

answered 2013-01-17 09:51:42 -0700

ThomasK gravatar image ThomasK
443 2 4 11

This 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).

link delete flag offensive edit

Login/Signup to Answer

Question tools

Follow

subscribe to rss feed

Stats

Asked: 2013-01-17 07:56:13 -0700

Seen: 260 times

Last updated: Jan 18 '13