Next revision needs better motor driver IC

BrickPi
1

Hey everyone,

Been playing around with BrickPi on my Raspberry Pi + Camera module to make a red ball following robot, using the easy OpenCV2 python wrappers and BrickPi Python API. Video showing it here: http://youtu.be/TggP78LQnak

I am using a 3-cell 1.3 Amp-hour LiPo pack. When fully charged its probably a bit too high Voltage, i’d be more comfortable with a 2-cell LiPo pack with higher capacity.

During my testing, twice now the motor driver IC has blown - first was because I put two motors on the one driver (port A and B) and a little bit of backwards - forwards motion caused a fizzle and pop of that driver. I replaced the IC with a L293D. The duty cycle maximum in my code, due to the voltage of the battery pack, always been less than 70% ( 180 / 255 as max PWM value)

More recently I was testing again, and had a mishap in my code which caused momentary high PWM duty cycle for a few seconds of oscillating motion while tracking the red ball in front of the robot, which caused a very exciting fireball on the remaining SN754410 driver IC, which i’ll now have to replace with another L293D.

I suggest for the next hardware revision that a far better motor driver IC is used, one that uses MOSFET output stages rather than these 30 year old technology Darlington PNP drivers. The ABSOLUTE MAX RATINGS page of the SN754410 datasheet show power dissipation is 2 Watts, which when powering Lego NXT motors leaves zero margin for error, especially if two motors are being driven by a single package.

An example of a more suitable Motor Driver IC is the Toshiba TB6612FNG dual channel full H bridge driver, which has a lower input voltage but has better efficiency with less dissipation for the current requirements of the NXT motors. Datasheet can be seen here: https://www.sparkfun.com/datasheets/Robotics/TB6612FNG.pdf

There are plenty of other, newer ICs with MOSFET driver output stages which do NOT dissipate P ~= 1.4V * Current, rather they are a function of On resistance times square of the current.

In this video http://youtu.be/zOFlJJj8pPA?t=5m11s You can see that using just a single one of these Toshiba drivers mounted on the Baby Orangutan Robot Controller, I was able to power (using LiPo batteries too! Although a lab bench supply is shown for some tests while the lipos recharged) two Pololu 25D Gearmotors (47:1 ratio) to operate my Segway balancing robot. This design inherently has repeated reverse currents and stalling currents, yet the single surface mount driver IC running at 11.1V was operating without failure. At numbers of 1000+ these ICs are AUD$1.5 each.

As a side note to admins who read this topic, I’ll be in Vancouver from Sept/Oct with a 2 year working permit and visa, I am interested in assisting with a far better design overall for the next BrickPi hardware. There are numerous issues and downfalls with the existing product, mostly with power stages (where is reverse polarity protection!?) and motor drivers as mentioned, but also in the inefficiency of having dual ATMEGA328P. I am a qualified Robotics/Mechatronics engineer with circuit design specialty and 2 years experience in professional circuit design and product design, having designed and built numerous successful projects.

2

Thanks for this post! So many things to consider here.

First, what an awesome video! Do you have any more information about the OpenCV aspect of this project? We’ve been playing around with it the past month for another project, and haven’t gotten it to work as well as you have in the video. Could we convince you to share the code?

If you’ve looked through the forums, there have been a few folks that have had the same problems with the motor drivers. As much as we’ve tried, we haven’t been able to replicate the problem. We’ve seen for example, at higher voltages (12V) the chips can overheat. But when they do, they always bounce back.

That being said, we definitely want to improve the design. With the new B+ just released, we see the perfect opportunity to, and we’ve started to round up all the suggestions about what we could do better.

A question for you about the IC drivers you used / suggested:

Looking for the L293, there are only a few types that can handle the 1A load. http://www.mouser.com/Power/Power-Management-ICs/Motor-Motion-Ignition-Controllers-Drivers/_/N-6g7mh?P=1z0wd73&Keyword=L293&FS=True
The L293D seems to be able to handle only a 600 mA load. Am I reading the datasheet wrong?

