Results-Design Expo

After our characterization, design, construction, and programming we came to the ME552 design expo with a function haptic feedback device. You can see our final device in the following video and pictures.

Some of the important aspects of our device that may go unnoticed are the important applications. According to the percussionist in our group this device is really exciting because it can help "teach beginners and experts the feeling of how to roll and flam faster." Just by holding the stick at a specific position you can get a continuous feedback bounce from the pad. Although this is not desired because it is not what happens in a conventional drum it is an artifact of the device that can be used as a teaching advantage. Holding a drum stick at the correct position to allow balanced bounces is one important skills a drummer needs to learn. By having a device that only allows the user to obtain this continuous bouncing through correct handling is a way to teach this important skill. This device also has the capability of being switched over to another drumhead or component to allow for different haptic feedback. Although this was not implemented in this device the possibility is there as well as for the creation of other virtual drums (which would be more realistic to simulate a smaller transportable drumset).

During the expo we encountered another problem. The hall effect magnet was initially placed between a crevasse to eliminate damage. However, midway through the expo it crept its way out and was eventually hit so much one of the sensors leads broke. A quick substitution allowed us to continue our display. However, for a while there the device was acting finicky which was unfortunate. Overall we were pleased to provide a wireless drumstick that implemented haptic feedback based on initial characterization of a conventional snare drum.

Programming and Electronics

Using complex programming we were able to create a virtual response that mimicked that of a conventional drumhead. For the expo we decided to use our snare drum response that we recorded and characterized. Another important piece of our program was that we were able to eliminate the annoying buzz sound coming from our motor. Thanks is due to Josh's group for creating this code and allowing us to use it. More details of our programming and electronics used will be discussed below.

As our goal is to produce a haptic force feedback to the user, the force that is felt by the user can only be transferred to the user hand through the drumstick, and this only happens when the drumstick is in contact with the drumpad. Therefore, all the necessary force and movement of the drumpad only matters during this split-second moment and the remaining response of the drumpad does not contribute to the feedback felt by the user. So, we need to program the motor to give an impulse force at the instant the drumstick hits the drumpad, where the impulse response of the drumpad is similar to the waveform we recorded from the tom and snare earlier. Particularly, we are looking for the amplitude of the drumpad's maximum acceleration to match with the first few part of the waveform data.

First, we need estimate how much current is needed to produce the necessary acceleration, which we need roughly 0.5 g (5 m/s²) based from our waveform data. We got the mass of the motor's plate from our parametrization of the motor constant, which is 115 grams. From these values, we got that the current required to actuate the motor at that acceleration to be 170 mA. The power supply we used can produce more than 250 mA, which is more than enough for our design.

After we get the initial displacement from the hit and the impulse force, we use position control to get the drumpad back to its original position. We were thinking of using a PD control to match the decay rate of our recorded waveform. However, when we tried normal proportional control we actually get a decaying system, which settled down quite fast. This means that our system also has a damping inside it, which makes this a 2nd order system if we use proportional control. Since the proportional control worked, we decided to just use proportional control for our system. The block diagram for our control system can be seen below.

Figure 1: System's Block Diagram

Now with our mechanical control done, we need to get the sound to work. We used the Arduino to send MIDI signal into Pure Data (pd) through a MIDI USB port. We set the the program inside pd to run a sound file (in the case we used for the expo was snare) whenever Arduino registers a hit. You can see what the pd interface looks like below.

Figure 2: Screenshot of the pd Interface

Construction and Issues

Once we obtained all of our laser cut components we began construction. A picture of our early base assembly can be seen in the diagram below.

We encountered a number of issues with our final design. First, as you can see in the picture below, the center component was created from two wooden pieces.




These pieces were drilled into another wooden piece at the base of the movable motor component. The issue we had was connecting this piece to the virtual drumhead. We wanted to make this connection as strong as possible to sustain most drum strikes. At first we thought wood glue would be strong enough but after our first final assembly and trial hit by another group we needed something sturdier. So we bought some metal brackets and were able to drill holes in the sides to allow for bolts to hold the connection together. This was working great until half way through the expo when the bolt started to become loose and didn't have the correct wrench to tighten them. The vibrational feedback response became more than we desired.

Now for the electronic assembly we attached a hall-effect sensor to the side of wall which needed to be sanded out for the tight fit. Then attached to our center posts we attached a strong magnet from RadioShack. A zoomed in view of the sensor and magnet can be seen in the following figure.




