Disalignment between iCub 2.* models (such as iCubGazeboV2_5) and real iCub 2.* models regarding analogServer devices publishing information on /icub/<...>/analog:o ports

[traversaro]

In robotology/icub-models-generator#231 all the analogServer wrappers that were exposing FT sensors measures /icub/<...>/analog:o ports were removed, and this change was released in icub-models 2.0.0 . See https://github.com/robotology/icub-models-generator/blob/fd2d430a399119f2ded5a15f1c8ea4185b9aca6c/simmechanics/data/icub3/conf/icub.xml#L23 .

In their place, there are multipleanalogsensorsserver drivers that publishes information on a /icub<Sim>/<..>/measures:o ports, among other ports.

However, physical iCub 2.* robots still just have analogServer wrappers to expose FT sensors measures, see: https://github.com/robotology/robots-configuration/blob/b01aa43c2f51f477cf5b3c855a7e51ec46700ffb/iCubGenova11/icub_all.xml#L97 .

So, at the moment there is no way to write the same code that runs for both simulated and real robot, that has always been the main advantage of our simulators based on gazebo-yarp-plugins.

Possible fixes are:

• Add back analogServer devices to iCub 2.* simulated robots
• Substitute analogServer devices in real robots with multipleanalogsensorsserver devices

cc @Nicogene @pattacini @gabrielenava

[Nicogene]

Substitute analogServer devices in real robots with multipleanalogsensorsserver devices

I am for this option since @randaz81 will remove AnalogServer in future YARP releases
I can open a robots-configuration issue for that, since AnalogServer is still around, this cleanup has not to be included in 2023.02.2, but it is nice to have for future Distro

cc @pattacini

[pattacini]

Agree @Nicogene 👍🏻

Please, open up an issue and put it on our backlog for the next sprint.

[traversaro]

Substitute analogServer devices in real robots with multipleanalogsensorsserver devices

In the end it was decided to do that, see the modifications:

• Refactoring of FT configurations for publishing them divided per parts icub-models-generator#239
• Migrate iCub FT to have one NWS for each part robots-configuration#517

[Nicogene]

This misalignment should be now solved am I right?
The visuomanip models have keept out from this refactoring because they don't expose FT sensors (if I am not wrong).

cc @pattacini @martinaxgloria

[traversaro]

The visuomanip models have keept out from this refactoring because they don't expose FT sensors (if I am not wrong).

I think they expose them:

icub-models/iCub_manual/robots/iCubGazeboV3_visuomanip/model.urdf

Line 3142 in b209ab8

<yarpConfigurationFile>model://iCub/conf_icub3/FT/gazebo_icub_left_foot_front_ft.ini</yarpConfigurationFile>

.

[Nicogene]

The visuomanip models have keept out from this refactoring because they don't expose FT sensors (if I am not wrong).

I think they expose them:

icub-models/iCub_manual/robots/iCubGazeboV3_visuomanip/model.urdf

Line 3142 in b209ab8

<yarpConfigurationFile>model://iCub/conf_icub3/FT/gazebo_icub_left_foot_front_ft.ini</yarpConfigurationFile>

.

Good catch, I was looking into the conf_manual folder

[xEnVrE]

The visuomanip models have keept out from this refactoring because they don't expose FT sensors (if I am not wrong).

If I can add on this, the analogServer is also used to publish the "equivalent" hall effect sensors of the fingers encoders in iCubGazeboV2_5_visuomanip:

icub-models/iCub_manual/conf_manual/iCubGazeboV2_5_visuomanip/gazebo_icub_left_hand_mais.ini

Line 7 in 78b150c

device analogServer

Since MAIS is obtained using the GYP maissensor plugin, which implements the IAnalogSensor interface if I am not wrong, does it mean that the maissensor plugin needs to be re-written such that it exposes one of the interface compatible with multipleanalogsensorsserver (as recently done on the real robots as well)?

cc @traversaro @Nicogene @pattacini

[traversaro]

I guess, yes, even if probably there is no need to re-write, just to implement some additional methods.

[Nicogene]

@xEnVrE you can take this as reference:

• embObjMais: expose data via MAS interface icub-main#905

[traversaro]

I think we can close this. The last point mentioned here will be tracked in #198 (comment) , but it is not related to the problem described here.