When the joint calibration goes wrong, some joint appears in idle with an uncertain PID configuration

[S-Dafarra]

Bug description

For the joints that use calibration 10 (https://icub-tech-iit.github.io/documentation/robot_calibration_types/amo_encoder_joint_calibration_10_details/), sometimes the initial calibration phase has some issues (the source of which is unknown). After the issue, the joint appears in idle and the PID configuration is unknown. In fact, the error is:

Calibration went wrong! Disabling axes and keeping safe pid limit

printed from this line:

icub-main/src/libraries/icubmod/parametricCalibratorEth/parametricCalibratorEth.cpp

Line 697 in 5245c9e

yError() << deviceName << ": set" << setOfJoint_idx << ": Calibration went wrong! Disabling axes and keeping safe pid limit\n";

Steps to reproduce

The steps to reproduce are unclear, as the calibration 10 sometimes fails for no apparent reason.

Expected behavior

If the calibration failed in an unrecoverable way, then the joint should be not calibrated. If instead, the joint is usable, then the PIDs should not be changed, otherwise there might be a source of uncertainty with the experiments, as it is not possible to know if the PIDs are limited at low level.

Example repository

No response

Additional context

No response

[S-Dafarra]

cc @valegagge @MSECode, as we noticed this during the demo in IROS

[pattacini]

Will be discussing it internally during our board meeting, next Tue.

[valegagge]

Hi,
i just want to highlight 2 points:

1. the problem due to the Calibration went wrong! Disabling axes and keeping safer PID limit isn't depending on the calibration 10. This occurs every time a joint in the joint set cannot calibrate and therefore the ParametricCalibratorEth sets all the joints of the same set in idle and leaves the safe PID limits
2. We need to take into account another two use cases during our discussion
   1. when one joint fails calibration, the user can retry calibrating it by the motor GUI and we need to keep the safer PID (Is this a mandatory behaviour??? )
   2. the user runs the other joint of the same set. Using a safer limit can avoid a "weird" situation in which one joint bumps into another Is this a desiderata behaviour??

However, the most important thing is to make the user aware of the fact that there are safe PIDs.

[S-Dafarra]

IMHO, safe PIDs are just a headache. Either the joint works, or it doesn't. "Safe PIDs" seem just a source of uncertainty.

[pattacini]

We discussed today this issue and in general an improvement to calibration.
People involved: @maggia80 @traversaro @valegagge @fiorisi @pattacini

I'll summarize below the main ideas:

1. When a joint fails to get calibrated is put in uncalibrated mode.
2. The joints belonging to the same set of a failed joint, which are able to complete the calibration, are considered operational and their PID gains assume the standard values.
   1. A set of mechanically coupled joints (e.g., the ergoCub wrist) represents an exception. In this case, if one of the joints of the set fails, all the joints are considered uncalibrated.
3. PID gains assume their standard values at the end of the homing phase of the calibration procedure. This is for safety reasons to cope with cases when one uncalibrated joint of the chain may cause self-collisions.
4. To optimize timing, joint calibration is performed only once and does not repeat upon launching yarprobotinterface several times in a row, unless the embedded boards get power-cycled, thus losing the calibration data. Instead, homing is always performed.
5. @valegagge and her team will be dealing with this development.

Point 4 is not strictly connected to this issue¹ but we will likely attempt to address it while modifying the state machine underlying calibration to meet the other requirements.

Hope I reported correctly everything we said. Feel free to add further comments / apply amendments.

Footnotes

1. @traversaro may open up an internal ticket for it. ↩

[S-Dafarra]

4. To optimize timing, joint calibration is performed only once and does not repeat upon launching yarprobotinterface several times in a row, unless the embedded boards get power-cycled, thus losing the calibration data. Instead, homing is always performed.

This looks great! One suggestion is to be careful in collisions between parts. For example, on ergoCub at the moment, we always rely on the calibration of the shoulder roll finishing before the calibration of the hip roll. There might be cases in which the hip roll is already calibrated, but the shoulder roll is not. Hence, when the hip roll goes to the home position (with the legs wide open), it might crash against the arm. This situation can be avoided if:

• there is a time precedence for the calibration of the arms wrt the legs
• we use different home positions depending on the case (joint already calibrated from a previous run or not)

[traversaro]

The idea is that to always home the joint, even if it is already calibrated. Anyhow, if the robot is starting close to the home position, the homing is almost a NOP, and for sure faster then actually doing the Calibration 10.

[S-Dafarra]

The idea is that to always home the joint, even if it is already calibrated. Anyhow, if the robot is starting close to the home position, the homing is almost a NOP, and for sure faster then actually doing the Calibration 10.

That's the problem. At the moment, the home position is the one with the arms up and the legs wide open (and not legs in zero). The problem is that the calibration of the arm, and in particular the elbow, requires the arm to be fully stretched. Hence, if we home a leg before calibrating the elbow, the leg collides with the arm and breaks the wrist.

[traversaro]

Can we quickly align on Teams?

[traversaro]

Ok, we aligned with Stefano. What was missing to me that also in the existing case during the calibration the robot avoid self-collision only if there the calibrations starts more and less at the same time. If that was not the case for some reason (and so the arms finish calibration before the leg) we can already have collisions.