The placement of the magnet was important to get the maximum range of the sensor. Once all of these issues were solved we moved on to connecting the drumhead to the brackets. A final assembly of our device can be seen in the figure below.




Wood glue was used to finalize the assembly as well as dowel pins to attach a rigid rim to the base components. Another important issue to note is that we had planned on using FSRs to record when and where a drum strike would occur. After many trials we determined that these sensors would not be feasible to sense a strike. It occurs so rapidly that hits would only be recorded if you help it there for a few milliseconds, which would not be a realistic device. So after much discussion we decided to add another hall effect sensor at the center of the head and add magnets to each stick to sense each strike. A picture of our drumsticks with the added magnets can be seen in the figure below.



Similar to the idea of multiple FSRs discussed in our proposal there is room here to add multiple hall effects around the outside of drumhead. Unfortunately, due to the late recognition of our hall effect problem these added sensors were not added. To dampen the sound of a drum strike on the wooden board we decided to use a felt pad which you can see in the results section of our blog.

Design

While we were characterizing each drumhead response we were also designing and creating a support for our voice coil. After using calipers to ensure a tight fit for the motor we created CAD models of support system using Catia. You can see in the following diagram an assembly of just three supporting components for our drumstand.

We decided to use a 3mm thick wooden board for material and create notches in each side so they would snap together. To cut each board we decided to use the laser cutter found in the graduate shop. For our first time cutting our parts we overlooked an important factor. The laser cuts an extra half a millimeter for each side so we were producing parts that did not fit as snug as we would have liked. The great part about the laser cutter we found was that it took at most 10min to cut each individual part. Most of our time was spent creating the .dxf drawings for Correldraw. A picture of the final .dxf drawing we used for the laser cutter can be seen below.
After about two more trials we obtained our final components that fit tightly. The assembly and electronics will be discussed in the construction section.

Characterization

For our initial analysis we decided to first measure the vibrational response of a drum stick strike on a conventional drumset. However, we first needed to characterize the voice coil given to us by Prof. Gillespie. Below shows how the force provided by the voice coil varies with current. The slope of the line is used as our motor constant (16.74 N/A). The y-intercept of the graph (-1.1287 N) corresponds the weight of the armature and internal friction. A current of nearly 70mA must be supplied to overcome this load. The winding resistance of the motor was measured to be 8 ohms and the inductance was neglected. Damping for a linear motor is exceedingly difficult to measure. Since there armature does not rotate, the conventional measure for damping, observing the oscillation decay, is not possible. The motor came equipped with bearings, and given the weight and orientation of the armature our team decided to neglect measuring damping. Instead damping was left for tuning in the closed loop system.



Next, our team set out to measure the force and oscillation of a drum. This test was done using an ADXL 203 accelerometer and LabView. We encountered some issues here with sampling rates for various components which vibrate at a minimum of 30 Hz to 5000Hz. Our research shows that bass drum have the lowest frequency and the cymbals tend to have the highest. So we decided to test the toms which have the second lowest frequency range of around 50Hz to 2kHz and the snare drum with a frequency range of 70Hz to 2kHz. Our initial problem was that the LabVIEW was not sampling anywhere near the acoustic frequency range output of the drum. Our LabVIEW code was stripped down of all the Express VIs in an effort to run faster. Our final LabVIEW, which achieved sampling rates of 1 kHz (the maximum allowable for computer sampling) is shown below. Prof. Gillespie had mentioned using a microphone and the PCs internal sound card to capture data at an even higher sampling rate. However, the changes to our VI seemed to work fairly well for the low frequency drum components.



Eventually, after many trials and error we were able to achieve a sampling rate close enough to the frequency of each drumhead. The following plots show the response we recorded and imported into Matlab for analysis. Data was captured on three axes, where the Z axis was orientated perpendicular to the drum membrane and the X and Y axes fall in the plane of the drum membrane. Note that similar vibrations were captured in all directions but vibrations in the Z direction are the most pronounced. Our team decided to only replicate the vibrations in the Z direction, since our motor could only actuate in one direction and this was the most important to user force perception.

Then using this data we were able to determine the decay rate and peroid of oscillation. From these values we were able to determine the transfer function below and produce a simulation of an impulse response. The time for decay and peroid of oscillation compares well between the data and the model. The scaling is off because the MATLAB produces and ideal impulse (infinite intestiny, zero pulse duration).

