ergoCub 1.1 S/N:001 – left-wrist suddnley move in a given configuration while teleoperating

[GiulioRomualdi]

Robot Name 🤖

ergoCub 1.1 S/N:001

Request/Failure description

While teleoperating we noticed that the wrist moved in a wired configuration and suddenly came back into the initial configuration

Detailed context

@S-Dafarra was teleoperating the robot, and as is visible in the next video, the operator was in a different configuration from the robot. Indeed, our infrastructure requires a command in position direct to mimic human movements. This occurred only when @S-Dafarra's wrist configuration matched the one shown in the video.

Unfortunately, we don't have a numeric dataset for the experiment. We will attempt to replicate the behavior in the next set of experiments and collect the data

Additional context

robot-wrist.mp4

How does it affect you?

Related to this demo:

• https://github.com/ami-iit/lab-events-demos/issues/296

[sgiraz]

cc @simeonedussoni @fbiggi @Fabrizio69 @Lawproto

[fbiggi]

we tightened the transmission belts
We await your feedback
Thank you

@sgiraz @AntonioConsilvio @maggia80 @Fabrizio69

[GiulioRomualdi]

During the today demo we noticed the same behavior described in the first comment of this issue. Next time we perform one test I will add the plots of the joint tracking in this issue

[simeonedussoni]

Actually this can be a known issue with the wrist, which provisionally is set to go back home if forced to exit the physical boundaries. This was intended as a safe measure altough questionable and we are already working on it. Moreover in the next version we will have mechanical hardstops preventing this kind of events.

Anyway as usual it is very important to have the position data in order to understand if this is the cause or other effects are active, thank you.

[SimoneMic]

I don't know for what reason but this post from Simone Micheletti is not available for reading here,

Yesterdey we were doing some tests with the walking-controller using the joint retargeting for the upper body (same as teleoperation).
After sending to both wrists the same setpoints, we noticed that the phisical joints were not in the same position as the photo below:

MicrosoftTeams-image.png (view on web) MicrosoftTeams-image.2.png (view on web)

Here you can see from the motorgui that the setpoints and the red encoder positions are the same (for the wrists roll, pitch and yaw):
Screenshot.from.2024-02-05.17-30-07.png (view on web)
Screenshot.from.2024-02-05.17-29-51.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

Because we have to further investigate it and it's not directly connected with this issue, so I've deleted it.

[S-Dafarra]

Because we have to further investigate it and it's not directly connected with this issue, so I've deleted it.

Deleting a comment can puzzle people because they still get emails 😉 Consider editing and/or hiding if you end up in a similar situation

[GiulioRomualdi]

During the demo preparation in Rome, we noticed that the roll was not moving if moved by the motorgui

I drop here the video

VID-20240207-WA0011.mp4

[simeonedussoni]

ciao @GiulioRomualdi we succeded in tracking down the origing of this problem and in reproducing it in our bench setup. basically it is caused by the wrist not reaching the parking position in time. This can happen when launching the robot as the joints are not already at home position. This disables (only software) the corresponding DOFs, thus it can be due to this cause. It's strange that only one DOF can not be operated since because of the mech all the three DOFs require all three motors to be run. I can check if there is a manoeuver to recover this on the robot (on the setup it was sufficient to detach and reconnect for instance the CAN cable but you don't have easy access to it) other than restarting

[simeonedussoni]

unfortunately the only alternatives to restarting the robot to cure this problem are:

1. detach and reconnect the CAN cable from any of the AMC/AMCBLDC, this sends the joint in HW fault, then switching to idle and run are ok
2. push the fault button and release it. again, this sends the joint in fault and recovering from this is effective in reviving the joints

it's a good practice to start the robot with the hands as parallel as possible to the forearm to avoid this.
I don't know if during the calibration the hands are maybe not driven and free to displace from rest position.

[S-Dafarra]

In this last specific case the problem was misplaced belt that got stuck

[Lawproto]

In this last specific case the problem was misplaced belt that got stuck

This seems odd. It should not happen when these components IC_021_P_005 are effectively assembled on the physical forearm.

[AntonioConsilvio]

Hi!

This seems odd. It should not happen when these components IC_021_P_005 are effectively assembled on the physical forearm.

This component had detached, which was probably the cause of the problem.

@fbiggi upgraded the forearm mechanics and replaced the damaged components (including the belt)! Now the belt is correctly positioned and the problem should no longer occur!
The robot has been tested and it is working properly! Closing!