Add the possibility to log the YarpTextLogging

nunoguedelha commented 2 years ago

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.

cc @GiulioRomualdi

Originally posted by @S-Dafarra in https://github.com/ami-iit/yarp-openmct/issues/121#issuecomment-1180685833

For the TextLogging I took inspiration from what is done in YarpManager. https://github.com/ami-iit/bipedal-locomotion-framework/pull/546

Originally posted by @GiulioRomualdi in https://github.com/ami-iit/yarp-openmct/issues/121#issuecomment-1182455351

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 https://github.com/ami-iit/bipedal-locomotion-framework/pull/541.

Originally posted by @nunoguedelha in https://github.com/ami-iit/yarp-openmct/issues/121#issuecomment-1235252330

For the development, we relate to the analysis done in https://github.com/ami-iit/bipedal-locomotion-framework/pull/540 .

nunoguedelha commented 2 years ago

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 printf or std::cout methods 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 --log option), 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_LABEL to 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_LABEL can be easily set for each individual process, via [yarpmanager](@ref yarpmanager), using the environment section.

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 the YARP_FORWARD_LOG_ENABLE environment variable to 1. Please note that, while [yarprun](@ref yarprun) is able to forward all the output of the application (including printf and std::out output), 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_ENABLE

YARP_FORWARD_HOSTNAME_ENABLE

YARP_FORWARD_PROCESSINFO_ENABLE

YARP_FORWARD_BACKTRACE_ENABLE

Please note that yarp::os internal 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_WholeBodyDynamics at 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.xml
```
YARP_LOG_PROCESS_LABEL=YarpJS_WalkingModule at 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
```

nunoguedelha commented 2 years ago

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.

nunoguedelha commented 2 years ago

@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 insert tab on the left pane
select the Arm Part model (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.

nunoguedelha commented 2 years ago

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.

done

full log

```bash + 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-forge ```

but it doesn't seem to be related to my issue.

traversaro commented 2 years ago

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.

traversaro commented 2 years ago

Are you able to run models by spawning an existing world?

nunoguedelha commented 2 years ago

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 https://github.com/conda-forge/gazebo-feedstock/issues/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.

traversaro commented 2 years ago

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.

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.

nunoguedelha commented 2 years ago

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.

nunoguedelha commented 2 years ago

Side note: it would be interesting to build Gazebo from source, installing the dependencies through Conda. This requires significant effort rewriting the CMake files.

traversaro commented 2 years ago

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 https://github.com/conda-forge/gazebo-feedstock/issues/148#issuecomment-1240321643 .

nunoguedelha commented 2 years ago

Awesome, thanks @traversaro ! I wasn't aware of this.

CC @S-Dafarra

nunoguedelha commented 2 years ago

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.

nunoguedelha commented 2 years ago

I'll open an issue on the superbuild repo.

https://github.com/robotology/robotology-superbuild/issues/1253

nunoguedelha commented 2 years ago

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:

[x] Add the Yarprobotinterface and WalkingController logging ports to the port configuration.

On the telemetry server:

[x] Add the Yarp Text Logging to the state buffer.
[x] Add the parsing of the data to the main parser.

On OpenMCT framework:

[x] Add a new folder "Modules process output logging".
[x] Add to the folder the two new entries related to the Yarprobotinterface and WalkingController processes.
[x] Add the respective dictionary and set the appropriate data type and format.
[x] Use plugin "Telemetry Table" to display the log data.
[x] ~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:

[x] 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.

nunoguedelha commented 2 years ago

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).

nunoguedelha commented 2 years ago

Updated the Implementation Steps.

nunoguedelha commented 2 years ago

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 (yarprobotinterface or WalkingModule).

(we are not breaking nor on the supportsSubscribe nor subscribe methods.

Analysing...

nunoguedelha commented 2 years ago

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.

nunoguedelha commented 2 years ago

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 126edf941d1448ba552ce3820859a1df3242c69b. (adding details shortly)

Work now on the automatic port detection.

nunoguedelha commented 2 years ago

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.

https://github.com/ami-iit/yarp-openmct/blob/126edf941d1448ba552ce3820859a1df3242c69b/conf/servers.json#L368-L377

`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.

https://github.com/ami-iit/yarp-openmct/blob/126edf941d1448ba552ce3820859a1df3242c69b/iCubTelemVizServer/iCubTelemVizServer.js#L87-L89 => https://github.com/ami-iit/yarp-openmct/blob/126edf941d1448ba552ce3820859a1df3242c69b/iCubTelemVizServer/icubtelemetry.js#L161 => https://github.com/ami-iit/yarp-openmct/blob/126edf941d1448ba552ce3820859a1df3242c69b/iCubTelemVizServer/icubtelemetry.js#L148-L151

...

https://github.com/ami-iit/yarp-openmct/blob/126edf941d1448ba552ce3820859a1df3242c69b/iCubTelemVizServer/icubtelemetry.js#L180-L186

`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.

https://github.com/ami-iit/yarp-openmct/blob/126edf941d1448ba552ce3820859a1df3242c69b/iCubTelemVizServer/icubtelemetry.js#L153-L156

nunoguedelha commented 2 years ago

Improved Version: auto search for ports streaming the logged data

In the configuration file

[x] We replace the full port names by a syntax[^*] 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_LABEL of his choice for matching the ports streaming the logging data fromyarprobotinterface and WalkingModule modules.

[^*]: The syntax is as follows: the pattern "@{...}" wraps a regular expression which, once unwrapped, can be directly interpreted by the Javascript code.

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 file servers.json route function.~
[x] Evaluate the template literals in the whole file.
[x] Build a list of all the port names integrating a regexp: <regexp-port-names-list>.
[x] If <regexp-port-names-list> is empty, return, otherwise continue.
[x] Run a full scan of the existing Yarp ports => <yarp-ports-list>.
[x] 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>.
[x] For each port in <matched-yarp-remote-ports-list>:
- [x] ~Check if the respective <yarpjs-local-port> port exists => if not, create it.~ We consider that these didn't change, otherwise just restart the telemetry server.
- [x] Connect <yarp-remote-port> to <yarpjs-local-port> (if the connection already exists, this step does nothing).
[x] Trigger the regexp ports reconnection in the config file servers.json route function (nice-to-have)

nunoguedelha commented 2 years ago

[ ] Trigger the regexp ports reconnection in the config file servers.json route 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.

nunoguedelha commented 2 years ago

Work completed.

ami-iit / yarp-openmct

Add the possibility to log the YarpTextLogging #138

Using `yarp_logging`