-
Notifications
You must be signed in to change notification settings - Fork 479
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
Laser scan (ray sensor) updates erratic and slower than desired #20
Comments
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher). Are there news on this issue? This IMHO definitely is no minor issue and apparently affects simulation quality for every user simulating LIDARs. I causes a slower than intended update rate that is hard to notice if not explicitly looked for and that will break or silently degrade performance of systems relying on the requested update rate. |
Original comment by Thomas Koletschka (Bitbucket: thomasko). It's not as bad as Fuerte anymore but I still only get 32.5Hz instead of 40 on the drc robot. |
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher). Some measured data along with related questions on answers.gazebosim. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). 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. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher). No, "rostopic hz" apparently does not use wall time. If I simulate atlas without stereo_image_proc I get about 0.5x realtime and:
Switching on stereo_image_proc I get about 0.27x realtime and
So let's agree that rostopic uses "some time" ;) for estimating the frequency, it might not be sim time, it most certainly also is not wall time. To get a valid sim time measurement I switched to rosbag, recording data and then putting out the frequency of scan messages.
Subscribing to point cloud data before recording, I get 32Hz:
Will do a fuerte test later. |
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher). Fuerte (same scenario as described in OP here: http://answers.gazebosim.org/question/890/laser-scanner-update-rate-on-fuerte-completely/ ) Again, update rate for LIDAR plugin s set to 40 Hz. Without image or pointcloud subscription:
Subscribing to camera images:
Subscribing to both camera images and point clouds:
I think we can agree that this looks broken, and to me this definitely is not a minor issue, because our USAR robots worked flawless in simulation in electric and stopped doing that in fuerte because of this. My question is if this will be fixed on fuerte, or if we should skip to groovy. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). My results from running Atlas: head_hokuyo_sensor: ~40Hz ( fluctates from ~37 to 41 hz) left_camera_sensor: ~14Hz (it can fluctuate from 13-17) I will try more to reproduce your results. |
Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher). Ok, to get more reproducibility: How I tested: Started Atlas:
New terminal, start a subscriber for scans (so recording via bagfile doesn't incur recording start overhead/delay when no scans have been subscribed before):
Record a bagfile of 1000 scans:
Optionally in new terminal, to increase load and also start up image publishers:
Then, again record bag file:
On my machine I then get the following using the 'info --freq' bagfile option: Only scan subscribed:
Also subscribing to pointcloud data:
I also recorded versions of both tests with both /scan and /clock. Interestingly, the frequency numbers exactly match those of the same test without clock data, suggesting that jitter doesn't play an important role.
/edit: Ok, recording only 1000 clock messages is probably making only limited sense ;) Still serves to show that the frequency is reproducible. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). Update:
The above reasons are why this issue was marked as minor. pull request #277 has incorporated threaded sensors. I have now been able to run Atlas at 1.40x real-time with all sensors producing correct Hz rate. In fact I was getting the correct Hz rate prior to this pull-request, but now Gazebo runs a bit faster. |
Original comment by Johannes Meyer (Bitbucket: johmeyer). Regarding 1) rostopic uses the time published on the When throttling Gazebo (version 1.3) to 0.1x real-time, Let's see if the threaded sensor implementation brings some improvements here. In general, I would expect that the update rate decreases if the computing resources are exhausted, but the publishing rates measured in simulated time should not degrade. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original comment by Thomas Koletschka (Bitbucket: thomasko).
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). There are two issues here. The first is the rate at which Gazebo generates data, the second is the rate at which that data is sent out over ROS. I was under the impression that this thread was about the first, and not the second. Here is the document that will list the rates at which ROS topics operate: Concerns about those TBD rates should be posted on the DRC Sim issue tracker. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
multi-threaded sensors in pull request #277 |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
can be anywhere from 10 to 50% slower than expected (see [[http://answers.ros.org/question/43960/publishing-rate-of-gazebo-sensor-plugins-broken-on-fuerte/ | this thread]]). This is probably because
SensorManger::Update()
calls image sensor updates and ray sensor updates serially. Image rendering is dictated by GPU transport rates, so it's a good idea to split the two up into separate threads.The text was updated successfully, but these errors were encountered: