Encoder Consistency test - hip pitch joint gear ratio

[violadelbono]

Hi all,

This issue connects with #76 since I found the same error when performing the encoders test on the last robots.

The hip_pitch joint has an additional cable transmission stage after the harmonic drive. The motor side pulley has a diameter of 50 [mm], while the joint side pulley has a diameter of 75 [mm], consequently, the additional reduction ration is: 75/50 =1.5

The encoder Consistency test cycles each joint and plots the joint parameters transported into the motor reference space (y-axis= motor encoder values) and the 2 trajectories should be overlapped.

This is the code implementing the test.

Each robot part has a .ini file where the J2M matrix is specified. In particular this is the coupling matrix and it is correct (element (1,1)=75/50=1.5 :

Therefore the matrix used in the test is not the one saved in the mechanical xml file of each robot (example iCubZagreb01) . I believe that this xml file is used by the test to extract the parameter gearbox (here).

This is what happens when modifying this the gearbox parameter in the robot xml file:

Case 1

If I only set Gearbox_M2J = 150 (see iCubZagreb01) and then I plot the joint position vs. motor position for the legs, I obtain a mismatch in j0 -pitch, since the test already takes into account a (correct) coupling matrix as above.

Case 2

 The original parameters in the previous robots (see iCubHongKong01) were:  Gearbox_M2J = 100 and identity coupling matrix M2J (wrong!)

With these parameters, when I perform the same encoder test I obtain the correct plots. This is expected because a unitary gear ratio and a correct coupling matrix allow a correct calculation:

Conclusions

In the mechanicals xml file of each robot I believe we need to do some corrections:

1. if Gearbox_M2J =100 --> matrixJ2M(1,1)=1.5 and matrixM2J(1,1) =1/1.5=0.667
2. if Gearbox_M2J =150 --> matrixJ2M(1,1)=1 and matrixM2J(1,1) =1 However in this case the .ini files of the encoder Consistency test must be modified with an identity matrix.

I suggest the option 1 for all the future robots, so I don't have to change the ini files, but I would like some feedback.

Thanks!

cc @Fabrizio69 @pattacini

[pattacini]

Thanks @violadelbono for the thorough analysis 🎉

I can see two problems:

• it's fundamentally a mistake that the test is taking the parameters from its own ini files instead of getting them from the official robot configuration, either by reading those files straight away or making some calls to the API. We really need to stick to the principle of the single source of truth.
• we don't have to adjust Gearbox and matrixJ2M in order to get the expected results; rather, we need to fix them up in order to make them correspond to their physical meaning. The fact that the test will be successful is only a consequence of such a fix. Gearbox and matrixJ2M do have different meanings indeed although they refer to the same mechanism and do have mutual interplay.

I suggest the option 1 for all the future robots, so I don't have to change the ini files, but I would like some feedback.

We need to fix all the robots that have this problem, past and future, and if this means that we need to touch thousands of conf files, it's the only way to go (we already did this in the past).

We will discuss this further.

[pattacini]

Talking w/ @traversaro, it came out that we could exploit http://www.yarp.it/git-master/classyarp_1_1dev_1_1IRemoteVariables.html to access robot variables.

This way, the test wouldn't have to load the parameters from its own conf files and the single source of truth would be guaranteed.

Example of usage.

[violadelbono]

@pattacini @traversaro I agree with you! Right now it's a bit confusing

[traversaro]

We would need to double check the values, but it seems that several related parameters/values are indeed exposed:

• https://github.com/robotology/icub-main/blob/cf42375998f1450ecfeaa027a64d83bd84c37094/src/libraries/icubmod/embObjMotionControl/embObjMotionControl.cpp#L3163
• https://github.com/robotology/icub-main/blob/cf42375998f1450ecfeaa027a64d83bd84c37094/src/libraries/icubmod/embObjMotionControl/embObjMotionControl.cpp#L3202
• https://github.com/robotology/icub-main/blob/cf42375998f1450ecfeaa027a64d83bd84c37094/src/libraries/icubmod/embObjMotionControl/embObjMotionControl.cpp#L3209

[pattacini]

This bug has been fixed via robotology/icub-tests#60.

We demonstrated that the approach of using IRemoteVariables is viable.
We may take this into consideration for a possible future overhaul of the icub-tests in this sense.

cc @davidetome @traversaro @gsisinna @Uboldi80