search

robotology / gazebo-fmi

FMI import plugins for the Gazebo Simulator.
GNU Lesser General Public License v3.0
23 stars 5 forks source link

Logging #33

Closed triccyx closed 5 years ago

triccyx commented 5 years ago

Logging success in load actuator.

traversaro commented 5 years ago

I check a bit the Gazebo's upstream plugin at https://bitbucket.org/osrf/gazebo/src/default/plugins/ , and none of them actually print non-warning or non-error messages. Given that this is useful to debug but may be confusing if you have a model with a lot of actuators, can you add an (optional) verbosity option to the SDF to control the printing of this diagnostic messages?

triccyx commented 5 years ago

<... but may be confusing ...> not agree with this, but I will uniform the code to others plugins and I will add a logging flag to SDF. We can use this also for other purposes (ie. logging input and output for debug reason)

traversaro commented 5 years ago

<... but may be confusing ...> not agree with this

Have you ever saw the output of gazebo_yarp_controlboard ? : D

Jokes apart, think about something like the iCub, if every motor had the transmission simulated: ~30 loaded FMUs, if we use FMU for aerodynamic forces, we will have an FMU for every major link, so ~15 fmus. A print of 50 lines may be quite confusing, especially if you are actually interesting in other output of the simulation and for some reason you load/unload the model frequently as part of a unit test.

For actually logging signals, I fear that printing textual data to stdout/stderr is a subpoptimal solution. I would prefer to have some kind of support for saving data from FMUs model to some kind of structure data format, for example .mat using matio, that we already use in the tests in https://github.com/robotology/gazebo-fmi/pull/29 . I think that this is deeply intertwined with https://github.com/robotology/gazebo-fmi/issues/19 : once we have a structure way to store variables from the simulated FMUs, it is then trivial to write a plugin that access this variable database at each simulation loop and save the variables on a file.

triccyx commented 5 years ago

I'm again with this issue. It is important to understand if your FMU has been loaded or not. Now we use different folders for different FMUs type (ie. with component A, without component B ...). It can happen that in one folder we have more FMUs than in the other folder. So we have lots of different possibilities. If you forget an FMU the simulation works but with different results and it is not easy to find the bug.

Can we write these infos to file? Yes we can but we have a configuration problem, where can we put the file path for logging? Can we use a fixed name? Can we define a general setting for FMI-Gazebo plugin?

Can we write to the screen? Also, in this case, I say yes because they are only startup information. We will have one line for each joint at the start of Gazebo. If we will have something like this for me is not a problem:

Successful loaded FMI-Gazebo plugin for L_AK_R Successful loaded FMI-Gazebo plugin for R_AK_R ...

traversaro commented 5 years ago

I see your point! What about a verbose setting that can be true or false passed as part of the plugin parameters in the SDF file?

triccyx commented 5 years ago

Ok for me. Just one thing, you will need to set the value verbose=true in all the plugins inside of the SDF. It is not the best but OK ... this is related to issue #31. As soon as I have time I will check it.