[ergoCubSN000] Different ft sensor names between URDF file and yarprobotinterface configuration files

[isorrentino]

Task description

With the latest release of ergocub-software the robot does not start because of an error from whole-body-dynamics about the ft sensors (sorry I do not have the message of the error to attach here).

Checking the URDF file of ergoCubSN000, I discovered that two duplicated fixed joints are associated with each ft.

See

ergocub-software/urdf/ergoCub/robots/ergoCubSN000/model.urdf

Lines 906 to 940 in d82ce6a

	<link name="r_arm_ft"/>
	<joint name="r_arm_ft_fixed_joint" type="fixed">
	<origin xyz="-0.006849910543190453 3.2679315392636354e-07 -0.05429971877536288" rpy="-3.1415924092528633 0 1.5707964070692688"/>
	<parent link="r_shoulder_2"/>
	<child link="r_arm_ft"/>
	<dynamics damping="0.1"/>
	</joint>
	<link name="r_shoulder_3">
	<inertial>
	<origin xyz="-8.316742504336366e-05 -3.0846217982133384e-05 -0.007966675096942724" rpy="0.12008559189031787 -0.2297881760318691 1.288278055899408"/>
	<mass value="0.271466"/>
	<inertia ixx="7.88881e-05" ixy="1.72745e-06" ixz="1.11496e-05" iyy="7.70973e-05" iyz="5.68308e-06" izz="0.0001241"/>
	</inertial>
	<visual>
	<origin xyz="0.020751322852116103 0.19966607735058817 -0.11374685915473111" rpy="0.12008559189031787 -0.2297881760318691 1.288278055899408"/>
	<geometry>
	<mesh filename="package://ergoCub/meshes/simmechanics/sim_ecub_r_shoulder_3_prt.stl" scale="0.001 0.001 0.001"/>
	</geometry>
	<material name="r_shoulder_3_color">
	<color rgba="0.7 0.7 0.7 1"/>
	</material>
	</visual>
	<collision>
	<origin xyz="0.020751322852116103 0.19966607735058817 -0.11374685915473111" rpy="0.12008559189031787 -0.2297881760318691 1.288278055899408"/>
	<geometry>
	<mesh filename="package://ergoCub/meshes/simmechanics/sim_ecub_r_shoulder_3_prt.stl" scale="0.001 0.001 0.001"/>
	</geometry>
	</collision>
	</link>
	<joint name="r_arm_ft_sensor" type="fixed">
	<origin xyz="-0.006849910543190453 3.2679315392636354e-07 -0.05429971877536288" rpy="0 0 0"/>
	<parent link="r_shoulder_2"/>
	<child link="r_shoulder_3"/>
	<dynamics damping="0.1"/>
	</joint>

.

cc @traversaro @Nicogene @SimoneMic

Definition of Done

[traversaro]

This seems a regression of #159, that was triggered by #158 .

[traversaro]

Looking more at this, it seems that it should be ok:

• r_arm_ft_sensor is the joint actually corresponding to the FT sensor
• r_arm_ft_fixed_joint is a joint that connects the "fake link" (i.e. additional frame) r_arm_ft, that is used on RViz to visualize the reading of the r_arm_ft sensor.

Clearly the naming of r_arm_ft_fixed_joint is not ideal, but it should work fine. What kind of errors are you seeing with this model?

[Nicogene]

I think that the error @isorrentino is having is due to the fact that on the real robot we have different sensor names.

See https://github.com/robotology/robots-configuration/blob/edc514623e39330540aecb500d75ecac3874f7bc/ergoCubSN000/hardware/FT/left_arm-eb2-j0_1-strain.xml#L34

I am afraid that until #156 is not fixed the real robot and the simulated one need 2 different wbd configuration files.

[isorrentino]

I'm not on the robot, but at this point I think the problem is the one specified by @Nicogene. The names do not match and WBD fails.

[traversaro]

I am afraid that until #156 is not fixed the real robot and the simulated one need 2 different wbd configuration files.

I think there are two different problems here. One are YARP devices names, and another are FT sensors names. For both consistency between simulated and real robot is important, but the latter is more important as it involves names specified in URDF that are harder to change.

[traversaro]

@isorrentino @Nicogene based on your comments I modified the issue name.

[Nicogene]

I am afraid that until #156 is not fixed the real robot and the simulated one need 2 different wbd configuration files.

I think there are two different problems here. One are YARP devices names, and another are FT sensors names. For both consistency between simulated and real robot is important, but the latter is more important as it involves names specified in URDF that are harder to change.

In this sense for iCub* i set the framename parameter in order to match the name in the urdf: https://github.com/robotology/robots-configuration/blob/edc514623e39330540aecb500d75ecac3874f7bc/iCubGenova11/hardware/FT/right_arm-eb3-j0_3-strain.xml#L34

[traversaro]

I am afraid that until #156 is not fixed the real robot and the simulated one need 2 different wbd configuration files.

I think there are two different problems here. One are YARP devices names, and another are FT sensors names. For both consistency between simulated and real robot is important, but the latter is more important as it involves names specified in URDF that are harder to change.

In this sense for iCub* i set the framename parameter in order to match the name in the urdf: https://github.com/robotology/robots-configuration/blob/edc514623e39330540aecb500d75ecac3874f7bc/iCubGenova11/hardware/FT/right_arm-eb3-j0_3-strain.xml#L34

That would not solve the problem. The problem here are the sensor names (i.e. the name attribute of the sensor tag), not the frame names.

[traversaro]

Probably we need to agree on what the sensor name for the FT sensor should before proceeding with robotology/robots-configuration#561 .

[traversaro]

Probably we need to agree on what the sensor name for the FT sensor should before proceeding with robotology/robots-configuration#561 .

See robotology/icub-models-generator#240 (comment) , in particular the comment:

Requires changes in icub-model-generator, ergocub-software, robots-configuration. If the changes are not done together, wholebodydynamics from whole-body-estimators stop working.

Looking at the situaton now, it seems that #158 basically went ahead with O1 for ergocub-software, so as there was no other input, I suggest to proceed with O1 to fix the situation on ergocub and permit people to use the robot.

See also robotology/icub-models-generator#242 .

[Nicogene]

Probably we need to agree on what the sensor name for the FT sensor should before proceeding with robotology/robots-configuration#561 .

See robotology/icub-models-generator#240 (comment) , in particular the comment:

Requires changes in icub-model-generator, ergocub-software, robots-configuration. If the changes are not done together, wholebodydynamics from whole-body-estimators stop working.

Looking at the situaton now, it seems that #158 basically went ahead with O1 for ergocub-software, so as there was no other input, I suggest to proceed with O1 to fix the situation on ergocub and permit people to use the robot.

See also robotology/icub-models-generator#242 .

I agree!

[Nicogene]

@traversaro it has been fixed by

• Harmonize ergocub FT sensor names with the one used in ergocub URDF robotology/robots-configuration#561

am I right?

[traversaro]

I think so, @isorrentino do you confirm?

[isorrentino]

Yes, I confirm. Feel free to close the issue.