Sonar Tracking SP2011

Progress Report, February 11, 2011.

• I am currently working on determining the feasibility of this project. To do this, I have done the following:
  • Determine the maximum velocity of the mobile platforms.
    • I found the maximum forward radial velocity was 7 rad/s. The max backwards radial velocity was 8 rad/s.
    • This translates to a maximum forwards and backwards velocity of 0.35 m/s and 0.4 m/s respectively.
    • Image of .vi used to find radial velocity.
    • This result is lower than hoped. We were expecting a velocity of around 1.0 m/s.
  • Set-up of Ultrasonic Transmitter and Receiver
    • Setting up the transmitter and receiver proved harder than expected. With help from Ed Richter, I got a .vi working that could run both the transmitter and receiver on the same Elvis board. However, there was an issue of the signals being mixed somewhere between the board and the computer; even if I had the transmitter unplugged, the receiver would still show a strong peak at the frequency the transmitter was programmed to transmit (40khz). So, my temporary solution is to run the receiver and transmitter on different Elvis boards (each of which is connected to a different computer). This works, but is not the most practical solution, so work will have to be done in that regard.
  • Analyze the Fourier Transform
    • Analysis is being done with the following settings:
      • Fs of 250k, taking 250k samples over 1 second. Emitting a sine wave of frequency 40khz.
      • Default Amplitude of sine wave was set at 3. Found setting higher created a more notable peak. Max setting is 10.
    • Moving transmitter by hand comparable to that of a mobile platform creates a noticeable shift in the peak of the receiver's FFT graph. Not sure of said peak's consistency over repeated experiments.
  • Analysis of the Spectogram
    • This is my first time working with a spectogram (or hearing of a spectograph). While I am not entierly familiar with it yet, I have made some progress with it.
      • Initially, I had settings that created a notable band of frequency around 40hz.
      • I am currently using a Hanning filter. The filter's setting has a very big effect on the output of the spectogram, and will probably have to be experimented with to a fair extent later on.
      • Increasing the frequency bins leads to a higher frequency band on the output of the spectogram.
      • This behavior is not what I expect. Will ask Phani about it next week.
• End Progress Report

Progress Report, February 18, 2011.

• We figured out how to properly use the spectogram. Yay!
• I am now trying to find the sampling criteria we need to have in order to detect a change in the mobile platform's velocity.
• The sampling frequency, Fs, is 250,000hz. We also know the robot can move at a maximum of 0.4 m/s.
• To calculate this, I have combined several equations to come up with this:
  • N = Fs/[f0*(vr-vs)/(v+vs)] , where:
    • N: number of samples
    • Fs: sampling frequency
    • f0: input signal frequency
    • vr: velocity of receiver
    • vs: velocity of transmitter
    • v: velocity of ultrasonic wave in air
• Which for my purposes, would look like:
  • N = 250k/[40k*(vrobot/340)]=2125/vrobot
    • where vrobot is the minimum change in velocity measurable
  • So, assuming I want a resolution of 0.01m/s, I would need to sample for 0.85 seconds.
    • Window Length: 212,500 (wL)
    • Frequency Bins: 131,072 (wL/2, rounded up to next power of 2)
    • Time steps is variable. Preferably: (212,500/n)+1, where n is the number of time windows wanted.
• I tested to see how the receiver will deal with receiving both the original signal from the receiver and the reflected signal from the mobile platform. This was done by combining two sine waves.
  • I assumed the signal sent by the receiver would be at 40,000 hz with an amplitude of 10 (the previously measured max).
  • The first wave is at 40,000hz with an amplitude of (10/(1.05)), which assumes the receiver is 5cm away from the transmitter.
  • The second wave is at 40,035hz. This assumes a speed of around 0.3 m/s. The amplitude of the second wave is an approximation, based on the assumption that the amplitude of the wave decreases proportionally with distance. The calculations I ran assumed the mobile platform was 2 meters away from the receiver at t=0, and was moving away from it. So, the amplitude was: (10/(1+.05))
  • Image of output of spectogram. Ten windows were taken.
• I then decided to add noise to the signal coming back from the mobile platform.
  • This is the subVI I created to do this: http://i103.photobucket.com/albums/m154/Cegasaturn/untitled-2.jpg
    • The noise is a white noise in a Gaussian distribution, with an amplitude of 10-15% of the amplitude of the original returning sine wave.
  • This is an output of the main VI using the signal with noise: http://i103.photobucket.com/albums/m154/Cegasaturn/untitled-3.jpg
