Check the behavior of iCub robot fingers at YRI restarting

[MSECode]

Task description 📝

Analyzing the work done in #393 the iCub robot fingers should behave correctly at YRI (yarpronotinterface) restarting, meaning that the following steps happens on the robot:

• when the YRI is closed all robot's joints are forced to idle
• at restarting the fw checks if there's any fault (which should give a negative result, supposed there were no faults at stopping)
• then the calibration procedure restarts and completes for all joints

However, it was noticed that at restarts some of the fingers results in hw fault, even if at YRI stopping the situation was fine.
Moreover, the weird things are that:

• a general problem related to that was already identified and solved as reported at Fix the bug regading the iCub fingers calibration #393, which was due to the resetting of some of the joint parameters only
• as things now this happens only for some of the fingers
• moreover, another unattended behavior (verified only for the fingers) is that it seems that when moving in position the hard limits at the motor set on the configuration files are not taken into account and the motor exceeds those limits without stopping

Definition of Done ✅

Correct behavior of the finger joints verified and PRs done

[MSECode]

It was noticed that after YRI restarting, for the fingers whose joint gives hw fault, the feedback position at joint is actually outside of the limits. However, this is not an expected behavior since the joint should save the last position reached at YRI stopping.
Therefore, I'll trace the updates of the joints data in the fw in order to analyze how the data are managed at deactivation and and re-initialization, checking if some parameters are still reset.

[sgiraz]

cc @AntonioConsilvio @Nicogene

[MSECode]

Today me and @AntonioConsilvio worked on the fingers calibration in order to solve the issue. Here follows some notes about the joint behavior and a possible solution:

• First of all, the problem which does not make the fingers recalibrate at yarprobotinterface (YRI) restart is due to the fact that some of the finger joints goes in hw limit fault, with the error of hw limit boundaries exceeded.
• Secondly, one important thing is that the error is somehow aleatory, meaning that is does not happen systematically on the same fingers
• Moreover, when calibration parameters are re-set the problems tends to do not verify for a while but sooner or later the joints goes again in hw fault at restart
• Another things that is not completely clear to me is that changing the value of homePosition in the configuration file does not affect the position that the fingers reach when the YRI is stopped (I'm not sure if things a desired behavior)
• the part of code which is responsible for raising this error is the fix that has been introduced with this PR where the flow of the code is stopped if there's an hw fault, things that is logically correct. The problem is that, because of ,as things now, the fingers are set to IDLE at YRI stopping and not to NOT CONFIGURED, every time the YRI is restarted some of the fingers oscillates around the zero and if the joint reaches negatives values the error is triggered
• Right now, in order to solve the issue I would propose to temporary invalidate the change introduced with the aforementioned PR, which is visible at this branch, which will kept as soon as the coming updates are ready. This updates will modify, in fact, the logic of the code by setting the joints in NOT CONFIGURED when YRI is stopped so that at restart they can be always recalibrated and no hw limit fault is triggered without no reason.

This solution is due to the fact that, as detailed above, it seems that at restarts some of the fingers tends to oscillates around the zero, independently of the positionHome value. Moreover, the exact zero of the joint set following the calibration procedure is lost after a while with a small error, which is though enough for putting the joint in error.
Therefore, as things now I will introduce the mentioned workaround, specifying is just temporary, waiting for the final change which will come on late September due to the fact that the code to check is a lot and is difficult to that everything fine in this week

[MSECode]

Here the PR merged:
robotology/icub-main#898

[MSECode]

DoD satisfied with PR merged