Close

And then happened...

A project log for Browser-Controlled Tracked Robot

A tracked vehicle for playing around with. Controlled from laptop for ubiqutousness, educational value and ... uh... data.

oldcrowOldCrow 08/19/2014 at 19:370 Comments

That badly behaving motor control board was not mine, by the way. It was from SeeedStudio. It's probably not a bad one, but it has insufficient suppression. I'm driving at twice the rated voltage of the motors, so a single tantalum was not going to cut it.

So I made the first version of my own design. See the photo with the single half-populated board.

Let me count the errors:

- Half the FETs (a.k.a. the N-side of the H-bridges) are tactically wired to be conductive at startup. Too fast power rise times may bring a momentary short. Yes, all gates have an NPN and a pull-up.

- I put small N-fets to the control lines so that N- and P-FETs could not be turned on at the same time. But since I remembered P-FET gate voltages backwards, the component (if populated) would make sure that both sides got turned on if the N-side was on. Shorted by bad design (potentially. Glad I caught it before wasting components).

- The board turn-on FET, which is supposed to cut power to the whole board (except the MCU that controls it) in case of low battery is active-open. Yes, if the MCU gets brown-out reset, the battery will get it, as the rest of the board starts drawing current from the already (very) empty pack.

- The MCU's timers are less easy to get running the FETs in Sign-Magniture mode than I'd imagined. It looks like I'd have to use 4 of the 6 timer channels to get it running right. No. Just no. That's a waste of perfectly good timer channels.

So, in short, time to redesign again. Next version will use a L298N. Why? Because all the SMD motor driver components need a thermal pad underneath. I'd need a reflow oven to get that right; it's un-inspectable so it needs to reflow perfectly the first time and every time.

Discussions