How can I speed up simulation in Gazebo?

Question

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.

---

Originally posted by Stefan Kohlbrecher on ROS Answers with karma: 24361 on 2011-04-15

Post score: 13

---

Original comments

Comment by Jim Rothrock on 2011-04-16:
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.

Answer 1

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 the case of the PR2 model, the two left stereo cameras generate depth data, and publish point clouds directly. This allows a point cloud to be generated by only using a single camera, to save an expensive render. It also reduces CPU overhead on your machine, since you no longer need stereo_image_proc.

If you're not working with the PR2, I'd still recommend using the version of Gazebo that's in the "kt2_simulator" rosinstall file, since that is where a lot of optimization improvements are going. I can't make a strong guarantee about stability, but I'm hoping that all the improvements in speed and quality make it into Electric.

Good luck.

Kevin

---

Originally posted by watts with karma: 584 on 2011-04-17

This answer was ACCEPTED on the original site

Post score: 16

---

Original comments

Comment by ReiniK on 2012-03-05:
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

Answer 2

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.

---

Originally posted by hsu with karma: 5780 on 2011-04-17

This answer was NOT ACCEPTED on the original site

Post score: 5

Answer 3

With gazebo 9 I would try to do more parallelism

See here for more: http://gazebosim.org/tutorials?tut=parallel&cat=physics

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?

---

Originally posted by Markus with karma: 311 on 2018-05-07

This answer was NOT ACCEPTED on the original site

Post score: 1

Answer 4

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 -->
  <shadows>false</shadows>
</scene>

---

Originally posted by Oscar Lima with karma: 831 on 2020-04-09

This answer was NOT ACCEPTED on the original site

Post score: 4

---

Original comments

Comment by m.bahno on 2021-03-03:
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.

Comment by DanielDL on 2023-03-23:
Turning off shadows actually works like a charm for both the CPU and GPU: When running a simulation with a 1000Hz real-time drone controller on my Intel Core i5-8250U processor, the GPU would shoot up from an idle 5% to 97% and the CPU usage would increase from 20% to 80/100%, only reaching a Real Time Factor of about .7 @ 25FPS, causing instability of the drone. Turning off shadows allowed an RTF of over 8, and at RTF=1 @ 60FPS, both GPU and CPU usage were reduced significantly: 50% GPU and 60% CPU at most.