-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ergoCub 1.1 S/N:001 β left-wrist suddnley move in a given configuration while teleoperating #1728
Comments
we tightened the transmission belts |
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 |
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
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 |
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 |
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 |
unfortunately the only alternatives to restarting the robot to cure this problem are:
it's a good practice to start the robot with the hands as parallel as possible to the forearm to avoid this. |
Hi!
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! |
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:
The text was updated successfully, but these errors were encountered: