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

asked 2013-01-17 09:56:13 -0500

473 ●15 ●19 ●29

updated 2013-01-18 02:28:26 -0500

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

(more)

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2013-01-17 23:44:40 -0500

nkoenig
7661 ●8 ●44 ●71 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.

edit flag offensive delete link

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-18 00:20:26 -0500 )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-18 01:58:24 -0500 )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 17:28:54 -0500 )edit

add a comment

answered 2013-01-17 11:51:42 -0500

ThomasK
508 ●3 ●6 ●13

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

edit flag offensive delete link

add a comment

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

2 Answers

Comments

Question Tools

Stats

Related questions

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

2 Answers

Comments

Question Tools

Stats

Related questions

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