• So, today I learned this project is not only feasible, but should have pretty good results (assuming the implementation doesn't cause drastic changes in the calculations I have made so far). I would guess my next step is to get some real data and see what I can do with it.
• End Progress Report.

Progress Report, February 25, 2011.

• I believe I have just finished work on the simulation.
• The code can successfully detect peaks of a simulated signal to the level I wanted.
• Numbers used for experiment:
  • Fs=250k
  • Number of Samples: 42,500 (So, sampling time of 0.17 s)
  • Same signals used as previously.
  • Detected peaks were found at 40,000 Hz and 40,034.9 Hz. Actual signals were 40,000 Hz and 40,035 Hz.
• So, results are very promising. Am not sure whether next step is to work with real data, or start working on mobile platforms. I will discuss this with Phani and Ed, and move from there.

Progress Report, March 11

• So, initially Phani and I planned on implementing the current software set-up on the mobile platforms, and try and get it all working from there.
• Unfortunately, we couldn't find all the sensors, so we instead decided to see the potential of using cross-correlation to determing the distance of the mobile platform.
• I was unable to cross-correlate using the sine wave. I also tried a step input, with no success.
• New plan is to set up one "master .vi" that will handle all signal creation.
  • Inputs of said .vi will be:
    • dist
    • vel
    • f0
    • df (for chirp)
    • sampling data
    • sin/chirp
  • Outputs
    • transmitter->receiver, returned signal from mobile platform

Progress Report, March 20

• Notes while working on signal vi:
  • Added two additional inputs;
    • Distance from Transmitter to Receiver
    • Amplitude of Transmitted Signal
  • I realized my previous returned signal was done too simply. Will have to write new, more complicated signal to create accurate model.
  • To calculate initial delay from signal transmission to return:
    • d+v*t=340*t , where t is the time for the signal to go from transmitter to mobile platform
    • This number is doubled, then divided by the speed of sound and multiplied by the sampling frequency, and finally rounded down to the nearest integer. This will tell me how many zeros there will be before I start receiving actual data.
    • Note: v is defined such that movement away from receiver is positive v.
• Well, after working several hours, I got the Sine portion of the .vi functioning, though not correctly. I was trying to justify the doppler shift mathematically, but I failed. Will ask Phani tomorrow, hopefully.
• I feel this I am making this more complicated than it needs to be. I'm not sure this level of accuracy is needed in the model, but we'll see.

Progress Report, March 23

• So, I realized what I had done as of last report was incorrect. I have new formulas, which are:
  • Amp for tcurrent: 1/(1+2*abs(x0+v*tbounce))
  • Sine Signal for tcurrent: sin(2*pi*f0*tbounce)
  • Assuming that tbounce=(vsignal*tcurrent-x0)/(vsource+v)
  • where:
    • v: velocity of mobile platform
    • vsource: velocity of signal (in our case, 340 m/s)
    • x0: position of mobile platform at t=0
    • tbounce: time when signal bounces off of mobile platform
    • tcurrent: time when receiver gets signal bounced back from mobile platform
  • Note: Amp & Signal at tcurrent = 0 if: tcurrent < 2(x+v*t)/vsource
• I will implement this and see how it works.
• It works! I'll try and get the chirp working by the end of the week, too.

Progress Report Part 1, March 24

• Some notes:
  • Set Chirp so that if Chirp Duration is greater than the duration of sampling, to limit the chirp to the duration of sampling
• Should have everything working, Mathscript doesn't want to truncate the array I have (too large). So, we'll see what to do about it tomorrow.

Progress Report Part 2, March 24

• Got everything working. Determing velocity using chirp useless with current methods. Will have to discuss with Phani tomorrow.
• But, sine works very well. And the .vi is very slick. Hooray pictures!
  • http://i103.photobucket.com/albums/m154/Cegasaturn/Yay.jpg
• Also, the cross-correlation is rubbish for chirp. Though not as rubbish as it is for sine. Will ask Phani about that as well.

Progress Report April 1

• Plan of Action:
  • 1) Set up 2 Elvis boards.
  • 2)
  • 3) Have a presentation for Friday, April 15 to give to prospective students.
  • 4) Undergraduate Research Symposium and Department Presentation.
  • 5) Exams.
• This is a somewhat serious plan of action. Fun!
• Anyways. Transmitter/receiver pair has a frequency range of about 10k centered around 40kHz. Which is a pleasant surprise.

Progress Report April 8

• Got demo system set up for next week. We used an average FFT to get data clean enough to detect the returned signal's secondary peak.

Progress Report, April 22

• Previous progress report was wrong, unfortunately. Spent a while getting it all working correctly with the mobile platform, and then had issues during presentation due to laptop acting up. Have to redo demonstration next Wednesday, so hopefully it all works smoothly then.
• Currently working on making my poster for the UGR Symposium. Which is fun.