Browser-Controlled Tracked Robot

I see that at least a few competing projects are missing log entries and/or video links. So I'll just submit and see what happens. I'll likely be disqualified. But maybe my project will haunt some last-minute voter. Muhahaha-ha.

Well, damn. Now I notice that a video is mandatory. And it has to be on Youku (is that a Chinese site?) or on You(are being watched by Google-land Security)Tube. I can make a video, sure. But I'm not making a Google account. And it's a bit late to ask someone else to do it, since it's near midnight on the 19th now. Oh well.

Disappointment-induced ranting:

Is it just me, or is HackADay having an unhealthy relationship with Google? These pages seem to work best in Chrome. Chrome translations are often mentioned. And there are a few very conspicuous bugs visible when viewing the IO pages on Firefox. Like, say, the images are cropped a lot in the project view. My PCB photo seems to be... uhh... vibrating? Shaking? Glitching positionally by a few pixels? And if I decrease window width to any less than 800 pixels, then the image thumbnails move and stretch to fill the window. Overall website execution points to a competent engineer, so the only remainingexplanation is that it wasn't tested with all browsers. Perhaps not even with two.

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.

I started this project about 8 months ago. The first thing I tried was to just slap an arduino on top of a Raspberry Pi and attach a motor driver board. In the photo with the chassis you can see the Arduino-compatible (from Watterott) on top of the RasPi. Fine and dandy, except the motor controller gets jammed to 11, if I increase input voltage over 8 volts and start a motor.

Well, at least my web interface works.

Ok. Let's see. A prize entry needs documentation. OK. Let's add some photos.