Proposals

To kick off our Final Project, we were asked by Prof. Brent Gillespie back on October 1st, 2009 to provide individual project proposals. After reviewing each we were placed into groups according to similar ideas. Our groups had the similar idea of a wireless drum stick and high bandwidth drum head response. Although each of our ideas varied we were able to compile important features of each into a final design idea.

In Scott's first proposal he mentions that "standard drum kits are very large and difficult to transport. The main advantage of the proposed instrument is that it is portable, which would allow musicians to practice and perform in any environment." As you will see in our design our intention to make a smaller drum set that is portable is possible. Although we all agreed on using MIDI as the musical interface to our synthesizer he also contributed the idea of using "either a Hall Effect sensor or potentiometer" to measure motor position. This idea came in handy when we encountered our first setbacks which we will mention later. A diagram of Scott's proposed idea can be seen in the figure below. There were also a few ideas implemented from Mike's first proposal. He suggested that we used force sensing resistors (FSRs) oriented specifically on a drum pad to sensor where a drum stick would hit. This information is important for sound because with conventional drums the closer to the rim you strike the higher the pitch or frequency. As you will find, this idea was implemented during part of the development process but was eventually removed due to poor sensing capabilities of the FSRs from a drum stick strike. However, with our final design there is still room for improvement to mimic this positional convention. Being a drummer himself, he was really interested in achieving "vibrotactile feedback for electronic drum pads because it could lead to improved use of fine control. Allowing the user to feel vibrations of the stick through this design will improve performance during rolls and flams (fine control beats). " A picture of his design from the first proposal can be seen below.

Eric's project idea to develop an "electronic MIDI drum set with variable stiffness and damping" was very similar to our combined final design. He makes the important point that "currently, most of these electronic drum sets are made of rubber pads for all of its components, which makes hitting all of these different drum components actually feel the same. The goal of this project is to design and create a haptic interface between the drum pads and the user so that each of these pads gives different “feel” to the user based on the mechanical response it produces." As you will see in our final design we used many of the important concepts Eric mentions here. He also suggest we use position and velocity sensors to control the "virtual" stiffness and damping of the haptic interface. A figure of Eric's proposed idea can be seen in the following diagram. We compiled all of our ideas and came up with the following design shown below. We decided to use a linear actuator (voice coil) provided by Prof. Gillespie and sense position using a hall-effect sensor. Then through a unanimous decision use MIDI and an Arduino to provide feedback through a synthesizer to the human user. The response of the drum head will be determined through initial characterization of a conventional drum. This system identification was to be conducted using LabView and a MEMS accelerometer. Then through modeling we proposed we could implement these effects virtually.

With this design there we provided important force analysis diagrams and equations which you can see below. In our second proposal we mentioned that "interactions with a stick and drumhead can generally be characterized into four different stages. These four stages are shown below along with their respective dynamic models. In the first mode the drumhead is initially in its stable configuration before the stick has struck its surface. The second stage occurs when a stick is in direct contact with the surface for a short period of time. Then once the stick is removed the head continues to vibrate, which is the third stage. The fourth and final stage can be classified as a complex interaction of an already vibrating head and a new stick strike. Each of these user interactions can be described in a quantitative manner as you will in the following diagrams."

Final Project: Team Members

Scott Bartkowiak
Mike Luginbill
Eric Sihite

Lab 6: Day 3

The third day we came in we decided to completely revamp our controller to LabVIEW. We first connected analog in and analog out pins to the same low pass filter we set-up the day before. Next, we created a .vi that simulated a signal of random white noise voltage out to the circuit. We also programmed the .vi to accept and write input voltages from the capacitor in the circuit. Then, we wrote each input and output voltage into a measurement .txt file. Finally, we were able to pass this data into Matlab where we ran the tfestimate command and were able to obtain somewhat reasonable results. The low pass filter results of can be seen in the figure below.

Note that the data does not fit well with the expected response. The cut off frequency and the dc gain agree well, but the roll off rate is significantly higher than expected. Hours were spent trying to track down the bug. Sampling rate, number of samples, resistors, capacitors were all varied and this was the best response we were able to generate. After exhausting all of our resources and spending several hours changing random parameters our team decided to table this aspect of the project and seek assistance from our instructors.

Lab 6: Day 2

The second day we came into the lab we had a better sense of some solutions to our problem. After obtaining the serial port error we were told to completely close Matlab and then reopen it. Surprisingly this solved our problems. From this point forth we could repeatably communicate between the Arduino and Matlab.

Once this communication was established we continued to rig up a low pass filter in a RC circuit. A circuit diagram of our set-up can be seen below. For the given values we determined a cut-off frequency around 169 Hz. Using these values and a sampling time of 1msec we ran a Matlab simulation of what theoretically should happen with the empirical model when we send in random white noise. The following figure shows the expected theoretical results obtained solely in Matlab.

As you can see in the above low-pass bode plot the response tends to taper off near higher frequencies which is what we expect when we send this circuit random noise.

Our next step was to repeat this process using Matlab and the actual RC circuit we built. However, we again began having troubles communicating between the two systems. Serial ports were closed and recognition was of the Arduino was not happening so again we decided that it be best to sleep on it.

Lab 6: Day 1

The first day in the lab was to say the least, difficult. We started out by running the provided Matlab code and testing out different transfer functions, record lengths, sampling frequencies, and nffts. We noted that for second order systems decreasing the sampling time below 0.1 msec or above 32msec tends to produces undesired results if none of the other parameters change. Also, if you return to default conditions and decrease the nfft value skewed data results. However, it was found that increasing nfft really high did not play as significant of a role. Of course, increasing or decreasing the record lengths changed the length of sampling time in addition to providing a more or less continuous curve.
After these effects were acknowledged we continued onto establishing a communication with the Arduino and Matlab. Here is where the difficulties begin. After we uploaded the SerialCallResponse.pde into the Arduino and then closed it, we ran SerialCallResponseSim.m to run the echo function. The problem was that after running the first time correctly, it would say from then on that the serial port was closed. After much debugging and errors we decided to continue at another time.

Lab 6 : Team Members

Scott Bartkowiak
Mike Luginbill
Eric Sihite

Lab 4 - Methods

Op Amps:

The initial op amp was constructed to amplify the signal of the hall effect sensor. A gain of 21 was chose to provide over 800 analog input points to signficantly improve the resolution of the motor position. A second op amp, the differentiator, was used to serve as a velocity sensor for the motor by differentiating the position signal.

One problem we encountered was the grounding of the single rail op amp chip. A virtual ground had to be constructed in order for the chip to work. This was done through the implementation of two resistors.

Results - MIDI Interface

Our modified Arduino MIDI output code was combined with our Virtual spring code to implement a one key keyboard with haptic feedback. The tone was based on the motor position, with feedback force increasing the further the motor armature was pushed from the center position. With the armature in the correct position the player would press the blue touch button (key) for the tone to be emitted from the computer speakers. You could also flick the motor and press the button while the armature oscillated to produce a variety of tones.

The Arduino sent the serial data with a value of 0-127 (based on the Hall Effect Sensor) to the PureData software, which translated the data into a sine wave with a frequency of 440 Hz assigned to an Arduino analog value of 69. A range of 0 - 10,000 Hz coulb be achieved in this design.

The two videos below show how our sensor with force-feedback emitted tones out of the computer speakers through the midi interface. Now there is two different kinds of force feedback for tones with pitch higher than the reference (middle position of the motor) and with lower pitch than that. It would also be possible to implement a different spring stiffness for each tone which would allow to feedback every pitch seperately.




This video shows our accelerometer which replaces the motor as a sensor as shown above. Here there is one axis enabled which is the x-axis. The results were quite satisfying and it is fun playing this instrument while getting feedback to the acceleration of the hand.


While rebuilding our sensor circuits on the arduino board we faced some problems with the new hall effect sensor. These were due to the inhomogeneous magnetic field or the nonlinear sensing of the device. We tried to find different applicable positions of the magnet but found that the standard position in "pushing"-mode was actually the best because other positions made the field very inhomogeneous in normal direction. Although the sensor values on the arduino ranged from 1 to 800, the middle position had an average value of 600.

Lab 4 - A Musical Motor

In the past lab we constructed a home brewed motor, with a hall effect position sensor. This week we upgraded our motors with higher resolution sensors, added op amps to serve as amplifiers and differentiators, and finally interfaced our Arduino with PureData to turn our motors into haptic feedback musical instruments. The virtual interfaces previously designed have been re-implemented with a true differentiator, rather than Arduino code, and with higher resolution. The virutal spring and virtual damper were re-tuned to feel even more realistic than before, thanks to the addition of op amps. The Arduino produced MIDI signals, correlated to a motor position, which were translated into audio waves by PureData. Haptic feedback was provided through the motor with the use of a virtual spring. The force of haptic feedback varied with the change in melody.

Lab 4 Team Members

Cameron Greybeal
Frank Sandner
Jonathan Williams

Lab 3 - Virtual environments

Virtual Spring:

Implementing a virtual spring environment was the equivalent of adding a feedback loop through the whole motor system to do position controller. With the proportional control, the controller force is simply directly proportional to the displacement from equilibrium, just as a spring is. Therefore, this virtual environment was working once we got our position controller functioning. A (sideways) video shows below that the force was indeed a function of the armature displacement.

Virtual Damper:

Implementing a virtual damper was done similarly to the virtual spring. The only difference was that the controller force was proportional to the derivative of the position signal rather than the position itself. Since we only had access to the Hall effect sensor signal, to get the derivative we had to perform numeric differentiation in the Arduino software. By taking position measurements of θ₁ and θ₂ at t₁ and t₂, the derivative is estimated by:

The controller force is then proportional to this value in the opposite direction.

In practice, we were unable to get an effective damper working. The Hall effect sensor only had a range of roughly 20 values over the range of the arm movement and would continually fluctuate, even when the arm was held perfectly still. This translating to the controller thinking the arm was perpetually moving back and forth violently and so its corresponding response caused the arm to vibrate significantly. Furthermore, if the controller gain was too high, the vibrations would be amplified, resulting in an unstable system. The net result was that when we ran the motor with a low enough gain to be stable, the response to our input movements was not high enough to be felt significantly stronger than the continual vibration in the system.

Virtual Mass-Spring Attachment:

The final virtual environment involved simulating a mass attached to spring that was also virtually connected to the motor armature. The equation modeling this environment had been worked out in the homework and we simply needed to translate it into the Arduino code. The end result worked by tracking the force on the virtual mass and integrating it twice to obtain its position. The position was then compared to the armature position, defining both the torque on the armature and the mass at the current time step.

By tuning the values of the mass and spring, we were able to get a good response in the motor that could easily be felt. The most intuitive settings were a relatively high value for the mass and a low value for the spring stiffness. This led to a high oscillation time period, during which the trajectory of the mass could very clearly be felt in the armature as it both stretched the spring out to maximum displacement and crossed over the center point, switching the torque direction.

Lab 3 - Motor controllers

PID

In addition to simple proportional control, we also were able to implement a full PID controller. For the I and D components of the PID controller we were forced to numerically differentiate and integrate the Hall effect sensor reading. Differentiation was done by computing the difference between successive sensor readings divided by the time period between them and integration was done by adding the current position error multiplied by a time interval to a running sum of the cumulative error. It turned out that the integral was far more stable that the derivative control due to the noise in the Hall effect. The integral controller also had the benefit of removing steady-state error in the arm position, but did have the disadvantage of a much slower response time, especially when a significant amount of error had accumulated, as can be seen in the video below.




Detent

The detent controller was designed to simulate a hard stop in the arm movement that could be passed over with enough force, similar to plucking a taut string. To implement this, we specified a small region in the center of the motor's workspace where a large torque was exerted away from the center. This was a simple discontinuous function that jumped to a high value in the detent region and was zero everywhere else. The net effect was a force strong enough to push back the arm unless a large external torque was applied, allowing the arm to "jump" over the detent and return to equilbrium on the other side of the workspace.

Lab 3 - Frequency response

We were also able to evaluate our motor system in terms of its frequency response. To do this, we removed the position control from our model, resulting in a simple forward path transfer function:

V_pwm corresponds to the duty cycle of the PWM signal being sent to H-bridge which acts as the input to the motor system. V_pwm was output from the Arduino board as a sine wave of varying frequencies and amplitudes. The minimum frequency we could take a valid reading at was 10 rad/s with a duty cycle value of 3.5 out of 255. This was the minimum value to overcome friction in the motor and at any lower frequencies the gain was high enough that the motor would reach the edge of its workspace. We took several data points over a frequency range up to 100 rad/s, with a maximum PWM output value of 40. For each frequency and amplitude combination we collect data points from the Hall effect sensor and measured the resulting amplitude in position. The two amplitudes were then divided to find the gain in each case. The resulting comparison is shown below.

