Fix Gazebo freezing if YARP_CLOCK is set #537
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #526 .
TL;DR: From gazebo-yarp-plugins 3.6.0, you can again set YARP_CLOCK for the Gazebo simulation, meaning that all the threads of YARP Network Wrapper Servers will be executed with the frequency correctly synchronized with the Gazebo simulation. This also means that if you like you can also set
YARP_CLOCK
directly in your.bashrc
orsetup.sh
script.With respect to the solution discussed in #526, i.e. :
in this PR there are two modifications.
First of all, the delayed initialization of the Clock is only done if the yarp::os::Network is not initialized, and this is checked by the
yarp::os::NetworkBase::isNetworkInitialized()
method. Secondly, callingyarp::os::Network::useNetworkClock
does not only need the/clock
port to exists, but also wait until something is published on that port and the NetworkClock becomes valid (see useNetworkClock). For this reason, callinguseNetworkClock
in the Gazebo Physics thread is going to deadlock, as the Gazebo physics thread is also the one that is publish the new time on the clock. To avoid this, theyarp::os::Network::useNetworkClock
is called as part of newstd::thread
that is just created for this.The PR also contains a regression test for the issue, that was failing before the fix. As the issue was quite related to the inner working of YARP, it was not use
NetworkBase::setLocalMode
as in the robotinterface and controlboard tests, but rather yarpserver is actually launched before the tests by usingtiny-process-library
.