icub-tech-support
icub-tech-support copied to clipboard
robotology
iCubGrenoble01 S/N:023 – right hand wrist in hardware fault
Robot Name 🤖
iCubGrenoble01 S/N:023
Request/Failure description
Right wrist fails to initialize with yarprobotinterface: error messages report about Hardware problem in the magnetic position sensor of the joint caused invalid position readings. and/or hard limit reached. The joint position is outside its hardware boundaries.
r_wrist_pitch and yaw are in hardware fault (code 8) joint 6 reports 115.906 degres in motorgui, whatever the position its moved to (manually) joint 5 values changes with manual movements in a way that seems reasonable (0 aligned with forearm direction)
Probably as a consequence of the failed calib, r_hand_finger is in idle with zero velocity. All other joints are runned, position 0
Detailed context
From yarplogger, after a yarprobotinterface:
2.021706 ERROR from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=1000s 815m 388u : CFG: EOtheEncoderReader cannot be configured: verification fails joint 2 (r_wrist_yaw) has error on primary encoder (code=0).
15.614137 ERROR from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=1014s 408m 929u : MC: hard limit reached. The joint position is outside its hardware boundaries. (Joint=r_wrist_yaw (NIB=2))
15.655028 ERROR from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=1014s 459m 953u : MC: Absolute encoder invalid data. Hardware problem in the magnetic position sensor of the joint caused invalid position readings. (Joint=r_wrist_yaw (NIB=2), encoderPort=0, encoderType=AEA)
Additional context
log_icub-head_yarprobotinterface_2590.gz
How does it affect you?
will not be able to perform pointing experiments
Hi @EliseiFrederic! You should find some useful information in this comment:
- https://github.com/robotology/icub-tech-support/issues/1466#issuecomment-1340810086
Probably as a consequence of the failed calib, r_hand_finger is in idle with zero velocity. All other joints are runned, position 0
Yes, your guess is correct. It is because wrist joints and hand finger are together in the calib order:
- https://github.com/robotology/robots-configuration/blob/0b5083f4c8dcabefd7509c444dc6464375c6d98c/iCubGrenoble01/calibrators/right_arm-calib.xml#L36
Give us feedback and if you have any questions feel free to ask!
@AntonioConsilvio thanks for the pointer. does this help ?
When dismanling the forearm, should I remove the skin first? Then 8 screws on the hard plastic?
@AntonioConsilvio
Situation is worst as first thought : on the board side, on the connector, several of the wires were detached... Which ones goes in which order? Does not seem to be the same as the other line
Hi @EliseiFrederic, This shows the correct wiring order for the connector:
If you have further questions, feel free to ask!
Not sure which PDF we should use to find this. We use page 13 of https://github.com/icub-tech-iit/electronics-wiring-public/blob/master/icub2.7/pdf/iCub2.7_E3.6.0_14839_Harness.pdf
If we'right, connectors would be : https://fr.rs-online.com/web/c/?searchTerm=50058-8000 https://fr.rs-online.com/web/p/boitiers-de-connecteurs-pour-circuits-imprimes/3421696*
We'll try to find the right tool for the crimps
We didn't find the right tool for the crimps, so the crimps were assembled by hand. We reconnected the sensor to the board, and made our first tries with red button pressed and manual moving of the wrist joints. The 2 values for the wrist are ok (0, range)... BUT I see that continuous flow in the log:
right_arm-eb27-j4_7 is the one with the wrist. We tested the 2 other joints (forarm rotation, fingers grouping) and they are ok too.
Any idea what the problem could be? We didn't dare to power the motors/have the calibration running in this situation...
Thanks in advance, Frédéric
[ERROR] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 376m 107u : SYS: EOtheCANservice could not tx frames on CAN bus. CanPort=CAN1. Size of fifo is 38 [WARNING] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 376m 227u : SYS: the TX phase of the control loop has last more than wanted. TX execution time 2791[usec]. Latest previous execution times[usec] (RX=N/A, DO=N/A, TX=2791); (Rx=15, DO=158, ...). Num of CAN frames[CAN1,CAN2]=[38 0] [ERROR] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 380m 107u : SYS: EOtheCANservice could not tx frames on CAN bus. CanPort=CAN1. Size of fifo is 38 [WARNING] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 380m 227u : SYS: the TX phase of the control loop has last more than wanted. TX execution time 2790[usec]. Latest previous execution times[usec] (RX=N/A, DO=N/A, TX=2791); (Rx=15, DO=158, ...). Num of CAN frames[CAN1,CAN2]=[38 0] [ERROR] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 384m 107u : SYS: EOtheCANservice could not tx frames on CAN bus. CanPort=CAN1. Size of fifo is 38 [WARNING] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 384m 227u : SYS: the TX phase of the control loop has last more than wanted. TX execution time 2791[usec]. Latest previous execution times[usec] (RX=N/A, DO=N/A, TX=2790); (Rx=15, DO=158, ...). Num of CAN frames[CAN1,CAN2]=[38 0] [INFO] Closing device right_arm-eb27-j4_7-skin [ERROR] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 388m 107u : SYS: EOtheCANservice could not tx frames on CAN bus. CanPort=CAN1. Size of fifo is 38 [WARNING] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 388m 227u : SYS: the TX phase of the control loop has last more than wanted. TX execution time 2791[usec]. Latest previous execution times[usec] (RX=N/A, DO=N/A, TX=2791); (Rx=15, DO=157, ...). Num of CAN frames[CAN1,CAN2]=[38 0] [ERROR] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 392m 107u : SYS: EOtheCANservice could not tx frames on CAN bus. CanPort=CAN1. Size of fifo is 38 [WARNING] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 392m 227u : SYS: the TX phase of the control loop has last more than wanted. TX execution time 2791[usec]. Latest previous execution times[usec] (RX=N/A, DO=N/A, TX=2791); (Rx=15, DO=158, ...). Num of CAN frames[CAN1,CAN2]=[38 0] [ERROR] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 396m 107u : SYS: EOtheCANservice could not tx frames on CAN bus. CanPort=CAN1. Size of fifo is 38 [INFO] Closing device right_arm-skin_wrapper [WARNING] from BOARD 10.0.1.27 (right_arm-eb27-j4_7) time=970s 396m 227u : SYS: the TX phase of the control loop has last more than wanted. TX execution time 2790[usec]. Latest previous execution times[usec] (RX=N/A, DO=N/A, TX=2791); (Rx=15, DO=158, ...). Num of CAN frames[CAN1,CAN2]=[38 0]
Hello @EliseiFrederic! Sorry for the delayed response.
If the encoders are reading correctly, you can proceed with testing the robot without pressing the red button.
The error shown in this comment is caused by the MC4-PLUS EB27 on the right arm not receiving signals from the CAN port. The boards that are located on that CAN port are the MTBs (i.e. the skin).
Therefore, the only thing that should not work is the right-arm skin, but the joints should move and function correctly.
Thank you @AntonioConsilvio , your help is always welcomed.
What if we think we once saw a strange value read from the encoder (with yarpmanager) but never reproduced that?
Unfortunately, problems that occur only once and then never again are the most complicated, because if you can't trigger them, you can't understand the cause and therefore how to intervene.
In such a case, it could be a sensor cable that is not making proper contact, so sometimes it works and sometimes it does not.
However, if this problem occurred during a start-up with the red button pressed, I am not sure how reliable it would be, as the sensor did not calibrate correctly and may show some oddities in the reading.
Therefore, I would try to start the robot without pressing the red button and see if it calibrates.
If it calibrates, I would try moving the joint to see if the problem recurs.
If it does not recur, I would try stressing the connector on the MC4-PLUS with tweezers to see if the joint goes into HW fault.
Try these tests and let me know!
@AntonioConsilvio indeed, it did calibrate 👍 But it seemed slow and jerky compared to the other arm (but when you're looking after a fault...) I could move the 2 wrist joints with yarpmanager, or use PositionControl code with iKin to do some pointing tests.
I also removed the right arm skin mentions from icub_all.xml, but it's not enough to get rid of the constant error stream with CAN mention (every 4ms, so it's a lot of activity for the logs...)