Beach Detecting Rover project

[fixstuff]

streaming audio test

Well, I tested the audio portion for being streamed via a network. We'll see if it will be real usable. There is about a slight bit of latency over the network, but quite responsive actually. Old prog but still good. http://www.speakfreely.org/

It can be run from a command line, I simply created a batch file for it to start a preset connection between the comps.

I used this years ago before Skype and all the other Voip programs came along. It's still available for download, and is under 1M in size.

The old standby streaming VLC couldn't cut it for some reason. It's looking like the current version has a filename length issue in the driver drop down menu. Maybe by build time it will be resolved. I also suspect VLC will have way more latency than the Speakfreely.

For now, this works, and it will allow me to hear the detector audio over the network to the remote computer. Keep in mind that the audio will be information only, the rover will still independently log and notify when a signal is detected, which I should see even with the latency. The whole point is ballpark location anyway, since I will pinpoint with another detector.

[Qiaozhi]

Oh, yeah your right, I missed that. I was thinking diameter for some reason. Do you think that a coil that big would work with the Barracuda? I'd like to use that if I can since I already have the kit.

Personally I would just try it, as it only needs 10 turns of wire.

Another question: Does the Barracuda have a non-motion mode? I'd prefer to simply drive over an area without worrying about sweeping a coil back and forth. Not sure if you worked with the Barracuda, but maybe someone else reading this may know also.

I've never used the Barracuda circuit, so perhaps someone else can answer this.

[6666]

Just looking at the BOM
thats adding up to a big weight
for something to run on sand
how big are the wheels

Here is the coil theory
according to Papa Alex
ORIGINAL COIL= Diam-11 inch, R= 1R5, L= 450uH, damping resister 330 ohm
if you tweak the number of turns in the 1100x1100 coil so its about 450uH
the 330 ohm damping R should still work, but would pay to look with CRO
Qiaozhi has given a starting point.

My Cuda works fine but it is a motion machine

[Sean_Goddard]

How about you scan a whole area using the rover, then "map" target hits? You can then simply upload the coords into a handheld GPS and go to each location using a "normal" detector to analyse / retrieve the finds.

[fixstuff]

How about you scan a whole area using the rover, then "map" target hits? You can then simply upload the coords into a handheld GPS and go to each location using a "normal" detector to analyse / retrieve the finds.

That is definitely something that I will be testing, but with the resolution of GPS no better than a couple meters, I will have to take additional measures such as averaging a triangulation of the scan area or something.

[fixstuff]

Just looking at the BOM
thats adding up to a big weight
for something to run on sand
how big are the wheels

Here is the coil theory
according to Papa Alex
ORIGINAL COIL= Diam-11 inch, R= 1R5, L= 450uH, damping resister 330 ohm
if you tweak the number of turns in the 1100x1100 coil so its about 450uH
the 330 ohm damping R should still work, but would pay to look with CRO
Qiaozhi has given a starting point.

My Cuda works fine but it is a motion machine

Ok, that answers that thanks. I'll just have to be moving the rover to pick up signals, or will have to sweep the coil somehow.

As to the wheels, they are 10" wheel chair wheels, that I can swap out for a balloon version. The balloon version is designed to allow people with wheelchairs access to a beach area, the "normal" 10" wheelchair wheels wouldn't probably work too well in loose beach sand, but might work fine on harder sands and soils like the desert. Mojave desert areas typically have a hard packed surface with a loose scattering on top, that should work with the normal wheels. I'm sure I'll probably end up with the balloon tires when it's said and done, like these..

http://www.wheeleez.com/beach-wheels...ane.php#WZ124U

The weight is indeed very heavy. When you start looking at a platform large enough to carry the payload I'm looking at, stuff gets big. I could have reduced some of the weight using batteries, but then I'd have to deal with charging issues, and deep-cycle batteries powerful enough to run 4 motors for skid steering would be almost as heavy, nearly as expensive, and only run for 20-30 minutes. I want something I can run 3 or 4 hours, refuel, and be back up and running quickly. The skid steering will allow me to make somewhat precise back and forth scans without having a traditional steering mechanism. The skid steering will allow me to use to Rover to pinpoint targets much more easier as well.

One good thing about the size of this rover, as it will be able to handle just about anything I throw on it. I intend to eventually mount more cameras to it, and try adding in more autonomy using, say, a Microsoft Kinect module. Using that module would allow me to build a 3D map of a scan area, that I could perhaps overlay onto existing survey maps perhaps. Really exciting stuff

[fixstuff]

built baracuda md and other things

Hi all,

