l_foot_rear_ft, l_foot_front_ft,, r_foot_rear_ft, and r_foot_front_ft, FT sensor frame have a ~2cm offset in Z direction w.r.t. to the corresponding link frame

[traversaro]

Yesterday discussing with @GiulioRomualdi and @G-Cervettini I noticed something unexpected in a URDF, i.e. a translational offset in the <pose> part of the FT sensor: https://github.com/icub-tech-iit/ergocub-software/blob/v0.3.3/urdf/ergoCub/robots/ergoCubSN000/model.urdf#L3204 .

This was unexpected as, due to a limitation of the SDF format used in Gazebo, the FT sensor frame origin must coincide with the origin of the child link frame of the joint to which the FT sensor is attached. See gazebosim/sdformat#130 . Fortunatly we do not have this limitation in iDynTree, so wholeBodyDynamics was loading the FT sensor position without problems.

Not only the ergocub models are affected by this, but several other related models:

• iCubGazeboV3
• iCubGenova09
• iRonCub-Mk3 (I would need to double check)

Fortunatly the offset is not big and in the Z direction, that is a direction parallel to the direction of the force that the feet experience, anyhow it would be nice to fix the problem.

Possible (alternative) solutions are:

• S1: Fix in ergoCub CAD the location of the frames SCSYS_L_FOOT_FRONT, SCSYS_L_FOOT_REAR, SCSYS_R_FOOT_FRONT, SCSYS_R_FOOT_REAR to have its origin coincident with the one of the frames SCSYS_L_ANKLE_2_FT_FRONT, SCSYS_L_ANKLE_2_FT_REAR, SCSYS_R_ANKLE_2_FT_FRONT and SCSYS_R_ANKLE_2_FT_REAR and document in https://github.com/icub-tech-iit/cad-libraries/wiki/Prepare-PTC-Creo-Mechanism-for-URDF that the link frame of links that are attached to their parent with a FT sensor must coincide with the FT sensor frame origin
  • Note that this is not possible to directly modify ergoCub CAD and export it to simmechancis due to Incompatibility with PTC Creo 9 robotology/simmechanics-to-urdf#55 . Anyhow, in the short term we could manually patch the existing simmechanics file to remove the offset that is present.
• S2: Fix the problem upstream in SDFormat/Gazebo, as discussed in Position part of force_torque sensor pose is ignored and this may be confusing or impractical gazebosim/sdformat#130
  • The problem of this solution is that, even if it we are able to implement it quickly and merge it in sdformat, on some platforms (such as Gazeb Classic on Ubuntu 22.04 with apt dependencies) we are stuck with an old version of sdformat until we update to a newer Ubuntu version of we start compiling sdformat manually.

It seems to me that S1 is the easiest solution, even because it is the reason why the simulation of all non-foot FT sensor works fine.

[Nicogene]

cc @Lawproto @fiorisi since you are working on the simulation model cad of ergocub

[traversaro]

cc @Lawproto @fiorisi since you are working on the simulation model cad of ergocub

I can quickly explain the change necessary in front of a coffee as it is much simpler than all the details contained in this issue.

[Lawproto]

cc @Lawproto @fiorisi since you are working on the simulation model cad of ergocub

@Nicogene I am surely available for help if needed, but I personally dealt with the forearm + hand sections. The mentioned-in-description SCSYS's are new to me, maybe @Mick3Lozzo could provide more help here.

[traversaro]

We have discussed this with @Lawproto @Mick3Lozzo @Nicogene @fiorisi @traversaro, there we decided:

• For ergoCub 1.0 and iCub3 models, we fix the issue manually with software workarounds. The presence of tests ensures that for some reason workarounds are broken we detect this.
• For ergoCub 1.1 models the problem will be fixed on the CAD a some point in the future.