The data clearly has similar behavior to the model with the major difference being an offset in the gain. This is most likely due to an incorrect characterization of one or more of our gain values.

Lab 3 - Motor model and theoretical behavior

Given the differential equations governing the motor system behavior, we were able to create a Simulink model of the system, following the general idea of the block diagram models discussed in class. The key element of the model is the element representing the motor mechanical dynamics which takes a torque as an input and outputs the resulting speed. The torque is determined by a series of gains starting at the Arduino PWM signal duty cycle value, which is converted to an effective voltage seen by the motor by the H-bridge and then further modified by the resistance of motor wires and the torque constant. Additionally, there is also feedback from the motor speed in terms of back EMF, but as we were almost always operating the motor at stall, our model assumes no back EMF feedback (K_m = 0). Finally, there is an additional external feedback loop which takes the integrated velocity output (in reality, measured by the Hall effect sensor) and feeds it back to perform position control. There is also the potential for a load torque on the armature, which acts as a disturbance to the position controller, but in our case the only load torque was gravity, which was negligible for the motor in vertical position.

To validate the model, we performed both a simulation and an experiment of the motor response when commanded to move to a position of 5 degrees with a position controller gain of 5. As can be seen in the simulation, the net result is a highly underdamped system that converges to the desired position after roughly 5 seconds. When the actual experiment was performed, we found that the motor immediately moved to the desired position and then stayed there with little to no extra oscillation beyond the Hall effect sensor noise. This difference was mostly likely due both to non-linear effects of the friction in our motor, and the poor quality and extreme quantization of the Hall effect sensor.

Lab 3 - Motor Characterization

J

We estimated the inertia of the motor armature through the use of a bifilar pendulum. This method involves hanging the ends of the arm by two long strings and measuring the time period of small angle oscillations in the horizontal plane. This gives the moment of inertia about the point halfway between the hanging strings, or the geometric center of the arm, through the relation:

Where m is the arm mass, g is gravity, r is half the distance between the hanging strings, h is the length of the strings, and T is the time period of a single oscillation. All of these values were easily measured with the time period taken as one tenth the value of the time required for 10 oscillations. As the resulting inertia is about the geometric center of the arm, two applications of the parallel-axis theorem are required to find the inertia about the axis of the rotation shaft. First, the inertia is translated from the geometric center to the center of mass and second from the center of mass to the shaft axis. This required knowing the distance between these three points. The geometric center and shaft axis were easily measured, while the center of mass position was found by balancing the arm on a fine edge. The net result for the inertia about the motor rotational axis was therefore found to be J = 5.64 x 10^-5 kg•m² or J = 564 g•cm².

B

To find the damping coefficient of the motor, we ran an experiment where we attached a relatively large weight to the armature, held the motor vertically, and let it oscillate as a pendulum. Assuming small angle oscillations, the equation of motion describing the arm behavior can easily be derived from a standard 2^nd order rotational mass-spring-damper system. Using the Hall effect sensor to estimate position, the results of our test appear below with the peaks of the oscillations describing a exponentially decreasing function:

H₀ is the initial Hall effect reading when the arm is released and H_C is the reading at the center when the arm is completely vertical and at equilibrium. Pulling out the data of just the oscillation peaks to measure the rate of decay, the values can be modified to fit the modified equation below, which is conducive to a linear fit.

The linear fit was then done on these data points, resulting in a value for T of 1.24s. From the equation of motion, T = J/b and compensating for the change in J from the mass added to arm, a value of b = 9.1 x 10^-5 N•s/m can be calculated.

K_t

To find K_t, we mounted the motor sideways on the table and hung various weights off the end of the armature. The voltage at the power supply was then slowly increased until enough current was flowing to produce enough torque to suspend the weights. We then were able to collect the data points measuring the current with a multimeter and knowing the torque produced on the motor by the weights. As can be seen in the plot of our data, the data points do not tend towards the origin, but rather a point of no current and non-zero torque. We believe this the static friction inherent that has to be overcome before lifting the weight and so we ignore the offset and simply use the slope of the linear fit as our torque constant. This value was K_t = .01562 N•m/A.

R

R was found simply by using the multimeter to measure the resistance in the motor wire. We measured a value of R = 0.4 Ω.

Lab 3 - LabVIEW Interface to generate sound

A part of our lab experience was connecting the aruino and the motor with a LabVIEW environment. We used LabVIEW to receive a signal sent by arduino and play appropriate tone of sound. We used the detent mode to replicate the guitar string. Once the user plucks the string (goes over the detent window) a digital signal is sent to the computer. The LabVIEW VI interprets the digital signal and generates a short sound with pitch controlled by the location of a potentiometer which is connected seperately to the LabVIEW. The block diagram and front panel screenshorts are shown below.



The VI runs on an infinite loop with sampling frequency of 1 kHz. Once a digital signal is received (the digital input voltage goes from 0 to 5 V), the DAQ system sends out a True signal to the case structure. Inside the case structure is Play Waveform.vi which generates a sound with certain frequency (note) provided from somewhere else. Of course the False case doesn't do anything. The frequency (note) is determined by the voltage output from a potentiometer. We wrote the model in a way so taht the potentiometer voltage output (0 to 5 V ) is translated to the frequency range of 220 Hz and 1220 Hz.

The front panel is made to give visual feedback of the sound generation. The LED shows whether the sound is played or not while the waveform chart shows the musical frequency.

Here is the final result of the interface in action:

Lab 3 - Motor Construction and Control

Some of the motor parts weren't as perfect as we wanted, so we ended up damaging the motor parts while we were characterizing the motor properties. However the deligent GSI, Hasan, was there to supply us spare parts. We followed the iTouch motor assembly instruction provided to us. The majority of the time was spent on reducing the friction between the rotor and the housing. The friction was minimized by the generous use of spacers/washers and multiple reassembly trials. The total number of wire winding was 22.

We used the sign-magnitude method to control the motor speed. We were not able to control the motor torque as we had no way to control the current flowing in the system. Arduino conveniently provided the sign-magnitude method capability via its analogWrite function. The H-bridge assembly (Pololu motor controller) was used to control the motor. The PWM signal and the direction signal were sent from Arduino. The both signals were in digital inputs and their magnitudes (high or low) determined the speed and direction the motor would rotate.

The controllable variables were the direction and motor speed and the feedback available from the motor was the rotor's relative location determined by the hall effect sensor mounted in the middle of the pendulum. Using these resources, we were able to implement multiple control strategies (P, PI, and etc) to achieve our goals throughout the lab experience.

Lab 3 Members

Josh Langsfeld
Amit Ranjan
Deokkyun Yoon

Lab 2 - Reading Sensors/Microprocessor & PC Interfacing

Team Members:

Deokkyun Yoon
Frank Sandner
Piyush Soni
Takumi Jinmon

Our own Theramin!

Theramin is a musical instrument which seems to be controlled by hand movement of the user. It works on the principles of proximity sensors like hall effect sensor and the photoresistor to name a couple. To the uninformed, this device has a mystic charm about it!

All our tasks in this laboratory were built up so that we could finally make our own Theramin! Initial task of checking each sensor proved instrumental in choice of sensors for the musical device. We understood the working of each of the sensors and made a note of their capacity to produce a change in signal. After these inspection, it was decided by common consensus that we use a photoresistor and a force sensing resistance in our device. The former would control the pitch of the device while the latter provides volume control. We chose these over others as they seemed to provide the maximum range of output.

A rough circuit was built to begin with and we got on the task of writing appropriate code to control the sound of the device. Simultaneous experiments on the device provided us with immediate feedback on the code which would then be modified to incorporate stuff/music which we found missing. Final circuit was built neatly when we were satisfied with the quality of output music.

Now it was the time to work on the packaging of the device and also thinking about the human interface. A cardboard box which would be just big enough to hold Arduino board and the bread board was luckily found and we made some subtractions on it to make way for the speakers, switch and the sensors!

The design is such that the user can control the switch and the volume contol (i.e. Force sensing resistor) with one hand while the other one can be used to control the pitch of the instrument (i.e. Photoresistor).

The device was tested in the ambiance of the lab and seemed to work great! The accompanying code on the Arduino is such that it gives the user a feedback as to which note is being played and we could see the various notes by covering the light on the photoresistor. (See attached video)

Lab 2 Arduino Codes and Plots

Here's the Arduino code for our instrument. Basically, the user input from the phtoresistor is read by Arduino and a musical note is assigned. We made eight bins where the input signal can fall into, so it's easier to pick up a note when we play the instrument. However, this can be changed and the musical note (frequency) can be continously varying by simple scaling of the input signal instead of quantizing. We also have a digital input via a mechanical switch, which plays the assigned note only when the switch is closed. As long as the switch is closed, the musical note will be fixed at the frequency when the switch is pressed and the sound will be played continously. Lastly, the sensor read out is transferred back to the computer where a user can see the sensor read out value and the assigned musical note.

