I have been looking at ultrasonic transducers like the ones here:
but even the waterproof ones typically have something like this in the datasheet:
... do not use this sensor in the following, or similar conditions.
a) In strong shock or vibration.
b) In high temperature and humidity for a long time.
c) In corrosive gases or sea breeze.
I am not looking for anything too sophisticated; navigation is by command and/or GPS. Obstruction detection is mostly a safety feature (try not to hit anything at full speed). I think a couple of wide cone with overlap in front (so if I detect something roughly the same decreasing distance away in both, it is likely in front of me) would work.
Ultrasonic detectors such as you suggest will be totally useless in this application. Firstly their range is very short - in the order of say 10 metres maximim. On a pitching boat their ability to detect an obstruction in anything other than a dead flat calm will be questionable. And lastly, placing ones life (at full speed - your quote -) on a device that will not work is suicidal.
Radar is what you need !
I have been programming the bot too much lately. By "me", I meant the unmanned USV. I am concerned mostly with close range. I figured I would have to correlate with pitch and yaw, which I have sensors for. The primary use for my device is almost guaranteed not to have an obstruction that isn't known to the GPS routing code. My main motivation to add this is so that I don't destroy a unit during testing if the route is wrong.
Does USV = Submarine
If so, and if it's underwater obstructions you are concerned with, then ultrasonic detectors are exactly what you need.
Howevre you need to get hold of the type used in echo sounders, which for obvious reasons are waterproof. I believe they work at somewhat lower frequency than the "air" ones. Somewhere in the order of 22kHz, I think.
USV = Unamanned Surface Vehicle
UUV = Unamanned Underwater Vehicle
So "unmanned USV" was redundant and needlessly reiterative...
I didn't make these up, they seem to be pretty standard in robotics. It's a boat what drives itself... :D
OK back to my original statement. Not suicidal as no person at risk but could be financially crippling as system will be unreliable, at best.
You could put a big rubber tyre round it to act as a fender
Do you have a specific recommendation (module or component to consider)?
Searching for radar and Arduino seems to lead me to topics that are technically really ultrasound. Parallax has a X-Band detector but it seems to be a motion detector.
How about something along this line - excuse the pun
What about something like this:
If that would work, would it still work with a coat of epoxy and UV protection over it?
The first thing you need to do is define the size, shape and material of the obstructions that you are attempting to avoid.
Needless to say a "barn door" standing vertical on a raft will be much easier to detect than a small log partially submerged but still afloat on the water.
Once you have defined the obstruction specification you can then start looking at what you need to "see" it.
The Doppler effect radar detectors work on the principal of detecting the relative frequency shift between the transmitted signal and the reflected signal from the object. If there is no relative movement, there is no frequency shift and hence no detection. You therefore should be looking at a device that will sense actual reflected signal rather than frequency shift (Doppler)
Motion detection could work since my unit is moving. Anything "moving" toward me at the speed I am moving forward is likely a non (or slow) moving object in my path. Anything moving faster is a real problem. But are waves "moving" ?
This sounds similar to a problem I've been thinking about - aircraft anti-collision methods. In such a case you want to have as many seconds of reaction time as possible. In your case fortunately the solution is 2 dimensional and restricted to a few degrees of angle off the bow (unless you are detecting torpedoes coming from any direction!) - not 3D as in aircraft.
Usually this is solved with radar or radio-frequency transponders, but I've been thinking "passive detection" - whether detecting motor ignition noise, audible or ultrasonic "wind noise", sonar-like devices, infrared heat detector, cameras looking for moving light or dark objects, etc.
So far the most promising is the camera - using Optical Flow analysis techniques.
In your case, I would imagine something like a forward-looking Fish Finder (sonar) would be the answer? I have no idea whether it would work, for example would the "clutter" caused by the water-air interface (waves!) make it totally useless?
By the way, you don't mention the speed which your USV is moving.
http://en.wikipedia.org/wiki/Sonar and the related http://en.wikipedia.org/wiki/SODAR (which sounds useless in my application due to the size of the equipment!)
Speed will probably be 10-25 mph. Conditions could be sunny and clear or pitch black with rain and high winds. Bad weather probably increases the odds of device deployment.
Some time back somebody posted a project where they made a small bot boat that traveled about in a bay mapping the depth and using gps for surface location. You might find it using a forum search. The last set of conditions you posted makes your project a non starter unless you have a lot of $$$ or have a Navy contract. You probably need to buy an inexpensive "fish finder" and do some testing out on the water. Also, you can study the current commercial equipment available such as side scanning sonar units.
Your optimism is refreshing. Here's an article about what you try to do: http://www.theengineer.co.uk/news/epsrc-funds-usv-collision-avoidance-system/1004270.article
And we're not talking here about submerged items (like lost containers, floating fishing-nets, whales and uprooted buoys.
As mentioned earlier in the thread, the primary use for my device is almost guaranteed not to have obstructions in the path. I am just trying to make X's approach to zero a little closer. It doesn't make it a non starter if I can't do it it perfectly.
The obstructions I am concerned with are not people. I suppose they could be, but the most likely thing (well, next to nothing which is what I am most likely to encounter) I would encounter would be a boat and less likely would be something adrift.
Searching around, the most promising stuff I found is using 2D images, finding the horizon, detecting the "pattern" (not really the right word; more like acceptable range of parameters) of the surface and mapping abnormalities. To do it well, you need visible, infrared and thermal all being processed at full speed and correlating the results. 4 processors would not be overkill. Even with that, it needs to have some height.
It is a really hard problem to distinguish things far out.
It does seem easy to detect that something taller than your craft is blocking your path right before you hit it and is progressively more difficult as you try to detect it further away and/or know its size and/or location.
I think for my prototype, I am going to try to get something that detects really big things in time for me to turn back.
well the image processing needs may be beyond the power of what Arduino is going to give you on it's own, I think. I would float/mount a camera very close to the water line (half submerged might be good) and monitor that horizon for changes. Short of radar, it's probably your most workable option. The key would be getting very clean data on the line where the contrast changes from sky to water.. and compensating for waves and the like would be a real pain, too.. but not impossible. You'd need more oomph than Arduino has however. Possibly one of the ARM's could do it. In addition, having two cameras, producing stereoscopic vision, would allow for a lot better distance estimation.
For image processing I would look at the BlackFin processors that have a lot of DSP capabilites, but may become pretty expensive, if you want something easier to use, just get one of this boards:
Add some ram and one 8-16Gb pen and throw in a light version of linux running openCv, choose the best board for your needs, but I think that the first one might be the best, put the openCv running in one core and the rest of the house keeping in the other core.
Improved algorithms have reduced the processing requirements, but they are still pretty hefty. One presentation bragged about getting horizon detection and object mapping under a second each on a fairly low end Windows PC. Even if I could get it down to a second, I may be travel 30' during that second and closing speed could even faster if it is moving also. Distance traveled during acquisition time is roughly the granularity. That is way too large.
If you use one of the waterproof ultrasonic receiver/transmitter pairs and really drive the transmitter, by that I mean don't mess around with 5V, use an amplifier chip, 2 LM380's in a bridge configuration or an STK module.
Those sealed ultrasonic transmitters will produce a >105dB and take a maximum input voltage of 140V!
That is enough to hurt, so don't put your ears anywhere near it when it's operating, you wont hear it, but believe me you will feel it, like somebody sticking a knitting needle in your ear.
Here in Australia you can buy a kangaroo scaring device that mounts on your front car bumper, I've seen 'roo's react to them at distances of over 100M! Again it's not something you can safely stick your ear in front of, it really hurts!
Same goes for ultrasonic "intruder" detectors, some of those have a VERY high output.
Bat's, rat's dolphin's and whales have been "imaging" like this for ever!
Dolphin's can stun fish with a concentrated pulse of sound.
I've been experimenting with a continuous output ultrasonic system.
Rather than a pulse I've been trying to "illuminate" the area in front of a small rover, then using multiple receivers to "watch" the reflected sound.
With 3 receivers I "fill" in the gaps between them by summing the outputs of the outer receivers with the centre one, sort of like synthetic aperture radar.
I started out just watching the output on my CRO, as soon as I got my Mega and XBee modules I started visualising the A/D converters output as simple vertical bar graphs.
You can drive around quite well without running into stuff.
Another thing I've tried is a few different shaped "reflectors" for the transmitter and receivers.
A simple plate at 45 degrees above a horizontally mounted transmitter widens the field of the beam produced, as well as flattening it out.
Building small horns for the receivers also is something to try.
You can definitely tell the difference between various materials and textures, grass has a different texture to gravel, bark and wood return a different sound texture to concrete, which is different to bricks.
Are you able to divulge more details? Like specifically what hardware you are using, how big it is physically, etc.
I started out using an LM386 @12V, then went to 2 LM380's in bridge configuration.
The receivers have 2 TL081 JFET op-amps, each with a gain of 10.
Originally I was using my SYM-1 (that's a 6502 single board computer with 32K of RAM, running @ 1Mhz) to process the data, using 3 ADC0804's.
That was kinda "iffy", so I gave each A/D converter it's own 2K static CMOS RAM, with a counter stepping @ 10khz, which is the max sampling rate of the ADC0804.
That only gives you a minimum of 1 foot/sample, as sound travels @1ms/foot.
I then went to TL0831 ADC's, those are 8 bit serial converters that let you clock data @600K, I divided the 6502's 1Mhz clock by 2, to give me a 500khz clock, which gives 62.5ksample/sec.
Thats a minimum range of around 5mm! Which was too tall an ask for a 1Mhz processor.
So I started using the same 40khz clock I was using to drive the ultrasonic transducer, which gives you a minimum resolution of 6cm, which was still pushing the envelope for a single 6502.
I started using the SYM simply to control the sonar, then passed the data on to an Apple II, that was kinda slow as well, but a friend gave me my first Linux system, a DX-4/100 and I transferred all my Pascal code over to the Linux box.
That's as far as I got until a couple of months ago when I got my first Mega.
As I said first thing I did was put a Mega on a $20 radio controlled car, with a Pololu H-Bridge module and an XBee module.
I'm using the first 3 analog inputs on the car's Mega for the 3 ultrasonic receivers.
My second Mega is receiving the data and I'm displaying it either on my eee or my desktop machine, just as simple vertical bar graphs.
It's all pretty crude right now, but when work calms down a bit I'll refine the circuit and code.
I'll draw up the circuit if you want and post it.
There is not much to it, just the LM380's driving the transmitter, I got the circuit straight from the National Semiconductor application note.
The receivers are just 2 JFET op amps each with a gain of 10.
Even if you want to use normal ranging you can still use the same setup.
I should mention I really like building big, complex circuits out of 7400 series chips, normal 74LS series can clock at a maximum of 25Mhz, which was pretty darn fast when I only had access to 1Mhz processors.
The craziest/most complex thing I ever built was a "Life" engine, that could do 25 generations/second.
So if this idea for "sonar illumination" sounds complex that's why.
Using a modern microcontroller will make it a lot simpler, even if you need to add external RAM as a buffer.
Besides if bats can do it, so can we!
Besides if bats can do it, so can we!
They can hang upside down completely naked over a 100' drop to a rock floor, let go and survive without incident.
Not sure I could do that, even with a dozen MEGAs. :D ::)
Anyway, yes, I am very interested to see what you come up with.
I have to stop getting sidetracked as well!
Said $20 rover now has GPS and an HMC6352 digital compass.
When I do have spare time I've been working on getting the thing to travel between 2 GPS way points.
Ultimately I want all this in my UAV, I figure a slow moving ground vehicle is a much more "forgiving" environment than a 'plane in the air.
The other, but related project is a GPS/navigator/"tricorder" thing.
One thing I should warn you, if you are going to do much work with ultrasonics, you ARE going to need a decent CRO.
Working with op-amps without a CRO is just plain frustrating, especially if you are using a single rail supply for op-amps like the TL081.
Not only that but just "keying" your ultrasonic transmitter and watching the return echoes on the CRO will give you all kinds of ideas on how to process the data.
The amount of detail you can see on the CRO screen will amaze you.
Just get you Arduino to send regular pings and watch the returns.
Also don't overlook doing stuff in analog with op-amps, THEN digitising the signals.
For ultrasonic receivers don't mess about with instrumentation amps like 741's, LM3900's and the like, you need to use a JFET op-amp that has a high input impedance and low noise.
I use TL081's or NE5534's, these are single amp/package devices.
The 2 and 4 amp versions, the TL082 and TL084 are ok, but you will get cross talk @40Khz.
That's why I said to use 2 stages of X10 gain, you get WAY less noise than a single stage of x100 gain.
I am scope impaired. I will probably take your instructions to a colleague who will build it and then tell me what to make it do.
I have a bunch of the GPS seeking stuff operational. One thing that helped me a lot was to download MS Visual Studio 2010 C++ Express Edition. It's free and almost entirely compatible with Arduino syntax. I copied and pasted my functions for computing bearings, distance and points into a VC++ project, entered some very simple unit tests using values I knew were good from other pages and stepped through the code in the debugger. Most of the mistakes I had were conversions (degrees<->radians, feet<->nm<->meters, etc) either missing or begin done twice or done when not needed or whatever. The formulas are easy to find, but we humans can't agree on units to use. The bats would have a much easier time with it. Anyway, once it worked, i just copied and pasted back into the Arduino IDE and life was good until I started worrying about somebody parking a freighter in my way...
I bought a Micromega uM-FPU-V3, not only does it handle NMEA sentance parsing, but the Micromega site has a whole bunch of application notes about stuff like bearing and distance between 2 waypoints.
The chip was cheap and it's really fun to play with, not only that but there is a whole uM-FPU library for the Arduino.
You should grab one from Sparkfun or where ever and have a play with it.
Wouldn't anything in the water be partially submerged? Doesn't everything at sea have a draft? I'd go the sonar route, but instead of doing it like a DDG and looking down for subs, look out and up at the horizon, set your angle to how far away you want to recognize objects.
As for the SAR comment... if they didn't have an EPIRB on them putting out a SAR or CSAR freq and nobody saw them go in the water, then nobody would ever even know they were in the water, let alone go looking for them.
I am not sure how much "solid water" is between two floating objects that have little draft due to the waves. I thought about sonar just below the surface but I don't know what it returns when you are pointing it through a wave.
How far in the water does your boat sit?
Only a keel will be more than a few inches and we are still trying things (like self righting) that may make that minimal also.
Originally I was using my SYM-1 (that's a 6502 single board computer with 32K of RAM, running @ 1Mhz) to process the data, using 3 ADC0804's.
SYM-1 6502. You've got the upgraded version.. I think the model I used was 4k, the interface a hex keypad and the display (if I remember) six 8-segement LED's. Some of the first programming I ever did was on one, in assembler, circa 1980. We talking about the same monster, screw mounted on a sheet of laminate plywood (with too rough edges?)
Well, if you get desperate you could use a towed array, that would get deep enough.
I seem to remember reading somewhere that capacitance could be used to detect nearby bodies in water... Somewhat similar to a the way a theremin works.
6502 - BTDT, but I had a "deluxe" model in the early 80s. I had an Atari 400, which was the same as the 800 with a few less bells and whistles, including the beer proof template keyboard. I programmed it in assembly also. I still remember that page 0 indirect addressing scheme; that was pretty slick for the era. I also had a Franklin at one point.
The 6502 was the first REAL RISC!
Only 157 instructions!
Z80 twits used to brag about how many registers they had, oh, and that damn block copy!
6502 had so many different ways to do indirect and indexed addressing, it made it hard to port code to anything other than 6809 or 68000!
What's this programming in assembler?! I used to hand assemble!
Still do! (I like to suffer)
My first contact with the Atmel processors was hand assembled code on the AT90S8535.
"I remember working with nothing but ones and zeros; we couldn't even afford ones for the early stuff. Had to do it with nothing but zeroes..."
OK, you win. :D I did do defines when I would use an oddball instruction or two, like SIM and RIM to set/read the interrupt mask on the 8085 (8080 did not have those instructions and I was using an 8080 assembler) and I have punched in boot sequences from a cheat sheet by jand. But hand assembling more than a few instructions? No...
Ouch - another very old synapses just fired...
I did not do defines, I did equates as in:
SIM EQU 0x20
RIM EQU 0x30
Wow - that hurt... ;D ;D ;D