Well, I built the Baracuda kit from Silverdog last night. I tested it today, and I have to say I'm pretty darn impressed. That was the first detector I built (other than a couple simple little BFOs), and it worked flawlessly. Even with the hokey little coil I wound around a 7" paint can, the detection depth was a good 5-7". I did tweak the delay and offset a bit, but the components are so darn well matched up, I had a ton of leeway - it worked right off the bat on power up. The coil was simply 25 turns of 22AWG, which was a bit low inductance, but it ran pretty well. I suspect if I'm very careful, and use smaller wire with a larger diameter, than depth should increase pretty well.

I did "simulate" the coil in a blanket, and it didn't do too badly. I believe it will be fairly straight forward on sewing that into a blanket if I so choose. I suspect I will prefer a rigid coil though, especially if I want to use to Rover to pinpoint.

I was able to secure my framing materials. Its going to look pretty sweet with the 80/20 frame.

The detector output audio is wonderfully clean. I had a 650hz pulse of 100uS which I can easily route into the sound card for detection in Flowstone.

Attached are some pictures of 80/20 framing, 2 screenshots of the baracuda waveforms, the assembled Baracuda kit and coil, and a screenshot of the audio pulse waveform. So far so good.

[6666]

Congrats on the Cuda build, that was fast.
One thing get rid of that 9v batt and run it off nicads

[fixstuff]

a couple more items

I forgot some things.

Question about the coil. Although this appears to be a true statement from my testing, does the detection depth increase proportionally with the diameter of the coil? If true, is there some detectorist formula out there that will calculate maximum depth possible based on coil diameter and object size?

I'm probably oversimplifying things, but if anyone has any "rules of thumb" with regards to coil sizes, motion, depth, battery life, inductance versus depth, whatever, I'd like to hear about them, particularly with PI type detecting and/or the Barracuda I'm using.

Question on battery life: The Barracuda uses a 9V battery. I ran it tonight for about 4 or 5 hours. After about 5 hours, I noticed that the detector circuit started getting unstable, and adjusting the threshhold pot made no difference. I put in a fresh new battery, and my problems went away. The "dead" battery had a voltage of about 7.5V. The detector went unstable almost all at once, so I suspect that its fine down to a certain point, say somewhere around 8V. Does 4 or 5 hours on a standard alkaline 9V seem right for this detector? Could my battery life be shorter because I don't have as many turns on my coil as I need? I have calculated the inductance at about 250-300uH. Should it be higher, and will that extend battery life?

I intend on powering the detector from the 250W ATX power supply, specifically the 12V output with an inline 9V regulator. A typical 9V battery has a high ESR rating which limits current to about 100mA. A 9V alkaline battery has about 550 mAH capacity, which gives you about 5 hours or so. This implies to me that the circuit is pulling 100mA. I verified that with an ammeter @ 102mA. Is this typical for anyone else using this detector? If I supply power to the detector with a power supply, would I need to limit the current so that the Baracuda, which is designed for a 9V battery, doesn't burn up with a power supply? I may do that in any case, but I'm also wondering would my detect depth increase if I supplied more current. The output FET gets slightly warm on a 9V battery. If I heatsinked it well, perhaps I could run it harder without hurting anything? I'd like to keep the 9V, so that I don't have to go back and change resistor values or retune it, but I could easily supply it with more than 100mA.

Feel free to let me know anything that may be helpful since I'm new to the homebuilt MD world.

[fixstuff]

Possible marking scheme for targets

Since GPS is only accurate to a couple feet, I was planning on supplementing that with a scheme to try a marking system of some sort.

When the rover detects the target, it will drive back and forth a bit over the target to pinpoint its location. The rover will then drive over the identified target and will shoot a marker of some sort onto the exact area that it detected with the MD. This, in conjunction with the uploaded GPS coordinates hopefully will make it easy to come back to a previous detected spot - especially if you aren't digging up every target.

One concept I'm thinking of is simply using a golf ball or something for the marker dropped onto the target. It shouldn't move or roll around on a sand surface, is highly visible, and can easily be retrieved when going to dig. The golf balls, or something simlar could be loaded into a hopper so something. I could spike the ball with an iron nail, in case it gets covered in the sand later.

I've also thought of darts, or a spray paint of some sort (beach might not be good for that one, would work for desert though). Any other ideas on a marker of some sort?

[6666]

I favour spraying food colouring then the greenies wont whinge
dump the 9v batt and use 8-10 nicads, so the circuit can source
all the current it needs.
With pinpointing
I can see some mechanical problems, but firstly is the coil going to swing from side to side
or just in a fixed position.

If the coil is 1100x1100 trying to pinpont canslaw will be hard.

