Schematic of the system in interest

For our system we decided to use the motorized fader. We will be using this in our project as a way to mimic virtual guitar strings. A rough schematic can be seen in the image below.

The way the motorized fader works is by a rotary motor driving a belt that drives a slider. The slider has a potentiometer that determines the position of the fader. We will be using the position in this lab and in our future project.

The key parts that we are interested in is the voltage required by the motor to produce the desire feedback force at F_H and the position of the fader. The desired feedback force will be determined by the position of the fader. Therefore we wished to find the transfer function relating the input voltage to the position of the fader in this lab. The circuit setup with the physical motorized fader can be seen in the image below.

Lab 6 Overview

For the lab, we used a fader motor, as it is the component that we will be using to haptically simulate the strings of our virtual guitar. Given that we had not previously performed a system identification for this fader motor, we cannot provide a comparison with the experimental frequency response plot.

Though we cannot provide a direct comparison, we can make judgments based on our observation of the motor behavior and compare our experimental plot with those. For example, as is apparent by the fact that a sound comes from the motor when we run it, there is metal on metal contact, which leads to a great deal of friction in the system. Because of this friction, system identification should return an overdamped system. Overdamping was definitely the case for the lab.

For future purposes, we plan to perform a system identification by loading a variety of masses on the fader motor so that, in the long run, we can better understand the system instead of just making judgments and best achieve the behaviors we want for our virtual guitar.

Lab 6 Overview

1) Compare theoretical and experimental frequency response plots by placing traces on the same axes. Show these for your low-pass filter:

We built an RC low-pass filter with a 430 Ohm resistor and 2.2E-4 Farad capacitor. This should produce a 1st order system with a w_cutoff of 10.6 Hz. Below is our input and output plotted, which was submitted to TFestimate and produced the given Bode plots:

RC, Arduino, Matlab input/output
Blue: input white noise, Red: RC voltage output

Bode from TFestimate
Notice w_c on magnitude plot

Trouble w/Phase response....
As far as the phase response goes, we did not get anywhere close to good results. This was much in part due to the delays in the Arduino and MATLAB.

day 4 - Arduino Success

Today we successfully characterized both our linear motor and a simple low-pass RC filter with the Arduino, connected by serial port to matlab.

Picking up where we left off yesterday, we quickly sorted the programming trouble and successfully stored Matlab-generated white noise data to the Arduino. Even with only streaming the data one direction, from the arduino to matlab, and shortening the transmit to a single byte, we were only able to acheive 60Hz.

Next step was to store the output data to the arduino as well, and then transmit it after the motion loop was finished. We had been hesitant to employ this, as it would require timekeeping on the arduino side, which in our group members' previous experience slowed the arduino down greatly, and we were also unsure about the arduino memory capacity. However, we implemented and ran it, and were pleasantly surprised to find the loop could deliver a data point every millisecond, resulting in a 1000Hz sampling frequency. Also, the arduino had no trouble storing up to 800 samples, each with white noise command, position, and time.

For our highly damped linear motor, the 1000Hz sample time was appropriate. Keeping that constraint in mind, we assembled a low pass filter with a relatively low critical frequency for successful validation.

Day 3 - Arduino-to-matlab communication

Today we spent a couple hours working on getting the arduino and matlab to communicate over the serial port, and then to run the white noise command and receive position output at an acceptable frequency. We started by examining Team 7's sequencer code from the previous lab, which streamed data to matlab, and waited for matlab data back to respond.

After sorting the code we did set up streaming white noise, and returned streaming position, using Matlab to time stamp the data with the built-in tic and toc function. Unfortunately, we could only push the data to 10-20Hz, and it became unreliable at higher frequencies.

To increase frequency, we went to transmit and store the white noise data to the Arduino. We ran into programming trouble getting the data to store correctly, and called it quits.

Day 2 - Lab plan and project-pertinent plant

Today we met to review the lab assignment and choose our plan to obtain data for TFestimate. We chose to use a linear motor with built in potentiometer as used in Lab 5 as an actuator in our final project, and therefore will find the transfer function from H-Bridge command to linear potentiometer position output. We built the circuit and mechanism for this. We chose to re-use some code from a member's lab 5 project for arduino-to-matlab communication, and broke off the meeting while waiting to get the code in hand.

Lab 6 - Day 1, sysidexample.m Exploration

Team members...
Kevin Melotti
Sean Murphy
Lisa Perez


Today we got a handle on the sysidexample.m matlab file, and the tfestimate function. Below is a plot of a second-order system simulated and run through TFestimate, green circles are analytical results, blue line is from TFestimate in all plots:


We explored changing sample frequency and period. As expected, reduced sample frequency led to undefined high frequency behavior prediction, and reduced sample period limits low frequency behavior. See plots below:

Low (100Hz) Frequency

Short Period: