Drivetrain Designs

In this post, I will give an overview of the drivetrain designs I've come up with and reveal which ones I've decided to prototype. After browsing Pinterest and Instructables, I found six ideas for drivetrains to travel on sand.

1. Four Wheels. This is the most common type of drivetrain for RC vehicles, and there's no shortage of tutorials for how to make a small four-wheeled robot. This one uses four motors, while this one uses two. A four motor design is simple- each motor drives one wheel. The two-motor tutorial uses an RC truck as the base, and didn't really modify the drivetrain, so the tutorial doesn't provide much insight into how it works. However, in FRC we drove multiple wheels from one motor by chaining them together, and I assume the RC-truck-based drivetrain uses a similar principle:

This drivetrain has six wheels, but it uses the same principle. Image Credit: http://www.robotshop.com

However, since this robot will be driving on sand, I want to minimize the number of exposed parts that sand can get into and damage, so it would probably be better to use four motors. I would also want to use wide wheels, with large surface areas, to help keep them from sinking into the sand.

2. Two Wheels. A lot of Instructables (Obstacle Avoiding Arduino Robot, First Robot) for basic robots use two driven wheels, usually with some kind of passive roller in the back for balance. This would be simpler and cheaper to build, but I'm not sure it would have any advantage over a four-wheeled vehicle in its ability to move in sand.

Image Credit: http://www.instructables.com

 
3. Six C-Limbs. This one's really cool. I referenced it briefly in my last post.

Image Credit: http://blogs.scientificamerican.com

The robot, called Sandbot, was built by a team of researchers from Georgia Institute of Technology, Northwestern University, and the University of Pennsylvania. It has six comma-shaped limbs, called C-limbs. I wanted to see how the limbs move, so I looked it up on YouTube and found this video from NPR.



The limbs move three at a time- the outer two wheels on one side are synchronized with the middle wheel on the other side. The video also revealed that the timing of the c-limbs' rotation is critical. Each rotation has a slow phase (the part where the limbs are in the sand) and a fast phase (the part where the limbs are out of the sand). The timing of switching from fast phase to slow phase is the key to Sandbot's ability to move so quickly through sand.

4. Tank. Tanks are designed to be all-terrain vehicles, so I thought a tank-style drivetrain might do well on sand. This Instructable shows how to make cheap, customizable tank tread out of PVC and bike chain.

Image Credit: http://s356.photobucket.com

5. Simple Walker. The first four ideas were essentially variations of wheeled vehicles. The next two are variations of walking robots. This Instructable shows how to make a very simple walker with two motors, which drags its feet as it moves. Spatula feet would immediately sink into the sand, so it would need to have a different type of foot. I think something with a large surface area would be best (the same principle as snowshoes).



6. One-Motor Walker. This one's intriguing. It uses one motor to run its four legs, and it moves like a lizard. Lizards are evolved for deserts, so I thought maybe its gait would do well on sand.



Like the simple walker, this one would need some kind of wide feet to keep it from sinking in sand.

Next, I needed to choose two or three ideas to prototype. The two wheel design is interesting, but I was concerned that its balance issues, even resting on a rear roller, would make it difficult to install the metal detector's search coil in a way that would keep it parallel to the ground. I'm also not convinced that it would have any advantage over the four-wheel design, so I decided to put the two-wheel design aside for now. I love the idea of the one-motor walker, and I want to make one eventually just because it's cool. However, the gears have to mesh in the middle of the bot, which is where I want to put the search coil. So that's off the table for this project as well.

I knew I definitely want to try the six C-limb design, and while I'm prototyping that, it would be easy to prototype the basic four-wheeler as well- it would be the same motors and chassis, and all I would have to change is the attachments on the motors. I decided to prototype some version of the simple walker too, because it's so different from the wheels and C-limbs. I'm intrigued by the tank idea, but making the tread seems very time-consuming. I also know from FRC that dealing with chains can be a real pain, and having chains and sprockets would create another mechanism that would be vulnerable to sand. But if the four-wheel prototype doesn't go well, I'm going to try attaching PVC pieces to the wheels in a sort of chain-free version of the DIY tank tread. Since the main function of the chains is to help the tank go over obstacles, and I don't anticipate many obstacles on the beach, I think a chainless-tank-tread idea could potentially work well.

