Open osrf-migration opened 7 years ago
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
It is difficult for Gazebo to prevent a plugin from doing something bad, like blocking indefinitely. The plugins we develop and release should behave correctly, and we can help other people developing their own plugins. But we can't easily prevent a plugin from blocking, segfaulting, etc.
Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).
This could be closed as "wontfix".
The troublesome part is we've recommended blocking during WorldUpdateBegin as a way to synchronize gazebo with another program. I believe it's being done here.
The ~/world_control
topic is a way to run the world one step at a time, but someone reported the world would unexpectedly unpause. That could be a separate issue if I can reproduce it.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
It does look like uctf is blocking during WorldUpdateBegin
, via the ProcessModelMsgs
function:
Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).
The original report had attachments: CMakeLists.txt, synchronized_model.world, TestModelPlugin.cpp
The gazebo GUI splash screen never goes away if a plugin blocks WorldUpdateBegin. This is used to synchronize gazebo with another tool. The plugin blocks until it receives a signal from the other tool that it is ready for the next timestep.
I've attached a model plugin and world that reproduces the behavior.
cmake
make
GAZEBO_PLUGIN_PATH=$(pwd) gazebo --verbose path/to/src/synchronized_model.world
There are workarounds to this issue
--pause
the splash screen will go away