Well, my robot project took a major setback today, but I’ll first catch people up on the status before today.
First, we found all the parts we need. Some have arived, some are still on order, namely the microcontrollers. We are going to have a magnetometer (a digital compass) and an accelerometer for each car, and have a microcontroller (AVR atMega32) read them, and feed the data via serial back to the routers, where it would be processed and locations and directions determined.
We took one car apart and found out how the innards work. Basically, there are 2 motors, one for forward/reverse, and one for left/right. There is a small IC that translates the RC signals into digital signals, which drive what’s known as an H-Bridge. There are 2 H-Bridges, one for each motor, and then there are some power regulation circuitry. An H-Bridge acts like having 4 switches across a motor, where the motor makes the cross bar of the H. If you close the switches in the upper right and lower left, the motor goes one way (power going diagonally across the H), and it goes the other way when the other two switches are closed. The switches themselves are really transistors, where you put a little bit of power at the Gate pin, and it closes the switch so that it lets power from the batter flow though it to the output pin. Anyway, this allows that small IC to just have 4 outputs (forward, back, left and right) that are simple High/Low signals and it can drive the whole thing. This, in turn, allows us to drive those pins manually.
So, we found a site that said we could basically take 4 of the so called GPIO pins that are on the WRT54G routers and tie them to the circuit in place of the IC, and it would work. We tested this first using a power supply set to 3V and applied power across the IC and it drove the motors just fine. We then soldered wires into the router for the GPIO pins and tried each motor that way, and it worked.
Now, to control the GPIO pins on the router, we first flashed the router to use dd-wrt, a open source firmware for these routers. We then took the GPIO utility that is also available, and we ran that program though telnet and drove the pins manually. We then took that source code and incorporated it into a program that would drive the car in a pre-programmed way. Easy enough. One thing we noticed was that most of the GPIO pins controlled LEDs, and that when the GPIO pins where High, the lights where off, and the lights came on when the GPIO pins where Low, making the LED’s active low.
Finally, we found out that the routers, while wanting 12V @ 0.5A, would work on as little as 7.5V. The RC cars use 9.6V batteries, so we found out that we could just power the router using the car’s battery. We might want to use a second battery just like it instead, so that if the car stalls out, the router keeps working.
Well, here’s where it gets interesting. After this myriad of tests, we finally decided to hook up all the GPIO pins to the car, and power the router with the car (up on blocks) to see how it worked. We make an init script that would disable the GPIO pins on start up so that it wouldn’t lurch when you turned it on. We hook it up, and the drive motor goes full tilt. waiting for the router to finish booting, figuring something was wrong with the start up script. But then smoke started coming off the car’s board. Never a good sign. Quickly turning it off, we doubled checked the connections, and tried again. More smoke, this time we could tell where it was. Disconnecting the router some, we tried again, and it did it again. More disconnecting, and more smoke. Finally, we removed the router completely, and tried turning on the car. Two of the H-bridge transistors where severely overheating still.
After much thinking and not much turning things on, we determined that we must have blown the transistors. A multimeter confirmed that, showing that the gate and the drain where connected, even when it was off. The transistors where for the Right and Left drive. The reverse was not hooked up because we had only found 3 pins that we could control on the router. Further thought uncovered that what happened was, while starting up, the router drove all the GPIO pins High to turn off the LEDs. The start up script wasn’t run until a few seconds after boot. During this time, both sides of the L/R H-bridge where being driven, and that caused a short circuit, where 9.6V where being dropped over just 2 transistors rather than the motor. This blew the transistors, causing the Gate to draw too much power from the GPIO pins.
The end result was a car with 4 dead transistors, and a router that won’t boot.
The car might be fixable, with some new transistors from radio shack. We are going to see about unbricking the router, but it’s doubtful. I have no idea how the earlier examples of this sort of thing got around the problem, but we are going to outsource the car driving to our microcontroller. We’ll have enough pins, and we can control them sooner (fractions of a second rather than a few seconds), and I believe they will be Low by default, so there shouldn’t be any issues. So nifty video of a router driving a car until we have microcontrollers, and we need to find a new router. We doubt we could have prevented this from happening. We might have been able to predict it somewhat, but we probably would have tested each motor individually first, then all together, resulting in the same thing. Oh well. At least we found out what not to do.
EDIT: I got a new router from a friend for cheep. So we now have enough parts. Lesson learned, I hop.
