A couple of problems related to Teo movements

roboticslab-uc3m / teo-main

TEO full-sized humanoid robot: super/meta repository.

http://roboticslab.uc3m.es/roboticslab/robot/teo-humanoid

GNU Lesser General Public License v2.1

4 stars 1 forks source link

A couple of problems related to Teo movements #22

Closed jgvictores closed 6 years ago

jgvictores commented 7 years ago

From @rsantos88 on November 14, 2017 17:28

There are a couple of problems related to Teo movements and it can ruin a demonstration (leading to reset it several times... :sweat:)

The first occurs randomly, when the program sends a sequence of movements, for example salute, composed by four movements: lift arm up, axial arm turn in, axial arm turn out, move arm down. We can see that this movement is not executed correctly in certain occasions. The arm finishes the movements early, running all at once and not sequentially. This can produce a freeze of all the demo, because the movement has not finished correctly all the sequence. Can it be a problem with checkMotionDone() function? Why does it works well sometime and sometimes not?
Other problem observed is, when Teo makes a movement (I would highlight axial movements), sometimes is not finished and the joint starts to shake (like a parkinson). This may take a while (shaking horribly) until the movement finally ends.

I don't know where I can post this problems, because the first can be a software problem, but the second it can be a tunning motors problem ¿? I don't know I need some ideas to solve it.

Copied from original issue: roboticslab-uc3m/questions-and-answers#34

jgvictores commented 7 years ago

The first occurs randomly, when the program sends a sequence of movements, for example salute, composed by four movements: lift arm up, axial arm turn in, axial arm turn out, move arm down. We can see that this movement is not executed correctly in certain occasions. The arm finishes the movements early, running all at once and not sequentially. This can produce a freeze of all the demo, because the movement has not finished correctly all the sequence. Can it be a problem with checkCanBus() function? Why does it works well sometime and sometimes not?

@rsantos88 I doubt this is related with checkCanBus(). It should be more related with checkMotionDone and delays. Could you link some example code where this happens?

Other problem observed is, when Teo makes a movement (I would highlight axial movements), sometimes is not finished and the joint starts to shake (like a parkinson). This may take a while (shaking horribly) until the movement finally ends.

That definitely looks like a driver tuning issue. Not that it has a simple solution, we're joint-level PID controllers for changing loads with coupled joints and links (a.k.a. complex multi-body dynamics).

rsantos88 commented 7 years ago

@rsantos88 I doubt this is related with checkCanBus(). It should be more related with checkMotionDone and delays. Could you link some example code where this happens?

Sorry @jgvictores . It was a mistake. I meant checkMotionDone(). You have examples in teo-self-presentation demo, with salute movement here. This state call to jointsMoveAndWait which makes use of the checkMotionDone() function. Don't be scared if you see that part of the code regarding the left arm has been commented. This is a temporal solution for the problems caused by the change of piece that is being made for the rotation of the left wrist (like this). Other example, can be in follow-me demostration, with salute movement or the arm swimming. In the arm swimming case, you can see that the arm doesn't finish its movement or it stays frozen for a while until it regains the swinging motion.

jgvictores commented 7 years ago

General programming recommendation: I'd recommend introducing a small delay before the checkMotionDone() (as commented somewhere among YARP issues).
Note on movement and sincronization of movements: Note that in the cited functions, velocity (not duration) is set to the same for all joints. This that the joint that has to move less arrives first, the second smallest increment reaches second, and so on.
Note on arm swinging: Note that arm swinging is pretty hackish. Cycle time should be adapted to the velocity. I would not point to it as a reference at all.
Note on GitHub issues: Please point to the specific commit (press y to get it on you URL, it works a bit more as a permanent link than without it).

Please provide feedback after implementing (1) and taking (2) and (3) into account. Thanks!