logger.hh and robot-utils

[olivier-stasse]

Dear all, We are planning to move logger.hh to dynamic-graph and robot-utils to sot-core. Are you ok with this ? Best, Olivier.

[jviereck]

The current robots-utils API assumes a humanoid robot (like ForceUtils::get_force_id_left_hand 1). When going to other robots (manipulators, quadrupeds, quadrupeds with manipulators) these assumptions don't hold anymore.

Having a central class to hold robot information in sot-core sounds good (and therefore move something like robot-utils etc. to sot-core). At the same time it would be great to keep the implementation general to work on different robot setups where it makes sense.

[olivier-stasse]

Thanks for the feedback. I agree with your remark. The idea is to go in this direction. robot-utils will act as a parameter server.

In the same line, logger as it is has some shortcomings:

• The behavior of Logger in terms of level of verbosity depends on the compilation variable used to compile Logger.cpp
• Some users would like to change this level on line.
• It would be useful to modify it entity by entity.
• It would be nice to stream it on something else than std::cout
• It would be preferable to have it explicitely in a non real time thread.

We will propose some changes to reflect this while minimizing the impact on the code using it.

[andreadelprete]

Hi @olivier-stasse

nice stuff, below a few comments

* The behavior of Logger in terms of level of verbosity depends on the compilation variable used to compile Logger.cpp

This was a design choice that I made for a specific reason. The user can insert extra-computations for DEBUG prints that could slow down the control loop. Then by changing the verbosity level from DEBUG to WARNING would automatically avoid computing these things. This wouldn't be the case without compilation variables.

* Some users would like to change this level on line.

* It would be useful to modify it entity by entity.

* It would be nice to stream it on something else than std::cout

* It would be preferable to have it _explicitely_ in a non real time thread.

We will propose some changes to reflect this while minimizing the impact on the code using it.

All other points are valid for me, especially streaming on a different stream.

[jviereck]

robot-utils will act as a parameter server.

Sounds good. I've implemented a "tsid_controller" 1, which works with arbitrary number of contact points, in my specific case for a quadruped robot. The code is not using the robot-utils right now because it was not suiteable for the robot I want to model.

Maybe this usecase can be useful for thinking about which parameters to provide in a new iterations of robot-utils.

[olivier-stasse]

@jviereck sounds good. We will try first to test the current iteration then we will add the parameters that you feel are needed. @andreadelprete There was already a sotDEBUG system using integer as a level of output, and based on preprocessing options. Obviously it was not sufficient to help you debug, and something very similar to your interface was asked by @jmirabel but at runtime. Therefore I suggest that we use the sendMsg interface for real-time debugging and possibly expand it to have it working with rqt_console. If this impact too much the performance (and once the entity works) we can simply remove it from the code.

[olivier-stasse]

Fixed by commit af35eb2b4403747e7086ade1987201db76c8181a