PDA

View Full Version : MX-64. Dead. Again.



jwatte
06-24-2013, 09:00 PM
So, after I got servos back from Robotis, I ID-ed them all using USB2Dynamixel, screwed them into the bot, and let them sit, without power.
I then re-built all my electronics, and when all that was working, I started out with a single, spare, Dynamixel hooked up.
That all worked, so I then hooked up the four strands of three servos to the same board. That didn't work at all.

First, one of the strands will pull the TTL bus down to ground. I tried only the first servo, as well as a strand of the other two servos, with two different cables, and have this same result, so at least two, possibly three, servos on that strand are pulling TTL to ground. Servo 1, and at least one of servos 2 and 3, do this.

Then, with the rest of the strands hooked up, I used a USB2Dynamixel to scan the bus, and servos 4-7 and 9-12 showed up. Not 8.
Isolating servo 8, and trying firmware recovery, fails.
Interestingly, when I just give it power, the LED turns on and off like it should.
When I give it power while the USB2Dynamixel is trying recovery, the red LED just turns on, and stays on, but the USB2Dynamixel doesn't see it.

From what I can tell, thee, or four, servos, have gone bonkers by just sitting screwed into a frame. There's been no lightning strikes, no accidentally grounded PCBs, no power supply failures -- nothing -- that can explain this behavior.
The power board gets fed 15V through a power MOSFET, and then runs that through a 33 uH 14A inductor and a 220 uF capacitor, as well as being guarded by a 16V 5 kW unidirectional TVS to make sure it's not overvolted. Rise time from zero is about 13 us/V, with about a 300 us overshoot of +3V before it settles to 15V (no ringing other than that.)

The TTL bus leg is fed by three out of four buffers on a 74HC125 tri-state buffer, with 68 Ohm resistors to each. This is in turn fed by the 5V from an Atmega 32u4 board. The TTL bus also has a 10 kOhm pull-up to 5V, and a 5,1V Zener diode for protection. This diode has not failed. And, working servos run through this set-up work fine. Rise and fall times are pretty sharp, clearly good enough for 2 Mbit, with no ringing (over-capacitance.) When using the Dynamixel straight to a single servo, there is significant ringing on the TTL bus, btw -- I'd say about a volt p2p (which is beyond specifications for the buffers in the servos -- -0.3V is the absolute minimum...)

Basically, super smooth setup, and the working servos work fine. Some servos just decided to die between provisioning and service.

If there was some catastrophic event I could point to, or some obvious bad design on my part, I could accept this, but at this point, the only conclusion I can draw is that these devices have failed from shelf life (what is it? Two months since I got them back?)

At this point, I really do fear that I've spent a zillion dollars on a product that can't be made to work.

(Edit: Measured some more. Three won't answer to recovery. One will answer to recovery, but won't then be pingable on any of the 9600, 57600, 1000000 or 2000000 baud rates. Tried with two different USB adapters. Other servos answer just fine.)

Th232
06-25-2013, 12:57 AM
I don't have anything to say other than that I'm feeling horrible for you...

tician
06-25-2013, 06:12 AM
I really hope they have been performing some sort of fault diagnosis on these instead of just clipping the dead boards out of the servo and tossing them in the trash because this is ridiculous. You are not alone in losing newer Robotis products to non-responsiveness, but.. damn... you seem to be getting smacked with it too frequently. I am really hoping it is just a bad batch of parts (full-to-half duplex logic IC, STM32, or TX/RX filters) that got into their supplies and not some stupid design flaw. If it is design flaw, it is shared by the MX-28 and CM-900 since we've had non-response failures in both of them as well. There was a thread on the CM-900 forum about a CM-900 not working with dynamixels unless programmed using a JTAG, but not really sure of the specifics of that dynamixel bus 'failure'.

jwatte
06-25-2013, 12:15 PM
Yeah, I'm starting to suspect a bad batch of PCBs. Or a bad batch of TTL buffer chips. Or some design problem where using the STM32 is different from the AVR8 and not sufficiently compensated for in the design.

Xevel
06-25-2013, 01:05 PM
That is rough :(

tician
06-25-2013, 01:31 PM
The RX-28M in our oldest DARwIn-OP use the same STM32 as all the other dynamixels, but have never had the non-response problems. The CM-900 uses a different STM32 from the dynamixels and CM-530/730, but has had the non-response problem. I just examined the internals of a (somewhat) newer MX-28 to check what logic IC it uses for full-to-half duplex conversion, and it still has the older HC126 and HC04 pair. We already sent back the non-responsive servos a while ago, so no way to check if they had moved to the single 2G241 IC like the CM-900. It could also be a problem with the little Amotech EMI/ESD filter array that is usually found on the RX/TX lines of Robotis products (AVRC5S05Q050100R on the CM-900) or any of another number of causes, and it annoys the hell out of me that I still have not yet figured out the specific reason.

tician
06-25-2013, 01:43 PM
I probably should also correct my older posts about the CM-730 having an inductor on the dynamixel line. It is actually for the buck converter that powers the various ICs and 3.3V LDO for the STM32, and not for input supply smoothing.

escott76
06-25-2013, 02:30 PM
and it annoys the hell out of me that I still have not yet figured out the specific reason.
I would imagine that it is annoying the hell out of Robotis as well...
I hesitate to even say anything, but so far the 12 MX28's that I just got are performing fine. I hope this remains the case...

tician
06-25-2013, 05:30 PM
I would imagine that it is annoying the hell out of Robotis as well...
I hesitate to even say anything, but so far the 12 MX28's that I just got are performing fine. I hope this remains the case...
If they are ever going to stop responding, it will probably be early on. The two MX-28 that went to Taiwan were barely used before they failed (one stopped responding and the other just crapped out - might have been the really high humidity and/or long-ass flight) and the v1.01 CM-900 both kicked relatively quickly when debugging the HaViMo2 library with two AX-12 and a HaViMo2 on a Robotis 12V SMPS.

KevinO
06-25-2013, 06:41 PM
Her Tican you might know....what is all the stuff on the Robotis SMPS aside from the Caps is that all for that dang little LED?

tician
06-25-2013, 06:58 PM
Not really sure there is anything special about them other than being pretty reliable. Only one out of more than a dozen has ever approached anything considered 'dud'. That SMPS had been horribly abused by the theatre students for months on end and may have become slightly unstable as several servos popped their H-bridges when powered by it. It may simply have been heat/impact damage to the servo electronics and/or motor during regular usage of the bot, but trashed the SMPS to be safe and had no more H-bridge failures thereafter.

jwatte
06-25-2013, 08:03 PM
trashed the SMPS to be safe and had no more H-bridge failures thereafter

That is interesting. I've heard of another bot that went paws-up after running low on battery. I often run with a 5A benchtop supply without necessarily also using the LiPo as a buffer; maybe I should stop doing that. Although I don't quite see the theory for why this should be a problem -- if the servos draw more than 5A, the voltage will simply drop, which *should* be safe...

tician
06-25-2013, 10:20 PM
That is interesting. I've heard of another bot that went paws-up after running low on battery. I often run with a 5A benchtop supply without necessarily also using the LiPo as a buffer; maybe I should stop doing that. Although I don't quite see the theory for why this should be a problem -- if the servos draw more than 5A, the voltage will simply drop, which *should* be safe...
I'm pretty sure it was more an over-voltage rather than under-voltage problem (regulation failure/instability).