electronics
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.
Building a Sumo robot (summary)
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.
High-power LED mountain bike light
In preparation for the 2006 Sydney 24 Hour, I wanted new mountain bike lights. Last year's light was a 20W halogen globe and two packs of ten AA cells. This was nice and bright, but the battery packs got rather hot and only lasted about 40 minutes each.
This year, I raced solo. Recharging two battery packs per lap wouldn't cut it. My plan was to spend about an hour per lap - each lap was 10km - and sleep for an hour or two when I charged the batteries. So I was aiming for 3-4 hours battery life at about the same brightness as a the 20W halogen.
The new system weighs 715 grams and lasts for about four hours at 9 watts of output. Charging the batteries takes under two hours.
Ultimate Luxeon K2 bike lights (in progress)
So after my recent set of mountain bike lights, I decided that I was ready to build what would be my be-all, end-all set of bike lights. These would be it. The Ultimate.
After the mountain bike lights, I wanted lighter, brighter, and longer battery life. I wanted to be able to use them for long road rides - so they can't use a bottle cage. I wanted to be able to commute without having to charge the battery every night. I wanted even more power for mountain bike riding and scaring pedestrians. I wanted lighter weight, so I could use them for fast group rides.
There are a number of bike light projects on this website:
|
The best batteries in the world...
... are NiMH AA cells.
It's quite simple:
- They store a lot of energy. Decent quality cells are rated at 2.4Ah nowadays. I remember a few years back, when a rechargeable AA cell could only store 500mAh, and a C cell was 2Ah. And we had to walk fifty miles in the snow to... oh, wait.
- They're rechargeable. This is a no-brainer. I go through far too many batteries to be buying new ones regularly.
- They're cheap. The price of quality rechargeable AA cells has remained roughly constant for the last 15 years - $5/cell. That used to be a lot of money for me 15 years ago - but now, I have dozens of the things.
Battery-powered USB iPod charge cable that requires no special components
Here's yet another way to build a battery-powered USB port. You can use it to charge your iPod or phone or lights or whatever. It should last about ten times as long as designs based on 9V batteries.
It's based around my favourite batteries of all time, AA NiMH cells. They're cheap, rechargeable, and perfectly suited to this project. I used this cable to keep my iPod charged on a bicycle tour of Victoria last year.
Controller hardware
The controller is based around a PIC16F84A. It has 13 I/O's, a timer, and not a lot else. To program it I'm using JDM programmer hardware, ICProg software, and the excellent Microchip MPLAB suite to compile and simulate the software.
The controller board, attached to the main control board: Note the I2C cable running between them, which provides the main control board with power.
AVR pulsing LED: avrledtest.c
Based heavily off the sample code on http://www.captain.at/electronics/atmel-programmer/
This has been tested on an ATmega32 with a 4MHz crystal oscillator.
#include < avr/io.h>
void delay_ms(unsigned char ms)
/* badly mangled delay_ms */
{
unsigned short outer1, outer2;
outer1 = 1;
while (outer1) {
outer2 = 1000;
while (outer2) {
while ( ms ) ms--;
outer2--;
}
outer1--;
}
}
int main(void)
{
/* enable PD5 as output */
DDRD |= 1 << PD5;
unsigned char bright = 0;
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.