Having decided which designs to prototype, my next step was to figure out what parts I needed to order. Most online tutorials skip over this step, since their purpose is to teach you how to build what they built, so they just tell you what parts you need. However, if you are trying to get into designing projects like this as a hobby, learning the process is valuable, so I'll go over it in my next post.

Choosing a Metal Detector Circuit

Since my last post, I've learned more about different types of metal detectors and how they work. I decided on a circuit to build, and ordered the necessary parts. I also got the webcam from the swap met to work, and started thinking about drivetrain designs.

After reviewing several metal detector schematics, I've decided to make an Arduino-based metal detector that uses the BFO principle. I started by reading up on how metal detectors work on How Stuff Works. There are three types of metal detectors:

1. Very Low Frequency (VLF). The part of the VLF metal detector that skims along the ground has two concentric coils. The outer coil is called the transmitter coil. The metal detector circuit runs electric current through it, which generates a magnetic field perpendicular to the ground. The circuit reverses the direction of the current, typically hundreds of times per second, which changes the polarity of the magnetic field. The number of times the current changes direction per second is called the frequency of oscillation, or sometimes the frequency of the coil. As the magnetic field pulses into the ground, when it hits a conductive object, the object starts generating its own weak magnetic field. The inner coil, called the receiver coil, is shielded from the magnetic field of the transmitter coil, but not from magnetic fields coming from the ground. When it encounters a magnetic field coming from the ground, an electric current runs through the transmitter coil, with the same frequency as the object's magnetic field, which allows the metal detector to detect approximately how deeply the object is buried and what kind of metal it is. Most consumer metal detectors are VLF.

VLF Illustration. Image Credit: http://electronics.howstuffworks.com

2. Pulse Induction (PI). The metal detector sends short bursts of current through the search coil, which sends brief magnetic fields into the ground. If the coil is over a metal object, the object generates an opposite magnetic field, and the search coil's pulse takes longer to fade. It's a bit like echolocation, but with magnetic pulses instead of sound. PI detectors can't really discriminate between different types of metal. However, they're good for when there's conductive material in the environment, like for salt-water exploration.

3. Beat-Frequency Oscillation (BFO). The circuit runs current through the search coil, switching current direction many times per second (much like the transmitter coil of the VLF). When metal is moved near the search coil, the coil's frequency changes. A second coil, the reference coil, is turned to have the same frequency of the coil changes. A second coil, the reference coil, is tuned to have the same frequency that the search coil has when not near metal. The two frequencies are fed into the circuit, which translates the difference between the frequencies into a user-friendly signal, like an audible tone or visible meter.

Armed with that knowledge, I started looking up metal detector schematics. I found four pretty simple ones:

• http://www.electroschematics.com/6046/cheap-metal-detector-circuit/ 
• http://www.electroschematics.com/1075/simple-metal-detector-circuit/
• http://www.electroschematics.com/7/metal-detector-diy-schematic/
• http://www.easytreasure.co.uk/bfo.htm

I found this site especially cool- they give a really thorough description of several circuits, starting with a very basic metal detector and working up to more complex ones.

• http://www.talkingelectronics.com/projects/200TrCcts/MetalDetectors/MetalDetectors-1.html

 Since I want my robot to eventually run autonomously, it needs to have a "brain" onboard. Since I've worked with Arduino before (for a full account of that adventure, you can read the blog posts from the research lab I worked at last summer), I decided to use an Arduino Duemilanove. To quote my post from last summer, "Arduino is a brand of microcontroller board designed to help you quickly build circuits and write programs that interact with the physical world. You can think of an Arduino as a tiny, and limited, computer. You can write programs on your laptop or desktop, then upload them to the Arduino board through a USB cable." Since I'll be using an Arduino anyway, I thought it would be simplest to have the Arduino read the metal detector too, so I went hunting for an Arduino-based metal detector schematic. I found a really extensive discussion about metal detectors on the Arduino forum, but in the end I decided to follow a design from Dzl's Evil Genius Lair.

Image Credit: Dzl's Evil Genius Lair

