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.
Subscribe to:
Comments (Atom)
