View Full Version : Another observation on MX-64

07-21-2013, 02:03 PM
I run with the "overload" and "overtemperature" alarm shut-offs turned on. This means that when the servo detects overload, or overheating, it will shut down to protect itself.
Additionally, because I had a number of servo motors damaged before, I also have active cooling on the "knee" servos on my legs to keep them from overheating.

However, I'm not sure the heat is the real problem here. I'm trying some new IK code, and two end (ankle) actuators drove themselves into interference. They stayed there for a few seconds before the overload kicked in and they turned off. This happened three times total. I've been monitoring temperatures, and they've never gone over 40 degrees C.

Trying to move those two servos by hand now is "stickier" than fresh servos. Also, setting torque to 200/1024 and giving the servos a command to move, doesn't move them. This is the symptoms of servo motors that have been damaged -- I've sent servos with similar symptoms back for service before, and they're deemed damaged and need a $89 new motor. They're not bad enough that I'm going to send them back at this point, but this explains the mechanical problems I've seen before (but not the electrical ones.)

Thus, the conclusion is that the overload protection in the MX-64 is not sufficient to actually protect the motor from damage. The only way to keep these servo motors from damaging themselves is to *never* drive them into interference. Note even once!

07-27-2013, 09:12 AM
The only way to keep these servo motors from damaging themselves is to *never* drive them into interference. Note even once!

That's a large part of why I created PyDyPackets :)

As always, thanks for sharing continued observations!

07-27-2013, 01:50 PM
I have a third servo, a hip joint (so only horizontal load) that went into interference once (turned the leg into the body) and stayed there for a few seconds -- probably less than the 7-8 second overload detection period. This servo is now also "sticky." So, MX-64T become sticky by a single overload event, and the overload protection doesn't actually protect against this.

What's worse, is that it seems that, if you use "sticky" servos in your bot, when they move, they put out harmful spikes on the TTL bus, which eats away at the buffer circuits on all servos connected to the bus. This will initially lead to the servos pulling the TTL line down lower than 5V when idle, and eventually lead to total inability to communicate. In the intermediate state, one servo may work fine on its own, pulling the bus only to 4V, but many servos together will pull the bus down close to 0V, so the bot won't work, but each individual servo appears to work when tested alone.

07-27-2013, 02:31 PM
Although I know they are speced to handle it, you are running these at 4S voltages correct? I wonder if the same thing would happen with a 3S or flat out 12V supply. I'm not suggesting you tank more motors to find out, I'm just wondering if the higher voltage is making the effect you see worse.
When first working with my quad, your stories of MX failures made me very concerned that I might kill something very easily. I drove several of these to overload/shutdown a couple of times during initial configuration. These have always run on a 3S pack. No ill effects that I can see, and it's had a bit of walking on them since. I know there is a significant gap in the 28 to the 64 in terms of overall power, but I wonder if that's why you see the "trickle down" failure of the buffers, simply because it involves bigger spikes.

07-27-2013, 03:49 PM
That's quite possible. I've built the robot to spec as documented, so it's disappointing out doesn't actually work as advertised.
If I continue with Dynamixel, I'll probably try 12.8V lifepo, or perhaps 11.1V Lipo.

07-27-2013, 07:03 PM
Have you tried contacting the NimbRo-OP boffins at UBonn to see if they have had any similar problems with the MX-64 and MX-106 in their teen size biped running on 4S LiPo. I know they have an addition to the DARwIn-OP framework to release torque after detecting a fall, but I am curious if they decided to implement that purely out of caution or from losing a couple servos. They also have torque compensation functions to keep the torque of the servos consistent as the voltage decreases (running at some fraction of full torque at full charge and increasing load limit as voltage drops), which might help prevent some damage if the higher current at 4S is the culprit. They may be spec'd to run at 4S, but they were all optimized to run at 12V.