Viotar/Quantifying the signal: Difference between revisions
No edit summary |
|||
(15 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{|cellpadding="10" | {|cellpadding="10" | ||
|-valign="top" | |-valign="top" | ||
|width="100%" style="border:1px solid #fabd23; background-color:#FEF5DE;"| | |width="100%" style="border:1px solid #fabd23; background-color:#FEF5DE;text-align: justify;"| | ||
{| padding="0" cellspacing="0" style="margin-top:.2em; width:100%; background:none" | {| padding="0" cellspacing="0" style="margin-top:.2em; width:100%; background:none" | ||
| rowspan="32" width="5px" | | | rowspan="32" width="5px" | | ||
| rowspan="2" class="BGorange1" valign="middle" style="text-align:center; padding:.6em 10px .6em 10px; background-color:#A9D0F5; border-top:2px solid #2E9AFE; border-bottom:2px solid #2E9AFE" | | | rowspan="2" class="BGorange1" valign="middle" style="text-align:center; padding:.6em 10px .6em 10px; background-color:#A9D0F5; border-top:2px solid #2E9AFE; border-bottom:2px solid #2E9AFE" | | ||
<h1 style="font-size:180%; border:none; margin:0; padding:0"> | <h1 style="font-size:180%; border:none; margin:0; padding:0"> | ||
'''Quantifying the signal | '''Software design - Quantifying the signal | ||
''' | ''' | ||
</h1> | </h1> | ||
Line 24: | Line 24: | ||
'''Subpages:''' | '''Subpages:''' | ||
</h1><br/> | </h1><br/> | ||
{{:Viotar_Menu}} | |||
|width="2%" style="background-color:#FEF5DE;"| | |width="2%" style="background-color:#FEF5DE;"| | ||
|width="49%" style="border:2px solid #fabd23;"| | |width="49%" style="border:2px solid #fabd23;text-align: justify;"| | ||
<h1 style="font-size:180%; border:none; margin:0; padding:0"> | <h1 style="font-size:180%; border:none; margin:0; padding:0"> | ||
'''Overview:''' | '''Overview:''' | ||
Line 50: | Line 36: | ||
|}<br/> | |}<br/> | ||
{| cellpadding="10" | |||
|-valign="top" | |||
| style="border:2px solid #00FF33; background-color:#CCFF99"| | |||
==Software Design (Quantifying the signal we want to see)== | ==Software Design (Quantifying the signal we want to see)== | ||
With software design, we mean the way the controller is structured. There are many possibilities, but it is important to design the controller in such a way that it matches the requirements that are stated. The controller will be tested on a fixed point model of the string, so it is also important to verify that the model is accurate enough to represent the real string. Besides that, also the following questions need to be answered to come to a good software design: | With software design, we mean the way the controller is structured. There are many possibilities, but it is important to design the controller in such a way that it matches the requirements that are stated. The controller will be tested on a fixed point model of the string, so it is also important to verify that the model is accurate enough to represent the real string. Besides that, also the following questions need to be answered to come to a good software design: | ||
Line 111: | Line 99: | ||
====Possible controller architectures==== | ====Possible controller architectures==== | ||
Before we can decide what type of controller would be best for our system, let's take a look at the possible controller architecture. The first type of controller is open loop (feed forward). This means that the controller only sends a signal to actuators without checking whether the desired requirements are achieved or not. The second architecture is a closed loop (feedback) controller. This controller compares a measured value with a pre-defined value and | Before we can decide what type of controller would be best for our system, let's take a look at the possible controller architecture. The first type of controller is open loop (feed forward). This means that the controller only sends a signal to actuators without checking whether the desired requirements are achieved or not. The second architecture is a closed loop (feedback) controller. This controller compares a measured value with a pre-defined value and adapts the system, untill the measured value equals the pre-defined value. At last, there is a combination of both. In this controller, all the known information is used to send a feed forward signal to bring the system as close as possible to the desired state. The small changes are made using the feedback signal. This controller is generally preferred above the feedback only controller because controlling on the feedback signal is mostly rather slow. | ||
Reflected on our viotar, this gives the following concepts: | Reflected on our viotar, this gives the following concepts: | ||
Line 127: | Line 115: | ||
[[File:controller_int_quant.PNG|frame|Border|center|Figure 6: Quality and intensity paths]] | [[File:controller_int_quant.PNG|frame|Border|center|Figure 6: Quality and intensity paths]] | ||
====Recognising Helmholtz and quantifying the signal==== | ====Recognising Helmholtz and quantifying the signal==== | ||
Probably, Helmholtz is the only harmonic vibration that you can get from a string when you bow it. With a bow you can never get a normal standing wave as when you would pluck the string. Because of this, it is not necessary to quantify "how much" the measured vibration is the specific Helmholtz waveform. It may suffit to merely quantify how harmonic the measured vibration is. This can be done by detecting the fundamental frequency in the | Probably, Helmholtz is the only harmonic vibration that you can get from a string when you bow it. With a bow you can never get a normal standing wave as when you would pluck the string. Because of this, it is not necessary to quantify "how much" the measured vibration is the specific Helmholtz waveform. It may suffit to merely quantify how harmonic the measured vibration is. This can be done by detecting the fundamental frequency in the Fourier transformation of the signal, and looking how many multiplications of this frequency are still in the signal. The more overtones, the sharper the Helmholtz, and therefore the better the tone. | ||
In order to do this we made amplitude plots in the frequency domain. This gives information about the frequencies at which high peaks appear and what their amplitudes are. We did this for the model as well as for our measurements. When we first analyzed the model, we seemed to be right in the fact that as the tone gets better, more peaks appear in the | In order to do this we made amplitude plots in the frequency domain. This gives information about the frequencies at which high peaks appear and what their amplitudes are. We did this for the model as well as for our measurements. When we first analyzed the model, we seemed to be right in the fact that as the tone gets better, more peaks appear in the power spectrum. These peaks are not randomly spread out, but appear at harmonic frequencies. That is, at n-times the fundamental frequency with n being the number of the peak. This is also made visible in the figures below. These figures show the difference between the frequency that you would expect following this rule and the actual frequency that comes out of the model. For an unidentifiable tone, there are no harmonic tones on the expected frequencies, as the graph runs out of the figure. For a clear Helmholtz vibration however, the rule is satisfied for nine peaks. A second thing that becomes clear by analyzing the results from the model, is that the amplitude of every next peak decreases exponentially. | ||
[[File:Model_unidentifiable.PNG|frame|Border|left|Figure 7: Amplitude ratio and frequency errors for an unidentifiable sound]] [[File:Model_helmholtz.PNG|frame|Border|center|Figure 8: Amplitude ratio and frequency errors for a Helmholtz vibration]] | [[File:Model_unidentifiable.PNG|frame|Border|left|Figure 7: Amplitude ratio and frequency errors for an unidentifiable sound]] [[File:Model_helmholtz.PNG|frame|Border|center|Figure 8: Amplitude ratio and frequency errors for a Helmholtz vibration]] | ||
Line 141: | Line 128: | ||
[[File:Metingen_helmholtz.PNG|frame|Border|center|Figure 9: Amplitude ratio and frequency errors for measured Helmholtz sound]] | [[File:Metingen_helmholtz.PNG|frame|Border|center|Figure 9: Amplitude ratio and frequency errors for measured Helmholtz sound]] | ||
So, we seemed to be right in the fact that a vibration being Helmholtz has something to do with the frequencies at which harmonic peaks appear and the amplitude of that peaks compared to that of the fundamental frequency. There is only one important thing that makes this method of quantifying the signal irrelevant for our prototype control system. The point is that for this method a | So, we seemed to be right in the fact that a vibration being Helmholtz has something to do with the frequencies at which harmonic peaks appear and the amplitude of that peaks compared to that of the fundamental frequency. There is only one important thing that makes this method of quantifying the signal irrelevant for our prototype control system. The point is that for this method a Fourier transformation needs to be done in the control unit in order to detect what the quality of the signal is. The problem is, that a Fourier transformation cannot be done instantaneously but only when enough information about the vibration is gathered. A simple rule tells that the resolution of the transformation equals 1/(sample time). In our case, where quality of the sound depends strongly on the exact frequencies where peaks appear, we should have a resolution in the frequency domain of at least 1 Hz. This means that the sample time for every transformation needs to be about a second, while the vibration needs to be adapted in several milliseconds up to several hundreds of seconds at most. So, this method is simply never going to satisfy our requirements. | ||
However, there is another way to perform this method, being in the time domain. When we take a look at the sawtooth like waveform of a Helmholtz vibration, we can already in the time domain draw some conclusions regarding to the quality of the vibration. The reason for this is that the harmonic peaks in the time domain, with their decreasing amplitudes, and the saw-toothed waveform in the time domain are strongly related to each other. A saw-toothed waveform essentially is a set of harmonic sinuses with decreasing amplitudes, being sharper when more harmonic sinuses are present. Putting this in an equation leads to the following expression for the signal, consisting of n harmonics: | However, there is another way to perform this method, being in the time domain. When we take a look at the sawtooth like waveform of a Helmholtz vibration, we can already in the time domain draw some conclusions regarding to the quality of the vibration. The reason for this is that the harmonic peaks in the time domain, with their decreasing amplitudes, and the saw-toothed waveform in the time domain are strongly related to each other. A saw-toothed waveform essentially is a set of harmonic sinuses with decreasing amplitudes, being sharper when more harmonic sinuses are present. Putting this in an equation leads to the following expression for the signal, consisting of n harmonics: | ||
Line 154: | Line 141: | ||
[[File:Constant_force.PNG|frame|Border|left|Figure 11: Correlation for varying bowing speeds]] [[File:Constant_speed.PNG|frame|Border|center|Figure 12: Correlation for varying bowing forces]] | [[File:Constant_force.PNG|frame|Border|left|Figure 11: Correlation for varying bowing speeds]] [[File:Constant_speed.PNG|frame|Border|center|Figure 12: Correlation for varying bowing forces]] | ||
====Controller concept==== | ====Controller concept==== | ||
The process described above, brought us to a controller design for the prototype. This controller makes use of a look-up table. This look-up table contains all the pre-defined values for bowing speed and force. By determining the fundamental frequency of the signal, the controller "knows" which fret is played and therefor what values for bowing speed and force are required. To make sure that the bowing speed indeed equals the value from the look-up table (also under varying bowing force) the engine speed is measured using an encoder and looped back to the controller. For the bowing force this does not seem to be neccesary, since the bowing force | The process described above, brought us to a controller design for the prototype. This controller makes use of a look-up table. This look-up table contains all the pre-defined values for bowing speed and force. By determining the fundamental frequency of the signal, the controller "knows" which fret is played and therefor what values for bowing speed and force are required. To make sure that the bowing speed indeed equals the value from the look-up table (also under varying bowing force) the engine speed is measured using an encoder and looped back to the controller. For the bowing force this does not seem to be neccesary, since the bowing force does not depend on the bowing speed. |
Latest revision as of 14:58, 23 March 2011
|