Page 1 of 4 1234 LastLast
Results 1 to 10 of 39

Thread: Burnt MOSFET in MX64T Dynamixel Servos

  1. #1
    srmhmd Guest

    Burnt MOSFET in MX64T Dynamixel Servos

    I was testing the MX 64T motors using USB2Dynamixel in ROS running on Ubuntu 14.04,The motors are almost an year old.I got an error saying the motor was not found.But other motors were working fine.I felt the motor was slightly hot. So,i let it cool for sometime. and tried it again in Windows using Dynamixel Wizard software,it recognised the motor I got the error 5 in the wizard.It was slightly hot again... switched off power and let it cool. then when i tried it again with the Dynamixel Wizard it did not find the motors.

    When i opened the motor i found that the Mosfet inside the was burnt.what could have possibly gone wrong?


    POWER SUPPLY used:12 Volt lead acid battery(i have been using these for the Dynamixels )

  2. #2
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,317
    Images
    27
    Rep Power
    284

    Re: Burnt MOSFET in MX64T Dynamixel Servos

    The overload/overcurrent shutoff function is not very responsive (the MCU can take up to several seconds to cut power), so a sudden stop while the horn is moving at high speed, or if the horn is stalled well away from the goal position, can lead to a high current condition that will damage the H-bridge and/or motor brushes. The easiest way to prevent damage is to decrease the 'maximum torque' value (puts a limit on the PWM duty cycle driving the H-bridge, which decreases maximum current through the motor) and/or ensure the servo never crashes into anything (which can also damage the gearset and/or frames).

    jwatte lost several servos to similar causes (and hardware issues on a revision/batch of MX servo control boards), and once some servos had received damage to the motor brushes they would often act as 'vampires' by causing voltage spikes that eventually damaged other servos on the bus. Damage to the H-bridge may also have caused damage to the motor brushes, so check the motion of the horn for 'stickiness' or unusually large 'drag' to determine whether you also need the motor replaced to prevent damaging other servos if you get the control board replaced by Robotis.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  3. #3

    Re: Burnt MOSFET in MX64T Dynamixel Servos

    The best way to tell whether a servo has a damaged motor, is simply to enable torque (without a goal position.)
    If the motor draws more than 50 mA when idling, the motor is bad.
    If you can't even ping the servo, then it's more likely the circuitry is bad (like, a burned-out bus buffer chip.)
    If the servo is still in warranty (< 1 year) then fixing problem 2 might be covered under warranty. Problem 1 is never covered under warranty.

  4. #4
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,317
    Images
    27
    Rep Power
    284

    Re: Burnt MOSFET in MX64T Dynamixel Servos

    If any part of the H-bridge is already dead (the two little SOIC-8 ICs nearest the motor), then it is very unlikely that one could actually enable torque. Even connecting that servo to power risks further damage to the servo's motor, other servos on the bus, and the power source. If the H-bridge failed open, then there would not be much risk as there should never be any current through the motor and there will no short between the voltage source and ground. But if any of the mosfets failed closed/short, then connecting power to the servo will result in heat and possible damage to other components in the system as the voltage supply gets shorted to ground.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  5. Re: Burnt MOSFET in MX64T Dynamixel Servos

    Quote Originally Posted by tician View Post
    once some servos had received damage to the motor brushes they would often act as 'vampires' by causing voltage spikes that eventually damaged other servos on the bus.
    So, is it better to have several buses on one robot? For example, for a six legged robot, one bus (i.e. one usb2ax) for each leg. Will this kind of "one bad motor causing damages to other motors on the bus" issue happen if the legs share a common controller (such as raspberry pi) and battery source?

  6. #6

    Re: Burnt MOSFET in MX64T Dynamixel Servos

    Will this kind of "one bad motor causing damages to other motors on the bus" issue happen if the legs share a common controller (such as raspberry pi) and battery source?
    The best solution is to not fail motors!

    But, yes, that would be one way of mitigating potential disaster.
    Another might be to add a small inductor on the TTL bus between the output driver and each strand. For a hex, you would have one strand for each leg. The circuit would look something like:

    Code:
    I/O -+-- L --- Servo --- Servo --- Servo
         |
         +-- L --- Servo --- Servo --- Servo
         |
         +-- L --- Servo --- Servo --- Servo
    ...
    You don't want L to be too high (because that will slew the signal too much) and not too low (because not enough filtering.)

    I had a 5.1V Zener at the I/O, and it got burned out by transients more than once before I figured out what was going on. Thus, a resistor from I/O to Zener, and then Zener to split, and each split has an inductor and one strand of servos, would be a pretty "safe" protection circuit. Make the resistor 100 Ohm or so (a failed-short Zener would cause no more than 50 mA of current!) and each inductor perhaps 10 microHenry. (Use low-current, high-resistance inductors. Also, measure the TTL waveform with a scope -- if it's too slow, reduce the inductance.)

    Finally, put some protection on the power lines, too. These will have about +/- 3V spikes even under normal situations.
    Perhaps a 13.8V 500W TVS would be about right? You could add one of these at the end of each strand, too. And, perhaps, a 5.1V low-capacitance Zener with a 100 Ohm resistor on the TTL line at the end of each strand as well. Couple with a 220 uF electrolytic capacitor at each servo for good measure.

    What I've suggested above is likely significant overkill for a developed system, but it would protect against certain kinds of failures/misbehaving signals. And it would protect the neighboring strands -- servos on the same strands would still be susceptible to each other's failures.

  7. Re: Burnt MOSFET in MX64T Dynamixel Servos

    Thank you for your suggestions. In your "safe protection circuit", do you mean the following:

    I/O->Resistor->Zener Diode- +-- L --- Servo --- Servo --- Servo
    ________________________|
    ________________________+-- L --- Servo --- Servo --- Servo
    ________________________|
    ________________________+-- L --- Servo --- Servo --- Servo

    (Sorry for the underlines. Without those lines, the | and + symbol get automatic alignment to the left.)

    Where do I put the usb2ax and the controller (in case of a: using an usb2ax for each leg and b: using only 1-2 usb2ax to control all the motors)? I know I/O means Input and Output but I am not quite sure what you mean by I/O in this case.

    There are several reasons I want to use multiple usb2ax. 1. To reduce the chance of damaging all the motors. 2. For faster sync read and sync write of multiple motors in each leg. 3. Possibly better cabling.

    If I want to have a dedicated usb2ax for each leg in a hexapod or an eight-legged robot, I will need 6-8 usb ports. I heard that the current version of Dynamixel SDK only supports one connection. Is there a C library that handles multiple connections?
    Last edited by Snoopy; 01-26-2015 at 01:55 AM.

  8. #8

    Re: Burnt MOSFET in MX64T Dynamixel Servos

    I would guess that your USB2AXs would act like your safe protection circuit. That is, because the USB2AX has some protections built into them. It would be interesting to see if multiple USB2AX gain you much in performance.

    As for ____ to keep things lined up. You would have better luck using code tages. you can put them in manually or you can "go advanced" and click on the # button to put in the code tages.

    Kurt

  9. #9

    Re: Burnt MOSFET in MX64T Dynamixel Servos

    1. Yes, the connection would be I/O, resistor, Zener. The idea being that when the Zener fails short, the resistor prevents the I/O from shorting out. If the I/O is already protected against shorting out, the resistor may not be necessary.

    2. The USB2AX may be able to protect itself, but it's unlikely to protect neighboring servos on the bus. The thing this circuit is trying to do is to prevent one bad ("vampire") servo from damaging (the electronics of) too many other motors. In the three-to-a-strand configuration, it's likely that at most two neighboring servos would be at risk when one servo is bad.

    3. The best solution is to make sure all your servos are good, and then never drive them into overload/interference. While developing, use 50% max torque or less. And develop with 11.1V/12V supply, not 14.8V/16V.

  10. Re: Burnt MOSFET in MX64T Dynamixel Servos

    Quote Originally Posted by KurtEck View Post
    I would guess that your USB2AXs would act like your safe protection circuit. That is, because the USB2AX has some protections built into them.
    What jwatte said.
    The USB2AX only protects itself and the computer, but will not protect the servos at all.

    Inside the USB2AX you have (see http://www.xevelabs.com/doku.php?id=...ecs#schematics ):
    Code:
    MCU --> resistor --> Zener 5.1V --> PTC resistor --> Dynamixel connector
    The PTC resistor increases its resistance when it heats up, that's for protecting the diode against continuous 12V on the Dynamixel DATA line.
    All of this creates a safety for the USB2AX itself but does not try to regulate the bus at all. If you want the sort of protection jwatte is talking about (protection for the servos), then his solutions are probably the ones you want to try - and you can omit his resistor since the USB2AX alerady has one:

    Code:
     USB2AX->Big Zener Diode------+-- L --- Servo --- Servo --- Servo
    |
    +-- L --- Servo --- Servo --- Servo
    | +-- L --- Servo --- Servo --- Servo
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Good place to find used Dynamixel servos?
    By OOrmOnIzArGoR in forum Robotics General Discussion
    Replies: 1
    Last Post: 01-03-2015, 12:40 PM
  2. Dynamixel Manager cannot find servos
    By lukeyes in forum DYNAMIXEL & Robot Actuators
    Replies: 30
    Last Post: 10-29-2014, 02:43 PM
  3. Question(s) pressure sensing dynamixel servos
    By crchisholm in forum Interbotix Robotic Arms
    Replies: 4
    Last Post: 02-24-2014, 06:45 PM
  4. Question(s) Wheels for Dynamixel Servos
    By SamQ in forum DYNAMIXEL & Robot Actuators
    Replies: 1
    Last Post: 07-27-2011, 07:56 PM
  5. Need to find a N-channel MOSFET replacement
    By librab103 in forum Robotics General Discussion
    Replies: 1
    Last Post: 09-08-2008, 01:11 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •