Date: Wed, 30 Nov 2005 23:53:29 -0600 (CST) Subject: runaway safety and corrections X-UID: 109 Content-Type: IMAGE/JPEG; NAME="img2426.jpg" Content-Type: IMAGE/JPEG; NAME="img2427.jpg" Content-Type: IMAGE/JPEG; NAME="img2435.jpg" Content-Type: IMAGE/JPEG; NAME="img2436.jpg" I've been stress testing the computer board with the USB card and webcams. If images are grabbed from two cameras at the same time, the computer locks up immediately. I've seen this on desktop PCs and read many posts about it. DMA (direct memory access) is a means by which devices may write directly into system memory and bypass passing data through device driver interrupts. It is much faster than PIO (programmed input output) which means that software interrupts are required to transfer data. This is my uneducated opinion. But I believe that fundamentally, this is a hardware problem. The DMA controller hardware does not handle bus contention properly in all cases. It must be difficult as it never seems to go away. Under heavy loads, systems can often lockup. A common combination is a video camera that is writing image data into system memory and a hard disk with the DMA device driver enabled. It can work ok for a while and then lockup. It's random. This tells me that the computers should not be viewed as reliable. I originally had the notion that the computers would be able to reset the microcontroller, even reprogram it remotely (just like NASA does with their planetary robots - reading about Sojourner and Pathfinder motivated this line of thinking). The real picture is the opposite. The microcontroller is several orders of magnitude more reliable than the computers. It is a far simpler device and unlikely to fail. It should detect fault in the computers. So I added a runaway safety to the microcontroller. If it does not receive any good commands from the computer board for about one second, it shuts down everything. All motors will stop where they are. This is the likely scenario - the robot is some distance away when the computers crash or lockup. Even if they reset, it may take a minute for them to complete a boot cycle so they can be contacted again. Without a runaway safety, the microcontroller would continue to drive the motors with the last commands. This is dangerous as the robot is relatively heavy (maybe 30 plus pounds) and can move quickly (probably 15 to 20 mph). I should have wired a connector for ISP (in-system programming). This uses Motorola's SPI (serial peripheral interconnect) protocol. Six pins are required: power, ground, MOSI (master out, slave in), MISO (master in, slave out), SCK (clock), and RST (reset). But I didn't. So I could: 1. Pull the chip out using the special tool (cheaply made - but it's the only one I've seen locally - and without this tool it is almost impossible to avoid bending pins), put it back in the STK500, reprogram it, remove it and reinsert in the motor control board. Yuck. 2. Unscrew the motor control board mount nuts, lift it up an inch, and slide some .025 box-end connector wires onto the IC socket pins beneath the board. Then connect these wires to the STK500 ISP header and reprogram. Not as bad but still requires disturbing all of those wires. 3. Use some test clips to hook on the IC pins directly from the top of the board. Then connect the clips to STK500 ISP header and reprogram "in-system". This is what I did. Note that I picked up the E-Z-Hook "pico-hook" jumpers. Most test clips are larger. The "mini" and "micro" sized hook clips from this and other companies are far too large. The only smaller slips are ones designed for SMT (surface mount technology). I got lucky as these were exactly the correct test clips to use. I've tested the motor control board and it seems to be o.k. Everything works as expected. It's a little messy but gets the job done. At this point, development will shift from the 32 MB CF (compact flash) card with my test distribution to the full sized 512 MB CF cards. Both computer boards, top and bottom, will be booting and connected through a hub. The reason is that in order to integrate and test the 900 MHz radio and GPS receiver, work shifts to software. It'd be best to stablize the operating system platform before doing much software integration. Also, the output of the TTL serial pins on the computer boards are also limited to sourcing 3 milliamps. So they too will need buffering (easiest way is a 10 Kohm resistor and a small NPN transistor in an emitter follower). That's not a big deal. Two explanations previously given are incorrect. 1. The two fried GPIO (general purpose input output) pins on one computer board were not caused by shorting power to ground. The short reset the computer, that's all. The power supply and reset monitor stopped any damage. What did happen is that the motor control board, powered with 18 volts instead of 5 volts, pulled the transmit and receive lines connected to the two GPIO pins to somewhere around 17 volts. There is no electrical isolation between the computer and motor control boards. The transmit line from the computer board is connected to an emitter follower. The serial line is normally high. This means the transistor is turned on. With 18 volts, this pulled the voltage on the transmit line far above 5 volts and burned out the the pull-up on that I/O pin. The receive line from the computer board is connected directly to the microcontroller transmit pin. When the microcontroller was powered with 18 volts (instead of 5 volts), this pin was pulled too high and agains burned out the pull-up on the I/O pin. So now both pins are forever at ground. The good thing is that this means the damage was very likely isolated to those two pins. I don't have to worry about replacing the boards. 2. I had thought earlier that overvolting the 3.6 volt steering motor to 12 volts with a low duty cycle would not work. That is untrue. In testing with the Mabuchi motor that is rated from 6 to 15 volts, the minimum duty cycle at which it stalls varies with voltage. This is common sense. So at 3.6 volts, it might stall at 60% duty cycle. Any less and the rotor does not turn. But at 12 volts, it might stall at a 3% duty cycle. So the steering motor would turn when overvolted. The reason why this is not a good idea is that precise control of the motor would be difficult. The duty cycle must be small to avoid burning the motor out. Power increases as the square of voltage. The on-chip PWM (pulse width modulation) of the AVR ATmega32 microcontroller supplies two 8-bit and one 16-bit oscillator that may be split into two 8-bit ones. I'm using four 8-bit resolution PWM pins. If the duty cycle must be very small, then the available resolution is limited.