# How can I speed up simulation in Gazebo?

What are the possible options for speeding up simulation in Gazebo? From talking to John I know there's work in progress on GPU-based acceleration of ODE. What's the status of that? What other settings for tuning performance are already available? The scenario I have in mind involves teleoperation of a robot, so real-time simulation would be highly desirable.

edit retag close merge delete

I'd like to know which affects simulation speed more: the CPU, or the graphics card? I'm simulating a vehicle with a cuboid chassis and four cylindrical wheels, but I'm getting only 3 FPS with Intel graphics, 7 with a GeForce Go 6600. The 2 GHz CPU is busy 100% of the time.
( 2011-04-16 04:21:47 -0600 )edit

Sort by » oldest newest most voted

Stefan-

I spent some time early this year working configurating Gazebo to run faster with the PR2 model. Basically, my approach was to downsample sensors as much as possible, downsample physics, and then patch Gazebo as needed where the profile showed huge hits. Like you, my application is teleoperation. With a powerful machine, Gazebo can run at real time or faster (I run at 1.4x real-time using an Intel i7 2600K with a GT 560 Ti GPU). I would guesstimate it to run about 5x faster with the PR2 model.

If you use the "kt2_simulator" branch of Gazebo, (https://code.ros.org/svn/wg-ros-pkg/branches/trunk_electric/kt2_simulator), you'll find the changes to the URDF of the PR2, controller gains, and the world file. A rosinstall file will allow you pull down the branch of Gazebo we're using. These changes should go out in Electric.

The biggest gains I found found were from lowering the physics update rate from 1KHz to 250Hz. Even if you have to increase the number of quick step iterations per physics loop, decreasing the update rate is still a win because you don't have to do collision checks as often. Obviously, this can cause problems in physics quality, and objects/robots can "explode". You'll have to tune controller gains for a lower update rate. The modified gains for the PR2 are in the "kt2_pr2_defs" package in the above stack.

One major improvement to PR2 physics to a "fixed joint reduction" which John put in place. The PR2 URDF calls out over 40 fixed joints (usually to connect a sensor to a body). In Diamondback, Gazebo models these joints as revolute joints. In the branch, the URDF is reduced to only bodies that are connected by revolute or prismatic joints. This increases physics-only simulation by about 50%. If you run the "urdf2model" or "spawn_model" utilities, fixed joints in your URDF will be reduced.

A large performance hit to the simulator is laser scan generation. The laser data is generated with ODE collision checking, and you can see a very noticeable difference in speed when you are subscribing to the laser data. For the PR2, I cut the update rate for the lasers in half, and reduced the number of rays from 640 to 180 for each laser. These are changes to the URDF, but ideally they will be dynamically reconfigurable at some point.

Camera rendering is also expensive. In the branch, I implemented a reconfigurable update rate for each camera to allow you to throttle down the render rate (this feature exists in Diamondback, but does not actually change the render rate of the camera, so does not affect the simulation speed). Slow down the camera update rates as much as you can. If you don't subscribe to a camera topic, the data won't be generated, so make sure you have lazy subscription in your pipeline.

In the new branch, Gazebo cameras can generate depth data, like a Kinect. In ...

more

Hello Kevin. I tried your version but it does not seem to compile because of dependencies to an old version of ffmpeg. Do you have a newer patched version that runs with the latest libraries and latest version of gazebo?

Best, Reinhard

( 2012-03-04 23:19:37 -0600 )edit

In trunk of physics_ode and simulator_gazebo, in addition to Kevin's above mentioned improvements, another notable change improving PR2 simulation performance is the introduction of an experimental screw joint constraint for gripper and torso simulation. The screw constraint alleviates previously existing numerical stiffness at gripper and torso joints due to high controller gains and high joint mechanism reduction ratio. Allows PR2 to run at time step size as large as 4 milli-seconds (250Hz) without URDF controller gain changes from current released 1kHz control loop values.

more

Guys no one here has mentioned shadows, in some worlds (like turtlebot3_world) they are active by default, you can turn them off and make a difference in performance using this snippet on your .world file:

<scene>
<ambient>0.4 0.4 0.4 1</ambient>
<background>0.7 0.7 0.7 1</background>
<!-- modified (shadows) to reduce computation effort, default : true -->
</scene>

more

I suppose this applies only if rendering is done on CPU. If GPU is used for rendering, then IMHO disabling shadows will not speed up physical engine.

( 2021-03-03 07:52:17 -0600 )edit

With gazebo 9 I would try to do more parallelism

See here for more: http://gazebosim.org/tutorials?tut=pa...

parallelization of the physics engine is the direction to go in order to help improve performance, with the goal of running complex robots and environments in real-time. Parallel Strategies

Two strategies to parallelize physics have been implemented: island thread and position error correction thread. For more details about these two strategies results and analysis, please refer to the parallel physics reports on the Gazebo webpage. Island Thread

The first strategy attempts to parallelize simulation of non-interacting entities. Simulated entities are interacting if they are connected by an articulated joint (such as a revolute or universal joint) or are connected via contact. Groups of interacting entities are clustered into "islands" that are mathematically decoupled from each other. Thus each island can be simulated in parallel. After each step, the clustering of islands is recalculated.

Anyone tried that option yet?

more