Take a decision about loading of gazebo plugins

[arocchi]

Currently the model plugins are loaded inside the .world file and not inside the sdf file of the model.
This has some benefits:

1. you can pass configuration parameters for the control_board plugin depending on the application, meaning that you can change the initial position for the joints for different world files, thus avoiding the homing procedure which cannot be done without a proper infrastructure (e.g. virtual crane) Set home positions robotology/gazebo-yarp-plugins#59
   But also some problems:
2. libgazebo_yarp_controlboard.so crashes when joints not found robotology/gazebo-yarp-plugins#66 that is, when the model changes (e.g. because you fix some joints or decide not to use the hands) you have to change all the world files accordingly, otherwise, currently, this causes the simulator to crash

Possible solutions to this problem would be to:

1. fix gazebo_yarp_plugins to be forgiving
2. put the plugins inside the sdf model, leading to these changes
   2.1) initial configuration for the joint should be...
   2.1.1) put in an external plugin (e.g. initial configuration plugin) - we loose the option of specifying custom PID configuration files, but this feature has not been used so far and I'm not sure it should be used
   2.1.2) delegated to the control code, thus introducing the need for a virtual crane, which could be as simple as disabling gravity and reenabling it after the homing, but several other solutions could be possible

What do you think @MirkoFerrati @traversaro @EnricoMingo ?

[EnricoMingo]

Allora, actually we could put these plugins inside the coman_robot.urdf.xacro so we can utomatically load the plugin based on the robot that we want to simulate (for instance coman with old forearms or coman with new forearm and actuated hands and so on). If we do in these way of course we can not specify anymore the initial configuration of the robot inside the world file but only in the urdf basically. This is not a big issue in my opinion since I think I am the only one that use this thing. So...

[traversaro]

@EnricoMingo +1, as the sensor yarp plugins are already defined inside the robot urdf/sdf I don't see why the controlboard should be different. This has also the nice side-effect of adding the feature of drag'n'drop of a working Coman from Gazebo GUI.

Regarding loading different parameters for the plugins, we can also consider the open discussion of supporting yarp-style configuration files ( robotology/gazebo-yarp-plugins#53 ).

[EnricoMingo]

ok so we will move the plugin from the world to the urdf.

[EnricoMingo]

Why we can not load also the clock plugin directly instead of passing it as argument?

[traversaro]

In which sense directly?
We can make the clock plugin a world plugin (instead of a system plugin), so it can be included in a world file.

[MirkoFerrati]

Please don't go offtopic with another plugin or we will not understand anything in 2 days from now, we were talking here about libgazebo_yarp_controlboard.
Now, about the controlboard, it's not really a problem to make it robust to missing joints. Maybe it's easier than the other solution. But I also like the coerence of having all the plugins inside the SDF file and the drag&drop feature. Why dont we just do both of them? We will make the plugin more robust AND move it inside the sdf. I think we should close this issue and open another one on a way to specify the starting position of the robot.

[arocchi]

Ok.
New issue for initial configuration robotology/gazebo-yarp-plugins#67
New issue to implement the decision https://github.com/EnricoMingo/iit-coman-ros-pkg/issues/24