Wednesday, October 21, 2009

Lab 4: A Haptic Interface for Musical Expression

Team members for Lab 4:

John George

Huai-Ning Chang

Michael Woon

Goals:

The objectives for this lab include testing new Hall-Effect sensor with virtual spring and virtual damper, use Op Amp as differentiators, and building a haptic musical instrument with MIDI interface.

Accomplishments:

Comparing the performance of new Hall-Effect sensor to the old one, it was found out that new Hall-Effect sensor was more powerful than the old one. Unfortunately, our new Hall-Effect sensor blew out by accidentally shorting the pins, so basically we completed our lab with the old Hall-Effect sensor, amplified through the Op Amp.

The implementation of the Op Amp increased the analog signal range to the Arduino controller, improved resolution, and reduced chattering. Unfortunately, as we were about to use the Op Amp as a differentiator, our old Hall Effect sensor started acting erratically (see below). But the Op Amp circuit we designed and tried to implement is shown as the modeled system in Matlab. There was a final step that we did not actually do, and that was to put a gain on the output by ~1000.



To build a haptic musical instrument from analog input, we first made a file for Pd to read MIDI signals from Arduino. Different notes come by writing serial data from 30 to 90, with the appropriate nibbles (ex. 0x90). The Arduino programming code is as follows:

const int LEDpin = 13;
const int Sensor1Pin = 1;
const int den = 8;
// Variables:
byte note = 0;
// The MIDI note value to be played

void setup() {

// Set MIDI baud rate:
Serial.begin(31250);

pinMode(LEDpin, OUTPUT);
}

void loop() {
// play notes from F#-0 (30) to F#-5 (90):

note = analogRead(Sensor1Pin)/den;

//Note on channel 1 (0x90), some note value (note), middle velocity (0x45):

noteOn
(0x90, note, 0x45);

digitalWrite
(LEDpin, HIGH);

delay(10);

//Note on channel 1 (0x90), some note value (note), silent velocity (0x00):
noteOn
(0x90, note, 0x00);

digitalWrite
(LEDpin, LOW);
delay(10);
}

// plays a MIDI note. Doesn't check to see that

// cmd is greater than 127, or that data values are less than 127:

void noteOn(byte cmd, byte data1, byte data2) {

Serial.print(cmd, BYTE);

Serial.print(data1, BYTE);
Serial.print(data2, BYTE);

}


Unfortunately, after the new Hall-Effect sensor got shorted, our old Hall-Effect sensor started acting erratically, sometimes getting stuck at max output voltage. We could power down and power up the sensor and it would work, but eventually it started producing a constant 2.4V output. With no other sensor hooked up to our motor, we had to improvise and come up with another input sensor for the human (which unfortunately did not provide active force-feedback). Our instrument schematic is shown below.



By connected to MIDI and with the circuit, we can play different notes by applying different force to the sensor. Following is a video of the concert:



Just a note about using the force pad: Earlier we used to force pad to modulate volume in the Theremin Lab, and we found that it worked very well. It had great response and could easily be learned. In this lab, we used the force pad to modulate pitch, and we found that did not work as well as, say, a sliding potentiometer or some sort of position-based input. The force required to sustain higher notes was uncomfortable, the resolution was too high so it was easy to miss notes, and you always have to "ramp up" to the note you want.

Thursday, October 15, 2009

Lab 3B - Frequency Response and Virtual Environments

Objective: The objective of this lab was to implement variuos virtual environments using our iTouch motor and the Arduino software.

More simulations: We modified our earlier version of the motor simulation and replaced the current-controlled H-bridge witha simpler amplifier model that assumed rejection of back-emf effcts. This basically meant that we could get rid of one of the feedback loops and represent our model as such:



We found the transfer function of our system to be:



The corresponding Bode plot of this plant is:

After creating a Bode plot of our system, we injected sinusoids of various frequency into our system and recorded the response displacement. Note that the sinusoidal displacement of the motor (red) has a phase shift when compared to the input signal (blue). If one cycle = 2*pi, we found that the phase shift was approximately 1.51 radians, or 86.4 degrees. The frequency of our input signal was 0.2 Hz, so this phase shift corresponds with our Bode plot.


Virtual Haptic evironments:

This was one of the coolest parts of the project wherein we were supposed to replicate the feel of mechanical elements on our i touch motor.

Virtual Spring: In this exercise our aim was to introduce programmable changes to make the i touch motor feel like a spring. We used the position sensor to implement this environment. Based on the position readings from the hall effect sensor, a translation formula is applied to make the range of readings symmetrical on both sides of the center position of the armature. The program is tweaked to make the pwm value higher as the armature moves out on either side of the center position. This makes the user feel that the armature has stronger tendency to bounce back as he/she is moving it out further and hence it acts as a virtual spring!

We had initial hiccups in this exercise wherein we were able to replicate the spring feel on one side but not the other.. It was happening because of a negative pwm feedback on one side which when corrected behaved exactly as anticipated.

Virtual Wall

This was relatively simple environment to simulate once we got the virtual spring working. One position on either side of the center is chosen arbitrarily as the "wall" and the program is modified to make the motor go really stiff at those positions. We have a very high pwm value at this junction in the code which makes the armature vibrate insanely if one tried to force it beyond that point which makes the Virtual wall!!
Virtual Damper and Virtual spring-mass

A derivative control is applied in the code to get the virtual damper simulation. The concept is based on the theory that the armature should make the user feel variable resistances depending upon the applied speed on the armature. We collect the position of hall sensor every 50 ms and then calculate the velocity from that array of readings. This velocity reading is then used to control the virtual environment of the damper using the principle: the higher the velocity, higher is the impedance experienced by the user. We did implement the program for virtual damper but are not completely sure if we could replicate the feel. It was kind of difficult to sense damping if there was any and we were not able to judge objectively.

Due to time constraints, we were not able to simulate the virtual spring-mass system.


The most rewarding environment, we felt was the virtual spring. The force did increase in a linear fashion in the program and we could feel that increment in force as the armature is pushed on either side. The easiest to simulate was a virtual wall which was kind of fun too. You felt like you have just been electrocuted because the fingers start vibrating due to the offered resistance by the motor! The most difficult to feel was the virtual damper as damping was too subtle to feel. It was not a challenge from programming point of view but it was certainly hard to feel the damping. Maybe that is because of the low resolution of the hall effect sensor..




Lab 3 - Overview

Overview:
The first thing we did was construct our iTouch motor. We decided to control our motor using the Arduino. We determined the physical and electrical properties of the motor, such as the motor constant, resistance, motor inertia and damping. We simulated our model using Simulink in MATLAB.

Motor Assembly:

The motor was constructed out of laser cut pieces of wood, magnetic wire, screws, and extremely hefty magnets. A picture of the semi complete motor is embedded below. The motor is not a traditional rotary motor. Instead it has ~70 degrees of motion. (A reliable commutator is kinda hard to make.)
The construction steps were incredibly easy, thanks to Hasan's hard preparatory work. The hardest part of assembly was winding the motor with ~ 114 winds of magnetic wire. (The windings are hidden behind the magnets. After that, all the parts fit into their spots relatively easily. Construction instructions can be found on the cTools site....

Motor Instrumentation:

Since this motor is not rotary it is relatively useless without some form of sensory input for position control. (Otherwise is is constantly at the edge stops...) To attain sensory control we put a Hall Effect sensor and magnet combination onto the frame. As the spindle moves the magnetic field would change and we would get a position reading. Sadly, the magnetic field generated was extremely low. We were only able to get a gradation of ~ 13 values on our 10 bit ADC. That resulted in ~ 7 degrees of travel per each adc reading value. This, as well as timing issues, would come to haunt us when we tried to implement a position controller.

We also attempted to set up a current sensor. A current sensor would allow us to perceive/control how much torque was being output by the system. This is because T=I*Km. The current sensor was a chip from Pololu that gave ~150 mV per each amp of current flowing through our motor. We initially thought that this value would be sufficient. However, our motor did not draw much current. So, once again the resolution on our ADC lead to issues when attempting torque control.
Simulation:
We modeled our motor as shown in the block diagram below:
For our model, we needed to find the values for the resistance R, moment of inertia J, motor constant Km, and motor damping b. We used a multimeter to determine the resistance of the motor windings and found that R = 10.1Ohms.

We found the moment of inertia by suspending the armature of the motor with two threads equidistant from the center of mass. We aligned the threads so the motor armature was level to the ground and provided a small torque about the vertical axis. We recorded the time it took for the motor armature to complete ten oscillations and used the equations of motion of a bifilar pendulum to calculate the moment of inertial. We found that J = 4.11e-5 kg m^2.

At first we found the damping of the motor bearings to be extremely high and we would not get even a single oscillation of the motor armature. However, after oiling the bearings significantly, we noticed that the motor armature completed about 2-3 full oscillations before coming to a stop. We also noted the amplitudes of the each oscillation, so we can use the logarithmic decrement equations to find the damping ratio zeta. We found that zeta = 0.015 and b = wn*zeta*2 = 0.368, where wn is the natural frequency of the pendular motor armature, determined by wn = sqrt(g/l).

To find the motor constant, Km, we applied several torques to the motor (by handing weights of known mass from it) and measuring the current the motor is drawing. Using this method, we found Km = 0.105.

Plugging these values into our model, and using a Kp=1, tauL = 0 and iDes = 1, we found our theta over time:

This output makes sense, since our motor is simulated as a simple rotary motor. This means that with a constant current input, it will rotate and theta will increase at a constant slope. However, it takes time to get up to speed, which is shown in the figure above. Note how quickly it manages to do so.

A better way of looking at our step response is by looking at the change in theta over time:

Proportional Control:


We implemented a very elementary P control on position. Using the Hall Effect Sensor and an adjustable target point we were able to tune the system so that it would reside there. As discussed earlier... our sensor inputs had extremely coarse resolution. Additionally, our controller had no sense of "real time." (We didn't implement a interrupt routine to guarantee timely and consistent execution of code) As such, the system tended to vibrate in place a lot. Additionally, we could feel definitive torque impulses when holding the rotor. These impulses could be from the coarse nature of the timing loop or that the electrical system does not completely filter the pwm input. As such, the torque would flicker. We also noted that using the serial port was an extremely expensive operation. The timing loop was slowed down a lot when that occurred; resulting in wider oscillations... more hectic responses... and a worse behaving system. Look at the video below!









Lab 3: DC Motor Control - Introduction

Project Goal: The goal of this lab is to construct our own iTouch motor and use a hall effect sensor, power supply and H-bridge amplifier to control it and simulate several haptic virtual environments.

Team members: Colin Foe Parker, Piyush Soni, Sasha Voloshina