New micro-controller selected that is better fit for UW Data Acquisition: While the Spark Core has been great and the new Photon (see https://www.spark.io/) has great specs and price, it is not available until March 2015. I looked around a bit and found that the new Teensy 3.1 fits the bill quite well: http://www.pjrc.com/teensy/teensy31.html - sells for just under $20
I will post more on this, but I wanted to share some of the first exciting results. With the additional RAM I can now sample as follows - 30,000 ADC samples in 143.00 ms = 209,790 samples/sec (16 bits 0-65535 0-3.3V) using: analogReadResolution(16); and analogReadAveraging(1);
This means that I can hold points data for 211 meters time of flight based on this sample rate.
Some Teensy 3.1 specs that are of interest to this project:
32 bit ARM Cortex-M4 72 MHz CPU (M4 has DSP extensions)
256K Flash Memory, 64K RAM, 2K EEPROM
21 High Resolution Analog Inputs (16 bit hardware)
3 UARTs (serial ports)
SPI, I2C, I2S,CAN Bus, IR modulator
Real Time Clock (with user-added 32.768 crystal and battery)
Thanks for the offer of help. It is much better to work with others on this type of project (many different skills are needed). I have just posted on github (https://github.com/jtrezzo/acoustic-location-system) some software that I am using to get started. There is much work to evolve this and we can discuss what work needs to be done - lots of room for improvement. Since you have a BBB and a Teensy 3.1, you can start working with this software even without the electronics (transmitter, receiver and transducers). If/when you are interested in building the electronics so you can do testing in water, take a look at what is already posted to see the designs. I am going to do some modifications as I analyze the results from this next phase of testing, so let's coordinate before you build.
here is a summary of what I have posted:
TonePulse - simple program to generate pulse of square waves at 40KHz and send digital trigger to data acquisition program (start collecting points). The trigger will be sent down the tether to the micro controller on the ROV. The square wave will be input to the ultrasonic transmitter that drives the transducer. This software will be modified to read the GPS data from a USB GPS device and record time and location when pulse is sent.
adcspeedtest (3.1 and 3.2) - using Teensy 3.1 micro controller, can sample signal at > 250K samples per second. adcspeedtest3.1 uses ADC library (ADC-master) from the Teensy website and collects as many points as can fit into memory. adcspeedtest3.2 uses built in library for Teensy. It only stores 500 points (can be modified to many more) and is triggered by a digital I/O. Both programs are test software for collecting signal data remotely using a micro controller. The plan is to put the analog receiver and Teensy 3.1 into the e-chassis on the ROV and interface with the BBB using the serial port. The transducer will be attached to the ROV and connected to a pair of wires that go into the e-chassis. The analog ultrasonic amplifier will be connected to the ADC on the Teensy. I need to modify the circuit to provide a DC bias and over-voltage protection (ADC only goes from 0-3.3V, the signal is 40KHz AC)
After each cycle of points collection the adcspeedtest program outputs the results as CSV data to the serial port. I then cut and past the results into a text file for processing.
PythonProgram - First cut (done by a friend - thanks Ali) at reading results from points collection into a graph. This software can evolve to do some DSP analysis. Once the algorithms are figured out (to measure the time for the acoustic pulse to arrive) this can be implemented on the micro controller and time-stamped results can be sent to the BBB (as a JSON string). The OpenROV Node.js software (via a plugin) can send the results as part of the socket.io data stream to software on the surface which can do the calculation for location (surface transmitter has GPS location and time pulse was sent).
First phase of this experiment is to acquire points data from on-board the ROV and modify electronics and software based on observations.
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. Bob
Updated receiver circuit with DC bias to work with analog in of micro-controller
I have attached the receiver circuit I am using (sorry for the hand drawn diagram). It uses a dual low-noise JFET opamp (TL072CP) that is widely available. I put a zener in front of the input to the first stage since banging a piezo element can generate a high voltage spike and damage the op-amp. The second stage is an active narrow band pass filter which can provide additional gain. I also use it to add in a DC bias (see R4) since the ADC from the micro-controller has a range of 0-3.3V and can't deal with an AC signal directly. I also have a 20K trim pot and another 5.6V zener in front of the analog input of the Teensy 3.1 micro-controller to protect it and allow me to adjust the input voltage.
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.
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.
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 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.
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.
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.