I have been doing a bit more work on my GPS timing board and have gotten the input capture routine to work, and have shown it can measure the 5 Hz PPS input period to the accuracy of the original PPS signal (<1us ). I am going to test its ability to measure ultrasonic signals in air since the distances are less and I can simulate a depth of 150 feet in water with 36 feet in air in my condo (31.25 mS transit time). The timing board now generates a GPS gated 40 kHz pulse of 1 millisecond duration 5 times per second. I have been trying to see if an old ultrasonic receiver I had in the junk box could detect the pulses, which it does, but I'm not sure it will produce a useful signal to use for timing purposes yet. I will also try the ultrasonic receiver I have from the old modem and the active rectifier from Garcia's thesis I have mentioned in other posts. Jim's work on software signal processing should give a better solution, but a simple hardware amplifier, filter, rectifier, and comparator might be helpful also. I'm thinking about using a second Arduino to simulate the return echos and possibly two different locations to work on the triangulation code. I'm impressed how stable the oscillators are on the Arduinos, so I think if clocks can be synchronized on the surface or with NTP over the tether timing issues may not be that much of a problem. Attached are some pictures and the code. Bob138-Picture65a.jpg (96.2 KB) 139-GPS_InputCapture_INT0.txt (9.45 KB) 140-Picture73.jpg (117 KB)
Updated receiver circuit with DC bias to work with analog in of micro-controller
I went with a nice small 1W 5V to +_15V DC-DC converter to power things (Murata MEJ1D0515SC available from Mouser for $8.46). We have regulated 5V available in the ROV in several places. Since the current is low, I can power this from the BBB 5V vout pin.
I will be making a hand soldered version of the receiver, that along with the Teensy 3.1 board will fit into the OpenROV main tube and connect to the transducer which is wired thru the end-cap. The Teensy 3.1 will connect to the BBB serial port and send the data points.
I have a points collection program that runs on the micro-controller using it's ADC. I have attached a points file and graph (Python program) of the output. I am working with Brian to integrate this software as a plug-in to the OpenROV software and will keep folks posted on the results.
I am also building a small batch of transducers (the piezo ring 40KHz potted ones) for the next set of experimenters. If anyone is interested in these experimental ones (will be built as was done in Bridget Benson’s UCSD PhD Thesis http://haduken.ucsd.edu/papers/phd-thesis-benson.pdf) please let me know and I will try to increase the number I am planning on. I don't know the final cost as yet, but can work with anyone that is interested.
Jim135-ReceiverCircuit.JPG (1.27 MB) 136-2MeterTest12015full.png (73 KB) 137-2MeterTest12015.txt (3.1 KB)
An update on the transducers
I am building a new set of transducers now that there are a few more experimenters who want to work with this technology. To that end, I have almost completed a potting rack which holds 10 molds. I am building two of them since the urethane needs to be used once the containers are opened and the two parts mixed. In theory you can extend the life of the unmixed liquids by filling the can with an inert gas like nitrogen to prevent moist air from affecting the chemicals, but it is easier to build transducers in batches that match the volume that the urethane mixes out to. I estimate I will use less than 2 ounces for each transducer and the two racks together hold a total of 20 transducers at a time. The piezo rings will hang upside down by the cable which is soldered on the the piezo material (need to use solder with some silver in it). Curing time is in the order of 16 hours.
Acoustic Modems, Location, and Pingers
Great news that you are doing a “small production run” to get some of these units “out there” to allow for further development of your “multi-purpose” acoustic system
I hope this gives it a push along and helps in it’s development
All the best
Now that we are getting closer to testing various systems based on the acoustic technology we are developing, I wanted to post a cross link to an earlier forum posting by Scott on the various approaches in use for acoustic positioning:
The initial approach I will try is the simplest: several GPS located transmitters synchronized via wi-fi sending pings to a receiver on the ROV. Location will be based on signal processing of the pulse. The tracked position is calculated in real-time at the surface from the Time-Of-Arrival (TOAs) of the acoustic signals at the ROV. Since we are tethered a micro-controller on the ROV can calculate the TOA and send that to the surface via our plug-in architecture and JSON socket-io messages.
There are lots of variations that will be possible: Transmit from the ROV, use arrays of transducers and look at phase differences, etc. Also the Navigation sw that will be developed around the IMU (essentially dead-reckoning with periodic corrections from the ping based location data + depth info from the pressure sensor).
I encourage others to try more sophisticated approaches along with me and share the results.
Big thanks to Jim for pushing this forward and hopefully he can gain some assistance from a fair few people from the OpenROV community to give him a hand so that we can all benefit from extension to the ROV
As a bit of background and just trying to expand upon your post I thought I would give some of the uses of the technology he is developing the possible uses and / or road map of the devise and its derivatives as well as bring together a few disparate threads to in part see if it can be seen in a bigger picture
Currently Jim and Co have developed a system that can both generate and listen to acoustic pings and as such (dependent upon its final configuration), the unit should be capable for being used as
For this the simplistic development the unit would be transmitting a ping and listening for a return and calculating the depth to the bottom using the (somewhat) consistent speed of sound through the water
This is advantageous as you would know you are nearing the bottom rather than hitting it with a cloud of slit or alternatively rather ran run a constant depth you could run a constant height above the bottom
Further developments could be an auto range with a scrolling display the ability to upgrade the ping generation to a chirp style wave form for greater bottom discrimination measure the return strength for bottom sediment/hardness studies also in the future the ability to upgrade hardware to allow the transducer to be scanning style radar / Side imaging / Doppler velocity log
As Jim articulates this is an add on to any Dead Reckoning (still to be implemented) that may be developed have a look at
With also the need to solve the issues with
The most simplistic acoustic navigation that can be achieved with Jim and Co’s electronics would be
For this development, a minimum configuration would be a transmitter and a separate receiver. The receiver can have its transducers element shielded to provide a directionality.
This could be utilised so as to drop and acoustic bomb on any target or area of interest (with a surface buoy) and use the ROV through nodding from side to side can focus in on the direction of source with the greatest signal
Further developments could be sync the transmitter and receiver to a time source and the transmitter transmitters the time and hence time of flight can be determined and distance to the target determined
The simplest form of this to implement is somewhat similar to the U/W Locator Beacon where the surface mounted receiver can have its transducers element shielded to provide directionality but mounted with a rotating encoder and /or compass. As the unit rotates and sweeps the maximum reply’s direction can be detected and given the bearing, the distance and depth of the ROV and the GPS location of the “fixed” surface receiver the ROV absolute location can be determined
Further developments would be rotating surface mounted receiver with compass and GPS
Less complex base units but more acoustic units required typically 3 receiver and one transmitter
Ideal for survey work but again more acoustic units required and greater complexity
I think it’s easy to say Jim ideal goal
Acoustic Transducer Mounted on OpenROV
I have just finished mounting and connecting the wires of my potted transducer into an OpenROV unit. I hope to have the electronics and software integrated before the May 9th Tahoe trip so I can do some testing at depth.
Wow Jim, this is looking great, I had no idea you had gotten as far as mounting it on on OpenROV! I can’t wait to see more of it.
Thanks - I think it looks cool, like an underwater police cruiser. May need to add red flashing lights.
I’m looking forward to hearing how this went.
Looks great Jim
What are you hoping to do just distance from ROV to a surface receiver or are you looking for some directionality as well?
Either way hope you get some great results
Should be able to set up a SBL type system using several (min 3) surface transmitters from known locations (GPS based or from dock positions). With the depth info from the on-board pressure sensor and time of flight info, will be able to do location calculation - maybe 10 times per second. Next step is to get the receiver working from on-board the ROV and capture points synched with transmitter pulse. Will try sending a signal via the tether to trigger the start of the points ADC capture. We have some software partially written to transfer the points data to the BBB and into the events data stream where I can view it on the surface.
I hope to at least have the data acquisition parts working in time for the May 9th Tahoe trip.
Thanks for the reply Jim
Straight into short baseline (SBL) acoustic positioning ------ nice
What you and @Jim_N are doing can really substantially add to the OpenROV system wishing you both all the best
Receiver Circuit Board Layout
I was able to hand solder the receiver circuit onto a 1 7/8" x 1 7/8" prototype board which should fit behind the HD webcam in the electronics chassis. I will connect the transducer to pins 20 and 21 of the DB25 connecter and can pick up 5V to power things from J4 header of the controller board. Once that is done, the output signal will go to the ADC on the Teensy 3.1 board which should also fit behind the webcam. The teensy will need 5V and a serial connection to the BBB.
More to come.
Transducer mounting looks great I’ll look forward to the results of the Tahoe tests. In the meantime I have been playing around with NTP and PTP to see if I can get clocks to synchronize across a network. I purchased a GPSDO from China that has both PPS 3.3 V square wave and 10 MHz sine wave outputs and interfaced it to an Arduino Micro and two Raspberry Pis. The 10 MHz output is divided by 2 in a D flip flop to have a 5 MHz clock for timing purposes and fed into pin 12 of the Arduino. Maximum external clock for the Arduino is 6.4 MHz (16/2.5 MHz) and the PPS signal is fed into Pin 4 (ICP input). The 10 MHz output is spot on at 5,000,000 counts/sec and varies by at most +/-1 count when the GPS is locked and TXCO is at temperature. That should work out to 5,000,000 x 100 /1500 = 333,333 counts for the 67 mS needed for sound to travel 100 meters. For NTP/PTP tests the GPS can be interfaced to the Raspberry Pis several different ways, either directly using the NMEA driver, or via the GPSD, which in turn passes the data to NTP using a SHM driver. In addition a separate driver is used for the PPS signal. On the master clock side I am running NMEA driver attached via USB to the Arduino so I only send the RMC sentence with the PPS driver and the PPS attached to a GPIO pin. The master runs NTPD and PTPD but the system clock is set by NTP (-t option on PTPD). On the client side the other system has NTP disabled and only PTPD is running and logs the difference between the master and slave clocks. Attached is a picture of the setup and the histogram of the differences between the clocks after running PTPD for about 6 hours. The attached results were a little disappointing, but I haven’t been about to see how much of the variance is due to the master clock drift. With expensive hardware clocks it is possible to get sub-micro second agreement, so more tweaking is definitely needed. These are just first look results but agreement to less than two microseconds on average isn’t bad (median -0.536) however the standard deviation of +/- 88 uS is probably too high so more work is needed. I assume it will be pretty easy to set up PTPD on the beagle bone if this approach is useful.
I’ll also try and develop a simple front end for the timing board and see if I can measure some acoustic pulse durations with the Arduino using the new transducers you made, and do a follow up post with how to set up the Pis and the Arduino code.
First off congratulations on your progress it’s great to see what you and @Jim_Trezzo are doing
Just reading between the lines of your post and dumbing it down to what I can understand
So in “theory” this would represent 1 count per 0.3 mm so depending upon how “clean” you pick up the flip flop interface (my guess the main issues will be in the acoustics for how clean this is) this would give (round figures) at even ± 100 counts a ± inch accuracy in this part of the system
You also mention
So after 6 hours of operation the “drift” between the 2 systems was “less than two microseconds” thus for the 100m range 2/67 mS or over the 6 hours the drift was equivalent to about 3 meters
Mate if you can do anywhere near this I would be more than happy
Again thanks for the work you and Jim are doing (I just wish I had the skill to give you both a hand)
Hi Scott: I agree detecting the time the pulse is received and avoiding false triggering are likely to be issues but I like how Jim is approaching that problem. Also, if we can send a back channel electrical pulse down the tether when the acoustic pulse is generated at the surface, something sufficient to detect but not shut the ROV off and on, then the need for having the clocks synced would be less critical. We might even consider sending a 1 PPS signal or 5 PPS signal, and initiating the surface acoustic pulses on the leading edge of these pulses. That would allow ongoing calibration of whatever device is measuring the time of flight of the pulses on the ROV. As you observed the computers we are using are more than capable of counting to far greater resolution than is needed if we can provide a clean gating signal and have a known stable frequency to count. With 0.3 mm resolution a SBL system on the ROV might even be possible.
Let me do a bit more work with NTP and PTP before determining whether this system is a viable alternative. What I think the data is telling me is I know the offset of the clocks with a somewhat wider range, maybe 0.3 - 0.4 mS with an acoustic signal that is 67 mS or less. Given this is only one source of potential errors it would be nice to have greater confidence in the offset. There is suppose to be a way to log the timestamps of the PPS signal of the Master Clock in NTP, but I haven’t figured it out yet. I think that data might be revealing also. I’m still at the beginning of the learning curve on all this.
Here are some additional graphs of the PTP testing. I piped the ppstest output to a file which gave me timestamps of the PPS signal from the GPS attached to time server (master clock). I did a fresh build on the client side so it is the current Raspbian OS updated and upgraded with the ptpd that is available using sudo apt-get. The attached plots show the PPS signal gets timestamped within a few microseconds of the seconds boundary, with some upward bias for noisy stamps presumably when the OS is busy with other tasks and can’t service the interrupt. On the client side, ntp was stopped as soon as the system was booted up, and ptpd was started with a log file. The client start-up graph shows the time difference between the server and client rapidly goes to near 0 in under 5 minutes. I ran the system for a few days and plotted 32K sample points to examine for bias and variability. The server client differences are much more variable than the PPS signal on the server side. The impact this would have on using the clock’s time for measurement would depend, I would think, on filtering and statistical algorithms used within PTPD to set the clock which I haven’t gotten into yet. It looks like some time might be required to get the on board clock properly disciplined to the Server attached to the GPS.
Overall, given we can get to within a few microseconds or less if we have a PPS signal, my inclination would be to see if there is some easy way to send the 1 PPS signal down the tether without shutting off the ROV or messing up the two-wire Ethernet, and recovering it in the vehicle. By initiating acoustic pulses from the surface at known offsets from the PPS signal, the time of flight could accurately determined against an on-board oscillator (like the processor clock), and that in turn is calibrated to the PPS signal as often as necessary given to quality of that oscillator.
If that is not possible, then more work on PTP or using an onboard processor with an Ethernet chip that does hardware time stamps might be worth testing out.