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

iCubGenova09 (iRonCub3) S/N:000 – Torso yaw goes in hw fault after or during startup #1628

Closed gabrielenava closed 11 months ago

gabrielenava commented 1 year ago

Robot Name πŸ€–

iCubGenova09 (iRonCub3) S/N:000

Request/Failure description

We start the robot and everything looks fine except for the torso yaw joint, that goes in hardware fault during startup. The error message says that the joint is outside the hardware limits despite it is actually in zero position. Indeed, the encoder on the joint side measures -360 degrees instead of 0 degrees. The encoder of the motor side instead seems fine (we looked at the data with robot-log-visualizer).

Sometimes the joint starts correctly in zero position, and after few minutes the measured value from the joint-side encoder jumps to -360 degrees and the joints goes in hardware fault.

In the yarplogger, the only error reported is stating that the joint is outside the limits. I will drop the full logger later on (we collected it with the iRonCub setup laptop and it is still saved on that laptop) EDIT: done.

Detailed context

Note that also in the past sometimes the torso yaw joint was going on hw fault, but the problem was recoverable: it was just sufficient to put the joint in idle and run it again. Now instead the error persists. I don't know if the problem we encountered in the past is related.

Additional context

torso_yaw_2 torso_yaw_issue

How does it affect you?

No response

gabrielenava commented 1 year ago

side note on this issue: we changed the calibration mode of the torso Yaw from type 12 to type 10 to see if there was any improvement in the encoder behavior. The calibration was effectively performed, but the problem persisted.

cc @DanielePucci

DanielePucci commented 1 year ago

@gabrielenava a possibility might be that of disabling the amo magnetic joint encoder and use only the lcore optical motor encoder for the joints where the amos are giving problems, as the torso-yaw does in this case.

The possibility of disabling an amo was implemented by @ale-git and the procedure is available at https://github.com/icub-tech-iit/task-force-miscellanea/issues/112#issuecomment-1761474195

Right now, with @GiulioRomualdi we are also planning to test the walking on ergoCub by using only the lcore optical motor encoders only for the entire lower ergoCub body: if this test will be fine, then we might also consider this possibility for the iRonCub, which should make the entire robot more robust also to electrical connections - if we do not use the amos, all the wiring connecting them becomes useless and then if a cable breaks, the robot keeps working.

For historical notes, the possibility of disabling the amos was an action point of the retrospective meeting associated with the demo at the minister of health - see point 23 of https://github.com/ami-iit/lab-events-demos/issues/208#issuecomment-1100130414. @ale-git implemented a temporary version of the firmware at night after we lost the amo of the left knee and we did not have a hardware replacement, so it was the only thing we could try back in time

CC @S-Dafarra

pattacini commented 1 year ago

@gabrielenava a possibility might be that of disabling the amo magnetic joint encoder and use only the lcore optical motor encoder for the joints where the amos are giving problems, as the torso-yaw does in this case.

The possibility of disabling an amo was implemented by @ale-git and the procedure is available at icub-tech-iit/task-force-miscellanea#112 (comment)

See https://github.com/icub-tech-iit/documentation/pull/321.

sgiraz commented 11 months ago

side note on this issue: we changed the calibration mode of the torso Yaw from type 12 to type 10 to see if there was any improvement in the encoder behavior. The calibration was effectively performed, but the problem persisted.

Just FYI,

@ale-git just merged the new FW for the EMS boards that enables the usage of the calibration type 10 without AMO (see https://github.com/robotology/icub-tech-support/issues/1660#issuecomment-1809777390)

@AntonioConsilvio

HosameldinMohamed commented 11 months ago

We flashed the firmware on the torso EMS board EB5 image

HosameldinMohamed commented 11 months ago

Now all EMS boards are updated! image

HosameldinMohamed commented 11 months ago

We started the robot and verified that the AMO can be execluded by changing the amo value to none in hardware file in robots-configurations

HosameldinMohamed commented 11 months ago

Now in iRonCub3, all joints that use calibration type 10 use only the optical encoder! We started the robot and the calibration is working as expected!

AntonioConsilvio commented 11 months ago

Hi, since the problem was tricked by using only the optical sensor and disabling the magnetic, I'll go ahead closing the issue!

cc @Fabrizio69 @sgiraz @HosameldinMohamed @gabrielenava