Create a logging tool using matio

[S-Dafarra]

I would like to have a logging library in the framework. I would need to log some rotation matrices from the MasImuTest I am currently developing. As far as I know, both @GiulioRomualdi, @prashanthr05 and @kouroshD developed a logger for different purposes. It would be better to unify these tools in a single library in this repo. Ideally, we should be able to save data to a mat file.

Any idea?

[traversaro]

I would separate "logging vector/matrix data" and "logging text". I guess this issue is about the first, and not about the second. MatLogger2 is nice, but probably would require some work to be supported on Windows (and macOS?) and there is still the licensing issue (see ADVRHumanoids/MatLogger2#3). I can ping the MatLogger2's dev on the license issue that is I am afraid the more critical, but if we want to move fast at least initially rolling out our own simple solution (perhaps using existing libraries for the actual dumping of data to files such as matio/Eigen-matio or something for csv) may be the way to go.

[S-Dafarra]

I would separate "logging vector/matrix data" and "logging text". I guess this issue is about the first, and not about the second.

Yes, I was not precise. It is about logging data.

MatLogger2 is nice, but probably would require some work to be supported on Windows (and macOS?) and there is still the licensing issue (see ADVRHumanoids/MatLogger2#3). I can ping the MatLogger2's dev on the license issue that is I am afraid the more critical, but if we want to move fast at least initially rolling out our own simple solution (perhaps using existing libraries for the actual dumping of data to files such as matio/Eigen-matio or something for csv) may be the way to go.

Ok, if MatLogger2 is a problem, then matio/Eigen-matio can be an option. As far as I can see, Eigen-matio seems to be pretty simple and a good example from which to start. At this point then, if we create a clean interface toward matio, does it make sense to incorporate it in the framework or it would be better to keep it as a separate repo?

[GiulioRomualdi]

Back in time, I developed a frontend for using MatLogger with yarp ports https://github.com/GiulioRomualdi/YarpMatLogger.
As regards eigen-matio I also implemented this simple cmake machinery to simplify the usage with other libraries/applications GiulioRomualdi/eigen-matio@5623ca4 (e.g. find_package() stuff)

[S-Dafarra]

Back in time, I developed a frontend for using MatLogger with yarp ports https://github.com/GiulioRomualdi/YarpMatLogger.
As regards eigen-matio I also implemented this simple cmake machinery to simplify the usage with other libraries/applications GiulioRomualdi/eigen-matio@5623ca4 (e.g. find_package() stuff)

For the time being, I would avoid being bound to Yarp. In addition, as mentioned above MatLogger2 is not an easy dependency.

The interface to matio is definitely interesting. As @GiulioRomualdi and @traversaro know already, it seems that CMake support in matio is a little complicated (tbeu/matio#53 and tbeu/matio#107), hence

I also implemented this simple cmake machinery to simplify the usage with other libraries/applications GiulioRomualdi/eigen-matio@5623ca4 (e.g. find_package() stuff)

is tempting. But then, how do we proceed. We keep working on https://github.com/GiulioRomualdi/eigen-matio/tree/install_package or we move this somewhere else as we did for osqp-eigen? A third option may also to move this interface in the framework. What would you prefer?

[GiulioRomualdi]

As @GiulioRomualdi and @traversaro know already, it seems that CMake support in matio is a little complicated

Actually matio can be installed with apt-get on ubuntu, with brew on macOS and on windows with vcpkg.
For eigen-matio I think it's a different story

But then, how do we proceed. We keep working on https://github.com/GiulioRomualdi/eigen-matio/tree/install_package or we move this somewhere else as we did for osqp-eigen? A third option may also to move this interface in the framework. What would you prefer?

I think we can move it in dic organization. By the way I don't know if it is still working 😃

[S-Dafarra]

As @GiulioRomualdi and @traversaro know already, it seems that CMake support in matio is a little complicated

Actually matio can be installed with apt-get on ubuntu, with brew on macOS and on windows with vcpkg.
For eigen-matio I think it's a different story

Ah, that's another story 😁 Thanks for pointing out. Probably, at this stage, given that this may be useful for projects outside the bipedal locomotion scope, it may make sense to open a separate repository using what we have as a starting point. Later on, we can think of some cool features to add.

[prashanthr05]

In the past, I tried using matio by installing from apt in a very naive and minimal implementation https://github.com/dic-iit/element_floating-base-estimation/blob/humest/benchmark/estimators/code/benchmark/base-estimator/include/MatHandler.hpp

However, https://github.com/GiulioRomualdi/eigen-matio/tree/install_package seems nice.

[S-Dafarra]

In the past, I tried using matio by installing from apt in a very naive and minimal implementation https://github.com/dic-iit/element_floating-base-estimation/blob/humest/benchmark/estimators/code/benchmark/base-estimator/include/MatHandler.hpp

However, https://github.com/GiulioRomualdi/eigen-matio/tree/install_package seems nice.

I used matio too back in time. As far as I remember, the problems were mainly related to the fact that memory is dealt in C style and you have to free variables manually, plus the documentation is not the best. Indeed, I was thinking of using/creating something that could hide the matio complexity.

[prashanthr05]

I used matio too back in time. As far as I remember, the problems were mainly related to the fact that memory is dealt in C style and you have to free variables manually, plus the documentation is not the best.

I agree. It becomes a bit cumbersome to use the library directly. Also, readability (motivation to read code) reduces with that kind of complexity :D

[S-Dafarra]

I forked https://github.com/GiulioRomualdi/eigen-matio/tree/install_package to https://github.com/dic-iit/eigen-matio

[S-Dafarra]

After working a little bit on https://github.com/dic-iit/eigen-matio/tree/initial_refactory I quickly realized that the refactory was touching most of the available code. Since:

• eigen-matio is basically a single header file and a CMakelists.txt
• I basically started changing more than half of the code,
• It does not support vector of matrices or structs,

I decided to start a new project defining a c++ interface to matio. It is still a WIP. The code is available at https://github.com/dic-iit/matio-cpp

[GiulioRomualdi]

I decided to start a new project defining a c++ interface to matio. It is still a WIP. The code is available at https://github.com/dic-iit/matio-cpp

I think that the code is private. I don't have the access for it

[S-Dafarra]

I decided to start a new project defining a c++ interface to matio. It is still a WIP. The code is available at https://github.com/dic-iit/matio-cpp

I think that the code is private. I don't have the access for it

I decided to keep it private before it is finished, but I should grant you access. Let me fix it.

[S-Dafarra]

I decided to start a new project defining a c++ interface to matio. It is still a WIP. The code is available at https://github.com/dic-iit/matio-cpp

I think that the code is private. I don't have the access for it

I should have granted you access. In any case, I am working on the branch https://github.com/dic-iit/matio-cpp/tree/firstVersion.

I will open a PR when I am going to have something useful.

[S-Dafarra]

The first PR is ami-iit/matio-cpp#1. It is still a WIP, but I thought it was starting to be something worth reviewing.

[S-Dafarra]

The first PR got merged. Working on a follow-up.

[S-Dafarra]

I opened a second PR: ami-iit/matio-cpp#7. This one deals with multidimensional arrays.

[S-Dafarra]

Here the third PR: ami-iit/matio-cpp#8. This was a necessary step to handle matio pointers correctly when using files, structs, or cell arrays.

[DanielePucci]

CC @dic-iit/dynamic-interaction-control

[S-Dafarra]

The almost-final version is in the improvements branch. I have more or less implemented all the features I wanted:

• handling of files
• handling of elements, vectors, and arrays
• handling of cell arrays
• handling of structs and struct arrays.

At the moment, several PRs are on the line. One is open (ami-iit/matio-cpp#15), other 3 are waiting. I think we can close this issue in the meantime.