search

robotology / icub-tech-support

Virtual repository that provides support requests for individual robots
GNU General Public License v2.0
20 stars 2 forks source link

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

Closed GiulioRomualdi closed 11 months ago

GiulioRomualdi commented 1 year ago

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

image

Additional context

cc @s-dafarra @DanielePucci @Gianlucamilani @lrapetti @mebbaid @paolo-viceconte @carlo

How does it affect you?

No response

lrapetti commented 1 year ago

When this happens the wrist seems to remain in control.

mebbaid commented 1 year ago

@GiulioRomualdi I think you meant to tag @CarlottaSartore

mfussi66 commented 1 year ago

Does the yarprobotinterface show errors?

mfussi66 commented 1 year ago

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

cc @maggia80

S-Dafarra commented 12 months ago

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

mfussi66 commented 12 months ago

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 commented 12 months ago

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 commented 11 months ago

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.

Cover_support

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:

https://github.com/robotology/icub-tech-support/assets/114915464/94cc63f8-e5eb-40ea-92a6-a2ec94a67b66

But with the Kapton this does not happen:

https://github.com/robotology/icub-tech-support/assets/114915464/8501176d-d676-4f74-9ab6-eb1655df9456

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

Holder

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 commented 11 months ago

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.