Home | Tutorials | Wiki | Issues
Ask Your Question

Parallel Physics Gazebo 7.7.0 ROS Kinetic Ubuntu 16

asked 2017-09-12 10:02:03 -0500

mhallak gravatar image

updated 2017-09-13 01:17:24 -0500

Hi I want to test the parallel physic feature (islands). For that, I followed: parallel-physics

and I installed everything else needed: libgtest-dev, python-empy


hg merge sdformat4_4.1.0
hg commit
hg sum
    parent: 2729:e7c0bfb62385 tip
    Merge with branch sdformat4_4.1.0
    branch: island_threads
    commit: 1 unknown (clean)
    update: (current)
    phases: 1 draft

I installed libignition2-math with dgb and dev.

I encountered the following problems:

  1. Diagnostics.cc:55:50: error: no match for ‘operator/’ (operand types are ‘std::string {aka std::basic_string<char>}’ and ‘const char [7]’)

so I replaced

this->dataPtr->logPath = paths->GetTmpPath() / "gazebo";


this->dataPtr->logPath = paths->GetTmpPath() / boost::filesystem::path("gazebo");

as advised on the forum.

  1. speed_thread_islands.cc:21:39: fatal error: helper_physics_generator.hh: No such file or directory#include "helper_physics_generator.hh"

so I replaced

#include "helper_physics_generator.hh"


#include "gazebo/test/helper_physics_generator.hh"

Then it built....

The problem is that now I have a crash on

#0  ignition::math::SignalStats::InsertData (this=this@entry=0x30, _data=1.9623000000000002e-05) at /var/lib/jenkins/workspace/ign-math-debbuilder/build/ignition-math2-2.8.0/src/SignalStats.cc:237
#1  0x00007facceca4839 in gazebo::util::DiagnosticTimer::InsertData (this=this@entry=0x7fac7c005e30, _name="loadPlugins", _time=...) at /home/robil/gazebo_parallel/src/gazebo/gazebo/util/Diagnostics.cc:409
#2  0x00007facceca55be in gazebo::util::DiagnosticTimer::Lap (this=0x7fac7c005e30, _prefix="loadPlugins") at /home/robil/gazebo_parallel/src/gazebo/gazebo/util/Diagnostics.cc:377
#3  0x00007facceca5861 in gazebo::util::DiagnosticManager::Lap (this=<optimized out>, _name="World::Step", _prefix="loadPlugins") at /home/robil/gazebo_parallel/src/gazebo/gazebo/util/Diagnostics.cc:189
#4  0x00007faccd60b05e in gazebo::physics::World::Step (this=this@entry=0xdd00e0) at /

I am using: libignition-math2.so.2 => /usr/lib/x86_64-linux-gnu/libignition-math2.so.2 (0x00007f2342f68000) that is linked to: /usr/lib/x86_64-linux-gnu/libignition-math2.so.2 -> libignition-math2.so.2.8.0

Obviously I must have some incompatibilities... anyone can help me to sort that problem out?


edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2017-09-12 16:14:17 -0500

Hi, since many threads were talking about parallel physics and we spent some time bringing it back. Right now it has not been merged yet. But if you checkout sdformat from: https://bitbucket.org/rosebudflyaway/... (using branch island_threads) checkout gazebo from: https://bitbucket.org/rosebudflyaway/... (using branch diagnostics_scpeters)

The conflicts should be resolved. We will either update the tutorial or merge this changes to osrf repo. Let us know if this works.

edit flag offensive delete link more

answered 2017-09-13 01:13:32 -0500

mhallak gravatar image

updated 2017-09-13 01:16:00 -0500

Hi @yinglu

With your two repositories:

and following Parallel Processing and on a station where gazebo 8 was installed from source:

it compiles and runs smooth!!!! Thanks a lot.....

But I don't see any improvement of the real time factor....(:+(

edit flag offensive delete link more


Well, one of the reasons I didn't see improvement with real time factor is not clear: I added the two tags that were defined in sdf/1.5/physics.sdf to the file defined in sdf/1.6/physics.sdf. That removed the warning from the parser that it doesn't know: island_threads and thread_position_correction. I really don't understand why I had to do that since the file dual_pr2.world is defined as: <sdf version="1.5">

mhallak gravatar imagemhallak ( 2017-09-13 04:38:37 -0500 )edit

As for the speed up, it depends on the complexity of your simulation scenario as well, For example, if you have multiple PR2 robots, the speed up factor would be larger than only one PR2 robots. Since the simulation scene with multiple PR2 robots could easily represent multiple thread islands, for one interacted complex robot, this is not that natural. Hope this helps! You can also try mhallak's suggestion by resolving the warning.

Ying Lu gravatar imageYing Lu ( 2017-09-13 11:30:09 -0500 )edit
Login/Signup to Answer

Question Tools

1 follower


Asked: 2017-09-12 10:02:03 -0500

Seen: 51 times

Last updated: Sep 13