Below the code is an example plot for the photoresistor sensor readout.


-----------------------------------------------------------------------------
int speakerPin = 9;
int sensorValue = 0; // value read from the pot
int outputValue = 0; // value output to the PWM (analog out)
int switchValue = 0; // switch to turn on or off the sound
const int analogInPin = 1; // Analog input pin that the potentiometer is attached to
const int digitalInPin = 22;// Digital input pin that the switch is connected to


int length = 15; // the number of notes



void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
pinMode(speakerPin, OUTPUT);
}

void playTone(int tone) {
for (long i = 0; i < 1;) {
digitalWrite(speakerPin, HIGH);
delayMicroseconds(tone);
digitalWrite(speakerPin, LOW);
delayMicroseconds(tone);
if (digitalRead(digitalInPin) == 1){
i=1;
}
}
}

void playNote(char note) {
char names[] = { 'c', 'd', 'e', 'f', 'g', 'a', 'b', 'C' };
int tones[] = { 1915, 1700, 1519, 1432, 1275, 1136, 1014, 956 };

// play the tone corresponding to the note name
for (int i = 0; i < 8; i++) {
if (names[i] == note) {
playTone(tones[i]);
}
}
}



void loop() {
for (int i = 0; i < length; i++) {
sensorValue = analogRead(analogInPin);

// map it to the range of the analog out:
char note;
if (sensorValue < 600) {
note = 'C';
}
else if (sensorValue >=600 & sensorValue < 638) {
note = 'C';
}
else if (sensorValue >=638 & sensorValue < 676) {
note = 'b';
}
else if (sensorValue >=676 & sensorValue < 714) {
note = 'a';
}
else if (sensorValue >=714 & sensorValue < 752) {
note = 'g';
}
else if (sensorValue >=752 & sensorValue < 790) {
note = 'f';
}
else if (sensorValue >=790 & sensorValue < 828) {
note = 'e';
}
else if (sensorValue >=828 & sensorValue < 866) {
note = 'd';
}
else if (sensorValue >=866 & sensorValue < 900) {
note = 'c';
}
else if (sensorValue > 900) {
note = 'c';
}
if(digitalRead(digitalInPin) == 0) {
playNote(note);
}


Serial.print("sensor = " );
Serial.print(sensorValue);
Serial.print("\t output = ");
Serial.print(note);
Serial.print("\t switch = ");
Serial.println(digitalRead(digitalInPin));
}

}
-----------------------------------------------------------------------------

Lab 2 Circuit Diagrams

The first step to become familiar with the Arduino Microprocessor was to set up a program in Arduino C-Code and load it to the device. As a first task we produced a digital output, which switched on an LED in a formerly coded rhythm. A video of this example can be seen below.



As a test for higher loads on the output circuit we connected a servomotor and controlled its rotation via Arduino. In order to achieve a higher current we built up a transistor circuit with an additional power supply:



The video below shows the rotation of the servomotor controlled by arduino microprocessor.



The next step was to test our sensor devices such as a photoresistor, a force sensing resistor and a hall effect sensor. First we tried to apply them as digital sensors. Therefore we set up a voltage divider with the sensors as adjustable resistance. With some of the resistors it was quite well possible to achieve a analog signal whos range covered digital 'on' and 'off' strength. In a next step we figured out the range of analog input signal, their accuracy and controllability. The circuit diagrams for those sensors can be seen below.







The analog application of the photoresistor and the force sensing resistor as a sensor can be seen in the video below.




In the next step we faced the challenge to write analog input signal to EEPROM and read it with the scope.



Now that we had become familiar with the arduino i/o ports and the coding in arduino c-code we wanted to access its pins through LabVIEW. We faced some data conversion problems (string vs byte) but finally fixed them and we were able to control the frequency of a square wave function at a digital output port. The program for this function had been loaded to the microprocessor before. We also managed to read analog input signals through LabVIEW. An example of how to control the microprocessor through LabVIEW can bee seen below.



At this point we had all necessary knowledge about our devices to build up a "Thevenin-like" musical instrument. We programmed a connection between analog input and output ports in order to be able to control a speaker by adjusting the above mentioned sensors.
Here you can watch the video of our final Thevinin instrument: