Loading parameters from Yarp Configuration files

[traversaro]

This pull request implements the loading of the parameters (joint actuated, pids, port names, ...) from yarp .ini files.

The general design is that the element in the sdf contains a child named that is the URI of the .ini yarp configuration file ( http://wiki.icub.org/yarpdoc/yarp_config_files.html ).

This file contains the parameters necessary to load the device (such as "device", "subdevice" and "name") and also parameters useful for the device itself (such as the pid values). You can access this information from the device trough the "yarp::os::Property plugin_parameters" attribute of the coman class.

For an example check: https://github.com/traversaro/gazebo_yarp_plugins/blob/2f3fe2ddeb7f350373f9c6dee70f9d2ee27d780c/world/yarp_gazebo.world
In this example the .ini file URI is a path in model directory, so for executing it correctly it is necessary to add a coman_gazebo.ini (such as this one: https://gist.github.com/traversaro/7165103 ) to the /conf/ subdirectory of model directory of coman_urdf (I guess that the script that generate the sdf model in iit-coman-ros-pkg
can be used to put it in the right place).

An updated version of the coman_urdf.tar.gz archive with the .ini files is available here.

I did not updated the coman.tar.gz archive in this repo because I guess having multiple heavy binary files in the history of the repository could cause problems in the future (by doing git clone you download all the history of the repo and so every version of a binary file).

If you try to run the plugin without providing a .ini file or providing a not compliant one, the plugin fallbacks to the old default option, so you can continue to work with as nothing was changed.

Unfortunately there are still some issue that prevent to have multiple plugins running simultaneously (that is necessary to simulate multiple control board such as in the iCub) for example gazebo_pointer_wrapper that is a static object. I will investigate on this next week.

Using the .ini that I provide should also solve an incongruence between the pid values serialization and the joint serialization that I was obtaining in gazebo, between the two serialization I choose the serialization torso left_left right_leg left_arm right_arm as Enrico has done here: https://github.com/EnricoMingo/gazebo_yarp_plugins/blob/master/config/pid.ini .

One last thing: there is a reason for which we have all the implementation of the yarp::dev::coman functions in the header file instead of the cpp file?

[traversaro]

This branch to build without problems also on a clean system: https://travis-ci.org/traversaro/gazebo_yarp_plugins/builds/13073546 .

[MirkoFerrati]

No reason, I was waiting for some more stability before moving the code to the CPP. the global pointer is a big issue, I tried for 4 hours and could not come up with a design that works. the problem is that you are not creating the yarp device, so you cannot give it the pointer as a parameter. There may be a trick using the option class of yarp. you can write the pointer inside the options as an int, and cast it back inside the load. Any other better (not casting things around) idea is welcome.

[traversaro]

Yes, I was thinking about it too. It is not clear to me what is the scope of global object gazebo_pointer_wrapper across different instantiation of the plugin. If it is local to the instantiated plugin I guess it does not affect the possibility of having multiples plugin running together, if instead it is common to all the instantiated plugins we can transform it in a sort of "pointer database" for all the concurrent plugins, a solution that I still don't like but should work.
In the next week I'll check PolyDriver internals to understand in deep the issue.

[EnricoMingo]

We needed that one because I want to use the pointer from gazebo inside the driver and it is not possible to pass pointers to the driver through options parameters.

Inviato da iPad

Il giorno 27/ott/2013, alle ore 03:41, Silvio Traversaro notifications@github.com ha scritto:

Yes, I was thinking about it too. It is not clear to me what is the scope of global object gazebo_pointer_wrapper across different instantiation of the plugin. If it is local to the instantiated plugin I guess it does not affect the possibility of having multiples plugin running together, if instead it is common to all the instantiated plugins we can transform it in a sort of "pointer database" for all the concurrent plugins, a solution that I still don't like but should work.
In the next week I'll check PolyDriver internals to understand in deep the issue.

—
Reply to this email directly or view it on GitHub.

[EnricoMingo]

Guys, never done a merge from pull request, someone can help me? Silvio do you need pull request because are you not ad admin???

[MirkoFerrati]

Never done. The green button "Merge pull request" should work as expected, since the pull request can be automatically merged. I have not clicked on it yet cause I thought you knew better than me how to do the merge. Just click and see what happens :)

[EnricoMingo]

OK :)

[traversaro]

Yes I had to do a pull request because I have no editing rights in this repository. It can be however useful to make sure all commits are reviewed.