Add the possibility to log the YarpTextLogging
Closed this issue · 24 comments
Some modules can forward their execution log to the Yarplogger through a Yarp port. We could visualise the logged data on OpenMCT. Refer to the discussion referenced below:
It might also be useful to log the text log coming from the modules. In general anyway, it would be nice to have a shared interface between the online and offline logging.
Originally posted by @S-Dafarra in #121 (comment)
For the TextLogging I took inspiration from what is done in YarpManager. ami-iit/bipedal-locomotion-framework#546
Originally posted by @GiulioRomualdi in #121 (comment)
For the TextLogging I took inspiration from what is done in YarpManager. ami-iit/bipedal-locomotion-framework#546
@GiulioRomualdi , I guess you meant more specifically ami-iit/bipedal-locomotion-framework#541.
Originally posted by @nunoguedelha in #121 (comment)
For the development, we relate to the analysis done in ami-iit/bipedal-locomotion-framework#540 .
Using yarp_logging
yarp_logging Logging with YARP
YARP has an internal mechanism to help you debug your distributed application.
While you can simply use
printforstd::coutmethods to debug your
application locally, if you use the functionalities offered, YARP will collect
and show several additional information, including system and network time,
file, line, thread id, etc., and eventually forward them to
[yarplogger](@ref yarplogger).YARP is also able to detect if it is running on a console or inside
[yarprun](@ref yarprun) and if the application output is forwarded to
[yarplogger](@ref yarplogger) (using the--logoption), and change its
output accordingly, so that the extra information is forwarded properly.When the log is forwarded over the network, the logging process opens a yarp port
with the following syntax:/log/hostname/processname/pid.
NOTE: If yarprun is used, hostname is replaced by the name of yarprun server.
Environment variables
Identifying the process which is currently broadcasting
User can set
YARP_LOG_PROCESS_LABELto specify a string which can help in identifying the
process which is currently broadcasting the log over the network.
The string will be appended after the process name in the log port and included between
two square brackets, i.e./log/hostname/processname[user_label]/pid.
A typical use case for this environment variable is when multiple [yarprobotinterface](@ref yarprobotinterface)
and/or [yarpdev](@ref yarpdev) are running simultaneously. In this case, the name log ports are
difficult to interpret, since the process name alone is not enough to identify them.
In this case the user can set a custom label for each of them to better distinguish them
in the [yarplogger](@ref yarplogger) gui.
YARP_LOG_PROCESS_LABELcan be easily set for each individual process, via [yarpmanager](@ref yarpmanager),
using theenvironmentsection.
Forwarding output
By default, the logging callback prints the output on the
stdout/stderr.
When a YARP program is started by [yarprun --log](@ref yarprun), this will
forward the output on a YARP port that can be read by
[yarplogger](@ref yarplogger), and displayed.This behaviour can be obtained also without [yarprun](@ref yarprun), by
setting theYARP_FORWARD_LOG_ENABLEenvironment variable to1.
Please note that, while [yarprun](@ref yarprun) is able to forward all the
output of the application (includingprintfandstd::outoutput), this
method will forward only the output using YARP log utilities.At the moment, not all the information gathered is forwarded. It is possible
to enable them by using the following environment variables:
YARP_FORWARD_CODEINFO_ENABLEYARP_FORWARD_HOSTNAME_ENABLEYARP_FORWARD_PROCESSINFO_ENABLEYARP_FORWARD_BACKTRACE_ENABLEPlease note that
yarp::osinternal logging is never forwarded, since this
could cause recursions that will crash the program.
For now, we shall only use the variables YARP_FORWARD_LOG_ENABLE=1 and :
YARP_LOG_PROCESS_LABEL=YarpJS_WholeBodyDynamicsat the step 5 of https://github.com/ami-iit/yarp-openmct#how-to-run-the-telemetry-visualization-tool-arrow_up :YARP_CLOCK=/clock YARP_LOG_PROCESS_LABEL=YarpJS_WholeBodyDynamics yarprobotinterface YARP_FORWARD_LOG_ENABLE=1 --config launch-wholebodydynamics.xmlYARP_LOG_PROCESS_LABEL=YarpJS_WalkingModuleat step 6 of https://github.com/ami-iit/yarp-openmct#how-to-run-the-telemetry-visualization-tool-arrow_up :YARP_CLOCK=/clock YARP_LOG_PROCESS_LABEL=YarpJS_WalkingModule YARP_FORWARD_LOG_ENABLE=1 WalkingModule
The YARP_FORWARD_LOG_ENABLE=1 setting is working properly, I'm able to connect to the respective logging ports and stream the expected messages.
The YARP_LOG_PROCESS_LABEL variable is not having any effect on the port name. This is probably because I was using an old YARP version older than 3.5.1, while 3.5.1 includes the commit https://github.com/robotology/yarp/tree/64beef5720bedd3ecca59d6a315a6fb7124047c5 .
So I tried updating my setup, installing a recent superbuild (binary installation). I'm having some issues installing the whole barraca due to some cross-dependencies on Conda. I will discuss with @traversaro offline about this.
@traversaro , at the end I was able to install Gazebo 11.11.0, after:
- updating conda to 4.14.0 (although you mentioned it shouldn't matter in this case, but maybe same base package was causing a conflict and resulting in a crash of Gazebo)
- re-creating again the environment
- installing first Gazebo 11.11.0 and running it (with success)
- then installing the robotology packages in the order yarp, gazebo-yarp-plugins, icub-models, icub-main.
The installation of Robotology packages was successful, but I'm now encountering a new issue with Gazebo, unrelated to Robotology packages. Every time I try to insert any model (even native Gazebo models), it simply disappears right away:
- run
gazebo --verbose - go to
inserttab on the left pane - select the
Arm Partmodel (for instance) - hover the world canvas (at this point the part is displayed and follows the mouse position on the canvas)
- click where you wish to drop the model => the model disappears from the canvas
No debug, warning nor error message is printed on the terminal.
When previously installing Gazebo with conda, I got the warning message:
...
Preparing transaction: done
Verifying transaction: done
Executing transaction: \ objc[39523]: Class GNotificationCenterDelegate is implemented in both /Users/nunoguedelha/miniforge3/envs/robotologybin/lib/libgio-2.0.0.dylib (0x103bc1bc0) and /usr/local/opt/glib/lib/libgio-2.0.0.dylib (0x104109330). One of the two will be used. Which one is undefined.
- objc[39594]: Class GNotificationCenterDelegate is implemented in both /Users/nunoguedelha/miniforge3/envs/robotologybin/lib/libgio-2.0.0.dylib (0x1065a9bc0) and /usr/local/opt/glib/lib/libgio-2.0.0.dylib (0x106aeb330). One of the two will be used. Which one is undefined.
donefull log
+ libgd 2.3.3 h1e214de_3 conda-forge/osx-64 245kB
+ libgdal 3.5.1 hcf5fda6_5 conda-forge/osx-64 10MB
+ libgfortran 5.0.0 10_4_0_h97931a8_25 conda-forge/osx-64 150kB
+ libgfortran5 11.3.0 h082f757_25 conda-forge/osx-64 2MB
+ libglib 2.72.1 hfbcb929_0 conda-forge/osx-64 3MB
+ libidn2 2.3.3 hac89ed1_0 conda-forge/osx-64 173kB
+ libignition-cmake2 2.15.0 hf0c8a7f_0 conda-forge/osx-64 252kB
+ libignition-common3 3.13.2 h9894a04_3 conda-forge/osx-64 556kB
+ libignition-fuel-tools4 4.4.0 h70e77c0_8 conda-forge/osx-64 235kB
+ libignition-math6 6.11.0 py310h9fb7402_1 conda-forge/osx-64 1MB
+ libignition-msgs5 5.9.0 h60f3e22_1 conda-forge/osx-64 839kB
+ libignition-tools1 1.5.0 hd8dcec6_0 conda-forge/osx-64 34kB
+ libignition-transport8 8.3.0 hd717ba6_1 conda-forge/osx-64 360kB
+ libkml 1.3.0 h8fd9edb_1014 conda-forge/osx-64 494kB
+ liblapack 3.9.0 16_osx64_openblas conda-forge/osx-64 13kB
+ libllvm14 14.0.6 h41df66c_0 conda-forge/osx-64 28MB
+ libnetcdf 4.8.1 nompi_hebd45d5_104 conda-forge/osx-64 1MB
+ libode 0.16.2 h9d931ec_10 conda-forge/osx-64 485kB
+ libogg 1.3.4 h35c211d_1 conda-forge/osx-64 207kB
+ libopenblas 0.3.21 openmp_h429af6e_3 conda-forge/osx-64 10MB
+ libopus 1.3.1 hc929b4f_1 conda-forge/osx-64 280kB
+ libpng 1.6.37 h5481273_4 conda-forge/osx-64 319kB
+ libpq 14.5 h76c7896_0 conda-forge/osx-64 3MB
+ libprotobuf 3.21.5 hbc0c0cd_0 conda-forge/osx-64 2MB
+ libraw 0.20.2 hefd3b78_1 conda-forge/osx-64 2MB
+ librsvg 2.54.4 h3d48ba6_0 conda-forge/osx-64 8MB
+ librttopo 1.1.0 he07d8f5_11 conda-forge/osx-64 223kB
+ libsdformat 9.8.0 h36e5baf_2 conda-forge/osx-64 670kB
+ libsodium 1.0.18 hbcb3906_1 conda-forge/osx-64 529kB
+ libspatialite 5.0.1 hdbf6ee6_18 conda-forge/osx-64 4MB
+ libtar 1.2.20 h0d85af4_1004 conda-forge/osx-64 41kB
+ libtasn1 4.19.0 hb7f2c08_0 conda-forge/osx-64 119kB
+ libtiff 4.4.0 h5e0c7b4_3 conda-forge/osx-64 618kB
+ libtool 2.4.6 he49afe7_1008 conda-forge/osx-64 528kB
+ libunistring 0.9.10 h0d85af4_0 conda-forge/osx-64 1MB
+ libusb 1.0.26 hc2f2c32_100 conda-forge/osx-64 79kB
+ libvorbis 1.3.7 h046ec9c_0 conda-forge/osx-64 254kB
+ libvpx 1.11.0 he49afe7_3 conda-forge/osx-64 1MB
+ libwebp 1.2.4 hfa4350a_0 conda-forge/osx-64 86kB
+ libwebp-base 1.2.4 h775f41a_0 conda-forge/osx-64 394kB
+ libxcb 1.13 h0d85af4_1004 conda-forge/osx-64 312kB
+ libzip 1.9.2 h3ad4413_1 conda-forge/osx-64 120kB
+ llvm-openmp 14.0.4 ha654fa7_0 conda-forge/osx-64 337kB
+ mysql-common 8.0.30 h7ebae80_1 conda-forge/osx-64 2MB
+ mysql-libs 8.0.30 hc37e033_1 conda-forge/osx-64 2MB
+ nettle 3.8.1 h96f3785_1 conda-forge/osx-64 548kB
+ nspr 4.32 hcd9eead_1 conda-forge/osx-64 253kB
+ nss 3.78 ha8197d3_0 conda-forge/osx-64 2MB
+ numpy 1.23.2 py310hf910466_0 conda-forge/osx-64 7MB
+ octomap 1.9.7 h940c156_0 conda-forge/osx-64 315kB
+ ogre 1.10.12 hf9dbd05_9 conda-forge/osx-64 121MB
+ openal-soft 1.22.2 h1b54a9f_0 conda-forge/osx-64 548kB
+ openexr 3.1.5 h6fbc5c6_0 conda-forge/osx-64 2MB
+ openh264 2.3.0 hb486fe8_0 conda-forge/osx-64 2MB
+ openjpeg 2.5.0 h5d0d7b0_1 conda-forge/osx-64 516kB
+ p11-kit 0.24.1 h65f8906_0 conda-forge/osx-64 834kB
+ pango 1.50.9 hc8ec20f_0 conda-forge/osx-64 457kB
+ pcre 8.45 he49afe7_0 conda-forge/osx-64 226kB
+ pixman 0.40.0 hbcb3906_0 conda-forge/osx-64 629kB
+ poppler 22.04.0 h101a726_2 conda-forge/osx-64 2MB
+ poppler-data 0.4.11 hd8ed1ab_0 conda-forge/noarch 4MB
+ postgresql 14.5 h6af9f65_0 conda-forge/osx-64 5MB
+ proj 9.0.1 h05f0992_1 conda-forge/osx-64 3MB
+ pthread-stubs 0.4 hc929b4f_1001 conda-forge/osx-64 6kB
+ pugixml 1.11.4 he49afe7_0 conda-forge/osx-64 107kB
+ qt-main 5.15.4 h938c29d_2 conda-forge/osx-64 54MB
+ qwt 6.2.0 h4cc5820_4 conda-forge/osx-64 5MB
+ ruby 3.1.2 h586acb3_0 conda-forge/osx-64 9MB
+ sdl2 2.0.22 hb486fe8_2 conda-forge/osx-64 2MB
+ simbody 3.7 h43072b6_3 conda-forge/osx-64 39MB
+ snappy 1.1.9 h6e38e02_1 conda-forge/osx-64 32kB
+ sqlite 3.39.3 h9ae0607_0 conda-forge/osx-64 896kB
+ svt-av1 1.2.1 hbbd2c75_0 conda-forge/osx-64 3MB
+ swig 4.0.2 hce5123c_2 conda-forge/osx-64 1MB
+ tbb 2021.5.0 hbb4e6a2_1 conda-forge/osx-64 161kB
+ tbb-devel 2021.5.0 hbb4e6a2_1 conda-forge/osx-64 983kB
+ tiledb 2.11.1 h3b7b576_0 conda-forge/osx-64 5MB
+ tinyxml 2.6.2 h65a07b1_2 conda-forge/osx-64 52kB
+ tinyxml2 9.0.0 he49afe7_2 conda-forge/osx-64 108kB
+ tzcode 2022c h775f41a_0 conda-forge/osx-64 69kB
+ urdfdom 3.1.0 hd1da41a_1 conda-forge/osx-64 117kB
+ urdfdom_headers 1.1.0 h1b54a9f_0 conda-forge/osx-64 19kB
+ x264 1!164.3095 h775f41a_2 conda-forge/osx-64 937kB
+ x265 3.5 hbb4e6a2_3 conda-forge/osx-64 3MB
+ xerces-c 3.2.3 hf5b2a72_5 conda-forge/osx-64 2MB
+ xorg-fixesproto 5.0 h0d85af4_1002 conda-forge/osx-64 9kB
+ xorg-kbproto 1.0.7 h35c211d_1002 conda-forge/osx-64 27kB
+ xorg-libice 1.0.10 h0d85af4_0 conda-forge/osx-64 49kB
+ xorg-libsm 1.2.3 h0d85af4_1000 conda-forge/osx-64 23kB
+ xorg-libx11 1.7.2 h0d85af4_0 conda-forge/osx-64 907kB
+ xorg-libxau 1.0.9 h35c211d_0 conda-forge/osx-64 11kB
+ xorg-libxaw 1.0.14 h0d85af4_1 conda-forge/osx-64 314kB
+ xorg-libxdmcp 1.1.3 h35c211d_0 conda-forge/osx-64 17kB
+ xorg-libxext 1.3.4 h0d85af4_1 conda-forge/osx-64 44kB
+ xorg-libxfixes 5.0.3 h0d85af4_1004 conda-forge/osx-64 16kB
+ xorg-libxmu 1.1.3 h0d85af4_0 conda-forge/osx-64 70kB
+ xorg-libxpm 3.5.13 h0d85af4_0 conda-forge/osx-64 60kB
+ xorg-libxrender 0.9.10 h0d85af4_1003 conda-forge/osx-64 25kB
+ xorg-libxt 1.2.1 h0d85af4_2 conda-forge/osx-64 207kB
+ xorg-renderproto 0.11.1 h0d85af4_1002 conda-forge/osx-64 10kB
+ xorg-xextproto 7.3.0 h35c211d_1002 conda-forge/osx-64 28kB
+ xorg-xproto 7.0.31 h35c211d_1007 conda-forge/osx-64 75kB
+ zeromq 4.3.4 he49afe7_1 conda-forge/osx-64 321kB
+ zlib 1.2.12 hfe4f2af_2 conda-forge/osx-64 95kB
+ zziplib 0.13.69 h5dbffcc_1 conda-forge/osx-64 84kB
Summary:
Install: 169 packages
Total download: 592MB
─────────────────────────────────────────────────────────────────────────────────────────────
Confirm changes: [Y/n] Y
openal-soft 548.2kB @ 1.4MB/s 0.4s
expat 149.6kB @ 365.2kB/s 0.4s
libdeflate 86.3kB @ 193.8kB/s 0.0s
libusb 79.5kB @ 127.0kB/s 0.6s
libpng 319.2kB @ 509.7kB/s 0.2s
imath 164.8kB @ 170.5kB/s 0.3s
octomap 315.2kB @ 292.5kB/s 0.5s
json-c 72.5kB @ 66.4kB/s 0.1s
curl 150.5kB @ 108.3kB/s 0.3s
eigen 1.3MB @ 893.2kB/s 1.0s
llvm-openmp 336.9kB @ 230.7kB/s 0.4s
libopus 280.0kB @ 159.8kB/s 0.3s
libprotobuf 2.4MB @ 1.2MB/s 1.9s
pugixml 107.1kB @ 54.2kB/s 0.2s
xorg-libxdmcp 17.2kB @ 8.7kB/s 0.1s
sqlite 896.3kB @ 430.7kB/s 0.7s
graphite2 86.6kB @ 39.3kB/s 0.2s
libignition-cmake2 251.6kB @ 113.0kB/s 2.2s
xorg-libice 49.5kB @ 21.7kB/s 0.2s
xorg-xproto 74.8kB @ 29.8kB/s 0.2s
gdbm 134.2kB @ 47.5kB/s 0.3s
lame 533.6kB @ 188.5kB/s 0.6s
openh264 1.6MB @ 431.9kB/s 1.8s
swig 1.2MB @ 274.0kB/s 1.5s
libtiff 618.0kB @ 134.5kB/s 0.8s
assimp 3.2MB @ 505.8kB/s 3.6s
openexr 1.7MB @ 253.2kB/s 2.3s
x265 3.4MB @ 488.6kB/s 4.8s
libdap4 2.3MB @ 317.0kB/s 2.6s
xorg-libsm 23.0kB @ 3.1kB/s 0.2s
libxcb 312.4kB @ 40.8kB/s 0.6s
fontconfig 287.6kB @ 35.5kB/s 0.5s
lcms2 413.9kB @ 46.8kB/s 0.7s
gts 335.1kB @ 35.0kB/s 0.7s
libgfortran 149.7kB @ 15.2kB/s 0.3s
libsdformat 669.8kB @ 62.1kB/s 0.9s
postgresql 5.3MB @ 438.4kB/s 5.5s
gnutls 2.2MB @ 172.9kB/s 2.2s
cfitsio 1.4MB @ 100.4kB/s 1.3s
xorg-libxext 43.7kB @ 3.0kB/s 0.2s
libraw 1.6MB @ 109.7kB/s 2.8s
libblas 13.0kB @ 868.0 B/s 0.1s
libignition-msgs5 838.6kB @ 54.1kB/s 1.0s
libclang13 8.5MB @ 536.3kB/s 9.4s
libignition-transport8 360.4kB @ 22.7kB/s 0.4s
libcblas 12.9kB @ 809.0 B/s 0.1s
ruby 9.0MB @ 486.5kB/s 11.2s
flann 3.0MB @ 148.1kB/s 5.3s
font-ttf-inconsolata 96.5kB @ 4.7kB/s 0.2s
fonts-conda-forge 4.1kB @ 200.0 B/s 0.0s
cairo 1.4MB @ 62.6kB/s 2.2s
poppler 1.8MB @ 71.6kB/s 2.7s
libllvm14 28.1MB @ 828.5kB/s 32.5s
libgdal 9.6MB @ 277.1kB/s 9.3s
libwebp-base 393.8kB @ 11.1kB/s 0.7s
zlib 95.0kB @ 2.6kB/s 0.5s
lerc 290.3kB @ 7.9kB/s 0.5s
jsoncpp 173.4kB @ 4.7kB/s 0.5s
libccd-double 30.9kB @ 830.0 B/s 0.2s
dartsim 15.7MB @ 397.5kB/s 20.9s
tbb 161.0kB @ 4.0kB/s 0.4s
libpq 3.0MB @ 74.6kB/s 3.5s
mysql-common 2.0MB @ 47.4kB/s 2.6s
pthread-stubs 5.7kB @ 132.0 B/s 0.1s
sdl2 1.6MB @ 37.0kB/s 2.1s
librsvg 7.6MB @ 177.0kB/s 9.1s
libtasn1 118.8kB @ 2.8kB/s 0.3s
gmp 792.1kB @ 18.1kB/s 1.1s
xorg-xextproto 28.2kB @ 642.0 B/s 0.2s
libsodium 528.8kB @ 12.0kB/s 0.8s
zziplib 84.3kB @ 1.9kB/s 0.4s
librttopo 222.8kB @ 5.0kB/s 0.4s
hdf4 951.7kB @ 20.9kB/s 1.6s
blosc 48.7kB @ 1.1kB/s 0.2s
urdfdom 117.2kB @ 2.5kB/s 0.5s
aom 3.3MB @ 71.0kB/s 3.6s
libgfortran5 2.0MB @ 41.2kB/s 2.9s
openjpeg 515.5kB @ 10.8kB/s 1.0s
glib-tools 96.7kB @ 2.0kB/s 0.2s
geotiff 131.5kB @ 2.7kB/s 0.3s
gdk-pixbuf 586.4kB @ 12.1kB/s 0.8s
libvorbis 254.2kB @ 5.2kB/s 2.2s
xorg-libxfixes 15.5kB @ 317.0 B/s 0.4s
xorg-libxpm 59.9kB @ 1.2kB/s 0.4s
liblapack 12.9kB @ 261.0 B/s 0.1s
gstreamer 1.9MB @ 38.0kB/s 2.4s
libopenblas 10.1MB @ 166.6kB/s 12.4s
font-ttf-source-code-pro 700.8kB @ 11.3kB/s 1.6s
qt-main 54.3MB @ 698.8kB/s 1m:1.9s
ffmpeg 11.1MB @ 137.9kB/s 18.4s
harfbuzz 2.4MB @ 29.5kB/s 3.1s
pcre 225.6kB @ 2.8kB/s 0.5s
jpeg 266.7kB @ 3.3kB/s 0.4s
libzip 119.7kB @ 1.5kB/s 0.3s
geos 1.4MB @ 17.1kB/s 2.1s
console_bridge 17.5kB @ 208.0 B/s 0.1s
tzcode 68.7kB @ 812.0 B/s 0.4s
xorg-libxau 11.4kB @ 133.0 B/s 0.7s
nettle 547.9kB @ 6.4kB/s 1.0s
simbody 39.2MB @ 448.1kB/s 38.1s
xorg-renderproto 9.6kB @ 110.0 B/s 0.2s
libkml 494.3kB @ 5.6kB/s 0.8s
libvpx 1.5MB @ 16.9kB/s 2.2s
gtk2 7.4MB @ 83.2kB/s 8.8s
libignition-math6 1.2MB @ 13.7kB/s 1.8s
p11-kit 834.5kB @ 9.2kB/s 1.1s
libidn2 172.8kB @ 1.9kB/s 0.4s
cppzmq 26.2kB @ 288.0 B/s 0.2s
atk-1.0 367.7kB @ 4.0kB/s 0.5s
xorg-libxrender 25.0kB @ 273.0 B/s 0.2s
glib 441.1kB @ 4.8kB/s 0.5s
mysql-libs 2.0MB @ 22.1kB/s 3.2s
kealib 168.6kB @ 1.8kB/s 0.5s
fcl 1.5MB @ 16.3kB/s 1.4s
libignition-common3 555.8kB @ 6.0kB/s 0.6s
poppler-data 3.8MB @ 39.7kB/s 4.4s
pixman 629.3kB @ 6.5kB/s 0.8s
qwt 4.6MB @ 47.2kB/s 5.4s
libtar 40.5kB @ 416.0 B/s 0.3s
snappy 32.0kB @ 328.0 B/s 0.1s
libtool 528.5kB @ 5.4kB/s 0.7s
bullet-cpp 42.8MB @ 435.6kB/s 47.4s
x264 937.1kB @ 9.5kB/s 1.0s
libunistring 1.4MB @ 13.9kB/s 2.2s
libode 484.5kB @ 4.8kB/s 1.1s
svt-av1 3.5MB @ 33.7kB/s 4.9s
graphviz 8.0MB @ 77.3kB/s 10.0s
xorg-libx11 907.1kB @ 8.8kB/s 1.2s
tiledb 4.6MB @ 44.3kB/s 5.8s
xorg-libxaw 314.2kB @ 3.0kB/s 0.5s
proj 2.9MB @ 27.7kB/s 3.7s
libnetcdf 1.4MB @ 13.2kB/s 1.9s
libignition-fuel-tools4 234.6kB @ 2.2kB/s 0.5s
freexl 42.6kB @ 401.0 B/s 0.2s
font-ttf-ubuntu 2.0MB @ 18.5kB/s 1.4s
tinyxml 52.0kB @ 488.0 B/s 0.2s
nspr 252.9kB @ 2.4kB/s 0.5s
libogg 207.3kB @ 1.9kB/s 0.4s
xorg-fixesproto 9.1kB @ 85.0 B/s 0.1s
libignition-tools1 34.4kB @ 321.0 B/s 0.1s
tbb-devel 983.4kB @ 9.1kB/s 1.0s
hdf5 3.9MB @ 35.9kB/s 4.4s
fonts-conda-ecosystem 3.7kB @ 34.0 B/s 0.0s
freeimage 470.0kB @ 4.4kB/s 0.8s
urdfdom_headers 18.5kB @ 171.0 B/s 0.1s
jxrlib 231.0kB @ 2.1kB/s 0.5s
gettext 3.4MB @ 30.6kB/s 4.0s
libwebp 86.5kB @ 773.0 B/s 0.2s
xorg-libxt 207.3kB @ 1.8kB/s 0.4s
font-ttf-dejavu-sans-mono 397.4kB @ 3.5kB/s 0.5s
numpy 7.0MB @ 61.7kB/s 6.4s
fribidi 65.4kB @ 572.0 B/s 0.2s
libglib 3.0MB @ 26.4kB/s 6.3s
freetype 936.9kB @ 8.1kB/s 0.9s
libclang 130.2kB @ 1.1kB/s 1.5s
tinyxml2 108.4kB @ 928.0 B/s 0.4s
xorg-kbproto 27.4kB @ 234.0 B/s 0.2s
gst-plugins-base 2.6MB @ 22.0kB/s 2.5s
pango 456.5kB @ 3.9kB/s 0.7s
nss 2.1MB @ 17.6kB/s 3.4s
libgd 245.2kB @ 2.0kB/s 0.6s
zeromq 320.8kB @ 2.6kB/s 0.7s
giflib 72.9kB @ 592.0 B/s 0.2s
boost-cpp 16.3MB @ 132.4kB/s 17.8s
xorg-libxmu 70.5kB @ 571.0 B/s 0.2s
libspatialite 4.4MB @ 35.8kB/s 6.6s
xerces-c 1.5MB @ 12.3kB/s 1.4s
ogre 120.7MB @ 890.1kB/s 1m:59.7s
gazebo 64.4MB @ 447.8kB/s 31.0s
Preparing transaction: done
Verifying transaction: done
Executing transaction: \ objc[39523]: Class GNotificationCenterDelegate is implemented in both /Users/nunoguedelha/miniforge3/envs/robotologybin/lib/libgio-2.0.0.dylib (0x103bc1bc0) and /usr/local/opt/glib/lib/libgio-2.0.0.dylib (0x104109330). One of the two will be used. Which one is undefined.
- objc[39594]: Class GNotificationCenterDelegate is implemented in both /Users/nunoguedelha/miniforge3/envs/robotologybin/lib/libgio-2.0.0.dylib (0x1065a9bc0) and /usr/local/opt/glib/lib/libgio-2.0.0.dylib (0x106aeb330). One of the two will be used. Which one is undefined.
done
(robotologybin) nunoguedelha@iiticublap199 ~
$
(robotologybin) nunoguedelha@iiticublap199 ~
$ conda list gazebo
# packages in environment at /Users/nunoguedelha/miniforge3/envs/robotologybin:
#
# Name Version Build Channel
gazebo 11.11.0 ha646a65_12 conda-forgebut it doesn't seem to be related to my issue.
updating conda to 4.14.0 (although you mentioned it shouldn't matter in this case, but maybe same base package was causing a conflict and resulting in a crash of Gazebo)
In theory no package in the base environment should be used by Gazebo . Anyhow, perhaps something strange was going on.
Are you able to run models by spawning an existing world?
Are you able to run models by spawning an existing world?
As discussed in Teams, yes I can, but I can't add other models from the GUI. As @traversaro noticed, it seems that the client is not connected to the server. refer to conda-forge/gazebo-feedstock#148 submitted by @traversaro .
As this issue prevents running Gazebo ≥ 11.10.1, and installing/running Gazebo < 11.10.1 prevents running the gazebo-yarp-plugins and yarp versions required for getting the proper handling of the YARP_LOG_PROCESS_LABEL variable, I'm proceeding without it for now.
As this issue prevents running Gazebo ≥ 11.10.1, and installing/running Gazebo < 11.10.1 prevents running the
gazebo-yarp-pluginsandyarpversions required for getting the proper handling of theYARP_LOG_PROCESS_LABELvariable, I'm proceeding without it for now.
A possible alternative is to compile yarp and gazebo-yarp-plugins from source with gazebo 11.9, right? Anyhow, if it is not worth the trouble no problem.
Indeed, but I wanted to avoid building from source to make it quicker 😄 , at the end it was worse.. well, I'll give a shot to building from source.
Side note: it would be interesting to build Gazebo from source, installing the dependencies through Conda. This requires significant effort rewriting the CMake files.
Side note: it would be interesting to build Gazebo from source, installing the dependencies through Conda. This requires significant effort rewriting the CMake files.
I actually did this, I do not think there is any modification required in CMake files, see conda-forge/gazebo-feedstock#148 (comment) .
Awesome, thanks @traversaro ! I wasn't aware of this.
CC @S-Dafarra
well, I'll give a shot to building from source.
I built the superbuild from source and installed Gazebo 11.9.1 on the same conda environment.
I ran Gazebo and as soon as I insert an iCub model, I get this protobuf error:
[libprotobuf ERROR google/protobuf/descriptor_database.cc:559] Invalid file descriptor data passed to EncodedDescriptorDatabase::Add().
[libprotobuf FATAL google/protobuf/descriptor.cc:1357] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):
libc++abi.dylib: terminating with uncaught exception of type google::protobuf::FatalException: CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):I'll open an issue on the superbuild repo.
I'll open an issue on the superbuild repo.
Moving on...
Implementation Steps
I list below the steps for getting the Yarprobotinterface and WalkingController modules logging output on the OpenMCT visualizer.
First Working Version: no auto search for the ports streaming the Yarp text logging
In a first step we focus on the data parsing and sending to the visualizer, the dictionary definition and the actual data visualisation in the OpenMCT framework. For this purpose, the port names are fully defined in the configuration file servers.js, and edited every time the processes logging the data (yarprobotinterface, WalkingModule) are stopped and run again.
In the configuration file:
- Add the Yarprobotinterface and WalkingController logging ports to the port configuration.
On the telemetry server:
- Add the Yarp Text Logging to the
statebuffer. - Add the parsing of the data to the main parser.
On OpenMCT framework:
- Add a new folder "Modules process output logging".
- Add to the folder the two new entries related to the Yarprobotinterface and WalkingController processes.
- Add the respective dictionary and set the appropriate data type and format.
- Use plugin "Telemetry Table" to display the log data.
-
Set eventually the canvas form to display the message details right below the table, and synchronised with the message selected in the table.=> this would be a nice to have, but not critical right now, since we have already a pop-up window when we point a given datum, and we have a "view full datum" option.
Improved Version: auto search for ports streaming the logged data
In the configuration file:
- Replace the full port names by the Yarprobotinterface and WalkingController process labels.
On the telemetry server:
- Connect the Yarp text logging ports as soon as a subscription is received from the OpenMCT client:
- Get the list of Yarp ports
- Select the ports matching the process labels set in the main configuration.
- Open the ports and connect.
On the telemetry server:
Connect the Yarp text logging ports as soon as a subscription is received from the OpenMCT client:
- Get the list of Yarp ports
- Select the ports matching the process labels set in the main configuration.
- Open the ports and connect.
I've worked on the design of this part, but it needs further analysis/improvement. I've decided to manually add the YARP ports in the config file for now and proceed with the development steps (parsing, dictionary & OpenMCT changes, etc).
Updated the Implementation Steps.
Testing First Working Version
- The new folder is added.
- The dictionary is properly requested and received upon clicking on an entry within the folder.
- No data sample is received on the OpenMCT client. Apparently the subscription is not sent when we click on a telemetry domain object (
yarprobotinterfaceorWalkingModule).
(we are not breaking nor on the supportsSubscribe nor subscribe methods.
Analysing...
Vue.js debugging
I've checked the Vue.js components bound to the telemetry domain objects, and compared a working case with the failing case, e.g. comparing yarpopenmct.icubtelemetry:sens.legacyIMU to yarpopenmct.processLogging:yarplogger.yarpRobotInterface:
yarpopenmct.icubtelemetry:sens.legacyIMU
yarpopenmct.processLogging:yarplogger.yarpRobotInterface
domainObject.telemetry.values hasn't been evaluated (expanded), we still see the unexpanded string ${JSON.stringify(this.presetValuesBase.yarpLoggerMessage)}.
This is because the dictionary file was retrieved through an http request, and no route function was added through app.get on the server side to "evaluate" the file (evaluate template literals through evalTemplateLiteralInJSON) prior sending it.
After fixing this issue, clicking on the domain object "yarprobotinterface process logging through yarplogger" triggers a subscription and the logging data stream is established. We can see the data displayed in the canvas, in the "telemetry table" view:
After creating a "Telemetry Table" domain object in "My Items", dragging into it the "yarprobotinterface process logging through yarplogger" and arranging the table to display the more relevant data, we get:
Next step is to display messages only when they are received from the Yarp port, instead of repeating the last received message.
Next step is to display messages only when they are received from the Yarp port, instead of repeating the last received message.
=> completed in commit 126edf9.
(adding details shortly)
Work now on the automatic port detection.
Additional config option: Telemetry server sends only last received Yarp messages
We added a sourceSync parameter to the portInConfig port configuration portInConfig, with two possible values, localTimer or yarpPort.
yarp-openmct/conf/servers.json
Lines 368 to 377 in 126edf9
localTimer
This was the default setting so far for which a notifierTask is triggered by a local timer every 10 ms and calls generateTelemetry which generates and sends the telemetry samples. The task used to send the samples for all the telemetry IDs in the ICubTelemetry.state buffer.
Change => The task sends the samples of the IDs scheduled for sending in ICubTelemetry.telemetryIDsToSend. Upon a call of the "read" listener, the Yarp message is parsed and the respective ID scheduled for sending.
yarp-openmct/iCubTelemVizServer/iCubTelemVizServer.js
Lines 87 to 89 in 126edf9
=>
=>
yarp-openmct/iCubTelemVizServer/icubtelemetry.js
Lines 148 to 151 in 126edf9
...
yarp-openmct/iCubTelemVizServer/icubtelemetry.js
Lines 180 to 186 in 126edf9
yarpPort
The notifierTask is not used. Upon the call of the "read" listener, the Yarp message is parsed and the respective ID is directly sent.
yarp-openmct/iCubTelemVizServer/icubtelemetry.js
Lines 153 to 156 in 126edf9
Improved Version: auto search for ports streaming the logged data
In the configuration file
- We replace the full port names by a syntax1 which is then evaluated by the telemetry server as a regular expression for matching existing Yarp ports. The user can integrate in the regexp the
YARP_LOG_PROCESS_LABELof his choice for matching the ports streaming the logging data fromyarprobotinterfaceandWalkingModulemodules.
On the telemetry server
(Re)connect the Yarp text logging ports as soon as the client page is refreshed (servers.json config is reloaded)
Trigger the operation in the config fileservers.jsonroute function.- Evaluate the template literals in the whole file.
- Build a list of all the port names integrating a regexp:
<regexp-port-names-list>. - If
<regexp-port-names-list>is empty, return, otherwise continue. - Run a full scan of the existing Yarp ports =>
<yarp-ports-list>. - For each port found in
<regexp-port-names-list>, get the Yarp port name from<yarp-ports-list>matching the regexp pattern =><matched-yarp-remote-ports-list>. - For each port in
<matched-yarp-remote-ports-list>:-
Check if the respectiveWe consider that these didn't change, otherwise just restart the telemetry server.<yarpjs-local-port>port exists => if not, create it. - Connect
<yarp-remote-port>to<yarpjs-local-port>(if the connection already exists, this step does nothing).
-
- Trigger the regexp ports reconnection in the config file
servers.jsonroute function (nice-to-have)
Footnotes
-
The syntax is as follows: the pattern
"@{...}"wraps a regular expression which, once unwrapped, can be directly interpreted by the Javascript code. ↩
[ ] Trigger the regexp ports reconnection in the config file
servers.jsonroute function (nice-to-have)
@S-Dafarra , this is very useful, but not a blocker. Without this you have to restart the server if the remote yarp text logging ports are closed and opened again (with different PIDs).
You can already perform some tests the development branch feature/ami138-visualise-yarptextlogging.
Work completed.