ergoCub 1.1 S/N:001 – Torso Pitch OverCurrent

[carloscp3009]

Robot Name 🤖

ergoCub 1.1 S/N:001

Request/Failure description

During my experiments, the torso pitch motor turned off due to overcurrent.

Detailed context

I was conducting an experiment this morning, during the initial calibration there was a problem with the torso pitch.. I restarted the calibration and everything went well. Then, during the first attempt to make the robot walk the torso pitch went to hardware fault due to overcurrent just as shown in the attached material.

Attached you will find a video and the logger output.

Additional context

log_ergocub-torso_yarprobotinterface_3916.zip

https://github.com/robotology/icub-tech-support/assets/44415073/72e440b0-766a-4b95-8e6c-b55c89fa2595

How does it affect you?

I can not use the robot.

[GiulioRomualdi]

We tried several time the walking and the torso went always in overcurrent. I'm afraid that the motor was burned.

As far as I know, the temperature check was disabled for the last demo

cc @S-Dafarra @DanielePucci @valegagge @MSECode @maggia80

[S-Dafarra]

Unfortunately, we did not manage to revert the FW in time

[GiulioRomualdi]

cc @evelyd @G-Cervettini @rob-mau

[GiulioRomualdi]

Hi all, I was wondering which is the plan to fix this issue since it prevents the usage of the robot for most of the people. In case the motor is burned and there aren't other spare motors, we may think to add the pin to block the joint. If we go for this solution, we will need to modify the model (cc @Nicogene and @traversaro) and all the configuration file associated to the robot.

cc @DanielePucci

[SimoneMic]

Hello, Is there any time estimation on how long the temporary fix will take to be put in place? It's actually blocking a lot of activities.

Thank you so much!

[fbiggi]

Ciao a tutti, mi chiedevo quale sia il piano per risolvere questo problema poiché impedisce l'utilizzo del robot per la maggior parte delle persone. Nel caso in cui il motore sia bruciato e non ci siano altri motori di riserva, potremmo pensare di aggiungere il perno per bloccare lo snodo. Se scegliamo questa soluzione, dovremo modificare il modello (cc@NicogeneE@traversaro) e tutto il file di configurazione associato al robot.

cc@DanielePucci

Hi @GiulioRomualdi The pin to lock the pitch was inserted due to a burnt motor Please remind everyone who will be using the robot that this component is mounted

[AntonioConsilvio]

Just to clarify, we inserted the torso pitch lock as we do not have the motors to replace the burnt one.

The motors have been ordered, when they arrive we will proceed with the replacement.

cc @GiulioRomualdi @SimoneMic

[SimoneMic]

Ok thanks, so we can use the robot now. Have the config files and urdf been updated?

Thanks again

[AntonioConsilvio]

Ok thanks, so we can use the robot now. Have the config files and urdf been updated?

Thanks again

The robot cannot be used at the moment because the lower arm is being upgraded.

When the upgrade is complete, the robot will be available!

[GiulioRomualdi]

Once the robot is back to be sure we are able to run it with whole body dynamics we will need to use the latest master in whole body estimator (the one containing https://github.com/robotology/whole-body-estimators/pull/188 ) and update the associated config file.

[traversaro]

To clarify, the plan at this point is not to modify anymore the URDF thanks to the changes mentioned by @GiulioRomualdi . For some reason you need the URDF modified in your software @SimoneMic ?

[SimoneMic]

To clarify, the plan at this point is not to modify anymore the URDF thanks to the changes mentioned by @GiulioRomualdi . For some reason you need the URDF modified in your software @SimoneMic ?

I need the transform from the head to the feet. The TF, which is computed from the /joint_states topic, uses the robot URDF. Furthermore, a lot of other software components(which are used for grasping, manipulation and perception) use as a reference frame the root_link of the robot. Since the torso_pitch is a joint inside the kinematic chain, it impacts them all.

Maybe I am missing something: since the torso_pitch has been fixed in place with a pin, it will also be excluded from the startup (calibration, and so on), correct? And it will not be enabled, right? Or do we still use the robot in permanent HW fault?

[traversaro]

Maybe I am missing something: since the torso_pitch has been fixed in place with a pin, it will also be excluded from the startup (calibration, and so on), correct? And it will not be enabled, right? Or do we still use the robot in permanent HW fault?

This is a good point, if it is present but in permanent HW fault, that should not be a problem as long as the encoder actually measure the correct value. However, if for some reason the joint is not available in the YARP controlboards or if it is present but reporting the wrong joint position, we can still try to avoid the expensive step of manually creating a custom URDF with the joint fixed to 10, by ensuring that torso_pitch remains available in /joint_states ROS 2 topic by adding a simple fakeMotionControl YARP device that contains a single joint torso_pitch and attach it to the remapper used to publish the /joint_states topic, i.e. in https://github.com/robotology/robots-configuration/blob/f3cb9d6c45de23966f6d99aae2f4ae984edcc44a/ergoCubSN001/wrappers/motorControl/alljoints-mc_remapper.xml .

[valegagge]

Hi guys, what I suppose is that we need to remove the joint from the calibrator list because we cannot use anymore. At this stage, the controlboard sends the joint position anyway but it is not calibrated. If the AMO encoder is configured then the joint position is a not calibrated value, while if only motor encoder is configured the joint position is zero, and I guess it is the position of the joint pinned.

If my suppositions are true, the YARP control board will receive the position of the joint at zero without changing anything. The only problem I see with this solution is that if an application set a control mode to the entire body part it gets an error because it is impossible to change the control mode of an uncalibrated joint.

[traversaro]

If the AMO encoder is configured then the joint position is a not calibrated value, while if only motor encoder is configured the joint position is zero, and I guess it is the position of the joint pinned.

As far as I remember the joint is pinned at 10.0 (deg) position.

[carloscp3009]

@fbiggi FYI

[valegagge]

@AntonioConsilvio please verify that on the robot the original 2foc fw is used instead of the one for the demo.

cc @fbiggi @Fabrizio69 @MSECode @S-Dafarra

[AntonioConsilvio]

Hi! We replaced the burnt motor with a new one! The motor has been calibrated and tested, here the PR:

• https://github.com/robotology/robots-configuration/pull/651

@valegagge, the robot has the original 2foc firmware in this moment.

Thank you @fbiggi @Gandoo @AntonioAzocar for your help with motor replacement!

[S-Dafarra]

We tried to walk and it seems to be working fine!

[AntonioConsilvio]

Thank you for the feedback! Closing!