If the coil is fixed and is 12 inch wide and your rover is 3 feet wide, you will have to go over the same 3 ft, 3 times, at 12 inch spacing.

Here is a bit more on the blanket coil,
The coil is embedded into a rubber material and probably shielded
The Blanket coil is made by a Bulgarian and sold through this mob http://www.accuratelocators.com/pi_blanket.html

[fixstuff]

Hybrid Multi-Detector Coil System

Ok, I like the food coloring idea. I'll go with that for now. I believe that, coupled with the coarse GPS and the discussed GPS triangulation techniques, I can come back to targets later pretty effectively.

For the coil, as much as I like a blanket concept, I think it may be somewhat limited. A remote rover platform like this allows me to start thinking out of the box on a lot of issues, including detector and coil designs. With the rover platform, I can attempt things that would be difficult, if not impossible to do with a hand detector.

For one thing, I'm looking at building the Rover around a Hybrid, multi-detector coil system. This system will work by switching to the best detector design for the task at hand. The assembly will consist of a non-metallic XY base, with small, individual coils located inside of a large PI coil on the periphery of the XY base. Each individual coil would use a different detector circuit. Each circuit's individual coil would only be powered up when being used. This would keep the coils from interfering with each other when not in use.

For general scanning, the rover moves forward, using the large, square PI coil located on the XY base, such as the Barracuda PI circuit.

Next, once a target is detected, the operator can select whatever coil is desired. The system would switch over to the desired circuit and coil. The operator would then manipulate the XY axis using the operator's Xbox controller thumb joystick, and would center the target as best as possible inside the selected coil. Once satisfied that the target is centered, the operator will hit the "save" button, the Xbox controller's green "A" button. The target's position is now stored in the system.

Next the operator can choose which coil is desired next. Once selected, the system will drive the XY axis automatically to center the desired coil over the previously stored target position. Once the new coil has reached the target position, the operator can again manually move XY to determine if the target is trash or not. This process can be repeated for different coils if desired. I have 4 coils shown in the sketch, but I will see what works best, it may need only 2 or 3. Eventually, this whole process can be automated at some point, but initially these steps will be done manually. If I can manage it, I will simply build a complex, multi-loop coil design, with each loop functioning for a different detector.

Another thing that's possible with this platform is detector design. For all that's possible with super advanced DSP circuitry and the best detectors, nothing beats what a human brain is capable of with training. Really, in some regards, a good detector design is attempting to emulate would a well-trained human being can do with a simple detector, and his ability to hear and discriminate different audio feedback clues. Another thing modern detectors do is to automate the settings necessary to allow an operator to not have to think about or remember what settings need to be adjusted for a particular method. A basic detector can be interfaced to a control system to allow for remote adjustment of the basic controls such as threshhold, offset, delays, etc. These positions can be saved, scaled, etc for many different possibilites. A single button on the GUI can instantly switch to a completely different setup, and the operator can select each individual setting and scan using that. On a handheld detector, that can get downright brutal, with different menu levels, options, etc, that the operator has to flip through, where a GUI on a LCD screen, the operator can select these with just a mouse click. I'm going to interface each detector circuit to A/D channels that can be tied into the GUI and system. This also allows for automatic system control of these features as well. The sky's the limit. My initial build of the system will bring in the hardware and basic slider controls on the touch screen, later on I can add the automatic switching and recipe functionality.

Here's where i need some more help. I want to use detector designs that are analog in nature, i.e pots to control features, but I want audio circuits to be rich with information. This gives me the ability to interface all of the features of a particular detector circuit, and also gives me the ability to bring in the audio for sampling that later on I can do a lot with in the PC. Simplfied go/no go audio circuits that may be good for an operator, might not be so desirable in a system capable of some heavy duty analysis of the audio.

A good example of what I call a rich audio system is a White's XLT detector, and I'm sure there are others. With all of the various audio options turned on, it basically gives information overload to an operator's ears. However, an automated sampling system might be able to do wonders with all that audio information.

What I need are detector design's that have those levels of audio discrimination as well as lots of control of metal detector functionality via analog interfacing, i.e. pots, The more the better.

Anyone who knows of suitable MD designs, with these features, please feel free to speak up. I'm new enough to this hobby to not be familiar enough with all of the dozens of various MD designs out there, of which I'm sure have features that would be beneficial to me on the rover. I'm not limited to how many designs I could incorporate into this hybrid. With this system, theoretically, I could use this platform to benchmark different detector designs fairly easily. These different circuits would all use the same common rover platform, eliminating the many differences in construction, movement, and technique, inherent with different MD builds. Using this system, it might actually be quite easy to really narrow down which detector designs are truly the most optimal.

