Optimal Hardware for Gazebo?

Question

Hej!

I want to speed up my gazebo-simulation and I will get a new PC specially for this purpose. So what should I keep in mind? What i found out so far: Use a graphic card with OpenGL 3D accelerated driver. Use CUDA with help of parallel-quickstep, according to: http://www.ros.org/wiki/simulator_gazebo/SystemRequirements http://answers.ros.org/question/750/how-to-make-gazebo-use-cuda

BUT, i didn't find any information about gazebo and multithreading? Does gazebo_simulator supports it? Will a quad-core speed up my simulation or is it mainly a graphic card issue?

In fact I want to simulate a pioneer 3dx with a kinect. And accordingly to http://answers.ros.org/question/760/simulating-kinect-sensor-in-gazebo they tried to speed up the simulator by making some software changes, but it seems like an unstable version to me. So i thought to get first the optimal hardware.

thanks for your help :)

---

Originally posted by Kike on ROS Answers with karma: 41 on 2011-05-26

Post score: 1

---

Original comments

Comment by Kike on 2011-05-27:
@ Felix: thanks! haven't seen it :)

Comment by Kike on 2011-05-27:
@ Eric: As fast as possible! The aim is to speed up the testing, but if it runs with 0.04 x real-time (my start value, now i'm already at 0.25 x Real time :) ) its faster to always work with the robot itself.

Comment by Felix Endres on 2011-05-26:
Have you seen this? http://answers.ros.org/question/783/recommended-system-for-complex-ros-programs

Comment by Eric Perko on 2011-05-26:
What speed does it currently run at? Are you hoping for realtime simulation of the Kinect? 0.5x realtime? Or just... as fast as possible! :)

Answer 1

Gazebo has two threads, one for physics and one for rendering. If you are running headless, only the physics thread is active. Approximate durations for an empty world with one PR2 in it running on a 2.8GHz i7 can be broken down to following serial processes:

• collision detection (~1e-5 sec without subscribers to the laser scanners)
• physics update (~1e-3 sec with 10 quickstep inner iterations)
• model (sensors, controllers, plugins) updates (~1e-6 sec without subscribers to laser scanners, but the range sensors/plugins can slow down this step significantly)

When an object + task is introduced, individual parts can take significantly longer. For example, when PR2 is holding a trimesh object such as in the example of the pr2_tabletop_manipulation_gazebo_demo package, each finger tip introduces around 20 contact joints with the object, totaling about 40 contact joints in all, resulting in physics updates taking about 2x more time to compute. In addition, physics thread in the grasping case can take up to 1.75 full cores.

When rendering thread is turned on, its update rate is much slower, and interlocks with the physics thread via mutexes at various places.

Hope this helps.

---

Originally posted by hsu with karma: 5780 on 2011-05-26

This answer was ACCEPTED on the original site

Post score: 4

---

Original comments

Comment by Kike on 2011-05-31:
thanks for your info :)