mouldy.org

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. 5V logic level won't do it. H-bridge schematic fragment Looking at the schematic, if A is set to 0V, Q1 doesn't conduct. If A is set to 5V, current flows from base to emitter of Q1, and it conducts. No problems there. If C is set to 0V, current flows from emitter to base on Q7, and it conducts. If C is set to 5V (from a digital logic output), it's still conducting because current flows from emitter (12V) to base (5V). It never switches off, and hence the C and D MOSFETs are always conducting. This is a Bad Thing (tm). I got around this problem by changing the emitter voltage of Q7 and Q3 to be 5V; this is easy in my case, because I already have the 5V logic regulator on the same board. It's part of reason why there are a lot more wires on the board than there were before testing, however. This is only a partial solution, though. 5V is pretty much the minimum voltage you can safely run the MOSFETs at, because their worst-case gate-source threshold voltage is 4V. Below that, they won't conduct fully, costing motor efficiency and generating heat. I'll probably want to use 3.3V logic at some point, and that won't be enough to turn the MOSFETs on without another transistor to shift the logic level.

Safety resistors

I don't (yet) have a current-limited power supply at home, so to compensate, I put a 22 ohm safety resistor in series with the supply voltage. This caused a whole host of problems when things were shorting out above (the microcontrollers would lock up, the MOSFETs would drop below their threshold voltage and stop conducting, lights would dim, I would swear, etc), but did allow me to debug the circuit with no unnecessary component destruction. (There is always a certain element of necessary component destruction, of course; you have to keep the parts in line, lest they begin misbehaving.) As I gained confidence, I added resistors in parallel to allow more current to flow. A part which gets warm with a reduced current will probably get very hot when run at full power - with the occasional exception of the MOSFETs, discussed below.

Power supplies

The need for a quality power supply was really driven home during this experiment. My current design uses a single battery pack and a regulator for the 5V logic devices. While I had the safety resistors attached, the voltage to the logic devices would often drop - but this by design. It never really got below about 2.8V, which is the point at which the MOSFETs stopped conducting (hence reducing current flow and the voltage drop across the safety resistors). The microcontrollers were generally OK at 2.8V, but less reliable. Having a microcontroller lock up or reset in operation is a long, long way from ideal. Putting very heavy loads on the motor - such as by running it in one direction, then reversing it - locked up one or the other microcontroller pretty reliably. It may have been recoverable - I've got no error recovery in my AVR I2C code yet - but I'd rather have error recovery as a 'just in case' option, rather than something which allows normal usage! Adding larger smoothing capacitors to the microcontrollers helped a little. The big surprise came when I (nervously) ran the system with no safety resistors at all. The motor spun beautifully with no current limits. But the microcontrollers were still getting lousy power! When the motor accelerated from a low speed, or reversed, the LEDs on the microcontrollers were dimming. There are two problems there: the microcontrollers will be less reliable, and the motors aren't getting as much current as they could. Microcontroller reliability is a safety issue; if the main controller locks up, the robot will keep on doing whatever it's doing already. This isn't such a big deal for a Mini Sumo robot, but you may not be able to physically pick up and turn off a combat robot. Reliable remote control is absolutely crucial. There's also the case where your main power supply runs flat during operation. Below 4V, things are going to get ugly; the microcontrollers won't get enough voltage to run, and the MOSFETs aren't going to switch on and off properly. Having the microcontrollers fail is bad for safety; having the MOSFETS not switch completely could lead to them heating up and being destroyed. It'll stop the robot, of course, but in suboptimal circumstances. The H-bridge controller could potentially monitor the motor power supply and turn the MOSFETs off when it drops below a certain threshold. So I'm thinking of using a more complicated power supply: tagged AAA NiCad cells to run the motors, and a tiny 4.8V NiMH battery to run the logic. The NiMH battery can be charged by the AAA cells, or separated in case power noise becomes an issue. The NiCad cells should be capable of higher peak current than the NiMH cells I'm using now, especially with a proper enclosure. The AVR board, H-bridge controller and H-bridge all working together