search

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

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

Closed GiulioRomualdi closed 4 months ago

GiulioRomualdi commented 8 months ago

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

https://github.com/robotology/icub-tech-support/assets/16744101/22cf9f86-b667-4574-a809-998db21c7865

How does it affect you?

Related to this demo:

sgiraz commented 8 months ago

cc @simeonedussoni @fbiggi @Fabrizio69 @Lawproto

fbiggi commented 8 months ago

we tightened the transmission belts We await your feedback Thank you

@sgiraz @AntonioConsilvio @maggia80 @Fabrizio69

GiulioRomualdi commented 8 months ago

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 commented 8 months ago

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.

simeonedussoni commented 7 months ago

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.

SimoneMic commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

I drop here the video

https://github.com/robotology/icub-tech-support/assets/16744101/8aee1195-5e1f-4439-b1a9-33176e08d75b

simeonedussoni commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

Lawproto commented 7 months ago

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.

immagine immagine

AntonioConsilvio commented 4 months ago

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!