Fix the bug regading the iCub fingers calibration

[valegagge]

Here there are the details of the bug.

Dod
Bug is fixed and tested

[valegagge]

Just an update....

Alongside with @MSECode, we started analyzing the bug.

On yarprobotinterface shutdown, the motion controller in the fw put the joint in idle instead of to "clean" everything in order to return to the state before yarprobotinterface has been started.

We can discuss whether this behavior is still the desiderata but in another issue.
Now we'd like to understand which change creates the problem on the fingers, because on previous release this bug wasn't there.

After some tests, it is clear that the problem is related to the joint with the mais only: after the second start, but before the calibration, the joint encoder position is out of the limits: since the joint is in idle, the Controller checks the fault on the joint and notice that the current position is out of range. In case the joint is in "NotConfigured" mode, then this check is skipped.

With a joint of another type of encoder, this situation doesn't happen: after the second start and before the calibration, the current position is the last before the shutdown.

so this means, that during the shutdown phase or during the next initialization phase, the calibration info related to the mais changes. We need to understand how.

We'll continue to dive in this issue.

[valegagge]

📢 Finally, we get the solution.... 🥳

The problem was due to a bug in the FW.
In the case of the fingers with Mais sensor, during the configuration of the joints, the FW clears a part of the calibration data leaving inconsistent data.
So in the second run of the yarprobotinterface, even before receiving the calibration command, the Motor controller calculates the position of the fingers using incorrect calibration information, therefore the positions are often out of joint limits, so the controller set the joint in fault.

This bug was raised after this PR(robotology/icub-main#866), because in this PR the Ethernet parametric calibrator checks the joints in fault and doesn't go further in the calibration if one of them is in fault.

So in conclusion the fix on the ethernet calibration lets the FW bug manifests.

There is another important thing to bear in mind: when yarprobotinterface sends the "shutdown" command, the fw controller sets the joint in the idle state instead of "not-configured" and doesn't cleans everything in order to come back to the situation.

I think this behavior is not correct, so I suggest to discuss a separate meeting.

Now we fix the FW bug with a patch. (asap will put here the reference to the PR)

We tested on our beach setup. asap we'll test on robot.

cc @MSECode

[valegagge]

Another minor bug we noticed:
When the FW deactivates the Mais service, it doesn't send the correct can message to stop the Mais transmission. it sends ID=210 [7 | 0] instead of ID=210 [7 | 1].

I suggest fixing this also.

Does anyone if this is a desired behavior instead?

cc
@marcoaccame @sgiraz @davidetome

[valegagge]

Another minor bug we noticed: When the FW deactivates the Mais service, it doesn't send the correct can message to stop the Mais transmission. it sends ID=210 [7 | 0] instead of ID=210 [7 | 1].

I suggest fixing this also.

Does anyone if this is a desired behavior instead?

cc @marcoaccame @sgiraz @davidetome

I found the answer:

[MSECode]

After flashing a test firmware on the mc4plus boards of the right arm controlling the fingers, i.e. 10.0.1.28 and 10.0.1.29, on iCubGenova11 it was possible to check that the error related to the HW limits does not happen anymore when restarting the yarprobotinterface as shown in the screen of the yarpmotorgui below

Basically the fix was done by skipping the riparsing of the calibration parameters given by the configuration files when the yarprobotinterface is just stopped and restarted

[MSECode]

Open the PR for:

• icub-firmware
• icub-firmware-build

containing the update firmware for the temporary fix.
The fix is working fine and fw behavior is as expected, however it is intended to be temporary considering that the code flow as designed until now it is probably not efficient as originally thought and therefore it is going to be re-designed with a upcoming issue soon.
For the current scope of solving the problem related to the bug identified with the current issue the changes developed on the cited PR can be considered completed and they satisfy the defined DoD