PDA

View Full Version : AX-12 motor failures



Gilrock
09-20-2012, 11:50 PM
Ok I'm starting to be frustrated. I just got a motor replaced this past weekend to get my PhantomX Hexapod up and running again and it ran just fine on Saturday. I charged up the battery and stored it till today. I pulled it out to show a group a kids at the house and when I powered it up one of the legs started to move to the right position then all of sudden reversed and spun back around and jammed itself and smoked before I could shut it down. I'm still running the original code that came with the Hexapod. I thought these motors had some type of built in protection. I have the Bioliod Premium kit built into the humaniod shape and the PhantomX Hexapod and have now had 3 of the motors fail on me with very little total runtime. I could see if I was tinkering with the code but I'm still running the stock code on everything. At $45 a motor I'm getting kinda pissed.

Gil

jwatte
09-21-2012, 11:26 AM
I would be pissed too if I were you! One of the claimed features of the AX-12 is that it has built-in temperature protection. It sounds as if it's not working right. Perhaps a software update could be made to fix that problem?

Btw: I wonder if you could run the AX-12s at a lower voltage. That would give them less power, but perhaps make them less likely to overheat?

tician
09-21-2012, 05:23 PM
If it is just the gearsets, they are easily replaceable for ~$6 each. If it is the motor, they run about ~$11 each as of May 2012 (via RMA with Robotis). Not sure about the control board.

What voltage are you running at (running at too low a voltage can cause instability, corrupted packets, random reboots, etc)? Are the joints assembled correctly? Have you updated the firmware via the RoboPlus Dynamixel Wizard?
For the humanoid, are the Task and Motion files the most recent versions and for the correct assembly (Type-A, Type-B, and Type-C Humanoids all use different files) from the Robotis support website? What revision of the sketches are you using (Nuke generated IK or sequence of static predefined poses)? If the servo was brand new, was it in servo mode or wheel mode? Either being in wheel mode already, or suddenly switching to wheel mode because of corrupt packet or operating instability, might explain the sudden reversal in direction.

As for temperature protection, yes, it does exist. No, it will not protect against sudden overload (only protects against long term use at high torque/current/PWM values). There is no current sensing on any of the smaller dynamixels (I think EX-106+ and MX-106 were the only versions with it, but MX-64 might have it as well). Without that current sense capability, it has to rely on the position sensing (and lack of motion for a predetermined time) to trigger the overload shutdown. Damage is more likely to occur when the servo is trying to move a large rotational distance (will use high torque/current/PWM values to get there quickly). If it encounters a sudden immovable obstacle while moving at high torque/current/PWM values, it may not decrease the PWM value quickly enough to prevent unsafe torque/current/PWM levels or realize quickly enough that the horn has locked up at high torque/current/PWM to engage the immediate overload shutdown.

Gilrock
09-21-2012, 08:58 PM
Yeah I'm afraid it's neither the gears or the motors. When this 3rd motor ran the wrong direction I removed it from the robot and took off the cover and pulled out the gears that interfaced with the motor. I pulled it back in to see if it would turn without the motor attached to anything and within 2 seconds I saw a spark shoot out of the middle of one of the small chips just above the motor. So that chip blew up with no load on the motor unless the motor was somehow frozen internally. Also one of my other motors when it failed I saw a puff of smoke come out. That happened while I was walking the hexapod.

Voltage is fine...I usually don't run the robot that long. I've probably barely powered it up 15 times since I got it. That's why I mentioned I had just recharged the battery so it would rule out low voltage. I'm using the battery that was sold with the PhantomX.

It's been over a year since I had last messed with the Hexapod but I don't think I've ever reprogrammed it. It came preloaded with software that ran fine. All the legs were attached correctly...like I said I've run it several times and seen it perform correctly. I'm used to having to get the legs positions facing down at power up cause it seems to want to take the closest move to the goal so if you start with a leg too high it moves the wrong way at startup. This recent failure the leg just moved the wrong way for no reason.

Gil

jwatte
09-21-2012, 11:06 PM
It's been over a year

If you're saying the blown bit was a capacitor, perhaps they used really low-rate capacitors? The rated life for the cheapest grade of capacitors is on the order of 14 months (!)
(Which, btw, explains why things always fail right after the warranty runs out ;-)
Also, capacitors are notorious for being finicky, and sometimes out of spec or failing prematurely, especially if heat is applied. Again, the cheaper capacitors are worse.
It would be a shame if the AX-12 simply used shoddy parts, but it's totally possible, given that the "typical" servos from Robotis are > $200.

tician
09-22-2012, 06:24 AM
Yeah I'm afraid it's neither the gears or the motors. When this 3rd motor ran the wrong direction I removed it from the robot and took off the cover and pulled out the gears that interfaced with the motor. I pulled it back in to see if it would turn without the motor attached to anything and within 2 seconds I saw a spark shoot out of the middle of one of the small chips just above the motor. So that chip blew up with no load on the motor unless the motor was somehow frozen internally. Also one of my other motors when it failed I saw a puff of smoke come out. That happened while I was walking the hexapod.
If the servo had already failed, then the part was likely damaged (and sparking) well before you opened it up to see it spark. Approximately how many leads/pins are there on the part that sparked? On the side of the pcb with the cans of the electrolytic capacitors, there are a couple multi-pin logic ICs for interfacing to the dynamixel bus, a voltage regulator, and several passives (two pin resistors and ceramic capacitors). On the opposite side, there are several more passives, the 32-pin main controller, and two identical ~8-pin MOSFET half-bridge drivers near the motor.

For the servo that smoked: how bad was the accompanying smell? The black resin encasing most ICs produces a powerfully horrible smell that tends to linger (blew up an opamp recently and the stench was stuck in the room for a couple hours and stuck in my head for much longer). I don't recall any stench from failed ceramic chip capacitors or any cheap chip resistors, but I seem to remember a smell from blown/leaking electrolytic capacitors (I may just be remembering the generic smell of old electronics that tended to be collected in the basement during my childhood - low to moderate hoarding seems to run in the family).


I'm used to having to get the legs positions facing down at power up cause it seems to want to take the closest move to the goal so if you start with a leg too high it moves the wrong way at startup. This recent failure the leg just moved the wrong way for no reason.
That first bit sounds like a pretty serious software error that is not necessarily just the servo. Moving the wrong direction on startup sounds a bit like the code running on the arbotix (IK engine?) is somehow getting confused and sending the wrong goal positions because the current sensed position is out of its expected range. The joints of the hexapod should be arranged so that the ~30 degrees not controllable in servo mode are not required in normal operation. If the current position is say 10 and the goal position is 1000, the horn will not rotate CW over that ~30 degree dead zone even though it is the shorter distance, but will instead spin CCW over the 990 position counts where the potentiometer produces valid values. This behavior can sometimes get annoying with the MX-series (if you want continuous rotation with position control like the pan axis of a turret) since they have full 360 degree sensing and the shortest distance could be 1 count of CCW rotation from 4095 to 0, but it will instead spin over the entire range 4095 to 0 in the CW direction.

Gilrock
09-22-2012, 02:37 PM
On the motor I opened where I saw it spark it was definitely one of the twin MOSFET chips. Both of the motors that smoked had that terrible electronic's smell tician mentioned. The third motor happened much earlier on the Bioloid and my son was controlling it so I'm not sure what happened there. We did end up with a motor wire getting pinched. That's one of the things I didn't like on the Bioloid Humanoid is that I can't seem to route the cables where they will never pinch but still look nice. And on the PhantomX I wish they came with a cable that went straight from motor to motor on the legs instead of wrapping it around. The smallest cables have about 1.75" of wire and are at least 1/4" too short. The next size up is at least 1" too long with no where nice to tuck the excess. So I ordered some pins to rework the cables.

I'm in a robotics club at work but I haven't been active lately. So I stopped by their workshop meeting yesterday and they said it's pretty common for those FET's to blow up. These guys built the mech warrior named RA that was at the Mech Warrior competition earlier this year. It was kinda cool to see the stuff their working on and got me excited to start working on something robotic again. I had two motors that are already in the mail before this last one failed but I had planned on using them to start designing a robot to turn and solve a Rubik's cube because that's what my son is into.

