ergoCub 1.3 S/N:002 – Initial calibration not reliable

[S-Dafarra]

Robot Name 🤖

ergoCub 1.1 S/N:002

Request/Failure description

While using the robot, I noticed that the initial calibration is often not successful, with some joints getting stuck at their limits. In particular, it seems that the robot is able to calibrate the right ankle pitch only once every three times (approximately), but we also experienced issues on the right knee and on the left elbow.

Detailed context

Here a log of an unsuccessful calibration of the right ankle pitch

failed_to_calibrate_right_ankle.txt

I noticed that there are some host transceiver errors at startup.

Additional context

Once I also noticed that the right knee was not controllable anymore, neither from motorgui, and I had to reboot the robot. In the terminal I had a ton of host transceiver issues similar to the one mentioned above.

How does it affect you?

Nw it takes several attempts (and hence a lot of time) to have the robot running correctly.

[S-Dafarra]

Another thing I noticed is that the robot seems to take more time to perform the calibration. By any chance, has something changed at firmware level?

[S-Dafarra]

cc @GiulioRomualdi @CarlottaSartore @LoreMoretti @steb6 @andrearosasco

[S-Dafarra]

Here two logs from two failed calibrations during a demo that could have lead to mechanical damages:
calibration_failure_1.txt
calibration_failure_2.txt

[valegagge]

Here two logs from two failed calibrations during a demo that could have lead to mechanical damages:

Hi @S-Dafarra ,
could you provide more details? what the robot did, the state of GUI.. thanks heaps! :)

[AntonioConsilvio]

Hi @valegagge, I can give you some info.
In some joints (for example right ankle pitch, but not only), this happens:

• The calibration starts with the joint looking for the index

• After an unusually long time, it finds it

• At this point, the joint goes to the hardware limit (as it should with incremental calibration)

• Because the duration of the steps before was particularly long, the calibration goes into time-out just as the joint goes to the hardware limit

• At this point the joint is stopped at the limit and usually in IDLE (sometimes also in RUN, but always stopped at the limit)

❌ The problem is that the joint stays on the limit and does not go into start-up position, probably because the time for calibration ends. ❌

The problem occurs often.

I have tried increasing the PWM to reach the hardware limit, in order to decrease the calibration time a bit, but this did not solve the problem.

[valegagge]

Thanks @AntonioConsilvio!
We noticed the problem on the ergoCub2.0 joints, but in this case, the cause was a different number of motor poles that affected the index search algorithm.
In this case, I think it is important to understand why it takes a long time to find the index.
We can check it!

@MSECode

[S-Dafarra]

Thanks a lot @AntonioConsilvio for the additional info! I can also add that in most cases, the faulty joint is in idle, but in some cases, it remains "Not Configured".

For temporal reference, lately it seems it happens less often, but just yesterday we had a similar issue on the right knee (but I did not save the log)

[S-Dafarra]

One thing we noticed is that if there is something wrong with one of the two wrists, then the entire calibration of the arm is delayed. This can cause a collision with the legs that might calibrate faster.

This might happen if the robot did not shut down correctly and the wrist is not in the home position (it can complain that it cannot exit from the singularity position)

[valegagge]

One thing we noticed is that if there is something wrong with one of the two wrists, then the entire calibration of the arm is delayed. This can cause a collision with the legs that might calibrate faster.

This might happen if the robot did not shut down correctly and the wrist is not in the home position (it can complain that it cannot exit from the singularity position)

Hi @S-Dafarra ,
thank you for your report.
In this case, the sw architecture of the calibration was thought to run the calibration on each body part independently. Therefore for now it isn't possible to configure a dependence between two body parts. Anyway, we keep in mind this issue. :)

[S-Dafarra]

In this case, the sw architecture of the calibration was thought to run the calibration on each body part independently. Therefore for now it isn't possible to configure a dependence between two body parts. Anyway, we keep in mind this issue. :)

Thanks, I understand. Maybe it is not worth blocking the entire arm calibration if the wrist has issues though

[S-Dafarra]

During Humanoids we noticed that the initial calibration was failing often. After that we updated the robot and we also fixed some HW limits that were more restrictive than the value used for calibration (on the knee and ankle pitch). Lately, the situation seems to have improved, but I don't know if they are related.

[valegagge]

In the fw is running on the robot there is any specific improvement strictly related on the calibration 10. Starting from the 2foc ver 3.36 we made the rotor/stator calibration not hw dependent and faster than before.