Testing Search Coils

After assembling the circuit and making a search coil (as seen in my last post), I ran a series of tests. Some of the tests let the circuit run uninterrupted, while in others I moved a bag of coins towards and away from the search coil. Overall, the coil was able to detect the coins, but its range was much less than the range DZL claims to have gotten using the same setup.

For the first test, I plugged the stripped enameled copper wire directly into the breadboard, uploaded the Serial_Output sketch, and left the setup to run on my dining room table for an hour and twenty minutes. At that point I was using the original example sketch, which didn't print out a timestamp (just the frequencies). At first all the frequencies were reading zero; when I unplugged and replugged in some wires on the breadboard, it started working.

The frequencies were erratic at first, then rose sharply. After about a minute, they stabilized near 86 kHz (DZL's circuit oscillated at about 160 kHz). However, the frequencies continued to increase very gradually over the rest of the test:

So while the signal didn't break down in the way the commentor described, it wasn't exactly stable either, increasing at a rate of approximately 3.5 Hz per minute (a range of about 12 Hz).

For the next test, I used the same coil and the same setup. I let the circuit run for about an hour then slowly introduced a bag of coins. The coins started 12 in above the coil, and were lowered down to be level with the coil, then raised back up to 12 in. The process took place over a 15 second period. During the uninterrupted portion of the test, the frequencies varied more erratically, not showing the steady gradual increase seen in the first test:

During the coin test, there was a very slight increase in frequency when the coins were within an inch and a half of the coil:

This shows that the circuit is fundamentally working, but it didn't have a very impressive range. Many of the other metal detector tutorials I read recommended using 70 or more turns of wire in the search coil, while DZL only used 30. I also thought that since I had to push in the wires every time to get the circuit to work, it might help to solder hookup wire onto the ends of the enameled copper wire, to get a more reliable electrical connection. I decided to first test adding hookup wire to the ends of the enameled copper.

Hookup wire is a thicker wire, usually 22 AWG, that is commonly used with breadboards. I stripped a little insulation from the ends of the hookup wire (I used nail clippers, since the wire strippers I had were the wrong size for 22 AWG). Then I wrapped the end of the enameled copper wire (with enamel removed) around the the hookup wire 7 or 8 times, and covered the connection with solder. I then repeated the last test, running the circuit for an hour uninterrupted, then lowering the bag of coins towards the coil (from 12 in) over a 15 second period. After the initial increase (from seconds 0 to 50), the frequency was remarkably stable, ranging between 86.873 kHz and 86.892 kHz (a range of 19 Hz) over the next four minutes.

Later on, the frequency looked more erratic...

...but actually only varied from 86.937 kHz to 86.948 kHz over the course of the ten minute period, a range of 11 Hz. This is less variation than we saw in the four minutes after ramp-up. Over the next three ten-minute periods, the frequency varied by 22 Hz, 30 Hz, and 599 Hz. Then the graph suddenly dropped by 585 Hz, after which it was very stable (variation of 9 Hz) until the bag of coins was introduced. I don't know how to account for the 585 Hz drop- all I can think of is that someone must have moved metal towards or away from the circuit at that moment, but to the best of my knowledge the room was undisturbed during the test.

This graph shows the 585 Hz drop and the peak from the coins.

The increase in frequency during the coin test is noticeable during the seconds marked 33 to 41 on the following graph:

  
The bag of coins was lowered the same way as in the previous tests, moving 24 inches over approximately 15 seconds. The frequency change was noticeable over an 8 second period, which suggests the coil can detect the bag of coins when it is within 5 or 6 inches.

For the next test, I constructed a new 30 cm coil, this time with about 70 turns of wire. The first change I noticed was that the frequency of this coil was lower, around 41 kHz instead of 86 kHz. After the initial ramp-up,

the frequency was quite stable, increasing linearly and very gradually:

If we divide the thirty minutes between the ramp-up (first five minutes) and the last 10 minutes (which include the coin test) into three ten minute periods, the frequency varied by 15 Hz, 28 Hz, and then 5 Hz. This is comparable to the stability of the first coil, but without the erratic jumps and dips in frequency- throughout that half-hour period, the frequency changes linearly, which could make this signal easier to work with than the signal generated by the first coil.

For this test, I had added the timestamp to the Arduino code (this version of the code can be found here), so that I could more accurately time the coin test. I held the bottom of the bag of coins level with each inch mark on the ruler for ten seconds before lowering or raising it:

As the graph shows, there are four recognizable "levels" on each side of the peak, which means that the coil was able to detect the bag when it was within 4 inches of the top of the coil. Since DZL says that his metal detector was able to find a single coin at a depth of almost 6 inches, it's clear that mine is not measuring up.

However, I do think it will improve with better code. In this post, when I say that the coil detected the bag, what I really mean is that I, looking at the graph with the naked eye, detected a change in frequency. For example, if the program can get a more sophisticated idea of the default frequency (for example, by taking a running average of the previous minute(s)), it would be able to distinguish between noise and small changes introduced by the presence of metal. At some point I'll return to the metal detector and work on improving the code, but for the moment I've switched gears and am going to focus on drivetrains for a while.

My First Metal Detector

Over the past month or so, I've made some progress with building the metal detector circuit for my robot. Its detection range is shorter than predicted by the blog I got the circuit from, but I think that can be improved by more sophisticated programming.

First I built the circuit, using the Arduino Duemilanove and a breadboard. A commentor on the original blog post said that he had trouble prototyping on a breadboard because the "parasitic inductance, capacitance, and resistance" caused the signal to break down after a few minutes. I decided to prototype it on a breadboard anyway and then transfer to something else later (maybe perfboard?) if it became an issue. I haven't observed the signal "breaking down", although the frequency does tend to slowly increase over time.

Here's my circuit on the breadboard:

It was easy once I figured out that the capacitors on the diagram were in nanofarads, not microfarads.

It's messy, I know- I wanted to test it before I went to the trouble of trimming everything down, and since there's still a possibility that I'll do the final version on perfboard or something, I haven't cleaned it up yet. If you want to know more about what breadboards are or how they work, I covered it in a post last summer.

After assembling the circuit, I made the search coil. I wanted to try out a few different sizes of coils, to see which size would work best for this project. This site gives a thorough comparison of different sizes of coils. I wanted one coil that would match the one DZL used, 30 turns of wire around a 15 cm diameter base; the other two are 20 cm and 30 cm in diameter.

I made the coil bases out of an old paint bucket, using a bandsaw. The bucket was originally 30 cm in diameter, so I was able to just use the slice of paint bucket for that base. To make the smaller bases, I made a cut through the side of each slice, pulled the sides to overlap, and then drilled holes and zip tied them together to hold them at the correct size.

I couldn't get DZL's code to work (it kept bringing up errors when I tried to run it). I also didn't understand parts of his code- for example, at one point he sets values to certain bits, and I can't figure out what they were being set to or why. Rather than try to decipher someone else's code, I thought it would be easier to write some of my own. I knew that the premise of the metal detecting circuit was that when metal comes near, the oscillation frequency of the coil changes. After some searching, I found an Arduino library called FreqCount that has a built-in function for measuring the frequency at a node. You can download FreqCount here. I ran my tests using a modified version of the Serial_Output example code that comes with the download. You can read my version of the code here.

For the first search coil, I used the 15 cm diameter base and wrapped about 30 turns of  30AWG enameled copper wire around it, leaving a good six inches at both ends to plug into the breadboard. Enameled copper wire is insulated with a thin layer of enamel (hence the name), which you have to remove in order to electrically connect it to anything. I had heard of people chipping the enamel off with a pocket knife, but since 30 AWG wire is very thin, I wasn't too confident in my ability to make that work. I read a forum that had lots of suggestions for ways to remove enamel from enameled wire, and ended up using 320 grit sandpaper to sand the enamel off. It worked quite well, and that's definitely the way to go in the future. Next time I would get a different color of enamel though- red is so close to copper that it was hard to be sure I'd gotten all the enamel off. Green or blue wire would probably be a little easier.

In my next post (which should be up today or tomorrow), I will reveal the results of testing my first two search coils.

Making Sense of Motors

For the past two months I've been doing an internship for Mark Andy, Inc, so I've had less time to write and work on the robot. I've made a lot of progress with the metal detecting aspects, but before we get into that, I'm going to honor my promise from back in June to write a post on how I figured out what parts I need. Figuring out what parts you need for a project can be intimidating, especially if you've never done it before, and most tutorials skip over the process- they're providing a recipe, not cooking lessons. But understanding how to find things is valuable if you want to get into designing and tinkering as a hobby, so today I'm pulling back the curtain and giving you a tour of the process.

As someone who doesn't have a whole lot of experience with motors, I wasn't sure what I would need for the drivetrain. Out of the drivetrains I want to prototype, the C-limb design would need six motors, the wheeled design would need four motors, and the walker design would need two motors (according to the tutorial). So right off the bat, I knew I would need to buy six motors.

Next, I investigated what type of motor I should use. Several sites broke down the options into DC motors, servo motors, and stepper motors. According to AboutTech, stepper motors are specialized for positioning (i.e., you can tell it to turn 30° and then stop), but generally provide less speed and torque than servos can. I don't really need precise positioning, and I do need torque and speed, so stepper motors didn't seem like a good fit. At Robotoid.com, I learned that plain DC motors spin very fast, but provide very little torque- to function in a drivetrain, they really need to be geared down. Since I don't currently have the means to make a custom gearbox, DC motors were not a very attractive option either. Finally, I went to Handyboard.com to learn about servos: "The servo motor is actually an assembly of four things: a normal DC motor, a gear reduction unit, a position-sensing device (usually a potentiometer-- a volume control knob), and a control circuit." With their built-in gearboxes, servos were definitely looking better than DC motors. Robotoid.com suggests that a downside of servos is that they have to be modified if you want continuous rotation (their default is usually to rotate back and forth along a 180° span). I found a tutorial on Instructables for how to do this, and it looked feasible, so I decided to go with servos.

That narrowed the space a little. But, being new to the world of motors, I was still a little lost. Motors come with a set of specification to inform users of what they are capable of, but I wasn't very famliar with what they mean or what I needed for my drivetrains. After slogging through sever rather dense explanation of motor specs, I had a little better idea of what they were, but still didn't have much of a feeling for what my robot would require. The main specs for motors are torque and rotation speed, and in general, increasing either of those increases both the cost and how much the robot is capable of. So I needed to figure out the minimum torque and speed required to make my robot work. Luckily, I found an AMAZING tool for exactly that purpose at RobotShop.com.

This calculator is a godsend.

I assumed that the RobotShop calculator was based on the premise that the robot would be running on a hard surface, like concrete, and I intuitively felt that running on sand would be more difficult (and therefore require more torque). So when putting in the parameters, I wanted to err on the side of overestimating how much torque my motors would need. I played around with the calculator and found that to increase the amount of torque required, you can either increase the mass of the robot, decrease the number of drive motors, increase the radius of the drive wheel, increase the maximum incline the robot will need to climb, and/or increase how quickly the robot will need to accelerate. Here are the parameters I put into the calculator:

• Mass: 15 lbs. The robot will have drive motors, limbs, Arduino and circuit, obstacle sensor, a plastic box to hold and protect the electronics, a search coil, and maybe some PVC structure. Since it'll be small and mostly plastic, I think 15 lbs is a high estimate.
• Number of motors: 4. The wheeled design calls for 4 motors, the C-limb design for 6. Four seemed like an appropriate underestimate, since I can always give the wheeled design six wheels if four doesn't cut it.
• Wheel radius: 3". The wheels I have on hand (from the toy trucks) have radii 1.5" and 2", so 3" is a comfortable overestimate.
• Robot Velocity: 1 ft/s seemed like a fairly quick speed for a metal detector. Velocity has no impact on torque needed, but does affect the rotational velocity needed. 
• Maximum incline: 10 degrees. The robot will be moving on a beach, so I don't anticipate that it will need to climb much incline.
• Voltage: 6V. Doesn't affect torque or rotational velocity, so I just guessed.
• Desired acceleration: 0.2 ft/s². If my robot's maximum speed will be 1 ft/s, then accelerating at 0.2 ft/s² would bring it up to full speed within 5 seconds. I can live with that.
• Desired operating time: 1 hs. I would like the robot to run as long as possible, but I can live with changing the battery every hour or so.
• Total efficiency: 65%. I left it at the default.

 With these parameters, the calculator advised me that I would need motors with torque of at least 3.58 kg-cm and 4 rad/s (with smaller wheels, I would need more rad/s).

With those specs in mind, my next step was to look for specific motors that meet them. I looked on Robotshop, Amazon, and eBay; unfortunately, most servos offered between 1 and 2 kg-cm of torque. I was most impressed by the TowerPro SG5010 servos on Amazon, which were $5.17 each. The Amazon description says they take voltage between 3.5 and 8.4 volts, and gave the torque specs as stalling at 8 kg-cm when powered at 4.8V and 11 kg-cm for 6V. That seemed almost too good to be true, since other sellers were offering a lot less torque for a lot more money. I checked the specs for the same motors on another supplier, iMall, who says the operating voltage is 4.8V to 6V and the torque is 5.2 kg-cm to 6.8 kg-cm. Not exactly what was advertised by the Amazon supplier, but luckily still sufficient for this project. I ended up ordering six of them, for a total of $31.02.

The TowerPro SG5010

Next, I needed a way to control the motors. One of my friends, who's built an RC car before, warned me that Arduinos can't directly power servos. He recommended using H-bridges, little chips that act as a go-between for the Arduino and the servos. However, I was concerned that between the six servos and the other sensors and things I'm using, the Arduino might not have enough pins available to control all the H-bridges. I started shopping around for motor shields, which would effectively create more pins for the servos to interface with, replacing H-bridges as the middleman. I decided to go with the 16-channel motor shield from Adafruit for $17.50. Since it can control up to 16 motors from one Arduino, it's more than sufficient for this robot, and it should be well-suited for any future project I can come up with.

Runs 16 servos off of two Arduino pins!

The last piece of the puzzle was finding a battery to power the motors. This Adafruit article recommends using separate power supplies for the Arduino and the motors, so I decided to do that. I won't go into too much detail about how I chose a battery, but after reading a lot of comparisons of different kinds of batteries, I decided to go with LiPo batteries for the motors and 9V Duracells for the Arduino. The motors need a voltage of either between 3.5 and 8.4V, or 4.8 and 6V (depending on whether you believe the Amazon seller or the iMall seller), so I decided a 6V battery would do nicely. LiPo batteries don't come in 6V- the closest you can get is 7.4V, so I decided to go with that, and also ordered some adjustable voltage regulators (LM317T) on Amazon ($6.19 for 10). This will allow me to set up a circuit to lower the voltage across the motors to 6V. The RobotShop motor sizing tool also tells you how much battery capacity ("battery pack") you need to run the robot you describe. Battery capacity is measured on battery descriptions in units of mAh, although the RobotShop tool gives it to you in units of Ah. For the inputs I described above, I need 938 mAh in order to run the robot for 1 hour on a single battery. More mAh means the robot can run longer at those specs, and gives me some wiggle room on my estimates. In the end, I ordered three 7.4V LiPo batteries of varying capacities, and a Tenergy charger from Amazon for $32.88.

If you've never done this kind of project before, hopefully this post has given you some insight into how to begin. In the next few days, I'll be post an update on my progress with metal-detecting.