ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Optimal Hardware for Gazebo?

asked 2011-05-26 02:11:45 -0500

Kike gravatar image

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_gaz... http://answers.ros.org/question/750/h...

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/s... 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 :)

edit retag flag offensive close merge delete

Comments

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! :)
Eric Perko gravatar image Eric Perko  ( 2011-05-26 02:52:02 -0500 )edit
@ 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.
Kike gravatar image Kike  ( 2011-05-27 23:23:00 -0500 )edit
@ Felix: thanks! haven't seen it :)
Kike gravatar image Kike  ( 2011-05-27 23:23:32 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
4

answered 2011-05-26 07:14:50 -0500

hsu gravatar image

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.

edit flag offensive delete link more

Comments

thanks for your info :)
Kike gravatar image Kike  ( 2011-05-31 03:18:52 -0500 )edit
0

answered 2011-05-26 05:48:45 -0500

updated 2011-05-26 06:12:02 -0500

From my experience, the more cores the better. And a nice video card.

My desktop system runs a simulation we're doing at about 0.2 x realtime. (4 core @ 2.33ghz, 4gb RAM, ATI Radeon HD 3450)

But our workhorse workstation runs it real time without breaking a sweat (8 core @ 3.33 Ghz, 16GB, NVIDIA Quatro FX 4800) but is probably overkill.

Edit: It's possible my slimmer system was not CPU bound and was rather GPU bound, but I couldn't get it much faster even running headless, so it's unclear to me where the bottle neck was.

edit flag offensive delete link more

Comments

But how many cores is gazebo actually using on each of the two stations? I have an i7 with 8 threads of execution and I never see gazebo using more than 200% CPU (2 out of 8 threads). Maybe that's just the way my world file is setup though...
Eric Perko gravatar image Eric Perko  ( 2011-05-26 05:51:20 -0500 )edit
On my slower workstation once we optimized as much a possible it was using around 80% on all 4 cores. So it's possible it wasn't CPU bound. On the 8 core, I don't have numbers, but if I recall correctly 5 or 6 of the cores had some reasonable load, though we have several other processes running.
Asomerville gravatar image Asomerville  ( 2011-05-26 06:02:07 -0500 )edit

Question Tools

Stats

Asked: 2011-05-26 02:11:45 -0500

Seen: 2,922 times

Last updated: May 26 '11