Make sure camera's FPS is strictly applied, should the real time factor be impacted

#2502 Open
Repository
ocrave
Branch
respect_fps
Repository
osrf
Branch
default

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update default
hg pull -r respect_fps https://bitbucket.org/ocrave/gazebo
hg merge e7a9e5a6073b
hg commit -m 'Merged in ocrave/gazebo/respect_fps (pull request #2502)'
Author
  1. samuel lekieffre
Reviewers
Description

When using cameras for running vision algorithms, the frame rate is often a very important parameter. If the simulated cameras do not provided precisely the expected frame rate, the algorithms are likely to be lost.

Besides, current implementation of cameras highly depends on the CPU/GPU performance of the host machine when the simulation is running. That means that the frame rate cannot be predicted and that the simulations using camera(s) are not repeatable.

The changes proposed in this pull request allows the cameras to run at the desired frame rate whatever the GPU/CPU available on the host. The idea is to put on hold the world update when we need to wait for a camera sensor that requires the current state of the world.

Much care has been taken to avoid wasting time in waiting for nothing. In particular, the threads "world update" and "sensors" are waken up as soon as they can continue their job.

It is possible to go back to the legacy working mode by setting the flag "strict_rate" to false in camera's parameters.

This pull request comes with two other changes located in ignition-math and sdformat: https://bitbucket.org/ignitionrobotics/ign-math/pull-requests/134 https://bitbucket.org/osrf/sdformat/pull-requests/289

Comments (8)

  1. Matias v01d

    Hi, I'm facing camera image delays of about 30ms on ROS+Gazebo on Xenial/Kinetic. I'm wondering if this could be fixed by this MR. Is there something similar already upstream or is this improvement still pending on this MR?