Project

# Title Team Members TA Documents Sponsor
9 Self-Tuning Violin
Erik Kwiatkowski
Ginny Bytnar
Kevin Lyvers
Tianxiang Zheng design_document1.pdf
final_paper1.pdf
other1.ino
photo1.PNG
presentation1.pdf
proposal2.pdf
video1.mp4
# Team Members:
Ginny Bytnar (bytnar2)
Kevin Lyvers (klyver2)
Erik Kwiatkowski (erikk3)

# Problem
Beginner string instrument players are usually discouraged to touch their tuning pegs on an instrument due to the fragility of the pegs and how easily the instrument can fall back out of tune. This is especially true for instruments with friction based tuning systems like Violin, Viola, or Cello. This leads to many students initially learning how to play without a tuned instrument or wasting lesson time by having a teacher tuning their instruments during the lesson.

# Solution
This problem can be solved with an automatic tuner. Once a note is played an electromechanical module can adjust the strings to be in tune. We have seen such devices implemented in this very class but primarily for guitars (and one very interesting but entirely different piano tuner). Guitars have a system of gears that make tuning extremely easy to the most novice of players, while friction-based instruments require skill and tact to tune. This creates a unique problem that our device would fix.

# Solution Components
There would be three main subsystems. Largely they can be described as the microphone module, audio processor, and motors.

## Subsystem 1 (Microphone Module)
This subsystem would take in sound input from a small microphone and amplify it to feed into a microprocessor’s input. This would involve primarily amplifying and manipulating a microphone's input into the microprocessor’s range for an input signal. The specific amplification depends on what microphone and microprocessor we use, but primarily we are aiming for the range of the microphone output to be as close to the full range of the microprocessor’s analog input.

Parts
- Micro-microphone
- An example of this kind can be found here. It even comes with adjustable amplification:
https://www.adafruit.com/product/1063?gad_source=1&gclid=CjwKCAiA5L2tBhBTEiwAdSxJX2guGEEvYkWgI5AiAc3-Vs7E--6RTIEcKtYPaxYz-V02dINoxKphdRoCSk8QAvD_BwE
- Amplifier circuitry (to get microphone voltage into microprocessor’s input range)

## Subsystem 2 (Audio Processor)
This subsystem would be entirely software. A microcontroller would receive input from the Microphone Module and run a Fast-Fourier Transform on the data. This would provide us strengths of different frequencies in the sound. This helps us because we assume the loudest frequency would be the fundamental frequency of the string being played. We can then compare the input frequency to the given frequency we are aiming to tune to and send an appropriate signal to the Motor subsystem.

Parts
- A microprocessor
- We are planning on using an ATmega328P or some variation of the ATmega chips


## Subsystem 3 (Motors)
This subsystem would be a series of motors being controlled by a microcontroller. We could either have four motors or one motor with on-off functionality to only change one string at once. One motor would be cheaper, but four would be easier to implement. The motor(s) will receive a signal from the microcontroller depending on how they should move. We have looked into a H-bridge to control the motor. Two considerations we must look at is the speed of rotation and torque of the motor. The speed must not be too fast, because the tension the strings put on the instrument can be detrimental if the strings are tuned too fast. Second, the motor must have sufficient torque because tuning the strings would need a strong enough motor to turn the string tighter as the pitch increases.

Currently, due to the affordability of H-bridges, and motors we are planning on going for a four motor approach. This would also decrease the amount of critical parts that could fail in a more mechanical design with one motor. We do not know the torque necessary to tune a string yet and we could not find any previous data about the torque required to tune a violin string. We are experimenting with different motors very early on to find a good fit. We are also aware of being able to change a motor’s torque using a series of gears, however we are trying to avoid many moving gears. Another consideration with the motors is power draw. A stronger motor or multiple motors requires more power compared to a singular weaker motor. This power will be handled by a simple power subsystem giving power to the h-bridges, the microprocessor, and microphone.

# Criterion For Success
We are looking for it to tune all four strings in a semi-timely manner. We say a vague semi-timely manner because the tuning can take different times. A slight tune-up would not last very long at all, but a new set of untuned strings could (and should) take a few minutes to get tuned up in a safe manner. To put a definitive number on the criterion, a short tune-up should last no more than 10 seconds per string and a full new-string tuning should take roughly two minutes of slow-tuning.

Prosthetic Control Board

Caleb Albers, Daniel Lee

Prosthetic Control Board

Featured Project

Psyonic is a local start-up that has been working on a prosthetic arm with an impressive set of features as well as being affordable. The current iteration of the main hand board is functional, but has limitations in computational power as well as scalability. In lieu of this, Psyonic wishes to switch to a production-ready chip that is an improvement on the current micro controller by utilizing a more modern architecture. During this change a few new features would be added that would improve safety, allow for easier debugging, and fix some issues present in the current implementation. The board is also slated to communicate with several other boards found in the hand. Additionally we are looking at the possibility of improving the longevity of the product with methods such as conformal coating and potting.

Core Functionality:

Replace microcontroller, change connectors, and code software to send control signals to the motor drivers

Tier 1 functions:

Add additional communication interfaces (I2C), and add temperature sensor.

Tier 2 functions:

Setup framework for communication between other boards, and improve board longevity.

Overview of proposed changes by affected area:

Microcontroller/Architecture Change:

Teensy -> Production-ready chip (most likely ARM based, i.e. STM32 family of processors)

Board:

support new microcontroller, adding additional communication interfaces (I2C), change to more robust connector. (will need to design pcb for both main control as well as finger sensors)

Sensor:

Addition of a temperature sensor to provide temperature feedback to the microcontroller.

Software:

change from Arduino IDE to new toolchain. (ARM has various base libraries such as mbed and can be configured for use with eclipse to act as IDE) Lay out framework to allow communication from other boards found in other parts of the arm.