Handle metadata refresh in real time mode

[xela-95]

Closes #103

Real-time signal provider improvements:

• Introduced a ROBOT_REALTIME_KEY constant and refactored all hardcoded "robot_realtime" string usages in realtime_signal_provider.py to use this constant.
• Added a new update_metadata method to RealtimeSignalProvider to allow refreshing metadata from the remote logger and dynamically updating internal data buffers and metadata.
• Improved _populate_realtime_logger_metadata to be more robust: now only missing nodes are created, leaf buffers are initialized if missing, and metadata merging is handled without overwriting existing data. Added input validation for parameters.
• Added a guard clause in _update_data_buffer to return early if no keys are provided, preventing unnecessary processing.

UI enhancements:

• Updated the autogenerated UI (visualizer.py) to add a new "refresh" button for metadata.

[xela-95]

After a meeting with @GiulioRomualdi @HosameldinMohamed and the issues with the installation of pyside2 documented in #108 I switched the dependencies back to use pyqt5 (always through the qtpy interface, so that it will be easy to switch to another backend. Now the branch is rebased on main and ready for review :)

[xela-95]

Hi @GiulioRomualdi have you had the chance to review this? Are there changes you recommend?

[xela-95]

With @S-Dafarra @carloscp3009 we tested this PR branch (with the corresponding logger version in ami-iit/bipedal-locomotion-framework#1008 ) on ergocub and also ran the walking module. The visualizer worked as expected.

We were able to:

• stream data in real time
• refresh the list of signals with exogenous signals launched after the logger and visualizer started (like the walking module data)
• visualize the rendering of the robot with the realtime pose and orientation.

Moreover we tested that the MAT file saved by the logger contained all the data visualized in real-time, including the cameras.

There also some minor improvements to do here:

• when the logger is stopped before the visualizer, it happens that the latter remains stuck, so maybe there's some thread stuck of nullptr not handled correctly. The desired behavior is that if the connection is lost the latest data remain visualized and the UI is responsive;
• as @S-Dafarra suggested, I could improve the logic of the refresh button, in order to change its state (button color or blinking) to signal to the user that there are new signals to be visualized (while now is always enabled in realtime mode and if there are no new signals the buttons doesn't produce any side effect).

[xela-95]

• as @S-Dafarra suggested, I could improve the logic of the refresh button, in order to change its state (button color or blinking) to signal to the user that there are new signals to be visualized (while now is always enabled in realtime mode and if there are no new signals the buttons doesn't produce any side effect).

In commit 70fa4ef I introduced this functionality! As you can see the refresh button blinks only when new metadata is available (flag that has been added in sister PR of blf without doing any rpc call to the server. In this way the user knows when new signals are available and can refresh the list, otherwise is disabled.

2025-11-13.15-39-30.mp4

[xela-95]

• when the logger is stopped before the visualizer, it happens that the latter remains stuck, so maybe there's some thread stuck of nullptr not handled correctly. The desired behavior is that if the connection is lost the latest data remain visualized and the UI is responsive;

Addressed with 501752c

[xela-95]

CC @traversaro

[xela-95]

I noticed that I missed to add some python bindings in blf, fixing it in ami-iit/bipedal-locomotion-framework#1017

[GiulioRomualdi]

That's great!! Thank you @xela-95 for all the effort!