Well, here you go, folks! I’m posting everything here. Code, schematics, the paper, pictures, and a clip of the cars moving! Enjoy!

First up, here is an archive of the code and schematics. I’ll try and post a full page detailing everything latter, but here’s the initial release. Please note that I take no responcibility for it’s use. If you try and make a robot using it and it somehow kills you, it’s not my fault. You made it. How you made an RC car kill you, I’d be interested in knowing, but that’s another matter. Also, assume all this is under the GNU General Public License, aka, the GPL. Meaning, you can use it, give it, change it, and give away your changes. But it means that if you do change it and try and give it way, you have to include all the source code, and you have to give us credit somewhere. Not hard to follow, but just a heads up. This is an open source hardware/software project, you know.

Download: swarm.zip

Note that you will need the mipsel gcc/g++ toolchain from ddwrt’s site to build the router’s code. You also will need the avrgcc toolchain, avrdude, and a programmer for the AVR’s code. Also helpful would be ddwrt/openwrt’s firmware modification kit, which will let you extract existing firmwares and build up custom ones. I would attach a firmware I made up, but it is too big to post. If you have any questions, let me know.

Next, we have a series of pictures.

You can see that we had to wire up the mouse manually. We used our own wire, and ran it to an old AT connector. We had PS/2 connectors, but they didn’t want to work. There was connectivity, but the mouse wouldn’t even respond correctly with the PS/2 cable attached to the mouse, let alone plugged in. The four colored wires you see are for the serial line. One is trasmit, one is recieve, and the other two are gound.  The small green board near the microcontroller is the magnetometer, or digital compass. The green terminal blocks are to route the car battery’s power over to the router. The seemingly unused 6 pin header is for programming the AVR. That is one thing not on the schematic as is not technically required. If you make this, you should probably extend the ISP pins to such a header to make reprogramming it easier. Finally, the mouse you see sticks out the back of the car, and you can see the wheel rolls along the floor. This proved much more accurate than the optical sensor. However, there is a speed limit with this, as the reported number is only -8 to +7, unlike the optical sensor, which goes from -253 to +254. But the number of points per inch is much less, so you can still travel at a good speed accuratly. This mostly stems from how often you poll the mouse.

Next, we have the movie.

You can see the first one go, then it seems to stop on it’s turn. I get the other guy in the lab to give it a push, and it finally finishes it’s path, and tells the other one to go. He didn’t expect that and jumps a foot. It’s rather funny.

Finally, we have the paper.

Download: Final Report (odt), Final Report (doc).

I sanitized it for names. “<Me>”, “<I>” and such refer to me, and “<Partner>” and such refer to my teammate on this project. I still don’t know if I like my name online yet, so I’m not going to, and especially not put someone else’s name up. I also removed the pictures that are above for size constraints. There’s a lot to it. We even had to break down the cost to make a production version and sell it. We don’t plan to, but it worked out to nearly $300 per car when you factor in labor, rent, advertising and legal stuff. Pain in the butt. Thus, this is open source everything. People that like it can copy it and further develop it. It’s meant to be a development platform for coordinated robots. Researchers and hobbyest alike can make their own and save money.

Which brings us to how I’d like to expand on what is there. First, it’d be awesome to make a web interface to control the car. Just one that would send commands or something. Second, better streaming of commands and status between cars. Third, more calibration on turning and distance measurement. Fourth, a better path calculation algorithm. Originally, I thought that each waypoint would have a goal x, y, and angle. Found out too late that you don’t need the angle, just getting there is enough. So some form of tagent that would determine one turning angle, and then a distance. Fith, driving would be so much easier if this was more tank stearing than car stearing. So it’d be awesome if someone made up a version on a different drive platform. Sixth, new sensors to do cool stuff. Seventh, port this to a router with a USB port for live streaming video. Eighth, we need new motor control circuits. Even the one that works probably will go bad soon. So much to do, and so little time, but I think it might be fun.

This entry was posted on Wednesday, May 6th, 2009 at 8:20 pm and is filed under Programming, School, hardware, linux, tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.