Various feedbacks, bugs, info [Reachy, Otis]


I am currently working on Reachy with the customized Otis (Handwriting gripper), we haven’t had the chance to use it for long, but I will try to share my thoughts and comments I find.

First of all, regarding Otis, do you have more documentation about the mechanism? Equations, transfer functions, CAD files, and so on? I opened an issue in GitHub. It would be interesting to know i.e. distance travel for the hand to the paper.

For Reachy in general, I found out that there is a high risk of backslash for the robot since after finishing a command of position the motors get lose and the traction of the gravity creates a considerable acceleration in the hand, which could cause the robot to break against i.e. a table, at the same time, while working with the head, after launching the “homing” (In this case look forward), once and trying to do it repeatedly it, the motors let lose the head making it fall against the shoulder in a not soft way. Due to the distance and weight, it does not seem it is going to break, however, besides the risk of impact, it would be better if it does not lose the current position to land the next one.
In terms of software, we have found a couple of outdated tutorials, especially in the website documentation: when trying to work with the hands. The test notebooks for the handwork right. However, the ones for the camera, as commented in other threats are outdated. We have found also the following problem when executing reachy.right_arm.wrist_fan.on() with the following error 'RightArm' object has no attribute 'wrist_fan'

Best regards

For this part, I just updated the github repository with more information, you check it here GitHub - pollen-robotics/otis

1 Like

Hi @VBorjaDD and thank you for your feedback, that’s always helpful for us!

I’m not sure to understand exactly what you are referring to. I mean there is definitely some backlash, mostly due to the motor itself but it should not be massive on the robot.

Especially, you say:

The motors have their present_position and goal_position separated in two different registers. And they should not get loose when you set a new goal position. Can you give me an example of how you control the motors when you observe such a behaviour?

This is amazing, thank you, we will come back with the feedback when we test it more :slight_smile:

Let me come back to you when I have access again to it, and I will include some video of it.

1 Like