Welcome to Robot Dialogs. This is a place where I will record my progress, mistakes, errors, failures, lessons learned and hopefully occasional success in my designs and implementations of robots and other technical endeavors. I will try to make it as educational, informative and entertaining as I can...

Monday, December 21, 2009

Remote Controlled Turret

This is an update and rehosting of a senior design project completed in Spring 2008 at RIT. It is (to date) my favorite robotics project. Myself and two friends collaborated to create a remote controlled turret that was accessible from anywhere on the web. The project makes use of a 5 gallon air tank at ~80 psi to fire foam (Nerf) darts. One servo operates six rotating barrels which are mounted on two more servos that provide pan and tilt movement. There are two ultra bright LEDs providing light in dark conditions for a top mounted web-cam. An Arduino is used to control the turret, while communicating (via serial over USB) with a web server that hosts the custom web page and live video stream. A modified PC power supply was used to provide the power. Here's a video of the finished turret...

Full System Test

I was in charge of most of the hardware and electrical work, Mike programmed the Arduino (I usually work with other AVR stuff) to take serial commands from a server and run all the servos, lights, etc., and Kyle got the server and client web page all sorted out.

The "update" mentioned at the beginning refers to software, since leaving school (and successfully demoing the turret on a number of occasions) it became evident that our web server based solution was very cumbersome for casual use and a pain to reinstall. So I took it upon myself to create a new JAVA GUI to use on whatever PC the turret was actually connected to (it is almost platform independent...damn you Sun for not supporting serial). I also went on to add some very rudimentary target tracking (blob detection)...but it mostly just spazzes out when I leave it on automatic (image processing in pure JAVA is difficult to bring up to even 10 fps). It was a great opportunity to explore JAVA's support of web-cams and I did a bit of JAVA 3D for the loading screen. Code available below.


I won't go into the gory details here because we did a nice job documenting the project during school. You can get that documentation (and CAD drawings of machined parts) here. Here are more pictures and videos!

Inside Electrical
Back (Modified PC Power Supply)

Pan/Tilt Servos
Barrel Servo and Gears
Design Poster

The only thing not shown in these photos is the clear Plexiglas walls later added to protect the electronics from curious fingers... In the future I will probably modify this to use the spring loaded piston from an electric AirSoft rifle to provide the air power...the tank is kind of annoying. I may also modify it to work with a smaller more appropriately sized power supply...the current solution was free :).

Firing Test
(It can actually fire much more rapidly than this test shows.)

High Torque Servo Pan & Tilt Test - One of the best videos from testing :)

The robot running the pan/tilt system in this video is one of the first I ever built, I use it all the time because it's a great test platform for new sensors and micro-controller code...it is described here.
  • The original project site is here. (Until I get access from the admin (who changed our directory structure) I can't fix all the broken links.)
  • Re-hosted project documentation is here.
  • Mike's post on his site is here.
  • Kyle's site which is frequently broken or redesigned...is here.
  • Java code is available here (licensed under GNU GPLv3). It's not really portable, a bunch is hard coded at the moment and it doesn't extract necessary libraries properly; however, should be easy enough to modify. JAVA 3D and JMF should be installed to used the code. GiovynetSerialPort is also needed.)
  • I'll try to locate the Arduino code, but really if your going to reproduce it you just need serial and PWM servo examples which are abundant. The documents have some decent info on getting a reliable serial protocol defined.
Dear Nerf, Hire me so I can make a commercialized version for everyone :).

    The First

    This post is a retrospective look at the first robot I built solely for myself (back in 2008). I had only helped build one robot before this. It's clear I got a very late start into robotics. Although school did prepare me formally to dive right in, I wish I had been more focused on it when I was younger, I would have really flourished in college. This robot was designed mostly on a whim, but has turned out to be a nice solid prototype, and it is very useful for testing sensors and AVR code...

    The Parts List:
    • Aluminum Chassis, Motor Mounts & Tire hubs - Machined while I was still at RIT when I had access to their machine shop. No original designs are available, I just went in and used what scrap I could find...I'd be embarrassed by providing the true measurements :).
    • Stepper Motors - From Sparkfun...I may replace these some day with cheaper gear motors so I can use these steppers in a CNC/Drill Press.
    • EasyDriver Stepper Motor Driver - Also from Sparkfun...simplest way to drive your steppers...the newest version of this board solves (I think) an issue that my version has with slowly shorting/draining power/whining when offline.
    • Tires - Sparkfun Again...I seem to like these tires.
    • Ball Caster - Another proven Sparkfun product...
    • Voltage Regulator Circuit - This was the second time I had built a voltage regulator circuit, but the first time for a robot. This has proved to be one of the most important circuits to know, understand, and be able to recognize on PCBs.
    • AVR ATMega32 - Since this project, AVR and in particular the ATMega32 has been my preferred micro-controller. I use AVR Studio, AVR Libc, and an AVR ISP mk2 programmer in most of my projects. The only exceptions are the Arduino projects, which are still AVR chips, just in a nice package that have a lot of the repetitious work already done for me.
    • USB to Serial Adapter - Lets me use USB for controlling the robot.
    • 8 AA Batteries & holders - Two sets of four paralleled together to provide enough voltage for the motors (outside the regulator circuit) and for all the electronics and sensors.
    • 6 inch Breadboard - The epitome of a prototyping.
    • Sensors - I've used a number of sensors on this robot, it usually gets used as the test bed for new sensors and circuits.
    Lessons Learned:
    • Always leave an LED wired to a pin somewhere on the micro-controller and a compiled program to blink said LED somewhere in the code repository. Don't assume you've fried you r controller. Check it against a circuit and program that you know will work.
    • Use one type of screw whenever possible (this one has all 4-40 standard hex screws, except the motor mount screws, which had to be metric).
    • Stepper Motors and batteries aren't the best option for a robot...next time gear motors.
    • Have a quick way to turn off your motors (see the jumper at the front with tape sticking up?). When your robot gets to the edge of the table and the suicide feature is enabled...
    • No sharp aluminum corners or edges...cuts hurt.
    Code for this robot changes all the time, so there isn't much point in posting it...besides, it's rarely documented enough for anyone but me.

        Wednesday, December 16, 2009

        My Favorite (Obscure) Code

        I don't really have time during the holidays to be working on robots. Celebrations and family gatherings aside I have to start focusing on getting my masters thesis finished (I'll post about this later when I get more done and I may need your help). To fill the void between now and my next physical computing/robot project I've decided to go back and document some of the projects I was lucky enough to work on when I was still taking classes and had access to a real machine shop :( . But those posts will come over time, hopefully when I get access to a better camera. For today I've got a post for the code monkeys.

        The code (stripped of meaningful names/comments see full below):
        public static double [][] getX(double radius ){
           LinkedList<double> x = new LinkedList<double>();
           for(double a = 30; a<=330;a+=10 ){
             x.add(new double []{radius*Math.cos(a*Math.PI/180), radius*Math.sin(a*Math.PI/180)});
           x.add(new double []{0,0});
           return x.toArray(new double[x.size()][]);
        public static double [][] getY(double radius )
           LinkedList<double> y = new LinkedList<double>();
           for(double a = 0; a<=180;a+=10 ){
             y.add(new double []{radius*Math.cos(a*Math.PI/180), radius*Math.sin(a*Math.PI/180)});
           boolean toggle = true;
           for(double a = -radius; a<radius*((double)6/5);a+=radius*((double)1/5)){
             y.add(new double []{a,(toggle ? -radius : -radius*((double)2/3))});
             toggle = !toggle;
           return y.toArray(new double[y.size()][]);
        Okay so that's pretty obscure right? You could figure it out if you drew each two element array as if they were x,y points. Don't waste your time unless you like obscure code. Just scroll on down. (And yeah I know this isn't exactly perfect or even "good" code...it was done quickly).

        Step back in time to May 2009. I'm taking a class called Robot Motion Planning mostly a high level independent work/"research something and present it" type course. I was hoping to learn more in depth about kinematics but the course ended up diverging from that so I picked a topic involving Rapidly-exploring Random Trees (RRTs). These beauties are used to find motion paths in complex environments for robots (both mobile robots, robot articulators (arms)) and can even extended to path planning for just about any object. Now there's a whole slew of algorithmic and mathematical stuff to know and dive into (computing C-spaces, obstacle collision detection algorithms, multi-dimensional spaces). But lets not worry about all that.

        The research I did isn't really original (I don't think a least) but it was pretty interesting to work on. I took RRTs to the next level by computing (in near real-time) paths for multiple robots using multi-threaded programming techniques (in JAVA). I've included the full source at the bottom, but it's not well documented or tested so use at your own risk.

        So what does the code actually do? Well It generates x,y coordinates for the "robot's" graphic in the simulation. Not getting it? Take another look at the real code.

        The actual code snippet:
        public static double [][] getPackMan(double radius ){
           LinkedList<double> packman = new LinkedList<double>();
           for(double a = 30; a<=330;a+=10 ){
             packman.add(new double []{radius*Math.cos(a*Math.PI/180), radius*Math.sin(a*Math.PI/180)});
           packman.add(new double []{0,0});
           return packman.toArray(new double[packman.size()][]);
        public static double [][] getGhost(double radius )
           LinkedList<double> ghost = new LinkedList<double>();
           for(double a = 0; a<=180;a+=10 ){
             ghost.add(new double []{radius*Math.cos(a*Math.PI/180), radius*Math.sin(a*Math.PI/180)});
           boolean toggle = true;
           for(double a = -radius; a<radius*((double)6/5);a+=radius*((double)1/5)){
             ghost.add(new double []{a,(toggle ? -radius : -radius*((double)2/3))});
             toggle = !toggle;
           return ghost.toArray(new double[ghost.size()][]);

        Yeah that's right baby, PackMan in 5 lines and only one loop. And ghosts in 8 lines. This made my day when I got it finished. I'm sure there are ways to get it even smaller, but this is 'as is' from the project...

        The presentation for the research culminated in some nifty videos. Double click on them (takes you to YouTube) and watch them in HD to actually see...




        The code is here: RRT.jar (This is a runnable jar containing the source. Use "java -jar RRT.jar" to run. Works best on a quad core...)

        Here is the presentation: Real-Time Crowd Path Planning with RRTs.pdf (It's fairly sparse. I believe in the "if you can't talk about it without reading from the slides then you don't know shit" approach.)

        Holy crap it's such a huge pain in the ass to embed code in Blogger. Argh.

        Sunday, December 13, 2009

        Hidden Maze Gift

        Okay...this doesn't even remotely fit the robotics theme of the site, but it's a weekend project/gift for a family member. The only rule at my family's gift exchange this year is that the gifts have to be "made". For me this is an excuse to kill a weekend with arts and crafts. I started with the idea of duplicating the brain teaser puzzle below.
        Well that one was easy enough to make...unfortunately it's not as colorful as the original (couldn't find that kind of rope). While looking online at similar wooden brain teasers I saw a picture of a small wooden box. As it turned out the box had a maze inside with the intended goal of getting a small ball through the invisible maze. I was hooked. So I went back to Lowe's grabbed what I needed and got to work. It has some weird dimensions because I had the guys at Lowe's cut the top and bottom before I really had anything designed (I wish I had a table saw...). I've always loved drawing mazes. The one inside this is fairly simple, but any maze is difficult when you can't see it. When I got home this is what I designed (in SketchUp again...).
        After getting it all drawn up and dimensions figured out I went to cutting all 42 of the maze pieces (haha...42...totally unintentional). I then sanded off the edges, laid out a grid on the bottom board, placed all the pieces, glued them on and got ready to put the top on.
        After gluing the top on I stacked ~60 pounds of books on it and let it sit overnight. Then I did some experiments with the stain I bought and some Sharpie markers to figure out if I needed to stain before putting a design on it (to prevent bleeding)...I did. After more sanding and one coat of stain I decided to draw a Celtic knot on the top. I've done quite a few of these on paper before. I was pretty nervous to do it on wood because it has to be inked and that's a lot more permanent on wood. But I followed the steps I always use and was very patient and careful. I managed to get it done without mistakes in just under 4 hours. So it's done now (with several more coats of stain to seal the design) and I have to say it looks pretty damn good. Shiny.The pictures don't do it justice (I really need a real camera) my phone just isn't good enough. I hope the gift is well received...and not too hard to solve :).

        Monday, December 7, 2009

        Gas Mileage

        Well today's post falls into the "other technical endeavors" category. For the past year and a half I have been collecting a fairly interesting data set: gas mileage. In June 2008 I purchased (that is I started paying for) a 2006 Ford Fusion (V4). Ever since the first time I filled the tank I have done one simple thing; I write the current mileage (to the tenth of a mile) on the receipt. Shortly after accumulating a few receipts I started a spreadsheet to record the data. Here we are 19 months later and I have some intriguing data to share. I've created several charts to illustrate various miles per gallon, miles/tank, price/gallon, and mileage vs. time. But first lets have some data:
        Most significant thing to me? 755 Gallons and $2,294 Holy Crap! Okay so the data in green is the only data I have to enter for each receipt. It's not so bad if you save a few receipts and do them all at once. All the fields in yellow, and the graphs below are setup to automatically update as new data becomes available. By the way, all of this was done in excel. As soon as Google Docs Spreadsheets are capable of the graphs I will start to use it instead (more than once I've come close to losing this data). Now for the graphs:
        Avg. MPG is probably the most interesting data set. You can clearly see the very stable MPG declines during my coop w/ Boeing last summer (22.5 mile daily commute in Southern CA traffic), my final school year (4 mile daily compute) and my current work commute of 24 miles on an evil Kansas Highway (HW 50).
        One of the perks of collecting this data was a record of how much I spent on gas, and also the price change (for me at least) over time. The nasty swings in price usually occurred during road trips.
        And finally a simple graph of mileage over time. The near vertical sections are road trips (KS->CA, CA->NY, NY->KS, KS->CO).

        I know it sounds weird but I enjoyed watching this data set grow. It's a strange thing to watch and look back on your life experiences in graph form.

        Here's a template Excel file you can use to record your own data. The graphs and yellow cells will automatically fill as you enter new rows in the green cells.

        Sunday, December 6, 2009

        The competition that wasn't

        Well unfortunately I was the only person to enter the competition officially, so it was canceled. To appease the robot gods' thirst for robotic mayhem Sparkfun morphed the events this weekend into a robot building/hacking/soccer match shindig. Making the 8 hr drive (one-way) was totally worth it even without the competition. I was able to demo "Spin Cycle" to those attending. Most of the day was spent on a class detailing the steps necessary to build an Ardubot for several people who had never made their own robot before. I've been a loyal customer and follower of Sparkfun.com for at least 3 years. It was great to finally meet some of the people behind the handles.

        I'm frazzled so no more text. Here is a video of my bot in action, and some pics from the trip.

        "Spin Cycle"

        The view from not even a mile away from SparkFun's building. (So...jealous)

        The fancy sign.
        Some nifty robot tracking (webcam+IR LEDs+ projector+codes=awesome).
        The famous giant clock.


        Time for the code... The software portion of this robot was fairly straight forward compared to the electrical and hardware designs. I had several previous robots and experiences to pull from when writing the code. As a result the code is very clean and well documented. There are two languages required to understand the code: JAVA and C (AVR Libc to be precise).


        I used JAVA to create a user interface which would take keyboard input and translate it into serial commands. The UI is very simple. It uses a KeyListener (which is added to all visible components of the UI) to pick up key strokes from the user. When a key is "typed" a string of characters is sent via GiovynetSerialPort1.3 to the XBee Module attached to the PC. The XBee acts a transparent serial cable with the XBee on the robot as the other end of the cable. Any serial data coming from the robot is displayed in the text area...

        I used Giovynet's serial port library for two reasons; first, Sun (JAVA) no longer supports serial ports and second, I've used this library before. This library's documentation leaves something to be desired...but I managed to get enough of it working for now.

        As far as design of the UI and JAVA control code goes I almost always follow the MVC software design model for this type of software. In this case their is no "model" but there is a clearly defined (by name even) 'control' and 'view' portion.

        One notable UI feature is the serial dialog (below) which was created solely to make the initial configuration of a serial connection easier. This and a handy Thread for receiving serial input into the PC are included in SerialTools.jar (w/ source code).
        I didn't comment the JAVA code very well, most of it is simple enough to read through with need for comments.

        C (AVR Libc):

        The micro-controller (an ATMega32) was programmed in a version of C specifically designed for AVR micro-controllers. The program written for the micro-controller is commented very heavily so I wont go into much detail on that. Possibly the most important feature of the program is a 2 second watchdog timer that disables the robot if the connection to the PC is lost (for two seconds). This is one of the first things I programmed and tested...safety first!

        The micro-controller program was used to control the following:
        • Serial Communication w/ PC (command parsing).
        • 2 9A motor controllers (A total of 4 digital inputs, 4 digital outputs, and two PWM channels).
        • 3 (up to 8) IR sensors for line following. (I fried all my sensors but the code was done).
        • 1 Digital output for the weapon's motor's controller.
        • RoboController.jar (archive w/ source not runnable) contains the JAVA code for the controller UI and key-stroke processing.
        • SerialTools.jar (archive w/ source not runnable) contains SerialConnDialog and ReceiveThread.
        • AVR C-Code.zip (for ATMega32) contains code for the robot's micro-controller.

        Final Assembly

        Well I managed to get all the parts purchased, designed and/or fabricated before the weekend of the event. As is often the case with project like this, my designs changed as I searched for parts. You will see below the final designs created in SketchUp (they really are final, based on the bot I took this weekend). I put a great deal of effort into getting exact dimensions in every place I could. In fact the only blatant differences between the drawings and the real robot are in the purchased parts(drill and batteries) which have too many curves to replicate.

        SketchUp Model

        I'm pretty certain no one will want to duplicate this exact design (anyone capable would probably find that boring) ; however, some of the components may be useful. The motors, motor drivers, wheels and hubs are all precisely measured, and could easily be copied into another drawing.
        I've decided on a name: "Spin Cycle" (a suggestion from my older brother). The name stems directly from the previously withheld weapon design. The "weapon" is a shiny stainless steel 14 inch rod from an old ink-jet printer. It weighs (about) 1.5 lbs. It is attached to a Craftsman 14.4 V cordless drill which has had it's handle chopped off. To attach the rod to the motor, I went to the local hardware store and purchased a galvanized steel 3/8" threaded "T" joint and short 3/8" coupler. The "T had to be bored out to 1/2" and finally two small 6-32 set screws added to secure the rod. Inserting a screwdriver into coupler and letting the rod rotate freely turned out to be a very easy way to check if the rod was balanced before tightening the set screws.I designed the following controller circuit (mostly based on the designs in an earlier post) for this motor. The controller takes up only one output pin from the micro-controller because it is only capable of driving the motor in one direction. Four power MOSFETs were used in parallel to increase run-time (by dispersing current and therefore heat). I recycled the big switching diode from the drill's trigger circuit to take care of back-emf when the driver was turned off with the motor still spinning.I left the drill motor and transmission intact so that the internal clutch would slip when the rod starts to spin. This is also safer from the electrical side because it allows the clutch to slip when the rod hits something thereby reducing the likelihood of a motor stall (huge current draw). I estimate that with full battery charge the rod/drill spins at ~200 rpm. It's enough to scare any little plastic robot away.

        I finished the build by filling the house with the sweet smell of spray paint... all the metal components of the chassis were painted with two coats of metal primer and several (I lost track) coats of glossy black paint. I don't know if I'll put any designs or text on it...unlikely.

        Tuesday, November 24, 2009

        Best laid plans...

        Well it seems that every attempt I make to reduce cost on this robot just comes back to bite me in the end. I think I've learned my lesson...buy new shit and don't try to cut corners. I'm referring to the motors and the motor controller... While investigations into the motor controller resulted in a good design (based on that of the Open Source Motor Controller) the cost and time needed is prohibitive at least for the motors I'm going to use. So I've ended up purchasing two 9A motor controllers (one for each drive motor).They work very well for these motors (they are way bigger than necessary). One issue came up when I mounted these to the chassis though... Two of the controller's mounting holes are attached to OUT A on the PCB as you can see in the picture. So when I bolted the things to the bot and started using them, a full 15V was applied to the chassis. This burnt out two cheap sensors (fortunately I had enough replacements on hand) and it wouldn't let the motors go in the same direction. I spent probably 6 hours looking for what was wrong with my test code. I finally asked the Sparkfun Forums again and went to sleep. The next day I checked the forums, but there were no helpful posts so I started testing from the beginning again and noticed the stupid way the board had been designed...ugh. A little hot glue to hold the two plastic standoffs in place (and electrically isolate the controller) and voilĂ  the bot could go forward/backward again!

        When I first started writing this post (almost 10 days ago) I had intended to show more drawings from Google SketchUp. At the moment I only have the one below available. Much more is designed already, but because I'm keeping the weapon components a secret until d-day, I'm restricted to what components I can show... I'll have more detailed drawings in the next post, as I said this post is already 10 days in the making, there have been some updates.

        Everything has exact dimensions by the way (long hours in SketchUp with a caliper).

        There aren't any dimensions (shown) in this pic...It's about 7.75" wide and 9.5" long. I'm a bit concerned about controlling the bot at this point, mostly because of how wide it is. I wont have fine enough control (I think) to do a solely automated bot (this was never the intention, but it's definitely not happening now). I'm not even sure at this point whether I will allow it to line follow without guidance. I'm leaning towards remote controlling everything with a laptop (I don't subscribe to the standard RC controller/receiver paradigm). To this end I've purchased a set of XBee wireless transceivers and the breakout boards necessary to use them (XBee Explorer USB and XBee Explorer Regulated).
        Once, in the past, I tried to use a different solution for wireless control on a different robot. I still have them but I've never been able to get them to work (which is sad, they should have a HUGE range and I'm out $100 for the pair). The XBee module's worked first try out of the box! I was floored. What these modules (both kinds) do is form a wireless serial link between the computer and and the robot. Its like having a serial cable without the cable. The XBee Explorer Regulated board allows my micro-controller running at 5V to work with the 3.3V XBee module. The XBee Explorer USB is a board that the XBee module plugs into and it serves as a USB to Serial converter (basically makes it so I can plug into the PC with USB, but the PC thinks it's using an old serial port and cable).

        With these modules I can send data and text to the robot from up to 300 ft away! For now I'll be developing a simple (safe) command set to control the robot for the competition. I'll be developing a JAVA program w/ a simple GUI and serial solution to take keyboard/mouse input from the laptop, convert it to a serial commands and send it to the bot. More on this when I've documented it and cleaned up/commented the code that still gets changed every 5 minutes :). Some may wonder why I purchased the 1mW version instead of the newer 2mW or 900 series. The explanation is simple; these were cheaper and they are recommended by Nate (the SparkFun CEO) in a wireless boot-loading tutorial for an AVR micro-controller. I'm going to try to follow that tutorial after this competition, but modify it to work with my preferred micro-controller the ATMega32 (which I'm using for this robot by the way, and yes I know they're getting replaced by the ATMega32A). I wish I had time to do it now so I could get free from my current programming method (AVRISP mkII + AVR ISP Programming adapter).

        Okay the post is officially way too long so I have only one more thing to say. If you ever question why I spew on about SparkFun, it's products, members, forums etc. I suggest you look at their news post here to get an idea of why.

        Sunday, November 8, 2009

        Motor Control Circuit

        Update: This circuit doesn't work (thanks Sparkfun Forums folks) revised version will be in next post.

        So I've worked out the motor controller circuit I'll be using. I've ordered the components too. Hopefully when I get them it will work as planned without too much modification.

        Or the Google Doc

        The major components:
        Power MOSFET
        NPN Switching Transistors

        It's less complicated than the circuit makes it look... It's really 4 identical circuits (which I show in lower part of schematic) attached to the MOSFETs of an H bridge. The optoisolators (PS2501) are also a single package so wiring won't be as complicated either. Please feel free to comment or suggest changes... I've never built a circuit for high voltage/current motors like this before and could really use another set of eyes on this. (Especially if it looks correct, I need positive reinforcement as much as criticism :)

        Change of Plans...

        I've visited about 15 local hardware/hobby/auto parts/tool stores in the last 3-4 day looking for ideas and ways to turn these drill motors into drive motors for the robot. I've also logged about 8 hours of research into gears, gear types, gear ratios, and speed/torque conversions. I've decided to scrap the idea of using these motors as drive motors. The two main reasons are cost and unknowns. It costs as much to buy geared motors as it does to buy the gears to get these working. These motors are terrible as far as documentation goes. There's no way to find out their intended voltages, current draw, stall current stall torque and on and on... Because of this I don't know how far they need to be geared down. It would take some trial and error at my cost. I don't have the time or funds to do it. The other reason is complexity...It would take a fair amount of machining to create mounts for all the hardware in a custom gearing solution. Don't believe me? Have a look:

        Every shaft would need a mount with precise holes, bushings (because bearings would be over kill) and testing. This kind of work isn't outside my abilities, I just don't have the right equipment... If I were still at school I'd just head over to the machine shop and make this stuff...unfortunately real-life means buying mills and lathes to do the work...I don't have the capitol for that yet.

        In response to this I located an alternate motor source.
        The site has been on my list of "places to try out" for a while so I'm glad to get the opportunity. This motor has good documentation for its electrical and mechanical characteristics and accurate dimensions. Meaning: I can design the mounts and electrical circuitry for them while they are in the mail. I also ordered a couple of tire hubs for this size shaft...should save some time. I really hope these motors were a wise choice.

        The next post should have the motor control circuit, possibly the sensor circuits (I already know them, but it's good to draw it out still) and maybe some code :) . Probably have CAD drawings of the bot too...I've spent about 8 hours in Google SketchUp...I think I'm finally getting used to the controls...in my opinion they are harder to learn than AutoCAD...but free :).

        Wednesday, November 4, 2009

        2 Days in and already Over Budget

        I did some scouting at local pawn shops for suitable power tools w/ strong motors over the last two days. I ended up finding 2 14.4V Craftsman drills (each of which came with 2 batteries and a charger) and a 14.4 V Black and Decker circular saw (w/ 1 battery). Grand Total $140...Doh!

        I shopped around with the intention of matching the two drill motors so that they would be balanced in torque/current/dimensions/etc. I made the assumption that being the same voltage and brand would be enough to get evenly matched motors. Unfortunately when I disassembled them later I found that the Larger (red) one had a motor much larger than the other (gray), and the transmission was very different... The circular saw has a motor similar to the larger drill. All three have different drive gears.

        So the plan at this point is to ditch the transmission from the larger motor and the gear box of the circular saw and find gearing for these two to make them drive motors.

        Next time I think I'll just buy identical motors...hopefully these last a while.

        I've been scouting out all the other things I'm planning to use as well: steel base, wheels, axels, bearings, etc. I'm also working on a custom motor driver circuit which hopefully will be cheaper than buying a ready made one...yay shopping! I used a uC and the power MOSFET from one of the drills to rig a test circuit before I order the parts for the driver. Tests pretty much confirmed that I'm on the right track, but I'm going to formally design it to try and minimize screw ups. During the test the motor had enough torque to throw itself off the desk...I can't wait to get this thing on wheels :)