Announcement

Collapse
No announcement yet.

Beach Detecting Rover project

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by oldyman View Post
    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
    Well, its not underwater, unless the motors go nuts but, thanks for the links. Those are some really nice pro level stuff they're doing. It will definitively help give me some ideas. I already saw one aspect that had been troubling me. They have a really long armed non-ferrous scanner assembly. I may have to do something similar with the magnetic signature of the rover.

    I also liked the Vallon mine detector marking system. This is exactly what I'm looking to do with the food dye idea for when I mark detected spots.

    http://www.vallon.de/news.lasso?a=82

    I really like what I'm seeing as an overall theme as well. It looks like its very doable to have a coil mounted extending out from the unit, to prevent interference. For a PI coil this to me shouldn't be much of an issue since the rover is not moving in relation to the coil during general scanning. Since its motion only it shouldn't see the rover. As long as there is no relative movement between coils and rover it shouldn't be much of an issue for the PI scan.

    I also noted some of the scans of the areas they show. That data set is definitely something I want to try with the false color image. I should theoretically be able to do something similar. By taking signal data, and superimposing GPS, compass heading, and wheel encoder movement, I should bee able to make a data map like that. To get better wheel encoder position data, I will have a 3rd axle that is not driven, but will simply have encoders on both wheels. This should give me a accurate dead reckoning position off of a starting high accuracy GPS reading.

    One thing I've noticed on all of those links. High end pro equipment is VERY expensive. This rover is looking to be in the $3K-$4K range, with most of that cost being surplus, so it might be way cheaper.

    One more thing.. Being since this rover will be outside, I've been knocking around some ideas on weatherproofing it. Here's what I thinking. Rather than have everything buttoned up in a housing where nothing is visible, I'm thinking of using some inspiration from the world of high end PC modding. The enclosures I am going to build out of clear lexan. This way all the boards and electronics will be visible, and it will look pretty darn sweet. I might even throw in some ground effect lighting in the enclosures (say low light red), so the rover is visible at night.

    Comment


    • #47
      This rover is looking to be in the $3K-$4K range
      One good find taken to the pawn shop will fix that.

      You might want to have a deadman kill switch in case it heads into the ocean by its self.
      re weatherproofing, dont build a solar cooker with that clear lexan

      Comment


      • #48
        Land Rov

        Hi
        one more
        still at the Internet :-)
        This guy is interesting because he is a professional underwater rov operator ! :-)
        working for Oceaneering International
        cheers
        the old one

        http://www.wiltshiretimes.co.uk/news...hunting_robot/

        Comment


        • #49
          Originally posted by oldyman View Post
          Hi
          one more
          still at the Internet :-)
          This guy is interesting because he is a professional underwater rov operator ! :-)
          working for Oceaneering International
          cheers
          the old one

          http://www.wiltshiretimes.co.uk/news...hunting_robot/
          I like his statement: "It does track far better than a hand held detector because it goes at a steady speed and just generally detects more efficiently."

          A steady sweep speed is very important for a "motion type detector". "Non Motion detectors" went out of fashion, but for many applications they would be better.
          Could we modernize a "Non Motion detector" so it could reach it's full potential is such applications?

          Tinkerer

          Comment


          • #50
            Originally posted by 6666 View Post
            One good find taken to the pawn shop will fix that.

            You might want to have a deadman kill switch in case it heads into the ocean by its self.
            re weatherproofing, dont build a solar cooker with that clear lexan
            Yes, there actually is a dead man switch. I have an Estop system that will allow the operator to hit a button at the operator console that will kill the motor power.

            Good idea on the cooling. I will have the bottom ventilated and the end with the motor amps house a fan blowing out. I'll throw in a temp/humidity sensor on my prop sensor board as well.

            Comment


            • #51
              Originally posted by oldyman View Post
              Hi
              one more
              still at the Internet :-)
              This guy is interesting because he is a professional underwater rov operator ! :-)
              working for Oceaneering International
              cheers
              the old one

              http://www.wiltshiretimes.co.uk/news...hunting_robot/
              I had seen this article at one time or the other, but had not read the text of the article, someone had just posted the picture. However, it does make me think. Even though I have bought the XY table, there are way cool alternatives. Particularly the sweeping motion arm. If I use an arm running off ax12 servos, I can have preprogrammed sweeping arm movements without reinventing the wheel. Yes, that will be very doable. I will keep the PI on a big non sweeping loop using motion from rover travel, and use the ax12 arm to do the VLF pinpointing. I'll post a link to what i'm referring to later when I get to a PC rather than my mobile phone.

              Comment


              • #52
                One more thing, using commercially available detectors what are the two best ones that aren't insanely expensive that use pots and knobs versus touch screens and membrane keypads. I can't interface to those very easily . I'm locking in on comercial detectors and coils to start with and playing with home built detectors later once the rover is working good.

                So to rehash. 2 detectors. 1 pi, and 1 VLF. Pots and switches only. Not to expensive (approx $500 or less)

                Suggestions?

                Comment


                • #53
                  Thought of an optimal marking system that will be quite nice. Simply use a solenoid actuated paintball gun aimed at the coil area, maybe even dead center of the coil. The paint ball hopper could hold a couple hundred balls I'd imagine.

                  Comment


                  • #54
                    parts on order

                    Alrighty then. All the parts have been ordered! I've finished the conceptual design on the coil sweep arm. I figured out a way to keep the design fairly simple, using two 12" linear actuators, and a chain driven servo base. It's an articulated jib crane design that will give me a very wide sweep area. I found several linear actuators in the $75 range, so I should be able to build the sweep arm under $300.

                    It looks like I'm not going to build the enclosures from Lexan after all. Although it would look cool, I already have a couple IP65 rated enclosures that look like they will work fine. I will have an enclosure housing the motor amplifiers and power supplies, and an enclosure for the rest of the controls.

                    I've got the concept design done for the Rover chassis and layout. The basic concept is a rover approx 6ft long, 3ft wide. The generator will sit on the rear of the Rover. Next to the generator, is the coil sweep arm which will be mounted to the chassis frame in the center of the rover. On the other end of the rover from the generator, the two IP65 enclosures will sit vertical up, back to back, with each door swinging out to each respective side of the rover. Everything in the enclosures will be DIN rail mounted, to a inner panel. This will allow me to remove the internals during bench testing without having a large enclosure to deal with. All connectors and cable penetrations will be rated IP65 rated for weather resistance.

                    The coil sweep arm will extend out over the generator and will hold a coil assembly behind the rover. This will allow the coil to be moved up or down based on the rover's inclination angle. A front mounted sweep would not allow this and would block the view of the rover from following the terrain. In addition it will be easier to pull the rover up a bit, when verifying targets with a hand detector if desired.

                    It may be possible to perform a very WIDE sweep of the coil using this setup. Theoretically, this could give me a scan area over 6ft wide...

                    I've tasked my son to getting me and animation of the rover. He's really into Blender, so it should look pretty cool. I'll post the animation video to Youtube, and include a link to it here later.

                    I'm at $3500+ so far on the build, and that's including scavenging a lot of parts, so a straight up build will probably be in the $5k range.

                    Still working on the schematics. I need to make some more changes, and finish the MD section. Now that I'm settled on using the Gamma, I will include the interfacing for that as well.

                    @oldyman: I was able to find some photos of the college contest, but they were dated 2007, and didn't have much info, thanks for the heads up though.

                    As far as the detector goes, I'm going to have to step back a bit. I had originally planned on using several coils, and just switching on whichever one I wanted. That doesn't work very well. It does work, but it absolutely kills the sensitivity of the detector. So for now, I'm back to a single detector. For now, I will just use my Gamma 6000. Once I get the rover built and running, I can start looking at other detector designs and such. It was helpful to have built the Barracuda, since it allowed me to test them together, but I will just put the Barracuda circuit into a hand unit.

                    There are some real benefits to using the Gamma 6000. One feature that drives me nuts when using it by hand, (i.e all settings returning to org when powering unit), is actually beneficial to interfacing it. I can have all of the settings I want set automatically by my control system for whichever feature I want, which will be nice. For a digital modern day detector, this would be very difficult to do without a built in interface to the detector. A typical detector's setup retains memory - meaning a separate control system doesn't know the power up state of the detector. The Gamma 6000 is however, perfect for this, since it's power up state is always known. I can have both a manual button control from the laptop, AND the automatic sequencing. The only thing I wish I could do better is the LCD screen viewing. A webcam looking at the Gamma's LCD screen sucks. It's usable, but I'd really wish I had someway to tap into the screen for feedback. Any First Texas folks want to PM me on some tips to do that, I'd really appreciate it.

                    I'm hoping to do some field tests on the rover in July. Hopefully, I can get it built in time for my trip to Caly. Otherwise, I'll just be using hand units.

                    Well, that's all for now!

                    Comment


                    • #55
                      I really like the ideas on this project but i think i must be missing something.

                      Why would you go to all the trouble of marking a targets exact location and all this involves when you are going to have to go recover the target yourself in the end?

                      We all know that beaches change each day so and data once obtained in effect becomes less acurate at the turn of each tide.

                      Why not set up your rover to just find a target with the GUI you have planned, then when it 'Hits' a target have a mini type beach cleaning machine, being towed by the rover, start up and scoop the target up for you. Even if the target is not collected by the cleaning machine you will have marks in the sand where the cleaner has activated to try and pick up the item. Cleaning machine only need be as wide as the coil.

                      This way your really do have fully automated detecting, just a case of getting that beach sweeper working properly. This will be the real hard part.

                      You cound also clean the beach of litter if you so wished depending on the amount of discrimination you wanted to use.

                      Go the whole hog and slap a big solar panel on the top

                      What ever you do in the end i would love to see some video footage of it working

                      Have fun....

                      Paul....

                      Comment


                      • #56
                        project name could be better..

                        The project name is actually a bit of a misnomer. Yes, I could use this rover for beach detecting, and I'm sure I will occasionally. What this rover is really designed to do is detect in a field or open area. The mapping portion is intended for 2 things. The first is to obviously log finds. That isn't a big deal, and doesn't have to be as sophisticated as what I'm building. The 2nd and most important reason is trending. With a scatter plot of finds on a topographical map, things that are not immediately visible with individual finds immediately become apparent when looked at as a whole data set. For example, for gold prospecting, a nugget wash area may show the location of an old stream bed not immediately apparent visually, especially in dry/desert areas. Another example is old foundations and dwellings. In an open field, it can become apparent where dwellings and buildings stood from a scatter plot of target indications. This is why its important for the mapping to be as accurate and precise as I can get it.

                        Once I get the unit built, I will get a better idea of what I can do with it. At that point, it simply becomes software and process development. Theoretically, I can even develop this rover as a general purpose research platform. I even intend to try it out as a remote drive unit for a pull-along mower unit. The mower unit could also be used in the field during detector scan area preparation.

                        Another task I will be testing with this unit is the Microsoft Kinect mapping. I'm really interested in terrain mapping using the Kinect in conjunction with GPS mapping using Google satellite mapping data. Google provides KML interfacing capability to Google Earth, which I can use to overlay maps with scan information. I can even set up boundary scans and can potentially have the rover scan automatically within those boundaries.

                        All of this is ambitious, but the first step is building the rover itself. Even if I don't succeed, I will learn a lot about the whole process.

                        If I'm successful, maybe I could even build these to order for others as long as they aren't afraid of a $5K to $10K cost.

                        Comment


                        • #57
                          PI related questions

                          Ok. I have been looking at the Barracuda schematic. I am trying to wrap my head around how it works, but I'm a bit rusty on my analog. I want to run this by you guys here on the forum, to see if I'm on the right track.

                          As to the schematics. It looks like the two schematics are fairly close with the exception of some components. The basic layout is the same. From what I understand, this is also how most analog PI circuits look.

                          In the upper left hand corner, marked Section A. This is a clock circuit correct? Does this clock circuit operate at 10Khz? I can check this, but I'd like to check for sure what it's supposed to be.

                          This clock circuit drives 2 sections. These are sections B and C.

                          Section C is the Mosfet Drive circuit, which drives L1 at the clock rate. The base of Q1 is driven by the NPN transistor Q2, which in turn is driven by the clock from section A.

                          Section B is a delay circuit. How does this delay circuit work? I see 2 sections. There are 2 delay signals coming off this section, how do they drive the matched FET pairs going into the input of Section H? They both invert twice, meaning no inversion, but each cap stage introduces a phase delay, correct? The only difference between the two sections is one is referenced to +, the other is referenced to -.

                          Section D is the coil itself, with a delay resistor that the voltage from the echo is generated off. The current through the coil is something like 5.8A. This is based on an Rds of 0.3ohm for the IRF9530, and the coil resistance of 1.24ohms. That energy stored in the coil will generate something like 1300v. On the 220 ohm version, its 1300volt, on the 330 ohm version its like 1900volt. Has anyone actually measured these spikes?

                          In section D, that voltage is clamped to about +0.6 to 0.7V to -0.6 to -0.7V by the 2 1N4148s. Does this mean the weak reflected signal will be in that range? I'm assuming yes due to the 1000X gain op amp in the next section.

                          Section G simply provides the +/- negative reference off the single supply.

                          This clamped -0.6V to +0.6V signal then goes into the NE5534 op amp, which has a gain of 1000, that can have the offset adjusted. Do the 2 series 1N4148 diodes clamp to zero anything below -1.4V?

                          Here where it gets a bit confusing for me. There are 2 delay signals coming off the delay circuit in Section B. If the only difference between the two sections is one is referenced to +, the other is referenced to -, does this allow either a positive or negative signal from Section E to enter the op amp input into Section I?

                          What function does Section L serve? Is it simply a gain stage, buffer, or comparator circuit?

                          Section J, I assume is a comparator circuit, due to the threshold adjustment. The output from this drive the audio circuit in Section L.

                          Section K. Does it keep the audio circuit off during the on pulse to the coil?

                          I want to do some of this circuit in software. I can generate the clock from software with no problems. The clamping circuit in Section D. Is any information lost from this clamping action? I realize this clamp is necessary to prevent damage to U1. However U1 is a gain stage of 1000, which I'm sure amplifiies noise along with the weak signal. I would like to try something different. If I simply put a voltage divider on the 330 ohm resistor, I can measure the full signal without any loss of information. The only downside to this is the signal will now be miniscule in relation to the spike information. With a 24bit signal of +/- 8.4 million counts or so, I should be able to sample the low end signal. What percentage of the full spike (1300V-1800V) is the full signal. Is it in the +/- 0.7V range? That would theoretically give me a signal in the 0-10000 count range. Does this seem valid? By doing so, I can basically just ignore everything above 12000 counts or so (clip off the unwanted feedback), and basically have a nice, noise free signal.

                          I can then do some further analysis. My question is this. Assuming everything I have mentioned is valid, what information could I expect to clean from this clean signal? Would it have different characteristics for different metals? I realize that PI technology doesn;t allow discrimination, but is this more due to the analog circuitry limitation, or is there actually usable information available in that signal?

                          I would like to take that clean signal, and actually display a sample of that on a scope display. I could, of course, take a couple hundred samples and average them as well to come up with a sort of VDI equivalent, but I also want to present that waveform for both a raw visual display, and perhaps use that waveform for a comparative analysis of other waveforms.

                          Any thoughts on this, or am I totally barking up the wrong tree in the wrong forest?

                          Hopefully someone will tell me something, anything.
                          Attached Files

                          Comment


                          • #58
                            Fix thats the wrong cct, no time for me right now but somebody should post up the correct cct for you, or search the barra thread for PAPA Alex cct, cheers
                            I am so late gotta run
                            Attached Files

                            Comment


                            • #59
                              Thanks for the schematics. I had seen those, but I assumed they were an earlier version. Has anyone done a CAD version, with the same component IDs and circuit? All the CAD drawings I saw don't match up to that or Silverdog's PCB. I'm guessing that's why the component IDs were left off the PCB - too many schematics floating around with different IDs.

                              Anyways. I'm gonna hold off on getting too deep into the PI circuit for now on this thread. I will start a new thread specifically going over my questions so that it doesn't clutter this one up, which I just want to be the build details.

                              Comment


                              • #60
                                new updates to project

                                Ok. I've got parts trickling in now. I received the first 24V23 motor drive board today. I assembled it (just a few components), and tested it. It seems like it works as advertised. I have good speed control, and it seems pretty straight forward using with the virtual COM port over USB. The board does scare me a bit it's so tiny. 20A continuous rating seems pretty wild for a board not much bigger than my thumb.

                                I also got in the Phidget Spatial 3/3/3 module, and the Phidget GPS. I tested both. The 3/3/3 looks pretty good, with lots of positional info flying in nicely. This will be used to measure to position of the Rover as it drives over terrain.

                                The Phidget GPS wouldn't lock in, since I was testing in my basement, but it did connect so I don't anticipate any problems with the sensor.

                                I received my 4 pack of Propeller Proto USB boards in. I haven't started soldering up the sensors on that yet. That board will currently have only a temp/humidity sensor, but it may eventually do a lot more. The schematic shows the accelerometer, digital compass, and gyroscope, but the Phidget module is way better, has 3 gyroscopes, and is ready to go. That will free up the Prop for other tasks, and that's some hardware I won't have to build.

                                I may have had some good luck on the hardware side of things. I was able to find some nice National Instruments hardware on for sale, so I might be able to use Labview in this project. Hopefully it isn't blown up and fried I still intend to use Flowstone, but if that doesn't work as I hope, the Labview has some really crazy analysis tools I can use. I'm even trying to figure out getting Matlab in on this. I would eventually hope to get a nice waterfall spectral analysis display like the one shown on the bottom in the attached post. I'd like to try all three to see how they work out with this rover. Nice thing is, they all work with the Phidget hardware.

                                Most of the big parts are in transit. The wheelchair motors, the linear actuators, the generator, amps, power supplies, all are on their way. I got the last of the 80/20 framing in my garage now from the scrap yard, so I can start working on that too.

                                I've got most of the schematics roughed in. My son showed me a rough draft model of the animation of the rover. It looked pretty damn good. He wants to refine it a bunch more, so thats coming soon. I'm going to have him model it driving around a field while it scans with the detector boom.

                                As to wheels, I've firmed up some conceptual ideas on the non-driven wheels for the encoder feedback. It looks pretty doable, and I ordered the wheels for it today. Need to order the other parts like the flanged bearing blocks and encoders.

                                I've done some conceptual sketches of the frame and detector boom, but I want to try to get it a bit nicer in CAD so that it's to scale.

                                I've included Rev 1 of the schematics. It doesn't show most of the PI detector stuff yet. I would like to include the software based PI interface board that I've caught bits and pieces of mentioning here and there. Does this board and PCB exist? Is it available for purchase, or can I get the Eagle file for making a PCB from it? Any info on this anybody?
                                Attached Files

                                Comment

                                Working...