Also, the L293 seems like an ideal solution: it could be dropped into the current footprint in a pin-for-pin replacement. Is that correct?

Since we’re in the process of trying to redesign the project now, please let loose with any other problems you see! We really appreciate the feedback and now’s the ideal time to tell us!

3

Seriously though about the video: if you’d be interested in doing a guest post, or telling us more, we would really like to be able to share the project so others can build something with OpenCV as well.

4

Hi Admin guy/girl,

Please, do not look at the L293 (or the D version. yes you read the datasheet correctly) as indeed it’s worse in terms of current handling than the SN754410, but it was the only easily obtainable exactly pin-compatible device I could get my hands on for fast re-work repairs. I would have got another SN754410 for the repair if I had the time. The reason why my L293D has not blown up is that i’ve been more careful in software, and made a “ramp speed controller” that my state machine updates each cycle. This dramatically slows down my robot’s reaction time though!

I shall share the code for you, I have written the vision section as a seperate module. Though surely I can just work for you and you can have all my skills and experience for all manner of software, firmware, circuit design! I will post the code soon, where is the best place?

5

Also looking at the TB6612FNG, it doesn’t appear to back emf protection. How would you address that, or do you not think that’s important?

6

There are either discrete diodes in the silicon, or there is at least the ‘body diode’ of the MOSFETs used in the output stage. As shown in the attached picture, the datasheet Page 3 shows the output stage for Output 1 and 2 with back EMF clamping diodes illustrated as built-in. Unless someone is using the attached motors as generators, the built in diodes are sufficient for that sort of power-handling.

As I said, that was just one example where I’ve used quite high power motors with that Toshiba motor driver IC, using MOSFET drivers rather than Darlington transistors, to achieve a fare more durable, efficient, and less destructive motor driving system for robotic vehicle or other strenuous uses.

7

In addition to above, if you wanted to ‘idiot proof’ your designs even further to ensure zero chance of back EMF related failures, if perhaps your customers decide to do strange things with the motors while not powered - consider placing your own diode clamps externally, in the same fashion as those shown in the datasheet (so they would be in parallel, circuit-wise). Something very small, surface mount, and cheap like this is perfect:

http://www.digikey.com.au/product-detail/en/MBR0530/MBR0530DKR-ND/2053226 which are 7 cents each in 1000+ quantity, for peace of mind.

8

BTW, I’m John and Karan is lurking (both engineers). We’re both dudes (just to take the mystery out of it!).

That’s interesting about the SN chips and LD chips. Since we’re redesigning everything, it should be doable to make a full change to a new chip.

Yes, I think the next version should be as robust as possible . . .

9

Hi John and Karan, i’m pleased to [cyber]meet you both! I am Kyran.

I believe it is very important that you do a redesign of the entire PCB, and indeed select a new and more robust motor driver IC, and implement reverse polarity protection on the input header. I suggest, seeing as there could be many amps going into up to 4 motors, that you use a P channel MOSFET rather than a Schottky (or other) diode-based protection.

Also perhaps it is because I’m in Australia, but it’s extremely hard for me to load your forum pages, in both Chrome and Firefox, I must create new tabs, and constantly try refreshing before it finally shows me the page. I suspect the webserver/host has a very short time-out that doesn’t allow easy access from all the way over here in Australia. See if your tech dudes can increase the page request timeout?

I would like to discuss design with you more, but until the website/forum loading issue is fixed for me, it’s going to be quite difficult. Perhaps you can email me on kyfindlater@gmail.com or message me somehow, maybe Google+ or something.

Isn’t it in the wee hours of the morning in Canada right now? Go to bed guys haha. Although mid-night designing is always fun.

10

Just a quick update: it probably wasn’t your fault. We just migrated to a new hosting provider, and had to rebuild a bit of our site. https wasn’t behaving very well.

Will shoot you an e-mail now.