Investigate how to set the initial position of models included in world

[xela-95]

We have to investigate if in Modern Gazebo there is a native way to do what on Gazebo Classic is done through ConfigurationOverride introduced in PR robotology/gazebo-yarp-plugins#392

[traversaro]

See:

• Proposal: system for setting initial position / velocity gazebosim/gz-sim#2318
• Prototype system for initializing model state gazebosim/gz-sim#2359

[traversaro]

It does not seem that gazebosim/gz-sim#2359 may land soon, and in any case it would not be available in older gz-sim versions. So if we are interested in this functionality, we may want to investigate in a custom solution, for example implementing a gz_sim_configurationoverride plugin that can parse the yarpPluginConfigurationOverride tag as the one used in Gazebo Classic, see for example https://github.com/ami-iit/paper_romualdi_viceconte_2024_humanoids_dnn-mpc-walking/blob/e1554e9453fc7d63c571e29ea446c60fff683d60/worlds/dnn_mpc_ergoCubGazeboV1_1/world#L27-L50 .

Otherwise, just to simplify the implementation we could copy gazebosim/gz-sim#2359 and change its name and test it in this repo. However, we would need somehow to be able to disable the parsing of initialConfiguration on the controlboard plugins, otherwise they may be overriden.

[LoreMoretti]

So if we are interested in this functionality

Interested!

[traversaro]

See:

* [Proposal: system for setting initial position / velocity gazebosim/gz-sim#2318](https://github.com/gazebosim/gz-sim/issues/2318)

* [Prototype system for initializing model state gazebosim/gz-sim#2359](https://github.com/gazebosim/gz-sim/pull/2359)

Those proposal did not saw a lot of progress, so probably it make sense to roll out our own solution.

[traversaro]

I checked if we could re-use the same strategy used for Classic Gazebo (that can be found in https://github.com/robotology/gazebo-yarp-plugins/blob/96d1de66afc770ca4bc8808cbbd18378f32b3015/plugins/configurationoverride/src/ConfigurationOverride.cc#L41-L42), but in gz-sim if we call the ->Parent() argument of the passed sdf we do not have access to the whole SDF of the parent model, due to the line in https://github.com/gazebosim/gz-sim/blob/4b6445faa1a060eec548a71034b904e802e0b3d5/src/SystemManager.cc#L78 that only pass the sdf stricly required by the plugin (and by the way, that definitely make sense).

At this point, probably we could just use yet another time the singleton, to pass configuration-related overrides to plugins.

[traversaro]

At this point, probably we could just use yet another time the singleton, to pass configuration-related overrides to plugins.

This is exactly the strategy I used in #232 .