ergoCub 1.0 S/N:000 – Right wrist in HF and we cannot recover it

[GiulioRomualdi]

Robot Name 🤖

ergoCub 1.0 S/N:000

Request/Failure description

We noticed that right wrist went in HF and we cannot recover it from the motorgui. The only way to have it functional is to reboot the motors

Detailed context

Additional context

cc @S-Dafarra @DanielePucci @Gianlucamilani @lrapetti @mebbaid @paolo-viceconte @carlo

How does it affect you?

No response

[lrapetti]

When this happens the wrist seems to remain in control.

[mebbaid]

@GiulioRomualdi I think you meant to tag @CarlottaSartore

[mfussi66]

Does the yarprobotinterface show errors?

[mfussi66]

Also, do you have logs of the currents as well for the wrist?@lrapetti @GiulioRomualdi @mebbaid

cc @maggia80

[S-Dafarra]

@AntonioConsilvio seemed to notice that it was happening when squeezing the covers in a particular point

[mfussi66]

Wild but educated guess, squeezing the covers might cause the amcbldc to move as well and get closer to the motors, causing the overcurrent due to induced current by the permanent magnets and subsequent HF.
Though it should be recoverable without reboot, if I'm not mistaken.

[S-Dafarra]

Though it should be recoverable without reboot, if I'm not mistaken.

It was not possible unfortunately. @AntonioConsilvio also changed one board, and reduced the current limits, but it was still happening

[AntonioConsilvio]

Hi @GiulioRomualdi, Yesterday I did some debugging to try to understand what was causing this hardware error.
I came to the conclusion that there were several causes.
The first was on the right wrist, where a loose screw behind one of the AMC_BLDCs was causing the board to turn off unexpectedly and thus the hardware failure.
After tightening the screw, the problem persisted and was probably due to an assembly problem, as the board's heatsink was under the cover support, which pressed the board against the mechanics, thus causing a malfunction.

I later turned the board to the correct position.

As for the left wrist, I think it was caused by the reversed AMC_BLDC, in fact I found that if something touches the back of the power supply or motor phase connector, the board shuts down:

Turn-off.mp4

But with the Kapton this does not happen:

kapton.mp4

After placing the kapton, we also inserted the new holder to prevent the reversed board from being held with cable ties:

After all these changes, I did several tests, even manually moving the boards with the intention of causing shutdowns, but this did not happen.

I therefore ask you to give us feedback after the your tests to see if the problem persists or not.

cc @maggia80 @Fabrizio69 @sgiraz @mfussi66 @lrapetti @S-Dafarra

[sgiraz]

Thank @AntonioConsilvio, the board now should be isolated properly and no more short circuits may happen. As a result of this, I would close this issue.