I am dealing with a (new ?) problem since a few days. But before, here is my Poppy’s story.
I’ve begun to work with the Torso of a Poppy Humanoid (so I called poppybot=PoppyTorso() ). I’ve worked on it first in low level, and then with PoppyTorso(), even used primitives. All worked well !
And then, I decided to add his legs. Here began the problems…
All the dynamixels are configured (IDs, baudrate at 1M, limit angles), and correctly integrated to Poppy (0 is aligned).
However, when I do poppybot=PoppyHumanoid(), I always have 1 or more dynamixels of the legs which have a TimeOut. A few time, it works well. But almost always, I have these TimeOut. Do you have a solution for that ?
Knowing that in low level of Pypot.dynamixel, or using the configuration tools, the legs are working well.
I’ve just checked one more time. Yes they are all configured, including return_delay_time config.
BUT It looks like one of them has been reset . It’s weird because it was first configured… So i reconfigured it
The question is : is it possible that a dynamixel reset itself by its own ?? Because I’ve tested the legs in low level and it worked, and today, I had to configure every thing for the bugging motor (ID, angle, return_delay_time…)
I’m using 2 USB2AX, one for Torso and one for legs. And each USB2AX is divided in sub-division (cf. picture : legs USB2AX).
Anyway, even if I reconfigured the dynamixel and all of them are now configured, I still have the :
WARNING:pypot.dynamixel.error:Timeout after sending DxlSyncReadDataPacket(ids=(11, 12, 13, 14, 15, 21, 22, 23, 24, 25), address=26, length=3) to motors [11]
The bugging motor is not always the same. But I observed that it changes when I move the robot (always one of the legs’ motors), so I guess it’s a problem of cable… Do you have a solution to fix the cables definitely to the dynamixels ? (but still let the possibility to remove them)
EDIT : Another question is : why does it work in low level (never have a TimeOut problem), but not when I do poppy=PoppyHumanoid() ? Can’t I modify the configuration file to increase the TimeOut ? are there consequences ?
We already see motors come back to initial configuration we don’t know exactly why but this is probably a wrang connection on a wire (12v on the data line?). Your two problem could be the same, you have a failing wire somewhere.
This kind of problem is really dificult to locate, you have to test it one by one.
At this time we don’t have any workaround about cables. @Thot add some external protection and group his wire together but wires are extremely sought and they get old really fast. You will probably have to change it once a year!
How old is your robot ?
The Dynamixel hubs is the first thing I removed because of false contacts inside (when there is mechanical sollicitation)
I solded the wires together for the legs (just a Y wire) and for the torso (this one is much difficult, it is an octopuss)
If you want to check your wires, I advise you to list all the voltage of each motor chain by chain.
It is simple, if the voltage is different between the motors (more than 0.2V), it means there is a wire issue.
It could be interesting to have a primitive which monitor the motor chains. The user should parameter this to know the order of the motors (as each robot is a bit different)
When you work at the robot level, there is a controller loop at 50Hz which fetch position, speed load and write pos/pseed/load if there is datas to write. When you work at low level, le communication bus is probably less used, which is statistically less possible to send you timeouts.
Timeout is cannot modify with config file, but you can change it in the code here ; but it is already very high.
If you are just annoyed with this messages when you code, you can simply hide them with changing the loglevel.
The robot is about 1 year old ? It’s the Poppy @Manon used ! Actually, when I began working on it, its left leg was broken, that’s why I worked only on the torso. I’ve repaired its leg (replaced the defective motors), and here I am.
Well, I think I’ll begin by removing the legs hub to see if it works. Whether not, I’ll test all the wires by checking the voltage. The point is that I will also check if there is a 12V on the data line, as @Nicolas said.
If I really do not succeed in correcting the problem in hardware, I’ll try this… If there’s no other solution.
Thanks to all, I’ll let you know of the bug/solution.
I’ve been making some tests about the legs, here are the results :
The hub looks like good (no lost of Vcc, communication ok)
the voltages are : about 11.6V everywhere, except in the right leg, about 11.3V in the r_ankle_y and the r_knee_y. (after one cable change)
The voltage sometimes tends to fall during movements.
Conclusion :
Is a difference of 0.3V so consequent ? Because the dynamixel datasheet says that between 10 and 14V, it’s ok.
I guess I have to check the connections, maybe put a point of glue, like @Thot does.
But if it’s that, I think that it’s weird that only the legs have problem, and not the torso, since the same wires are used…
I continue testing, hoping that the problem will be solved.
PS : I see that there are a lot of problem with the servomotors/wires (connection, Timeout, dead/burnt dynamixels…). I’ll try to do a documentation about it (problems, recommendations, warnings, possible solutions…). I’ll open a post when I’ll do it if some of you wants to help
. It’s weird because it was first configured… So i reconfigured it 
Because I’ve tested the legs in low level and it worked, and today, I had to configure every thing for the bugging motor (ID, angle, return_delay_time…)
