detecting obstructions on the sea

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. and the related (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:

And we're not talking here about submerged items (like lost containers, floating fishing-nets, whales and uprooted buoys.

Good luck.


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.