It's similar to a BFO metal detector. However, instead of comparing the search coil frequency to the frequency of a reference coil, the Arduino compares the search coil frequency to a stored value. To calibrate the metal detector, you power on the circuit with no metal around, and then press the null switch to record that search coil frequency. The Arduino stores that frequency, and reports that metal has been detected when the search coil frequency differs from that stored value. I'm not sure what a null switch is, but from Dzl's description of what it needs to do, I think I can use one of the pushbutton switches that came in my Arduino starter kit.

Image Credit: http://www.smcelectronics.com/SW52.JPG

The starter kit also included a little Piezo buzzer, which I probably won't use in my final design, but it could be useful for testing the circuit. Or I might use an LED and have it get brighter when metal approaches. I ordered variety packs of resistors and capacitors from Amazon, which will be useful for future projects as well. I also ordered a transistor, on eBay- commenters on Dzl's blog had trouble getting it to work with the 2n2222 transistor, so he now recommends the BC547 transistor. The capacitors arrived today, and I have the necessary resistors in my Arduino started kit, so as soon as the transistor gets here I can start building the circuit. I also have to decide which appliance motor I'm going to sacrifice for its enameled copper.


This week, I got my USB webcam to work! It would be really cool to be able to watch live video from the robot on a computer or tablet (probably tablet, since I could put it in a gallon-sized Ziploc to keep sand out of it). Someone at the swap meet a couple weeks ago was selling a Logitech webcam for a dollar, so I took a chance on it. It's a Logitech Quickcam, model number V-UBG35.

Image Credit: www.laptopsolutions.ca

I plugged it into my laptop, and my family's desktop, and all it would do was try to install drivers and then give me an error message. It turns out that the V-UBG35 was designed for Windows XP and Vista, and isn't compatible with Windows 8. Luckily, I found software (LWS 1.1x64 with Vid) on the Logitech support site to make it compatible with Windows 8, and ran the Windows Program Compatibility Troubleshooter (as described here). The webcam works now; the video quality is grainy, but might be good enough for this. All I really need is to be able to see when it's heading towards water or an obstacle, so I can power it off or make it turn around (if it fails to turn on its own).

In my next post, I'll talk about my progress on drivetrain designs.

Learning about Metal Detectors and Taking Things Apart

Two weeks ago, I picked up some junk at the swap meet, in the hopes that I would be able to salvage some parts. For $16.50, I got two electric mixers, a blender, a small fan, an Arduino-compatible USB cable, a Logitech webcam, and a toy truck. This week I took some of those apart, researched metal detectors, and took the SuperNURDs to a competition at the fair.

I originally thought I might be able to re-purpose the motors from the appliances for the robot, but it turns out that anything that plugs into the wall runs off of mains supply, which in the United States is 120V. The highest voltage battery I would possibly use for this robot is probably an 18V drill battery, so I won't be able to use a motor that needs much more than that. It is possible to increase voltage between the battery and the motor using an electrical component called a transformer, but transformers that can increase voltage from 18V to 120V don't seem to be commercially available and at this point I'm thinking it might not be worthwhile to try to hunt one down and figure out how to use it.

My next thought was that some of the appliances might have motors that actually run off lower voltages, and have circuits that step down the voltage for them. So I opened up one of the mixers to check it out.

The motor inside the mixer was labeled as being rated for 120V, so no luck there.

I also took apart the blender. There was a weird triangular screw holding the bottom on, and I couldn't get it off with a flathead screwdriver, so I drilled out the screw. Companies usually use unusual screws like that when they want to keep people from opening a device- if you can't open a device, you can't repair it and you have to either buy a new one or pay to have it repaired by a professional.

The blender motor doesn't seem to be marked with the voltage it takes, and there's a small circuit board inside that could potentially be lowing the voltage. It seems unlikely that it would lower the voltage by much, when they could instead use a motor that is suited to mains voltage, but I'll take a closer look at the circuit over the next week and hopefully be able to talk about that in my next update.

Top: Disassembled blender; Bottom Left: Blender circuit; Bottom Right: Blender motor

When I bought the toy truck, I thought it was just a basic toy with no electrical components, and I thought I might be able to use the wheels or the jointed arm for something. When I got home and started looking at it more closely, I saw that it has a battery compartment. I put in three batteries and tried flipping the on/reset/off switch and moving the knobs, but nothing happened. So I opened it up, in the hopes that I might be able to figure out what was broken, or at least salvage some electrical parts.

