gazebo-yarp-plugins
gazebo-yarp-plugins copied to clipboard
robotology
Clock plugin blocks gazebo if it starts paused.
It is impossible to start a gazebo world paused, if the clock plugin is loaded.
The test was done with the cer model and the libgazebo_yarp_clock plugin. If gazebo is started with the -u parameter, then the world never finishes loading. And an message for waiting for clock to be published is printed.
Hi @DatSpace, just to understand a bit more:
- which version of YARP and gazebo-yarp-plugins are you using?
- Are you setting the
YARP_CLOCKenv variable also for gazebo or just for the other modules that you are using? - Can you report the exact message (or even better, the complete log) that gazebo prints?
Thanks!
Hi,
Yarp version is: YARP version 3.5.100+20211119.4+git7e8148bc6
The clock variable is set on the terminal and all of the modules start from that terminal using a bash script, so it is everywhere.
Gazebo is started with:
rosrun gazebo_ros gazebo -s libgazebo_yarp_clock.so <Any_world_with_cer_model> --verbose -u
The -u parameter is the one that blocks. Removing it starts everything fine.
The log can be found in the link.
The clock variable is set on the terminal and all of the modules start from that terminal using a bash script, so it is everywhere.
I see! Just to let you know, this is a feature supported only since gazebo-yarp-plugins 3.6.0 (see https://github.com/robotology/gazebo-yarp-plugins/issues/526, https://github.com/robotology/gazebo-yarp-plugins/pull/537) but probably was never tested with -u option.
I looked at the logic in the clock,see https://github.com/robotology/gazebo-yarp-plugins/blob/09ff5daaf693e5ef85d5094b4086c048a2726958/plugins/clock/src/Clock.cc#L75, and I am not sure if there is anything wrong. As long as the variable networkIsNotInitialized is true, all the logic seems to be correct. Can you check if that is the case in your simulation?
I can verify that the variable is true in both cases, with and without starting paused.
I did another test and removed the plugin from the starting command, and the same problem exists. Yarp prints that it is waiting for clock server to start broadcasting data. The difference is that in this case, it doesnt matter if its paused or not as the data will never be broadcasted anyway cause the plugin is not loaded.
I did have a look at the code, and without being certain of what yarp expects, I found this:
m_worldCreatedEvent = gazebo::event::Events::ConnectWorldCreated(boost::bind(&GazeboYarpClock::gazeboYarpClockLoad,this,_1));
on line 107.
This binds the callback in the plugin the the world update event. The even is triggered on every simulation step. My concern is that assuming yarp expects at least one bottle to be transmitted to "start the broadcast", if the simulation starts paused, then no bottle is transmitted.
I hope that helps.
My concern is that assuming yarp expects at least one bottle to be transmitted to "start the broadcast", if the simulation starts paused, then no bottle is transmitted.
I think that this is the expected behaviour: if the simulation is paused, no bottle is transmitted. What I wonder is what is preventing the rest of Gazebo to start correctly. In the gazebo_yarp_clock plugin, the only code that should be waiting on the clock to be transmitting, and hence printing the "Waiting for clock server to start broadcasting data" message, is the yarp::os::NetworkBase::yarpClockInit(yarp::os::YARP_CLOCK_DEFAULT) call, but exactly for that reason that call is done in a detached thread, so it should not influence the rest of Gazebo starting up.
While the gazebo is stuck and yarp prints that it is waiting, if I connect to a new terminal and connect to the clock rpc port and send it the command to do 1 step, then it gets unstuck and everything works fine. Not sure if that helps.
Are you able to reproduce the problem just running the gazebo_yarp_clock on its own?
I tried with:
gazebo --verbose -u -s libgazebo_yarp_clock.so
and I am unable to reproduce the behaviour, gazebo starts correctly even if paused. Perhaps there is some strange interaction between the gazebo_yarp_clock, rosrun and the rest of the plugins loaded by the R1's world? If you could link a specific world in which this is occuring, ideally without ROS it would be great.
Version of software used in my test:
(gazeboyarp) C:\Users\STraversaro>mamba list
# packages in environment at C:\Users\STraversaro\AppData\Local\mambaforge\envs\gazeboyarp:
#
# Name Version Build Channel
ace 7.0.5 h0e60522_0 conda-forge
boost-cpp 1.74.0 h5b4e17d_5 conda-forge
bzip2 1.0.8 h8ffe710_4 conda-forge
ca-certificates 2021.10.8 h5b45459_0 conda-forge
cairo 1.16.0 hb19e0ff_1008 conda-forge
cfitsio 4.0.0 hd67004f_0 conda-forge
console_bridge 1.0.1 h5362a0b_0 conda-forge
cppzmq 4.8.1 h4324990_0 conda-forge
curl 7.80.0 h789b8ee_0 conda-forge
dirent 1.21 0 conda-forge
dlfcn-win32 1.3.0 h0e60522_0 conda-forge
eigen 3.4.0 h2d74725_0 conda-forge
expat 2.4.1 h39d44d4_0 conda-forge
ffmpeg 4.3.1 ha925a31_0 conda-forge
font-ttf-dejavu-sans-mono 2.37 hab24e00_0 conda-forge
font-ttf-inconsolata 3.000 h77eed37_0 conda-forge
font-ttf-source-code-pro 2.038 h77eed37_0 conda-forge
font-ttf-ubuntu 0.83 hab24e00_0 conda-forge
fontconfig 2.13.1 h1989441_1005 conda-forge
fonts-conda-ecosystem 1 0 conda-forge
fonts-conda-forge 1 0 conda-forge
freeglut 3.2.1 h0e60522_2 conda-forge
freeimage 3.18.0 hfcb8cd7_7 conda-forge
freetype 2.10.4 h546665d_1 conda-forge
freexl 1.0.6 ha8e266a_0 conda-forge
gazebo 11.9.0 h0acfcac_1 conda-forge
gazebo-yarp-plugins 4.0.0 h4d5cf38_32 robotology
geos 3.10.0 h39d44d4_0 conda-forge
geotiff 1.7.0 h350af67_3 conda-forge
gettext 0.19.8.1 ha2e2712_1008 conda-forge
gts 0.7.6 h7c369d9_2 conda-forge
hdf4 4.2.15 h0e5069d_3 conda-forge
hdf5 1.12.1 nompi_h2a0e4a3_102 conda-forge
icu 68.2 h0e60522_0 conda-forge
ilmbase 2.5.5 h12d4b20_0 conda-forge
intel-openmp 2021.4.0 h57928b3_3556 conda-forge
jasper 2.0.33 h77af90b_0 conda-forge
jbig 2.1 h8d14728_2003 conda-forge
jpeg 9d h8ffe710_0 conda-forge
jsoncpp 1.9.4 h2d74725_3 conda-forge
jxrlib 1.1 h8ffe710_2 conda-forge
kealib 1.4.14 h8995ca9_3 conda-forge
krb5 1.19.2 h20d022d_3 conda-forge
lcms2 2.12 h2a16943_0 conda-forge
lerc 3.0 h0e60522_0 conda-forge
libblas 3.9.0 8_mkl conda-forge
libcblas 3.9.0 8_mkl conda-forge
libclang 11.1.0 default_h5c34c98_1 conda-forge
libcurl 7.80.0 h789b8ee_0 conda-forge
libdeflate 1.8 h8ffe710_0 conda-forge
libffi 3.4.2 h8ffe710_5 conda-forge
libflang 5.0.0 h6538335_20180525 conda-forge
libgdal 3.3.3 he0d6347_2 conda-forge
libglib 2.70.1 h3be07f2_0 conda-forge
libiconv 1.16 he774522_0 conda-forge
libignition-cmake2 2.9.0 h0e60522_1 conda-forge
libignition-common3 3.13.2 h9bd54ec_1 conda-forge
libignition-fuel-tools4 4.4.0 he2780a4_2 conda-forge
libignition-math6 6.9.2 h0e60522_0 conda-forge
libignition-msgs5 5.7.0 hb9694b1_1 conda-forge
libignition-tools1 1.4.0 h0e60522_0 conda-forge
libignition-transport8 8.1.0 h5ccfabf_8 conda-forge
libjpeg-turbo 2.1.1 h8ffe710_0 conda-forge
libkml 1.3.0 h9859afa_1014 conda-forge
liblapack 3.9.0 8_mkl conda-forge
liblapacke 3.9.0 8_mkl conda-forge
libnetcdf 4.8.1 nompi_h1cc8e9d_101 conda-forge
libode 0.16.2 h415ef7b_9 conda-forge
libopenblas 0.3.18 pthreads_hc469a61_0 conda-forge
libopencv 4.5.3 py38hb110498_5 conda-forge
libpng 1.6.37 h1d00b33_2 conda-forge
libpq 13.5 hfcc5ef8_0 conda-forge
libprotobuf 3.18.1 h7755175_0 conda-forge
libraw 0.20.2 hee1bdec_1 conda-forge
librttopo 1.1.0 h22ffb85_7 conda-forge
libsdformat 9.3.0 h0e60522_5 conda-forge
libsodium 1.0.18 h8d14728_1 conda-forge
libspatialite 5.0.1 h9c61790_10 conda-forge
libssh2 1.10.0 h680486a_2 conda-forge
libtiff 4.3.0 hd413186_2 conda-forge
libusb 1.0.24 h8ffe710_105 conda-forge
libwebp-base 1.2.1 h8ffe710_0 conda-forge
libxml2 2.9.12 hf5bbc77_1 conda-forge
libzip 1.8.0 hfed4ece_1 conda-forge
libzlib 1.2.11 h8ffe710_1013 conda-forge
llvm-meta 5.0.0 0 conda-forge
lz4-c 1.9.3 h8ffe710_1 conda-forge
mkl 2020.4 hb70f87d_311 conda-forge
ogre 1.10.12 hadbb816_7 conda-forge
openal-soft 1.20.1 h1ad3211_0 conda-forge
openblas 0.3.18 pthreads_h543f93c_0 conda-forge
openexr 2.5.5 hab3b255_0 conda-forge
openjpeg 2.4.0 hb211442_1 conda-forge
openmp 5.0.0 vc14_1 conda-forge
openssl 1.1.1l h8ffe710_0 conda-forge
pcre 8.45 h0e60522_0 conda-forge
pip 21.3.1 pyhd8ed1ab_0 conda-forge
pixman 0.40.0 h8ffe710_0 conda-forge
poppler 21.09.0 h24fffdf_3 conda-forge
poppler-data 0.4.11 hd8ed1ab_0 conda-forge
postgresql 13.5 h1c22c4f_0 conda-forge
proj 8.1.1 h1cfcee9_2 conda-forge
pugixml 1.11.4 h0e60522_0 conda-forge
python 3.9.7 h7840368_3_cpython conda-forge
python_abi 3.9 2_cp39 conda-forge
qt 5.12.9 h5909a2a_4 conda-forge
qwt 6.2.0 h552f0f6_0 conda-forge
robot-testing-framework 2.0.1 h0e60522_0 conda-forge
ruby 2.7.2 h1d9c0f5_6 conda-forge
sdl 1.2.15 h13ae965_1 conda-forge
sdl2 2.0.12 h0e60522_1 conda-forge
setuptools 59.2.0 py39hcbf5309_0 conda-forge
simbody 3.7 hade3207_2 conda-forge
sqlite 3.36.0 h8ffe710_2 conda-forge
tbb 2020.2 h2d74725_4 conda-forge
tbb-devel 2020.2 h2d74725_4 conda-forge
tiledb 2.3.4 h78dabda_0 conda-forge
tiny-process-library 2.0.4 h0e60522_0 conda-forge
tinyxml 2.6.2 h2d74725_2 conda-forge
tinyxml2 9.0.0 h39d44d4_1 conda-forge
tk 8.6.11 h8ffe710_1 conda-forge
tzdata 2021e he74cb21_0 conda-forge
ucrt 10.0.20348.0 h57928b3_0 conda-forge
urdfdom 2.3.5 h2d74725_0 conda-forge
urdfdom_headers 1.0.5 h5362a0b_2 conda-forge
vc 14.2 hb210afc_5 conda-forge
vs2015_runtime 14.29.30037 h902a5da_5 conda-forge
wheel 0.37.0 pyhd8ed1ab_1 conda-forge
xerces-c 3.2.3 h0e60522_4 conda-forge
xz 5.2.5 h62dcd97_1 conda-forge
yaml 0.2.5 he774522_0 conda-forge
yarp 3.5.1 py39he88dcca_32 robotology
ycm-cmake-modules 0.13.0 h0e60522_0 conda-forge
zeromq 4.3.4 h0e60522_1 conda-forge
zlib 1.2.11 h8ffe710_1013 conda-forge
zstd 1.5.0 h6255e5f_0 conda-forge
zziplib 0.13.69 h1d00b33_1 conda-forge
Well, I verified that this world:
Where the model cer can be found in robotology/cer-sim
<?xml version='1.0'?> <sdf version='1.7'> <world name='default'> <model name="SIM_CER_ROBOT"> <include> <uri>model://cer</uri> </include> </model> <include> <uri>model://sun</uri> </include> <include> <uri>model://ground_plane</uri> </include> </world> </sdf>
Does reproduce it. I started it without ROS with the command:
gazebo -s libgazebo_yarp_clock.so /home/user1/cer-full-body-obstacle-avoidance/gazebo_stuff/src/world.world --verbose -u