So we have a four wheel robot using 25d 34:1 pololu motors w/encoders. We’re using a 7.4v lipo battery(so max voltage supply is about 8.4v) and the motor drivers are being controlled with a Xula2. For connections we have the not_PWM inputs grounded, a 18.75kHz PWM supply, and the direction pins controlled accordingly. The enable pin is always hi and the data ground is also connected. After deliberation we determined the vin on the data pin side isn’t necessary as long as motor power is connected.
Now for our issue, we have burned out one chip on two separate boards, which is the determination because there was only random supply to the motor on a previously working setup and swapping to our backup board resolved the issue. During running we have a very rapid control system that will independently change the speeds of each motor independently. We have not experienced any of the protection shut down symptoms, the driver just quits working and isn’t restored after setting for a period of time. Additionally the driver was connected to different motors so a high draw from a problem motor is unlikely.
I am sorry you are having problems with your dual motor drivers. Could you tell me more about your setup? Which 25D metal gearmotors are you using (the HP or lower-power version)? What kind of load is on the motors? What were the motors doing when the driver failed? Could you post pictures of your entire setup and both sides of the boards?
Here is our connection setup, and we are using the low power 25D motors. For physical connections the motors are connected with solid core wires, and the control pins are connected with 0.1" offset pins/sockets and 22ga wire. The motor board power and ground inputs are 18ga stranded wire connected straight to the board on one end, and to two bridged 0.1" offset pins from our 7.4v lipo battery source. The Xula2 is supplying 3.3v logic as well as 3.3v power to the encoders.
As for load I’m not sure what it is exactly but the robot weighs about 10lbs and has Dagu Thumper wheels.
I don’t know exactly when the drivers burned out, we ran some testing that goes up about a 7 degree incline ramp then reverses the motors and comes back down the ramp. It completed the testing and we put it on our stand and one of the motors would begin to drop off supplying inconsistent operation that couldn’t handle any load.
My team and myself are all graduating seniors in computer or electrical engineering with a fair amount of experience in; sensor data acquisition, serial communication, control systems and electrical circuit analysis. In addition, we are also contributing to a Northrop Grumman sponsored autonomous vehicle project over the last two years. I’m confident in saying we have established a very good system but obviously something has been overlooked.
I really only have two days(Wednesday or Thursday) if I’m going to add a passive protection system. So basically I’m looking for testable reasons why this could be happening. I have access to; oscilloscope, multi-meter(10A max with record function), and logic analyzer.
Since you are not sure of the torque requirements of your robot, it is hard to say for sure, but it sounds like those motors might be under powered for the load you have. You mentioned that your test reverses the directions of the motors. When reversing a motor’s direction quickly (i.e. changing from full speed forward to full speed reverse), it could briefly draw up to twice its stall current. If that happened, the motors you have running at 8.4V could draw over 6A, which could definitely damage the MC33926 Motor Driver Carriers. I am not familiar with multimeters with recoding functions, but if it is fast enough you might be able to use it to record the spike in current when your motor changes directions. If you have access to a current probe for your oscilloscope you should be able to see any current spikes with that as well.
How many times and for how long did you run the test before each board was damaged? Have you tested the motor that seems to have inconsistent behavior by supplying it with power directly to determine if it is the motor or the driver that is causing the issue? If you can send us a close up picture of the damaged drivers, I might be able to spot any signs of damage on the boards and better tell what happened.