The truck has a speaker, a small motor that turns the arm in the truck bed, an adorable little gearbox, and a bunch of LED lights. It also has some kind of little switches that look like they're supposed to be triggered by the doors opening and closing.

The gearbox (which was full of mud), the speaker, and the switch that's triggered by the truck door.

One of the leads on the motor was broken. I'm not sure if that's what was wrong with the truck (it seems like some of the other functions should still work, even if the motor was disconnected), or if I accidentally broke it while taking it apart. I'm going to solder the connection back together, and see if it works any better then. If the truck still doesn't do anything, I'm going to try putting the batteries back in, switching it on, and measuring voltage and current through various parts of the circuit and see if I can diagnose anything.

I did some internet research on metal detectors this week, and found a ton of different DIY metal-detecting circuits from various websites. I learned that the search coil of a meal-detector (contained in the disc at the end of the handle) is the part that controls what you can detect. The search coil is a coil of wire, usually enameled copper. The larger the circumference of the coil, the deeper it will be able to search. However, as the coil gets larger, it becomes less sensitive and loses the ability to find small objects like coins. I'll experiment with different size coils once I figure out what circuit to build. I think it could be cool to have two search coils on my robot (one to look for small objects near the surface, and one to look for larger objects deeper down). I suspect that the coils might interfere with each other, but since I'll be making a couple different sizes of coils anyway, it's worth a try. I also learned that enameled copper is what they use in motors, so even if I can't use any of the appliance motors as motors, I can at least cannibalize them for wire.

Image Credit: http://phandroid.com/2009/05/03/android-metal-detector/

 I went to the beach on Sunday, and brought my dad's old metal detector. It has a pretty small range- it was able to detect a ring of keys from two or three inches above. I walked around the beach for 20 minutes or so, and didn't find anything. I learned that you have to keep the search coil close to the ground, almost skimming the sand, since it has such a short range, and that people usually sweep it back and forth as they walk, so that they search more area per distance traveled, which are both important things to keep in mind as I design the robot. There were a lot of people at the beach, and I started thinking that if the robot is going to run autonomously (or semi-autonomously), it will need to be able to avoid crashing into people and their stuff. I saw a tutorial a couple weeks ago on how to build an obstacle-avoiding robot using Arduino and an ultrasonic sensor, so I will probably end up adding obstacle-detecting capability to my robot.

While I was walking around with the metal detector, I also started thinking about whether it would be better to build a wheeled robot or a walking robot. I've only ever worked with wheeled robots, so that's definitely more in my comfort zone. However, I know wheels tend to get stuck in sand (this site gives a particularly thorough explanation of how to drive in sand to avoid getting stuck, and the gear you should bring to help extract your vehicle when it does). I think this risk can be limited by keeping the robot light and using wheels with a large surface area, but it might by easier and/or more effective to build a four- or six-legged walking robot. Since it would pick up its feet, it would be less likely to get itself stuck. On a related note, these researchers at Georgia Institute of Technology, Northwestern University, and the University of Pennsylvania built a walking robot that can travel at almost one foot per second. They said that when they programmed the robot's legs to move faster, it got stuck in the sand, so they had to find the maximum speed that allowed it to actually move.

In other news, my team competed in an off-season event at the San Diego County Fair on Saturday! We placed last (out of a total of eight teams), but we had a blast. Out underclassmen were driving and this was their first competition as drivers. By the end they were doing pretty well, but there was definitely a learning curve. We also got to show off our robot and talk to passersby about FIRST- one man I talked to was at the fair with his daughter, and they were really excited. They had tons of questions about the competition- in the father's words, "I'm such a geek aobut this stuff- building a robot like these, I wouldn't even know how to begin, but it's just so cool." He said they would stay and watch a match, and then they ended up staying until the end of the competition. Part of FIRST's mission is "To transform our culture by creating a world where science and technology are celebrated," so I thought it was really cool to have someone who's not an engineer stop by with his daughter and get so excited about the competition.

Left: Grace drives, while Matt coaches and Otto feeds the robot totes. Right: Our bot, 3255, lines up with the feeder station.