Gil

tician
09-22-2012, 04:48 PM
Cannot definitively say that I have ever seen the P/N MOSFET half-bridge fail before. We've had a lot of dynamixels for several years and I guess we just don't abuse them enough. We've had several AX-12+ with broken gearsets and one with a damaged motor (currently sitting on the floor about two feet away) (when disassembled and disconnected from the gearset, the motor pinion will spin only if a user begins it moving with a flick and will quickly stop and trigger an overload shutdown - don't recall any sparks, but it could be the FETs and not the motor). The MX-28's have not been so lucky: one RX-28M in the knee of a DARwIn-OP had its motor destroyed when a theater student dropped it off a table and the most recent casualty (another original RX-28M) had the spline completely sheared off the output gear when another theater student dropped it about 4 feet (the only thing holding the arm was the bolt in the horn - could literally unscrew the arm off the bot). One nice thing about the DARwIn-OP software is that it uploads to every servo its own preset CW/CCW angle limits every time it restarts to ensure that no servo can kill itself too easily.

Upgrayd
09-22-2012, 06:48 PM
This really sounds like you have an electrical issue.
Inspect your cables and make sure none of them are pinched or damaged.

Gilrock
09-22-2012, 11:03 PM
This really sounds like you have an electrical issue.
Inspect your cables and make sure none of them are pinched or damaged.

Easier said than done. Most of the cables in the legs are tucked down into the wire channel and tie wrapped in a few places cause as I said earlier they have to wrap around the leg. It's actually almost impossible to get them back out without damaging them if they aren't already damaged going in. It's really poor design in those brackets. The wires are too big to tuck them in there and half the tabs end up breaking. I've ordered pins so I can shorter some of my extra cables and replace the ones on the legs that wrap around.

Gil

darkback2
09-23-2012, 10:32 AM
Unfortunately a pinched cable can cause pretty serious damage that seamingly spreads from servo to servo. he fact that you replaced a servo and then had the same thing happen again strongly suggests that it is not the servo. It is most likely a bad cable which will only continue to cause frustration.

As for the "servo spining the wrong way" problem, AX-12s do not hve 360 degree encoding. If the servo is somewhere between 300 and 60 (not sure on the actual numbers) then it will sometimes take the wrong path to its goal position. This happens with Hikari's shoulder servos if she has bee laying on her back and her arm is over her head and I tell her to stand up. The arm twists all the way around instead of just coming down.

I know ripping the bot apart to inspect a cable is a PITA, but trust me, sending servo after servo back to robotis is more so.

hope this helps more than it hurts.

DB

Gilrock
09-24-2012, 08:54 AM
To be honest I posted to vent frustration not to find a solution. I'm an engineer with a EE degree that has 25 years of experience as an embedded software developer. I'm more than capable of digging in and troubleshooting this and I'm experienced enough to know whether I did something wrong when I see a problem. There are improvements to cable routing and the design of the brackets that could have prevented any of these cable problems. I haven't opened up the software in these things yet but maybe there are improvements that could have added safety.

And in regards to the servo possibly taking the wrong path....I power up holding the hexapod up in the air with the legs facing down to prevent that situation. I saw the legs all go into the correct starting pose and as soon as it got there one leg reversed and started moving the opposite direction while I had it suspended up in the air. I immediately powered it off and pulled the leg back around close to where it should end be and tried powering it again and it moved the wrong way. So I don't know if its because these motors are delicate or the software doesn't have the proper protection or whether it's the lousy design in the cable brackets but I do know I didn't cause the problem. I will not look at this thread again.

Gil

lnxfergy
09-24-2012, 01:06 PM
I want to address two speculations that have come up repeatedly for any future readers:

1) "the servo taking the wrong path" -- if you never modified the code, and the IK at some point worked, which appears to be the case, then this should not be a problem, because the servo bracket designs effectively limit the leg from ever entering that 60-degree wide deadspot in the encoder.

2) "the leg moved in the wrong direction, and did so again after powering on" -- this really sounds like the *effect* not the *cause* of damage - in other words, the H-bridge is blown closed in a particular direction.

-Fergs