Closed gabrielenava closed 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.
cc @DanielePucci
@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 amo
s 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 amo
s, 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 amo
s 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
@gabrielenava a possibility might be that of disabling the
amo
magnetic joint encoder and use only thelcore
optical motor encoder for the joints where theamo
s are giving problems, as thetorso-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.
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
We flashed the firmware on the torso EMS board EB5
Now all EMS boards are updated!
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
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!
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
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
How does it affect you?
No response