Acoustic Location System


#1

This discussion is about developing an acoustic based location system for small ROVs.

Much of the early work that we have been doing is in the blog: http://community.openrov.com/profiles/blogs/acoustic-modems-location-and-pingers

That blog covers broader topics, so I wanted to start this discussion specifically for developing the acoustic location system.

Knowing where you are when exploring and gathering images and data is clearly a vital piece of information. GPS systems provide this on land. Underwater, radio waves that GPS depends on to function are absorbed by water. Acoustic signals are one of the best alternatives to transmit information for location and other data communication. Commercial underwater modem systems exist today and are widely used in exploration, but suitable systems for low-cost small size platforms like OpenROV are not available. This project plans to deliver such a system and is in-part inspired by university research in this area – Bridget Benson’s UCSD PhD Thesis http://kastner.ucsd.edu/wp-content/uploads/2013/08/admin/phd-thesis-benson.pdf is one example.

Information about 3D location in real-time is a key enabler for many scientific and exploratory needs. The technology to do this is known, but has not been scaled down for systems of this size. With location information, one could map any discoveries (sunken ships, archeological sites, and coral reefs are some examples). Maps of the ocean/lake/cave can be made with location and sensor information together. Virtual Reality and 3D gaming technology could be used to represent information about an exploration either in real-time (shared over the internet) or archived for many to explore on-line as they study results of explorations.

The technical approach is to use acoustic transmissions (ultrasonic sonar) from known locations on the surface (GPS would be used to maintain location of the sender). The ROV would have a receiver unit on board and can determine the time for the signal to arrive. That information along with depth, temperature and the on-board IMU (gyro, compass, accelerometers) would be used to determine/compute location. Location information would be available to the operator of the ROV and a graphical display could be developed (possibly in conjunction with maps of the bottom if available) to help with navigation.

Current status and near term work items:

Working designs for ultrasonic Power AMP and receiver exist and initial testing with 40KHz piezoelectric transducers has begun. A micro-controller or processor can be used to generate a 40KHz square wave pulse which is shaped and amplified into a sine wave to drive the transducer. Currently the amplifier produces a 27Vp-p signal. If testing shows that this is not enough to generate a powerful enough ultrasonic pulse, a step-up transformer may be required.

The high gain (> 100), high input impedance (FET front end) receiver amplifier design includes a narrow band pass filter to allow only frequencies in the desired range to be amplified. This receiver needs to be packaged and integrated with the ROV electronics along with a micro-controller to process the waveform (>100 samples/sec and real-time FFT processing required).

System level: Some how the timing for the start of the pulse from each transmitter (correlated with GPS location at time of transmission) must be matched against the time the first pulse is received (any delayed echoes would be rejected). The time of travel for the pulse would be used to calculate the distance from the transmitter (with know location) and along with depth information, water temperature, salinity (salt or fresh) and IMU data (plus and location history - dead reckoning, etc.) location would be determined. Data from a second transmitter some distance from the first would greatly help the calculation (see Virtual Long Baseline VLBL Navigation). The transmissions and calculations should be able to be done every tenth of a second to provide timely location.

I will establish a location on GitHub for this project and start to organize existing material there. for now, take a look at the blog http://community.openrov.com/profiles/blogs/acoustic-modems-location-and-pingers.

It would speed things up if I got some help with the micro-controller software while I continue with the electronics and in the water testing. To do: sample the signal and determine when a 40KHz pulse arrives. FFT analysis would be the likely approach. Also will need to determine which micro-controller is adequate to handle this processing load. I can probably collect some raw data samples using my NI VirtualBench if someone just wants to work on the FFT part.

There are a few folks already interested, and some possibility of collaboration is there.

If you are interested in getting involved, please let me know and what area(s) you think you can hep with.

Regards,

Jim Trezzo

jim@openrov.com

or jtrezzo@trezco.com


Side scan sonar
Acoustic Positioning Overview: SBL, LBL, etc
GPS for ROV Surface Navigation
Underwater metal detector
Work Class OpenROV
Acoustic Modems, Location, and Pingers
GPS for ROV Surface Navigation
Close loop control of motors
GPS for ROV Surface Navigation
Ability to fly grid pattern
Underwater positioning GPS by triangulation?
#2

