The AMC 12A8 Servo Amplifier was used to send the impulse current to our electromagnetic drum. It is capable of handling 20-80 volts and a peak impulse current of 12 amps (6amps continuous). The amp was used in "voltage mode", were an output voltage was determined from a reference input pwm sent from the Arduino. We initially tried to use the amp in "current mode" but found a parasitic current was always sent to our drum, not ideal for our setup. While in voltage mode we tuned the potentiometer gains while the amplifier was connected to an oscilloscope to provide a maximum output current from the pwm signal.
The amp was connected to (4) 25V power supplies, 2 connected in series, 2 in parallel to provide 50 V and twice the amperage. This resulted in a reasonable repelling force.
Thursday, December 17, 2009
Final Project - Arduino Code
We used the Arduino Mega board to manage drumstick motion detection, sound synthesis, and force feedback.
Drumstick Motion Detection
We set up our detection system using three pairs of IR emitters and sensors. Each pair of emitter and sensor acts as a photogate; that is, the voltage across the sensor changes when the IR beam is blocked by an object, such as our drumstick. When the IR beams are not blocked, Arduino receives a high analog value (>300). When the drumstick passes through the IR beam, Arduino received a low analog value (<100).
Each pair was mounted such that the IR beam was horizontal, and the three pairs were stacked vertically, separated by 2 inches. The top two pairs were used to measure the velocity of the drumstick. This is accomplished by recording the time between when the top photogate is broken and when the second photogate is broken. Based on this time and the known distance between the two photogates, Arduino calculates the velocity of the drumstick. The third photogate acts as the virtual drum face, so that when it is broken Arduino sends a PWM signal to the electromagnet controller and a MIDI signal to the MIDI controller. The duty cycle of the PWM signal and the loudness of the MIDI sound is modulated by the measured drumstick velocity. The figure below shows the signals coming from the photogates during a typical strike of the drumstick (the signal from Sensor 1 is stronger due to better alignment of the emitter and sensor).
Sound Synthesis
We created a function in Arduino called noteOn that sends a signal to the MIDI controller telling it what sound to make. The function takes in three arguments. The first argument tells the MIDI controller to turn on or off any sounds. The second argument specifies the type of sound to make (i.e., snare, tomtom, cymbals, etc.). The third argument is a loudness value between 0 and 127. This value is derived from the measured drumstick velocity.
Force Feedback
The PWM signal sent from the Arduino when the third photogate is broken goes to a controller that supplies power to the electromagnet. The duty cycle of the PWM signal determines how much current to supply the electromagnet. The figure below shows the supply current with respect to duty cycle. Note: the supply current saturates at a PWM signal of about 230.
The duty cycle is derived from the measured drumstick velocity, and can also be amplified or attenuated to match different drum types. The duration of the PWM signal is a constant that can be altered to match the characteristics of any drum. For example, in the code shown below the duration of the signal in snare mode is short, but it repeats creating a vibratory effect, and the duration of the signal in tomtom mode is long. The figure below shows the (inverted) supply current profile for five separate strikes of the drumstick with an impulse duration of 100ms.
Aduino Code
int sensorpin1 = 0;
int sensorpin2 = 1;
int sensorpin3 = 2;
int PWMpin = 10;
int switchSend = 24;
int switchRec = 34;
int sensorval1 = 0;
int sensorval2 = 0;
int sensorval3 = 0;
int sensorval3_prev = 300;
long time1 = 0;
long time2 = 0;
float vel = 0;
float distance = 2;
float clearance = 2.8;
float snare_dur = 50;
float tomtom_dur = 100;
float snare_coef = 2;
float tomtom_coef = 1.2;
float impulse_amp = 0;
float impulse_coeff = 2000;
int soundOn = 1;
void setup()
{
Serial.begin(31250);
pinMode(switchSend, OUTPUT);
pinMode(switchRec, INPUT);
digitalWrite(switchSend, HIGH);
}
void loop()
{
sensorval1 = analogRead(sensorpin1);
sensorval2 = analogRead(sensorpin2);
sensorval3 = analogRead(sensorpin3);
if (sensorval1<100)>
time1 = millis();
}
if (sensorval2<100)>
time2 = millis();
}
if (time2 > time1 && time2-time1<1500)>
vel = distance/(time2-time1); // vel = [in/ms]
impulse_amp = vel*impulse_coeff;
impulse_amp = constrain(impulse_amp,0,255);
}
else {
impulse_amp = 127;
}
if (sensorval3 <>
if (digitalRead(switchRec) == HIGH) {
if (sensorval3_prev > 100) noteOn(0x90, 38, map(impulse_amp,0,255,0,127));
for (int i=0; i<=5; i++) {
analogWrite(PWMpin, snare_coef*impulse_amp);
digitalWrite(13,HIGH);
delay(snare_dur);
analogWrite(PWMpin,0);
digitalWrite(13,LOW);
delay(snare_dur);
}
if (sensorval3_prev > 100) noteOn(0x80, 38, 127);
} else {
if (sensorval3_prev > 100) noteOn(0x90, 48, map(impulse_amp,0,255,0,127));
analogWrite(PWMpin, tomtom_coef*impulse_amp);
digitalWrite(13,HIGH);
delay(tomtom_dur);
analogWrite(PWMpin,0);
digitalWrite(13,LOW);
if (sensorval3_prev > 100) noteOn(0x80, 48, 127);
}
}
sensorval3_prev = sensorval3;
}
void noteOn(int cmd, int pitch, int velocity) {
Serial.print(cmd, BYTE);
Serial.print(pitch, BYTE);
Serial.print(velocity, BYTE);
}
Final Project - MIDI
We are using General MIDI to communicate between the drum and sound synthesizer. Since our instrument is a percussion device, we are using channel 10. When the MIDI synthesizer is in channel 10, note becomes different instruments. For our drum, we opted to produce snare drum and high tom sound.
We are using the note number 38 to generate the snare drum sound and the note number 48 to generate the high tom sound.
We are using the note number 38 to generate the snare drum sound and the note number 48 to generate the high tom sound.
Final Project - Fabrication
Our prototype is consist of the IR emitter and receivers, a wood base, wood towers for the IR sensors, an electromagnet, an Arduino Mega, an amplifier and power supplies.
The IR sensors were bought at Radio Shack and placed on the wood towers. The sensors were placed 2 inches apart from each other as seen on the pictures above. The wood towers and base were made from flat wooden panels and the laser cutter in the Autolab machine shop was used to cut the parts. The base is made of two flat wooden panels that sandwich the bottom plate of the electromagnet. By this way, the electromagnets are secured to the instrument and more professional look was achieved. Furthermore, in order to enhance the overall ergonomics of the playing drum, the base is tilted so that it faces the user. Lastly, the switch for selecting different instruments was attached to the base. The pictures below show the CAD drawing for the laser cut parts.
The electromagnet was made from a spool of insulated magnet wire. The entire spool was used as the core of the electromagnet and we used a circular pipe and a thin iron plate to minimize the magnetic field loss.
We are using one Arduino Mega board for data acquisition and control signal generation and the code is shown on another thread. The Arduino board sends out a PWM signal to drive the electromagnet and the signal is amplified by AMC 12A8 motor controller. The amplifier receives the power from four 25 V power supplies. The power supplies are connected in series and parallel to achieve both high voltage and current. Two power supplies are connected in series and so are the other two. And then the two groups of power supplies are connected in parallel. This gave us approximately 50 V to operate the amplifier and high current so that the electromagnet could generate the strong magnetic field.
The IR sensors were bought at Radio Shack and placed on the wood towers. The sensors were placed 2 inches apart from each other as seen on the pictures above. The wood towers and base were made from flat wooden panels and the laser cutter in the Autolab machine shop was used to cut the parts. The base is made of two flat wooden panels that sandwich the bottom plate of the electromagnet. By this way, the electromagnets are secured to the instrument and more professional look was achieved. Furthermore, in order to enhance the overall ergonomics of the playing drum, the base is tilted so that it faces the user. Lastly, the switch for selecting different instruments was attached to the base. The pictures below show the CAD drawing for the laser cut parts.
The electromagnet was made from a spool of insulated magnet wire. The entire spool was used as the core of the electromagnet and we used a circular pipe and a thin iron plate to minimize the magnetic field loss.
We are using one Arduino Mega board for data acquisition and control signal generation and the code is shown on another thread. The Arduino board sends out a PWM signal to drive the electromagnet and the signal is amplified by AMC 12A8 motor controller. The amplifier receives the power from four 25 V power supplies. The power supplies are connected in series and parallel to achieve both high voltage and current. Two power supplies are connected in series and so are the other two. And then the two groups of power supplies are connected in parallel. This gave us approximately 50 V to operate the amplifier and high current so that the electromagnet could generate the strong magnetic field.
Wednesday, December 16, 2009
Final Project - Bill of Materials
The following are the components used in our working prototype.
Electromagnet:
(1) Steel Core with theaded hole
(1) Clear Plastic Spool
(~3600 Windings) Insulated Magnet Wire
(1) Clear Plastic Spool
(~3600 Windings) Insulated Magnet Wire
(1) Galvanized Steel Cylinder Tube for BackIron
(1) Retangular Steel Plate for BackIron
(1) LaserCut Wood Base
DrumStick:
(2) 2B Wooden Drumstick
(3" Long) 1/4" Cylinder Magnets
Sensor Array:
(2) LaserCut Wood Towers
(3) InfraRed Emitting LED
(3) PhotoTransistor Detectors
Power and Control:
(4) 25V Power Supply
(1) AMC 12A8 Servo Amplifier
(1) Ardunio Mega
(1) MidiSport 2X2 USB Box
Final Project - Electromagnetic drum kit with controlled impulse response
There will be three main components to our design: the electromagnetic drum, the drum stick with an embedded permanent magnet, and a sensor curtain. The electromagnetic drum will consist of a ferrous, non-permanent winding core surrounded by a back iron. The purpose of the winding core and back iron will be to minimize the air gap around the electromagnet, thereby increasing the strength of the magnetic field. A cylinder magnet will be embedded in the drum stick, with an isolated pole at the tip designed to experience repelling forces when placed near the "virtual drum face". The sensor curtain will be composed of infrared emitters and phototransistor detectors to determine the speed of the drumstick and location to correlate a proper impulse response to the drum.
When playing the instrument, the user will initially select what type of drum they would like to play, be that a snare or tom tom. This will tell the controller which type of impulse to send to the electromagnet. At wil the user can change the design, and sound, of the drum.
Concept Sketch:
Wednesday, November 11, 2009
Lab 6 Real System Identification
To analyze the new system, we modified the code used in the previous exercise with the addition of another array to control motor direction. The array was populated with a random distribution of 1's and 0's, which translated to HIGHs and LOWs for output to the H-bridge direction pin.
A plot of the white noise input (in blue) and the system's response (in green) is given below. (Note: the input and response are not given in the same units, and thus the y-axis scale should be ignored.)
Running the system identification, Matlab returned the following bode plot of the estimated transfer function. Comparing the figure below with the expected bode plot (shown above), it is clear that the results are not as accurate as the results for the RC circuit. The phase plot decreases in degrees, but acts more like a 2nd order system than the expected 1st order system. The magnitude plot does not show the expected 20dB/decade slope. Possible causes are the resolution, or lack of calibration, in our accelerometer or noise in the system. One solution not attempted was filtering the data through an op amp filter. Further system identification work will have to be completed on our actual project system in hopes to obtain better results.
A plot of the white noise input (in blue) and the system's response (in green) is given below. (Note: the input and response are not given in the same units, and thus the y-axis scale should be ignored.)
Running the system identification, Matlab returned the following bode plot of the estimated transfer function. Comparing the figure below with the expected bode plot (shown above), it is clear that the results are not as accurate as the results for the RC circuit. The phase plot decreases in degrees, but acts more like a 2nd order system than the expected 1st order system. The magnitude plot does not show the expected 20dB/decade slope. Possible causes are the resolution, or lack of calibration, in our accelerometer or noise in the system. One solution not attempted was filtering the data through an op amp filter. Further system identification work will have to be completed on our actual project system in hopes to obtain better results.
Lab 6 - Real System
The team explored system identification of the fader motor used in previous labs. Rather than measuring a position response to a motor voltage, we decided to explore acceleration response by attaching an accelerometer to the slider. We also added mass to the slider to overcome the effects of friction on the slider. We chose exploring the acceleration response of the system as we thought an accelerometer may be useful for the final project, if accelerometers were used on a drumstick.
The system is represented by a constant K, which is comprised the of motor constant, radius of the gear, and motor resistance, mass of the bolt/accelerometer, damping of the motor and system, and resistance of the motor.
This system is represented by the Bode plot shown below. It should be noted that this system is only a parametrized model and does not incorporate real numbers. It was created to see the shape, not values, of the plot.
The system is represented by a constant K, which is comprised the of motor constant, radius of the gear, and motor resistance, mass of the bolt/accelerometer, damping of the motor and system, and resistance of the motor.
This system is represented by the Bode plot shown below. It should be noted that this system is only a parametrized model and does not incorporate real numbers. It was created to see the shape, not values, of the plot.
Lab 6 - System Identification
To familiarize ourselves with Matlab's tfestimate() function and learn how to set up serial communication between Matlab and Arduino, we first constructed the RC circuit shown in the circuit diagram below.
The above RC circuit functions as a low-pass filter characterized by the transfer function and frequency response bode plot given below.
We then programmed Matlab to send a stream of white noise to Arduino, which outputs the white noise as a PWM signal to the RC circuit, senses the response, and transmits it back to Matlab. At first, we had Matlab and Arduino communicating signals one at a time (i.e., Matlab would send a single piece of white noise (a random number) to Arduino, and Arduino would respond with the RC circuit's response). We found this method to be incredibly slow, with sample rates less than 10HZ, well below the cut-off frequency of our low-pass filter. To remedy this, we reprogrammed the system so that each operation (e.g., creating the white noise, sending the PWM signal and sensing the response, etc.) was done separately with no overlap. Using this method, the system was programmed to follow these steps:
Step 1: Create the white noise and save it as an array
Rather than retrieve one random number from Matlab at a time, we programmed Arduino to create an array of random numbers that serves as the white noise. This eliminated the delay between when Arduino transmits the RC circuit's response and when it receives another random number from Matlab.
Step 2: Output the white noise as a PWM signal and sense the response
After the array of white noise is created, Arduino outputs a single element as a PWM signal to the RC circuit, senses the response and saves it to an array, and then delays for 0.9ms. This operation iterates until every element of the white noise array has been output.
Step 3: Transmit the white noise array and the RC circuit response array to Matlab
After all white noise output and response sensing is complete, Arduino transmits the two arrays to Matlab for processing. Delaying the serial communication until after all signal output/sensing is complete significantly increases the sampling rate. Using this method, we were able to achieve sampling rates of 1000Hz.
Step 4: Read and process the data from Arduino in Matlab
We programmed Matlab to process the data and produce two figures. The first figure, included below, shows the white noise (in blue) and the system's response (in green) with respect to time. The second figure, also included below, shows the bode plot of Matlab's estimate of the transfer function (in blue) and the bode plot of the actual transfer function (in green).
The above RC circuit functions as a low-pass filter characterized by the transfer function and frequency response bode plot given below.
We then programmed Matlab to send a stream of white noise to Arduino, which outputs the white noise as a PWM signal to the RC circuit, senses the response, and transmits it back to Matlab. At first, we had Matlab and Arduino communicating signals one at a time (i.e., Matlab would send a single piece of white noise (a random number) to Arduino, and Arduino would respond with the RC circuit's response). We found this method to be incredibly slow, with sample rates less than 10HZ, well below the cut-off frequency of our low-pass filter. To remedy this, we reprogrammed the system so that each operation (e.g., creating the white noise, sending the PWM signal and sensing the response, etc.) was done separately with no overlap. Using this method, the system was programmed to follow these steps:
Step 1: Create the white noise and save it as an array
Rather than retrieve one random number from Matlab at a time, we programmed Arduino to create an array of random numbers that serves as the white noise. This eliminated the delay between when Arduino transmits the RC circuit's response and when it receives another random number from Matlab.
Step 2: Output the white noise as a PWM signal and sense the response
After the array of white noise is created, Arduino outputs a single element as a PWM signal to the RC circuit, senses the response and saves it to an array, and then delays for 0.9ms. This operation iterates until every element of the white noise array has been output.
Step 3: Transmit the white noise array and the RC circuit response array to Matlab
After all white noise output and response sensing is complete, Arduino transmits the two arrays to Matlab for processing. Delaying the serial communication until after all signal output/sensing is complete significantly increases the sampling rate. Using this method, we were able to achieve sampling rates of 1000Hz.
Step 4: Read and process the data from Arduino in Matlab
We programmed Matlab to process the data and produce two figures. The first figure, included below, shows the white noise (in blue) and the system's response (in green) with respect to time. The second figure, also included below, shows the bode plot of Matlab's estimate of the transfer function (in blue) and the bode plot of the actual transfer function (in green).
Saturday, October 24, 2009
Lab 4 - Abstract
For this lab, we have a better hall effect sensor for the iTouch motor. Instead of about 20 quantized signal levels, we now have about 200 levels. We even enhanced the precision of the sensor by implementing the signal amplifier using an op amp chip. Using this improved signal, we were able to construct better virtual spring and virtual damper system. We also differentiated the location sensor value to get the velocity value. This velocity value gave us another way to construct the virtual damper system. Lastly, we connected the iTouch and Arduino with the computer via MIDI protocal to generate sound. We used PD (Pure Data) to synthesize the sound.
Thursday, October 22, 2009
Lab 4 - Sound of MIDI...
We used one of the examples from the pd documentation to interface and generate sounds from the Arduino board. We first applied a constant voltage from the arduino board to the MIDI jack, which produced a series of notes being played repeatedly desired. To generate sounds using our motor, we used the force from our virtual damper set-up to control the pitch in our pd document. As previously mentioned, we used our digital virtual damper because of the ease with which we could adjust the gains. The video below shows the result:
Lab 4: Op Amp Success!
After much tribulation we decided to use a voltage divider and an op amp to supply 2.5V to the non-inverting input of our inverting op amp. A diagram of this 2.5V virtual ground can be seen in the following diagram below.
Virtual Grnd Op Amp
Since this is a single supply op amp (0-Vcc instead of +/-Vcc) the need for a virtual ground is paramount. As we realized just supplying 2.5V will not solve the problem of a functional op amp. Once we had the op amp virtual ground supplying 2.5V we connected it to another inverting op amp as shown in the circuit diagram below.
Inverting Op Amp with Virtual Grnd
Once we constructed this circuit, we then tested it with a multimeter to see what voltages were being output. We found that for a ~1V input from the Hall-Effect sensor's "push-push" configuration we obtained an output range of 0.73-3.5V or ~3V. The following diagram shows how we connected the Arduino, Hall-effect sensor, and Op amps together.
Op Amp Circuit
Finally, we compared the theorectical output voltage with the empirical data and found values to be close to expected using the following formula.
Inverting Op Amp Equation (V_Bias=2.5V)
Virtual Grnd Op Amp
Since this is a single supply op amp (0-Vcc instead of +/-Vcc) the need for a virtual ground is paramount. As we realized just supplying 2.5V will not solve the problem of a functional op amp. Once we had the op amp virtual ground supplying 2.5V we connected it to another inverting op amp as shown in the circuit diagram below.
Inverting Op Amp with Virtual Grnd
Once we constructed this circuit, we then tested it with a multimeter to see what voltages were being output. We found that for a ~1V input from the Hall-Effect sensor's "push-push" configuration we obtained an output range of 0.73-3.5V or ~3V. The following diagram shows how we connected the Arduino, Hall-effect sensor, and Op amps together.
Op Amp Circuit
Finally, we compared the theorectical output voltage with the empirical data and found values to be close to expected using the following formula.
Inverting Op Amp Equation (V_Bias=2.5V)
Wednesday, October 21, 2009
Lab 4 - Virtual Dampers
Two kinds of virtual dampers were experimented with in this lab. A digital damper was implemented by use of a memory variable that would store the previous location of the armature and compare it against the current location. The difference would then be multiplied by a damping gain, b, and added to the total force equation as follows:
Force = (Neutral Position - Current Position)*KSpring + (Previous Position - Current Position)*KDamper
Again the sign was taken to map to the direction of the PWM and the absolute value because the magnitude of the PWM.
The range of damping coefficients (aka gain b) was somewhat narrow before the system would grow unstable. We do not believe this was due to the mathematical dynamics of the system, because the system became unstable with high damping, which is the opposite as one would think. Instead, like we saw in the previous lab with the spring constant, since the signal and PWM are sampled and sent out in discrete packets of time, they are simply not fast enough to change to compensate for large forces. Therefore each successive PWM would grow unboundedly if any PWM was enough to push the armature fast enough that the discrete system could not catch up.
Regardless, some damping was implemented and its effects can be seen below.
Then, after the digital implementation was proven a success, an analog analog was created using a capacitor in series with Ri and in parallel with Rf. Because of the time needed to charge the capacitors, there was induced a lag between full conveyance of signal from the input and the output of op-amp. Therefore, if the voltage changed too quickly (velocity), the charge would not catch up and the action would be weakened. This can be observed in the form of damping. Below is a video of the effect of the capacitor in parallel with Rf and then the undamped system after the capacitor has been removed.
Since the gains were easier to modify in the digital implementation, the other virtual environments such as the virtual wall, etc. were performed through purely digital computations. They were no more elaborate than in the previous lab (adjusting spring gains very high for walls, etc.), and the effects were comparably improved as they were with the simply virtual spring.
Force = (Neutral Position - Current Position)*KSpring + (Previous Position - Current Position)*KDamper
Again the sign was taken to map to the direction of the PWM and the absolute value because the magnitude of the PWM.
The range of damping coefficients (aka gain b) was somewhat narrow before the system would grow unstable. We do not believe this was due to the mathematical dynamics of the system, because the system became unstable with high damping, which is the opposite as one would think. Instead, like we saw in the previous lab with the spring constant, since the signal and PWM are sampled and sent out in discrete packets of time, they are simply not fast enough to change to compensate for large forces. Therefore each successive PWM would grow unboundedly if any PWM was enough to push the armature fast enough that the discrete system could not catch up.
Regardless, some damping was implemented and its effects can be seen below.
Then, after the digital implementation was proven a success, an analog analog was created using a capacitor in series with Ri and in parallel with Rf. Because of the time needed to charge the capacitors, there was induced a lag between full conveyance of signal from the input and the output of op-amp. Therefore, if the voltage changed too quickly (velocity), the charge would not catch up and the action would be weakened. This can be observed in the form of damping. Below is a video of the effect of the capacitor in parallel with Rf and then the undamped system after the capacitor has been removed.
Since the gains were easier to modify in the digital implementation, the other virtual environments such as the virtual wall, etc. were performed through purely digital computations. They were no more elaborate than in the previous lab (adjusting spring gains very high for walls, etc.), and the effects were comparably improved as they were with the simply virtual spring.
Lab 4 - Virtual Spring v2.0
With the newly magnified analog signal coming from the hall effect sensor, coupled with its increased sensitivity, we were able to get a range of just about the full five volts into the Arduino.
For the virtual spring, we implemented a detent such that there existed an equilibrium in the middle of the armature space, and there were virtual springs on either side of the middle. The force was calculated as a neutral position minus the current position multiplied by a gain (acting as a spring constant). The sign of the force was translated into a direction (HIGH or LOW) into the dir pin of the H-Bridge, while the absolutely value was directly translated to an output PWM.
The new virtual spring was very smooth (when the serial window was not open--unfortunately leading to a lack of graphs). Furthermore, a work-around in the previous lab to calm the action of the armature was to add a "dead-zone" at the equilibrium point where no force, however small, would be induced, and then take the square-root of the force calculated to eliminate some non-linearities in the signal range. The fidelity of the current set-up was superior and so neither one of these work-arounds had to be implemented.
For the virtual spring, we implemented a detent such that there existed an equilibrium in the middle of the armature space, and there were virtual springs on either side of the middle. The force was calculated as a neutral position minus the current position multiplied by a gain (acting as a spring constant). The sign of the force was translated into a direction (HIGH or LOW) into the dir pin of the H-Bridge, while the absolutely value was directly translated to an output PWM.
The new virtual spring was very smooth (when the serial window was not open--unfortunately leading to a lack of graphs). Furthermore, a work-around in the previous lab to calm the action of the armature was to add a "dead-zone" at the equilibrium point where no force, however small, would be induced, and then take the square-root of the force calculated to eliminate some non-linearities in the signal range. The fidelity of the current set-up was superior and so neither one of these work-arounds had to be implemented.
Lab 4 - Trouble in Op-Amp Land...
We began to venture forth on the path of multiplying our new hall effect sensor signal when we came across some trouble.
The new hall effect sensors were in and, according to their spec sheet, twice as sensitive as the previous versions. Still, after the Arduino digitizes the analog in signal, we would still only be working with 40-60 tics of range out of the possible 1024. To combat this problem we did two things. First, we adjusted the magnets which were inducing the magnetic field that the hall effect sensor was reading in a push-push configuration so that the field would be the densest and the signal would be the strongest. Then, the more important step was to amplify the signal by means of an op-amp. Furthermore, since we were interested in a range of number interior to the max range of the signal, we not only wanted to magnify the signal, but we also wanted to offset the voltage to more or set 0v to one end of our range (low end for non-inverting, high end for inverting op-amp). To do this we would need to produce a virtual ground and send this signal to the non-inverting pin of the op-amp. The virtual ground was a non-zero voltage that would act as a starting line for the signal voltage. For example, if our voltage range was 2-3v and the virtual ground was 1v, the resulting signal would be read as 1-2v (2-3 minus 1). We therefore wanted to send in about 2.5v into the non-inverting terminal and then scale the .93v of range we were reading from the multimeter at the armatures extremes into the full 5v the Arduino would read. We thought it would be a bright idea to send a PWM equally the equivalent of 2.5v directly into the non-inverting terminal from the Arduino to save us some time creating circuits and then pick an Rf/Ri = 5.
We tried this and it did not work. Furthermore, the output size and range of the same signal did not scale according to Rf/Ri at all, and actually did not seem to follow any trend. In fact, switching Rf for Ri also did not have any effect. We tried the following combinations of Rf and Ri with the following results:
Rf: 20k, Ri:15k Vrange:.5-.72v
Rf: 20k, Ri:20k Vrange:.2-.7v
Rf: 20k, Ri:25k Vrange:.09-.64v
Rf: 20k, Ri:47k Vrange:.07.13v
We could not find a pattern or rule to go by. We tried a number of other circuits, and even tried double up the gain, by feeding the output of one op-amp into another. This didn't have any effect at all.
We actually still don't know the reason for the trouble, but, when we replaced the PWM with a voltage divided 2.5v from another op-amp circuit, everything worked like a charm. We think that perhaps there were some current flows that we did not measure that were messing up the function of the op-amp. We were checking voltage consistently, and they all looked to be alright on the input side of the op-amps, but the current was never checked.
The new hall effect sensors were in and, according to their spec sheet, twice as sensitive as the previous versions. Still, after the Arduino digitizes the analog in signal, we would still only be working with 40-60 tics of range out of the possible 1024. To combat this problem we did two things. First, we adjusted the magnets which were inducing the magnetic field that the hall effect sensor was reading in a push-push configuration so that the field would be the densest and the signal would be the strongest. Then, the more important step was to amplify the signal by means of an op-amp. Furthermore, since we were interested in a range of number interior to the max range of the signal, we not only wanted to magnify the signal, but we also wanted to offset the voltage to more or set 0v to one end of our range (low end for non-inverting, high end for inverting op-amp). To do this we would need to produce a virtual ground and send this signal to the non-inverting pin of the op-amp. The virtual ground was a non-zero voltage that would act as a starting line for the signal voltage. For example, if our voltage range was 2-3v and the virtual ground was 1v, the resulting signal would be read as 1-2v (2-3 minus 1). We therefore wanted to send in about 2.5v into the non-inverting terminal and then scale the .93v of range we were reading from the multimeter at the armatures extremes into the full 5v the Arduino would read. We thought it would be a bright idea to send a PWM equally the equivalent of 2.5v directly into the non-inverting terminal from the Arduino to save us some time creating circuits and then pick an Rf/Ri = 5.
We tried this and it did not work. Furthermore, the output size and range of the same signal did not scale according to Rf/Ri at all, and actually did not seem to follow any trend. In fact, switching Rf for Ri also did not have any effect. We tried the following combinations of Rf and Ri with the following results:
Rf: 20k, Ri:15k Vrange:.5-.72v
Rf: 20k, Ri:20k Vrange:.2-.7v
Rf: 20k, Ri:25k Vrange:.09-.64v
Rf: 20k, Ri:47k Vrange:.07.13v
We could not find a pattern or rule to go by. We tried a number of other circuits, and even tried double up the gain, by feeding the output of one op-amp into another. This didn't have any effect at all.
We actually still don't know the reason for the trouble, but, when we replaced the PWM with a voltage divided 2.5v from another op-amp circuit, everything worked like a charm. We think that perhaps there were some current flows that we did not measure that were messing up the function of the op-amp. We were checking voltage consistently, and they all looked to be alright on the input side of the op-amps, but the current was never checked.
Thursday, October 15, 2009
Lab 3b - We're done!
In this lab, we were able to run frequency analyses on our motor system, injecting various sinusoids, observing the responses to those injections, and comparing those responses to the expected responses based on the Bode plot created from our system's transfer function. Additionally, we created virtual environments for the first time. We were successful with creating the wall and the damper, but did not have much luck with the mass-spring due to its complexity.
Wednesday, October 14, 2009
Lab 3b - Creating virtual environments
Days Three to Seven:
After we took care of the frequency runs, we attempted to create three virtual environments: (1) a virtual wall, (2) a damper, and (3) a mass-spring system. Below, you can see the code we wrote and videos for (1) and (2).
Virtual Wall
Damper
Mass-Spring System
a1old = a1
v1old = v1
d1old = d1
end loop
The video below shows the effect of implementing the virtual mass-spring:
The haptic interface exercise provided us great insight into how to mimic mechanical behaviors while helping us to better understand how to program the Arduino given the motor characteristics we had.
The virtual environment that was the hardest to implement (and the one that we actually did not even end up getting to work) was the mass-spring system mainly due to the fact we had to create for a double integral in the Arduino, which ended up putting us far from the desired result due to the complexity of our coding.
The most satisfying environment to implement, on the other hand, was the damper due to the simplicity of our coding, since it required only one proportional control which was then multiplied by our velocity.
To make the device better, we could have assembled the motor better. This includes, but is not limited to, the way we wound the wires, the orientation of the small magnets, and the spacing about the envelope of motion. If these were assembled better to begin with, we would have had a lot fewer outside sources of error to account for.
After we took care of the frequency runs, we attempted to create three virtual environments: (1) a virtual wall, (2) a damper, and (3) a mass-spring system. Below, you can see the code we wrote and videos for (1) and (2).
Virtual Wall
// These constants won't change. They're used to give names
// to the pins used:
const int digitalOutPin = 0; // Connect to DIR pin
const int analogInPin = 0; // Connect to PMWM
const int analogOutPin = 5; // Analog output pin that the LED is attached to
int sensorValue = 0; // value read from the pot
int outputValue = 0; // value output to the PWM (analog out)
int designValue = 128;
int measureValue = 127;
int measureoldValue = 127;
int Kd = 0.1;
int Kp = 0.1;
int velocity = 0;
void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
}
void loop() {
// read the analog in value:
sensorValue = analogRead(analogInPin);
// map it to the range of the analog out:
measureValue = map(sensorValue, 494, 520, 0, 255);
// direction control
digitalWrite(digitalOutPin, HIGH); // set direction to right
// P controller
if (measureValue < outputvalue =" abs" outputvalue =" 0;" sensor = " ); Serial.print(sensorValue); Serial.print(" output = "); Serial.print(outputValue); Serial.print(" measure =" " measureoldvalue="measureValue;">
Damper
// These constants won't change. They're used to give names
// to the pins used:
const int digitalOutPin = 24; // Connect to DIR pin
const int analogInPin = 0; //
const int analogOutPin = 5; // Connect to PWM
const int analogInPin2 = 2; // Vout from hall effect current sensor
int sensorValue = 0; // value read from the pot
int outputValue = 0; // value output to the PWM (analog out)
int designValue = 128;
int sensoroldValue = 0;
int measureValue = 0;
int velocity = 0;
int sensorValue2 = 0;
int Kd = 1;
void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
}
void loop() {
// read position information:
sensorValue = analogRead(analogInPin);
// read the Vout from current value through Hall effect sensor
sensorValue2 = analogRead(analogInPin2);
// map position to the range of the analog out:
measureValue = map(sensorValue, 494, 520, 0, 255);
// Define direction of output
if (velocity > 0) {
digitalWrite(digitalOutPin, HIGH); // set direction to right
}
else {
digitalWrite(digitalOutPin, LOW);
}
// virtual damper
outputValue = abs(velocity);
analogWrite(analogOutPin, outputValue);
// print the results to the serial monitor:
Serial.print("current = " );
Serial.print(sensorValue2);
Serial.print("\t velocity = ");
Serial.print(velocity);
Serial.print("\t output = ");
Serial.println(outputValue);
velocity = (sensorValue - sensoroldValue) * Kd ;
delay(10);
sensoroldValue=sensorValue;
}
Mass-Spring System
Below is the pseudo code for the mass-spring system.
When the code was implemented in the Arduino, the motor would vibrate violently due to the relatively large time steps (90 m seconds) and the low resolution of the hall effect sensor.
- Set virtual mass displacement (d1), velocity (v1), and acceleration (a1) as zero loop
- Read Time Stamp(t)
- Calculate time difference from last step dt = t – t_old
- Read armature position (hall effect sensor) data (d)
- Calculate difference of armature position and virtual mass position (d – d1)
- Multiply Kd to (d-d1) to find force due to virtual spring (F)
- Apply current through motor to represent the force (F) due to virtual spring
- Divide virtual mass by the force calculate in (7) to get acceleration of virtual mass (a1)
- Integrate virtual mass acceleration to get velocity v1=v1old + a1 * dt
- Integrate virtual mass velocity to get displacement d1=d1old + v1 * dt
- Set current values as old:
a1old = a1
v1old = v1
d1old = d1
end loop
The video below shows the effect of implementing the virtual mass-spring:
The haptic interface exercise provided us great insight into how to mimic mechanical behaviors while helping us to better understand how to program the Arduino given the motor characteristics we had.
The virtual environment that was the hardest to implement (and the one that we actually did not even end up getting to work) was the mass-spring system mainly due to the fact we had to create for a double integral in the Arduino, which ended up putting us far from the desired result due to the complexity of our coding.
The most satisfying environment to implement, on the other hand, was the damper due to the simplicity of our coding, since it required only one proportional control which was then multiplied by our velocity.
To make the device better, we could have assembled the motor better. This includes, but is not limited to, the way we wound the wires, the orientation of the small magnets, and the spacing about the envelope of motion. If these were assembled better to begin with, we would have had a lot fewer outside sources of error to account for.
Tuesday, October 13, 2009
Lab 3b - Getting frequency responses from our motor
Day Two:
To understand the frequency characteristics of our motor system, we created a Bode plot based on the system's transfer function that would reveal to us the amplitude and phase shift of the output curve at a given frequency.
The following are the plots of the forcing function and experimental output curve at 10, 20, and 40 Hz, respectively:
The following chart outlines the behavior in the graphs and the expected behavior based on the data from the Bode plots:
To understand the frequency characteristics of our motor system, we created a Bode plot based on the system's transfer function that would reveal to us the amplitude and phase shift of the output curve at a given frequency.
The following are the plots of the forcing function and experimental output curve at 10, 20, and 40 Hz, respectively:
The following chart outlines the behavior in the graphs and the expected behavior based on the data from the Bode plots:
Lab 3b
The Team:
Takumi Jinmon
Lisa Perez
Janani Viswanathan
Our Goals for Lab 3b:
Day One:
We input a variety of sinusoidal curves such that we would be able to compare experimental frequency response to theoretical frequency response.
Takumi Jinmon
Lisa Perez
Janani Viswanathan
Our Goals for Lab 3b:
- Model motor system with current-control feedback
- Plot the theoretical frequency response of the motor system
- Plot the actual frequency response of the motor system and compare with the theoretical Bode plots
- Create controls that simulate a wall, damper, spring-mass
Day One:
We input a variety of sinusoidal curves such that we would be able to compare experimental frequency response to theoretical frequency response.
Lab 3a - We're done!
In this lab, we built an iTouch motor from scratch, characterized it through tests such as the bifilar method, modeled it in Simulink to predict and verify behavior, analyzed behavior with a P controller implemented, analyzed behavior with a PD controller implemented, and used all of the above to create a musical instrument.
On to 3b!
On to 3b!
Lab 3a - Making it move (and sing!)
Days Five to Seven:
To verify our motor system, we conducted an impulse response experiment and checked it against the predictions of a pendulum Simulink model with our constants plugged in:
After, we programmed the Arduino to have P control:
The velocity controller was supposed to feel like a damper. We got a damping effect, however, it was not very strong due to the fact that if we increased the derivative gain any more, the system would become unstable.
We integrated the motor system and position control with Labview. This was so that we could get an instrument with a haptic response so that it would simulate a piano key. It would play a note when the armature was pushed to a certain point and make it such that the armature would want to go back to center position:
To verify our motor system, we conducted an impulse response experiment and checked it against the predictions of a pendulum Simulink model with our constants plugged in:
After, we programmed the Arduino to have P control:
We then added PD control:
The velocity controller was supposed to feel like a damper. We got a damping effect, however, it was not very strong due to the fact that if we increased the derivative gain any more, the system would become unstable.
We integrated the motor system and position control with Labview. This was so that we could get an instrument with a haptic response so that it would simulate a piano key. It would play a note when the armature was pushed to a certain point and make it such that the armature would want to go back to center position:
Sunday, October 11, 2009
Lab 3a - Characterizing and simulating our motor
Days Three - Five:
To expand our understanding of the motor pre-PD controller, we characterized it by doing a series of tests. We figured out the torque-current curve and our motor constant (simply the slope of the curve) by placing a force on the armature and increasing the voltage through the motor system until the armature moved the force. During this process, we monitored the voltage through a resistor that was in series with it. See table and graph below:
We then calculated our rotor inertia using the bifilar method:
After we did this, we determined the damping constant by displacing the armature all the way to one side, and simply letting go. We recorded the behavior of the armature (a decaying sinusoidal), and tried to fit an exponential curve to it to obtain the damping constant.
See summary of constants that we determined below:
(Note: Vemfs all have units of V.)
Additionally, we were able to calculate the mechanical time constant of the motor to be 0.066 s by using the following equation: T = 1/a, where a = constant of decay of fitted exponential curve.
After all of this, we created a model of our motor in Simulink to generate a prediction of position behavior:
To expand our understanding of the motor pre-PD controller, we characterized it by doing a series of tests. We figured out the torque-current curve and our motor constant (simply the slope of the curve) by placing a force on the armature and increasing the voltage through the motor system until the armature moved the force. During this process, we monitored the voltage through a resistor that was in series with it. See table and graph below:
We then calculated our rotor inertia using the bifilar method:
After we did this, we determined the damping constant by displacing the armature all the way to one side, and simply letting go. We recorded the behavior of the armature (a decaying sinusoidal), and tried to fit an exponential curve to it to obtain the damping constant.
See summary of constants that we determined below:
- Motor constant k = 0.005 N-m/A
- Motor resistance R = 0.4 Ohm
- Rotor inertia J = 4E-5 kg-m^2
- Damping constant b = 0.0015
- Damping ratio 0.26
(Note: Vemfs all have units of V.)Additionally, we were able to calculate the mechanical time constant of the motor to be 0.066 s by using the following equation: T = 1/a, where a = constant of decay of fitted exponential curve.
After all of this, we created a model of our motor in Simulink to generate a prediction of position behavior:
Tuesday, October 6, 2009
Lab 3a - Wires and magnets and motor housings, oh my!
Day Two:
Today, we assembled our iTouch motor. This consisted of winding wires and then fixing the windings into a structure. After these steps were completed, the magnets were placed on each side of the structure, such that when we send current through the windings later on, we will create a force that moves the windings about the pivot.
We are having issues the clamping force of the magnets on the structure (it is causing the nylon bolts hit the wood, even after quite a bit of sanding). We are going to add spacers so that this is no longer an issue.
Here is the circuit we have created for this lab's purposes:
Today, we assembled our iTouch motor. This consisted of winding wires and then fixing the windings into a structure. After these steps were completed, the magnets were placed on each side of the structure, such that when we send current through the windings later on, we will create a force that moves the windings about the pivot.
We are having issues the clamping force of the magnets on the structure (it is causing the nylon bolts hit the wood, even after quite a bit of sanding). We are going to add spacers so that this is no longer an issue.
Here is the circuit we have created for this lab's purposes:
Friday, October 2, 2009
Lab 3a
The Team:
Takumi Jinmon
Lisa Perez
Janani Viswanathan
Our Goals for Lab 3a:
Day One:
Our windings for the motors that we will be building are not in yet, so we tried to do what we could to get the most of the lab in time being. We tested our Hall effect sensors with everyday magnets, and noticed that while the effect was noticeable on the serial output of the Arduino, it was not substantial enough to make a difference when place in a circuit with the motor. Based on this, we decided to calibrate the circuit using the Arduino such that the magnets would be able to activate the motor.
Additionally, we soldered the components of our H-bridge. Took a little bit of time since the parts are minuscule, but it is ready to go!
Beyond that, there is not that much for us to do right now. We are working on setting up the block diagrams in Simulink so that we can just plug and chug the gains once we measure them.
Takumi Jinmon
Lisa Perez
Janani Viswanathan
Our Goals for Lab 3a:
- Assemble and set up
- Estimate winding resistance, motor constant, damping, and inertia
- Create simulation models of the motor system and generate predictions of behavior
- Use an analytical system model with test data to estimate and verify system parameters
- Try a basic position feedback loop
- Create controllers and synthesizer communications
Day One:
Our windings for the motors that we will be building are not in yet, so we tried to do what we could to get the most of the lab in time being. We tested our Hall effect sensors with everyday magnets, and noticed that while the effect was noticeable on the serial output of the Arduino, it was not substantial enough to make a difference when place in a circuit with the motor. Based on this, we decided to calibrate the circuit using the Arduino such that the magnets would be able to activate the motor.
Additionally, we soldered the components of our H-bridge. Took a little bit of time since the parts are minuscule, but it is ready to go!
Beyond that, there is not that much for us to do right now. We are working on setting up the block diagrams in Simulink so that we can just plug and chug the gains once we measure them.
Wednesday, September 30, 2009
Lab 2 - Stepping back from the instrument and learning how to interface with LabVIEW
In parallel to all of the work that we were doing for the instrument, we were also getting acquainted with the basic functions of LabVIEW - namely, we were learning how to plot output from the circuit that we were playing with before putting together the instrument.
Below, you can see the plots that we obtained by playing with the force sensor and the photoresistor.
Force sensor output
Photoresistor output
Below, you can see the plots that we obtained by playing with the force sensor and the photoresistor.
Force sensor output
Photoresistor output
Monday, September 28, 2009
Lab 2 - Our instrument in its last few development stages
For our instrument, we chose a speaker as our sound output, and replaced the LED that was previously in our circuit with that speaker. We used the potentiometer to change the tone of the note.
We tried to build our own electrical music instrument using analog sensors to tune the frequencies. We played with the force sensor, thinking that we could control the notes by pressing different areas or combinations of areas to get different resistances (and thus, frequencies). We even tried to concentrate forces on the sensor at different areas with a bolt. However, we did not get repeatable resistance readouts. Also, we could not get satisfying resistance range differences. We decided to turn to other sensors.
Time to sing a song!
We decided to use the potentiometer due to its stable and linear performance. We divided the resistance into 8 parts, and then set 8 cases for different output frequencies (and thus different notes: Do, Re, Mi, etc.). See figure:
Then, we decided to use the force sensor to control volume.
We made a control panel with all of marks on it so that people could play music without having to sift through the circuit board to play what they wanted to play.
Time to sing a song!
Lab 2 - Making progress with our circuit
After gaining confidence in the operation of the Arduino, we experimented with using it to drive a resistor-transistor-LED circuit. In order to build this, we looked back to the circuit diagrams from Lab 1.
In the Lab 1 circuit diagrams, we had a button/switch, an LM555 timer, capacitors, resistors, a transistor, a speaker/LED, and a 5V power supply. This time, we took away the LM555 timer and replaced the 5V power supply with the Arduino microprocessor. We recalculated our optimal resistors with different values, and added a potentiometer to the circuit. See below for diagram:
We designed the circuit to work successfully with the LED, keeping in mind that the light blinking frequency depended on the resistance from potentiometer. This success was a booster to the next step -- an electronic musical instrument.
In the Lab 1 circuit diagrams, we had a button/switch, an LM555 timer, capacitors, resistors, a transistor, a speaker/LED, and a 5V power supply. This time, we took away the LM555 timer and replaced the 5V power supply with the Arduino microprocessor. We recalculated our optimal resistors with different values, and added a potentiometer to the circuit. See below for diagram:
We designed the circuit to work successfully with the LED, keeping in mind that the light blinking frequency depended on the resistance from potentiometer. This success was a booster to the next step -- an electronic musical instrument.
Subscribe to:
Comments (Atom)