Frames of skin-related quantities

[traversaro]

For expressing information related to the skin (the one published by the skinManager and the wholeBodyDynamicsTree on the *contacts:o* ports using the skinDynLib data structures) we have to define for each link the frame in which we want to express this informations, such as taxels position and force/torque orientation.

For discussing this issue, I will use the convention discussed in #57 (soon to be transformed in proper documentation).

Existing convention

For the links on which the skin is used, the frame of expression is the one indicated in the following table:

Proposed Frame Name	Link name	SkinPart enum name	iKinChain	Index of the iKinLink associated with this frame
l_upper_arm_dh_frame	l_upper_arm	SKIN_LEFT_UPPER_ARM	iCubArm - left	5
l_forearm_dh_frame	l_forearm	SKIN_LEFT_FOREARM	iCubArm - left	7
l_hand_dh_frame	l_hand	SKIN_LEFT_HAND	iCubArm - left	9
r_upper_arm_dh_frame	r_upper_arm	SKIN_RIGHT_UPPER_ARM	iCubArm - right	5
r_forearm_dh_frame	r_forearm	SKIN_RIGHT_FOREARM	iCubArm - right	7
r_hand_dh_frame	r_hand	SKIN_RIGHT_HAND	iCubArm - right	9

Extensions to existing convention

For the skin patches in the leg no frame is currently used, but assuming a convention similar to the one used in arms a possible choice could be:

Proposed Frame Name	Link name	SkinPart enum name	iKinChain	Index of the iKinLink associated with this frame
l_upper_leg_dh_frame	l_upper_leg	LEFT_UPPER_LEG	iCubLeg - left	2
l_lower_leg_dh_frame	l_lower_leg	LEFT_LOWER_LEG	iCubLeg - left	3
l_foot_dh_frame	l_foot	LEFT_FOOT	iCubLeg - left	5
r_upper_leg_dh_frame	r_upper_arm	RIGHT_UPPER_LEG	iCubLeg - right	2
r_lower_leg_dh_frame	r_forearm	RIGHT_LOWER_LEG	iCubLeg - right	3
r_foot_dh_frame	r_foot	RIGHT_FOOT	iCubLeg - right	5

Notice that while for intermediate link the frame is defined by the DH convention, for the end effector frame is just a choice independent from the DH convention, so perhaps the *_dh_frame name could be misleading.

@alecive can you review iKinChain link numbers?

Problems with extending the existing convention on chest skin

However, the existing convention of using DH frames cannot be strictly followed for the chest link, SkinPart name SKIN_FRONT_TORSO. The main problem is that the chest link for the DH convention used by iKin for frame placement has three different frames, depending on which chain is considered (if head, right arm or left arm).
We started discussing this issue informally with @alecive , and he was proposing to use the chest frame in the head DH chain (as defined in http://eris.liralab.it/wiki/ICubInertiaSensorKinematics and http://eris.liralab.it/wiki/ICubInertiaSensorKinematicsV2 ) because it is a frame that respect the left-right simmetry of the robot. The main problem that I see in this proposed is that in this case the taxel position files for the SKIN_FRONT_TORSO (the one loaded by the skinManager) should be different between robots with V1 neck (such as iCubParis01) and the V2 neck, even if the taxel position (with respect to the root_link) are the same.

cc (people I assume could be interested in skin issues) @jeljaik @alecive @lornat75 @matejhof @naveenoid

[alecive]

@traversaro I still have to finish reading, but currently on the skinManager the index of the iKinLink is not considering the torso (i.e. the forearm link number is 4 instead of 7).

[alecive]

Keeping that convention would make more sense in order to not break compatibility. Furthermore, it is more consistent with the leg convention.

[matejhof]

I had to solve this issue while programming the skin emulation for the simulator. My code and notes were:

 case TORSO:
                      T_root_to_link = odeinit._iCub->iKinInertialSensor.getH(SkinPart_2_LinkNum[skinPart].linkNum); 
                      // SkinPart_2_LinkNum[SKIN_FRONT_TORSO].linkNum  is 2, this should give us the FoR 3 - the first neck joint which is the expected torso FoR
                      //- check " SKIN torso 2" in iCub/main/app/iCubGui/skeleton.ini
                      //- importantly, this needs to be the iKinInertialSensor, not the iKin Arm;

I was checking this in the iCubGui and with Alessandro Scalzo, so this is the convention apparently (at least the one adopted back then). That is using the iKinInertialSensor and link 2.
Silvio rightly points out that even though the torso is the same, the neck differs in iCubs V1 and V2, so the FoR for the taxels is shifting. So we need to account for that somehow.

[alecive]

Creating a new ad-hoc chain (that does not depend on neck versions and goes up to the neck base) would likely solve the issue. @pattacini what do you think?

[lornat75]

I am inclined to support this suggestion, it would simplify a lot configuration files.

[pattacini]

I'll do that.

[pattacini]

I'm done with iCub::iKin::iCubTorso.

[alecive]

@traversaro how would you relate this issue with the BodyPart enum? Also related to the refactoring proposed in #149 , it seems to me to be quite redundant to have an enum that collects multiple enums, but still the BodyPart is part of SkinDynLib. Are you thinking to maintain the convention also for the new parts?

[alecive]

@traversaro @jeljaik slightly related to this topic (and #149 ), do you have any idea about why the torso position file (i.e. https://github.com/robotology/icub-main/blob/master/app/skinGui/conf/positions/torso.txt ) is filled with 768 lines of 0.08 0.10 0.00 1.00 0.00 0.00?

[jeljaik]

If I'm not wrong, that's because the torso has never been calibrated and that was manually introduced for some particular experiment in the past.

[alecive]

Ok.
So can I change them back to 0.00 0.00 0.00 0.00 0.00 0.00 ? I'd rather keep nothing than fake numbers 😄

[jeljaik]

Personally I wouldn't have any complain.

Jorhabib Eljaik Gómez,*Ph.D. Student - *Istituto Italiano di Tecnologia
Dept. of Robotics, Brain and Cognitive Sciences
Cognitive Humanoids Laboratory
e-mail: [email protected]
Cel: +39 388 352 33 85
Tel: +39 010 71781 420
Fax: +39 010 7170817

On Fri, May 22, 2015 at 3:35 PM, Alessandro Roncone <
[email protected]> wrote:

Ok.
So can I change them back to 0.00 0.00 0.00 0.00 0.00 0.00 ? I'd rather
keep nothing than fake numbers [image: 😄]

—
Reply to this email directly or view it on GitHub
#124 (comment)
.

[traversaro]

0.0 0.0 0.0 is as much as a fake number as 0.08 0.10 0.0. The latter has the useful property of visualize an external force in the middle of the chest in iCubGui, while the first creates an external force mesh that is hidden by the chest mesh.

[alecive]

Ok. I'll move back to the previous version.

[traversaro]

🔝

[pattacini]

This should be solved by now.
cc @traversaro