I'd love some ideas on this please. Let me know what you think.

[fixstuff]

More on Hybrid

The more I think about it, the XY base will need a Zaxis. This XYZ will use a complex, multi-loop coil, on an arm extending out from the rover. I may simply just stack coils in layers, and just switch in whichever layer I need for the detector.

The Z axis is also needed for pinpointing.

[oldyman]

Hello ,
I like the Idea, and I´m looking for a underwater rov for myself for quite some time .
So here some links to get more ideas and see what the pros doing :-)
Take care and keep up this fantastic Projekt
the old one

http://www.vallon.de/products.lasso?...i-sensor&b=915


http://www.foerstergroup.de/FOERSTER...7573ab0.0.html


http://www.jwfishers.com/rmd1.htm

[fixstuff]

More ideas...

Ok. Hadn't replied in a while this week, being busy at work and all. I have been working on the Rover schematics. Got most of them done. I've been ordering misc parts here and there for the build. Found a really cool little XY table that I think might work for the detector scanner. One of the THK slides is missing its bearings, but I sure I can scrounge some up. I'm not sure if I want to use the steppers though, we'll see about that.

I've been thinking about the detector portion. I've pretty much decided to finalize on the prototype the Barracuda for the PI, and the IDX Pro for the VLF portion. One thing I really like about the IDX Pro portion. I will be using the VDI code thoughtfully posted by dfbowers as a starting point. I won't use the Arduino, but I would like to use the Propeller for that. So that's good. Trying to get actually source code from folks is like pulling hen's teeth. That will get me started. I'm thinking that it will take me a good bit to really, really understand detector design at the level I will need to to actually start coding for it in software. For now, I will use analog metal detectors, like the Barracuda and the IDX Pro to at least get started. One day, I hope to use a board similar to Aziz's and do the whole detector in software on the PC. We will see.

I have some pretty cool ideas about what I can do though. Although the PI is more of a all metal type detector, the VLF IDX Pro with the VDI has given me an interesting idea. Since we have a VDI number associated with the target, I am planning on using that number to bring up samples on the PC GUI. For example, for a VDI of say 65, I can have a sample played saying, "Nickle!". Same goes for any other of the VDI numbers. For a range, I will take the sample and adjust it's pitch. Like this "Nickle!" *high pitch* for a VDI of 68, and say "Nickle!" *low pitch* for a VDI of 63. This will be the equivalent of a icon discrimination, but with audio. That might be pretty cool. We'll see how that works out.

I ordered one of the wheelchair motors, and a different motor amplifier than the one I specified earlier. I like the Sabertooth 2X25 and the Syren 25, but I don't like just having the serial input. The whole rover concept is to be able to build the control system rapidly. I found an amp from Pololu that may work out better for this design. The Pololu 24V23 is nice because of the USB port. It will appear as a virtual COM port, so I won't have to worry about analog wiring, or serial wiring off the microprocessor board. Here is a link to the amp:

http://www.pololu.com/catalog/product/1383

Some other ideas I'm going to implement (why not huh?). I will be using a USB Cam to monitor the XY table during pinpointing, but I will be using a Kinect sensor for the main Rover view. If one works out, I will put one on all for sides eventually. This will allow me to map the terrain around the Rover, which might allow me to overlay that point cloud onto Google Map terrain data. This might make the GPS accuracy less of an issue.

Speaking of GPS, I've been researching that a bit as well. By taking up to a minute of samples, and averaging them, accuracy can be increased. Another trick that can be used is multiple GPS sensors. Using 3-4 GPS sensors versus 1, can increase accuracy by a factor or 5 or more. I've even seen a GPS project that can get accuracies to 1cm, although that seems rather far fetched. I'm thinking with multiple GPS's averaging, with the food dye target painting, I should have fairly good repeatablity.

Other design changes from the original BOM. It looks like I will be using the Phidget SBC2 after all. It makes too much sense not to have it, even if I only use it initially for the webservice control of the Phidgets. Using the webservice gives me both a remote control option via the Flowstone remote laptop, and local SBC2-based control later. Particularly where I want this local control is the XYZ motion. With the motion control algorithm done locally, I can have a sweeping motion to be a true harmonic sine wave type rather than a crude back and forth motion. This will allow me to hit a single button, and have the detector coil sweep back and forth smoothly. During pinpointing, I can also have the Z axis pull up a bit, and possibly automate the whole pinpointing operation.

More later... Once I get the metal detector interfacing schematic done, I'll post the whole Rovers schematic.