First off, I have to thank Jim and Bob getting this sub project/payload kicked off and started and for the work they have collectively done to date. This is still just at the start but this piece of electronics has potential as the basis of several highly useful payloads and has great potential for large enhancements to the OpenROV as it is the basis of a whole heap of potential uses including

  • Simplistic Locator / recovery Pinger (just the transmit side of the circuitry at maybe 25kHz)
  • A simple open source Depth Sounder (the transmit and receive of a single "side of the acoustic modem maybe 200 - 455 kHz)
  • Potential to modify the sounder element into a Doppler Velocity Log
  • The ability to provide the ROV with a 3D relative location in real-time from single surface and bottom unit via single unit Ultra-short baseline or with multiple units via long baseline acoustic positioning when the surface units are connected to a GPS
  • A full underwater data Modem (maybe not video at this stage but useful in the potential for making units autonomous

As with any open source project it's outcomes will only be as good as what people put into it and the knowledge of the crowd can both can enhance the work as well as lightening the load and in the end benefit as all. Jim's and easy guy to talk to if you have skill that may be useful I'm sure he would love to hear from you and I would strongly urge people to have a look at the Blog entries

Scott


#3

I’ve been hoping for an open source DVL for awhile now. This would give us the ability to track true motion over ground and can be used as an altimeter. If we were able to have bottom lock on the DVL and GPS the navigation uncertainty could be kept to a minimum.


#4

Sorry commenting from my phone my idea is to start on the surface get a GPS fix and DVL bottom lock then submerge and use the DVL to keep position uncertainty to a minimum.


#5

It is great to have this set up as a forum and also get a code repository started. I don’t know if there is a way to do it, but feel free to move any of my previously posted materials that apply here. I’ll try and clean up the GPS gated timing work and post it to the forum also. Getting a GPS disciplined Stratum-1 NTP server working to see how accurately one can sync the Beaglebone clock over the 2 wire Ethernet is planned, but that may be a bit later. I haven’t worked out the math, but if you are using two surface pingers with known transmission times and locations and have a synced clock on the ROV and depth, I think you have the information(along with the things Jim mentioned) required to calculate location. First cut would probably be to just fix the distance between the transmitters.

Bob


#6

I have done work on LBL acoustic nav systems including SHARPS for WHOI and SNAP for Imetrix, including transmitter, receiver, and timing box design.

There is no need to shape the transmit pulse into a sine wave, the Q of a piezoelectric ducer will do that for you. The SNAP system puts a 24V 4 cycle 300kHz square wave into a 4:100 turn transformer to get 600V (about 1kW) at the 1/4" piezo hemisphere. We get about 150m range in seawater with 5mm resolution fairly easily.

SherpaDoug

sherpadoug@ieee.org


#7

Here is the information on the GPS gated timing board I have been playing with. It can be used to calibrate clocks and the clock then gated to measure the transit time of pulses. I had originally thought about building a hardware rectifier and comparator to process the acoustic signals from the receiver, but I think the threshold detection can probably be done within the Arduino ADC registers themselves. I am using a Garmin GPS 18x-5Hz GPS unit, which may not be the best choice, since it generates 5 Hz updates and PPS signal and requires some coding to get a 1 Hz gate for counting purposes. There are more expensive GPS's designed for timing purposes which provide a 10 Mhz clock phase and frequency locked to the Satellite's atomic clock and 30nS timing accuracy. The Garmin unit's PPS is rated to be within 1uS. I have tried several different nominally 1 MHz sources and none are exactly 1 MHz on the GPS gated counter, but the frequencies agree with my frequency counter. The Arduino Micro has the ability to communicate with the computer via USB so one can dedicate the hardware Serial I/O to the GPS. This seemed to work a lot better than Arduino UNO software serial port, particularly at 38,400 baud. Hopefully the code will post without deletions, but if not maybe Jim can post it to the repository he is setting up. This is all very much a work in progress but hopefully may be of some use to others. Bob

128-IMG_0211.JPG (1.56 MB) 129-MicroPinOut.JPG (185 KB) 130-LCDCounterText.txt (7.52 KB)

#8

Some updates: I am targeting a modular set of electronics and software that will allow us to tackle many different solutions with different approaches that best match various missions or situations. The tethered world is quite different from the AUV space that many are also interested in.

I have been pursuing a bottom up strategy with complete system solutions in mind. I want to gather more signal data at greater distances/depths to help guide required signal strength for transmitting and signal recovery in the presence of noise and multi-path. I can't go much beyond 4 Meters (limited by length of probe cables and transducer cable). Also based on tests in Foster City , CA lagoon (attached results - salt water at 68F/20C) you can see that at 4 Meters the SNR is getting marginal. I will try to add a step-up transformer soon and get more results. To measure at a greater depth, I will try to use on-board data-acquisition (try BBB) to capture signal data. This won't be how a deployed solution will work (likely will use a dedicated micro-controller so not to impact the capability of the existing ROV sw), but a convenient next step to gather useful empirical data.
Signaling - for now a short pulse at a know frequency from a know location at a known time. We could have one or more additional transmitters at different frequencies or times and should be able to discriminate. I think a software based DSP approach will be the most economic and flexible approach to recover the pulse timing. Frikk Solberg (a Norwegian University of Science and Technology(NTNU) grad student with DSP background) is looking into this - others are welcome to try. It will also give us a stronger technology to filter out noise and multi-path. I am generating the pulse from a TTL square wave using an Arduino sketch. Since this is SW driven, we can easily experiment with multiple approaches (vary pulse width/# of cycles, how often sent, frequency of pulse, etc.). The transmit and receive electronics are stable and can be packaged up onto a small circuit board.
Time synchronization - Either synchronized clocks between the transmitter and receiver (kept up with NTP and GPS time info as Bob has suggested) or possibly sending a start of transmission clock over the tether (make sure not to interfere with the system reset pulse that Walt has put in place) would be workable approaches.
More sophisticated encoding schemes - lots of ideas around phase shift and spread spectrum have been developed and folks would like to try this out. Since the components are modular, these advanced ideas can be tried independently - in parallel with a more basic approach. Some folks are interested in data communication, and as we have seen with our FSK experiments, this will work. Again there are more advanced encodings with higher performance that can be done.
Transducers - Lots of experimentation and choice for different missions is possible. In order to to make progress on the rest of the system, I am happy to stay with the 40KHz potted rings we are using. The UCSD folks have transducers that were built for the modem project. So for now they can make progress and we will be using the same transducers and circuits. It may be better to have a piezo disc from the surface to focus the beam - we will see. We can do these experiments later. Also to do depth soundings from the ROV, a piezo disc possibly at a higher frequency (say 70 or 200KHz) might be the choice. I think my Raymarine depth sounder on my sailboat is 200KHz - will check. It would be good to not interfere with the location pinging at 40KHz.
Jim
125-4Meter_20141106_150228.png (64.2 KB) 126-OutputFromTTL_20141104_130628.png (69 KB) 127-0.5Meter_20141104_172214.png (66.1 KB)

#9

Thanks for the info Doug,

If the circuitry is open-source, can you share the design? Do you have a pointer to the supplier of the transformer? Hopefully a small inexpensive, easy to get item.

Thanks,

Jim


#10

I am currently working on a simple sonar doing echo detection with DSP on an ARM micro. I'm more of a software than a hardware guy, and am having trouble finding information on how to couple the transducer to the water. Can anyone point me to how this is done? I would be interested in helping with this project.

My sonar works fine in air, so I know the algorithms are ok. I just need to figure out how to get the pulse into the water.

Thanks!

Jason


#11

Jason

Jim and Bobs (and others) circuit is essentially an underwater sonar echo detection system with the circuits posted here. Basically (sorry if any of this is telling you how to suck eggs) although their unit has split into the transmit and receive (so that it can act as a modem and transfer data) it is essentially transmitting a pulse into the water, waiting and then listening for (or timing to give range) the return. With very little modification these 2 half’s can be consolidated and one pizeo transducer used to give a sonar echo detection system /depth sounder/range finder (and then a number of other uses eg DVL, SSS MB) .

I assume with your work you are already using transducers designed to transmit sound into water rather than transducers designed to transmit sound into air. If looking to use your system on a ROV I would recommend upping the frequency to at least 200kHz (realistically 455 or 800kHz would be better and the way to go and should give ample range on a ROV) to get better resolution from the unit (in water you get better resolution in higher frequencies but less travel through the water column). There are just a couple of hardware tweaks in Jim and Bobs circuit to change the frequency to do this and then some modification to the code

Wishing you luck with the project and would love to hear how you go

Scott


#12

Would this feature enable the OpenROV to know how far off the bottom it is? This would be wonderful: I think it'd mean we could build a "hold depth at 1 foot above the bottom", something that'd be useful for exploring our local pond.


#13

For that all you need is a depth sounder. The usual term for this use on an ROV is "altimeter". Advanced ROVs can hover based on either altimeter or depth (pressure).


#14

Thank you, Scott. I got it working in air first with a mic and piezo transducer built for air, just to make sure the algorithm worked the way I expected. I'm now trying to figure out how the transducer should be done in water.

I have read that some systems used in ships actually project the sound straight through the hull, and others use transducers designed for immersion. It appears to me that you're using the latter approach - I will take a good look at your design.

It appears that leads are soldered to the cylindrical transducer and then you encase it in rubber - is that pretty much what you've been doing? I'm thinking something like that Plasti-Dip tool coating.

I appreciate your time - it would be nice to have a low cost altimeter/obstacle avoidance system option for hobbyist underwater robotics.


#15

Soldering to the ceramic can be tricky. This link has some pointers http://www.noliac.com/Soldering_procedure-134.aspx

Important points:

Be quick - the heat of soldering with deactivate (depolarize) the ceramic at the spot where the work is done. Make that spot small by working fast.

Use solder with some silver in it, generally 2%.

When the piezo is heated it will generate voltage. Short the piezo with a bent paperclip while you are working on it. Otherwise it may startle you and ruin your solder job.

Keep the coating thin. Most such coatings absorb some of the acoustic energy. Ideally you have a low loss coating half a wavelength thick and use it to match acoustic impedance to the water, but that is a science in itself.

If your solder joint is not real good, consider a mechanical bond for the wire like a gob of epoxy which is separate from the electrical solder joint.


#16

We are all quite interested in an altimeter solution for OpenROV.

I think we now have transmitter and receiver electronics designs that are small enough for the ROV. Work has begun on the DSP and data acquisition software ( I put some links in the blog post on examples ). I am using the 40KHz piezoelectric potted rings that were made for the acoustic modem project (see Bridget Benson's thesis for details) for our current development work. For the altimeter we may want a different frequency and shape (send/receive a downward pulse) a relatively short distance to sound the bottom. Maybe a flat disc would be best. If someone wants to research this topic and fabricate inexpensive solutions, that would be appreciated. It may be a while before I have time to look into this.

I can try out any transducers solutions with the electronics and software that has already been developed in one of our OpenROVs and share the results.

Thanks Doug for your suggestions.

Jim


#17

I did find this 40KHz ready to go transducer - waterproof and with wires. It might be good as is for the surface transmitter, but may need additional potting for depth. Murata MA40MF14-0B. $13.20 unit cost. This distributor will ship from Japan (may be other sources):

http://www.chip1stop.com/web/USA/en/dispDetail.do?partId=MURA-0128411&utm_medium=cpc&utm_campaign=aggregator&utm_source=octopart&utm_term=MURA-0128411&cid=octopart_MURA-0128411


#18

Thank you all for the information. I'll keep you posted on any progress that I make - I'll be focusing on a disc transducer for a downward pulse.

- Jason


#19

Hi Jason

In concept the stuff your doing in air (with a piezo and mic) should carry over into the water (with some modifications for the different speeds of sound etc). You can have transducers potted inside ship hull etc if there are no air gaps and a liquid fill around the transducer but they do suffer a bit from performance (eg anything in front of the transducer can absorb energy os less discrimination and power) If I was you I would be looking at the concept of a transducer mounted in the water. Also just plastic dipping a air transducer won't be as effective as a transducer designed for water use (remember water is 800 times denser than air and sound is the movement of those molecules so a unit designed to push something that much lighter doesn't do well with the water)

For a 200kHz unit you could consider the transducer from this as a somewhat cheap hack (I haven't searched around for where they got their sensor from)

Jim 40 kHz is great for the modem where you need the lowest frequency you can get for range but for a ROV sounder/collision protection maybe where 20m range is all that is needed at a max so higher (eg 800kHz) and with then the better associated resolution would be where I would be looking (again if you need a hand with anything let me know)

I would consider less the shape of the transducer but more the angle of the beam produced - narrow and tighter would be my choice for a sounder if need be in the future we can swing the transducer to provide scanning function for collision protection

Jason reading between the lines are you looking at a chirp style transmission or just a simple ping? (keep in the back of your mind the strength of the return can also provide information on bottom/object composition)

Scott

Douglas thanks for your real world knowledge I'm sure Jim and Bob and others would appreciate your wisdom and thoughts on the design to date


#20

Hi Scott:

I'm doing chirp detection. I first implemented it in Python using a PC sound card (writeup here http://shortcircuitsandinfiniteloops.blogspot.com/2013/12/new-project-sonar-experiments.html) and then on a Stellaris Launchpad. I've got it outputting to a simpe GUI fishfinder-like screen that shows a grayscale representation of each echo.

I'm happy with how it's coming along. Right now the Launchpad is using a simple transistor driven piezo element at 27 volts driven by a square wave, and an amplified mic into the ADC.

From what you guys have told me, I am going to experiment with potting a piezo transducer and see if I can get them working in water. I appreciate any feedback or advice.

Thanks,

Jason