Sumo robot build blog
Integrating the H-bridge and its controller
This is one of those things that sounded so simple in theory, and wound up being a living hell. Bugs were found. Lives were lost. Alligator clips were placed where alligator clips should never be placed. Tracks were cut, joined, and cut again. 
Nurse! More alligator clips! I found two bugs in my PWM firmware:
- The output table was wrong. Easy fix.
- The outputs aren't initialised on startup. I'd say that it's an easy fix, but I haven't bothered doing it yet.
H-bridge bugs
More time consuming was a problem I found with the H-bridge circuit: if you're independently driving the quadrants, you need to drive them with the motor voltage.
A simple logic analyzer
In the process of building my H-bridge controller, I needed to watch what was happening on the I2C bus. I built a simple logic analyser that runs off a PC's parallel port. It's based on the active design from JWA Systems, although I have to admit that I didn't look at the schematic before I started building it. I assumed that the source code for the control software was on the website, which it isn't. Fortunately, the designer had the same idea that I did for how the thing should work.
Driving the H-bridge controller from the AVR
The following code will test that the AVR and H-bridge driver are communicating properly. It assumes that there's an H-bridge and motor attached to PWM channel 0. It will run the motor at full power in one direction, then reverse the direction every few seconds. As I soon found out, this is a pretty tough on the hardware. This is intended for the ATMega32. I'm using WinAVR for compilation.
#include < avr/io.h>
#include < avr/interrupt.h>
#include < util/twi.h>
typedef unsigned char uchar;
void delay_ms(unsigned char ms)
/* badly mangled delay_ms */
Problem: driving the H-bridges
I couldn't use the AVR outputs to directly drive the H-bridge; as ample as four PWM channels seemed before, it would only be enough for a single H-bridge. And if separate PWM channels got out of phase or had slightly different timing characteristics, the MOSFETs would be switching out of time and would probably get hot. So I'd need a separate controller of some sort.
Building the robot's motor drivers
The two designs that looked best for my situation were:
- Bob Blick's Darlington-based H-bridge. I really liked the risk-free braking behaviour of this design. I'm confident enough in my coding abilities, but I'd feel much more comfortable with a design that made it difficult to destroy hardware with software. Darlingtons have the advantage of being cheap and less likely to spontaneously combust than MOSFETs - but they'll get hot and waste a fair bit of power. Since I'm aiming to run off as low a voltage as possible, this was an issue. So I went with:
- Eugene Blanchard's MOSFET-based H-bridge. It's about the same complexity, but is a riskier and more expensive design due to the MOSFETs. It would be able to drive much more powerful motors, and heat would be less of an issue. It doesn't have the idiotproof braking behaviour, so I'd have to code carefully.
Again, I assembled the circuit on Veroboard. I really don't like Veroboard for high-power designs like this one, but empirically, I've never had a problem. My main concern was in the braking design, which routes the motor current through the ground tracks. The current is burnt off as heat somewhere, like in the tracks or MOSFETs, neither of which was particularly appealing to me. I hoped that this wouldn't be an issue in operation, where worst-case, I could be braking while getting pushed hard by another robot.
The robot's main control board
I can do microcontrollers. Let's start there.
I got pretty intimate with the Microchip PIC16F84 a few years ago, to the point of writing compilers and driving pretty much every type of peripheral from it. So I naturally figured that that would be a good starting point - moreso given that I already had programmers and chips and crystals. But after reviewing the specs again, I became less convinced. No PWM. No UARTs. Only 13 I/O lines - which seemed like a lot before - but which would probably be quite constrained on a robot.
Building a Sumo robot (in progress)
Robot Sumo is a competition based on the idea of robots shoving each other out of a ring. It's (nominally) non-destructive, unlike BattleBots and the like. The robots are autonomous, so there's a much greater emphasis on sensors and on-board intelligence.
I'm documenting my Sumo robot build as I go. This is my first robot. I am nominally trained as a software engineer, but I've done a lot of personal study on the electrical side of things as well. My mechanical skills are pretty poor. So I'll be constructing the electronics from scratch and going for a lot of prefab mechanicals where possible.
