TUSIC
  • Home
  • Process
    • Sprint One
    • Sprint Two
    • Sprint Three
    • Final Sprint
  • Budget
  • Systems
    • Mechanical
    • Electrical
    • Software
  • The Team
  • Blog
  • Home
  • Process
    • Sprint One
    • Sprint Two
    • Sprint Three
    • Final Sprint
  • Budget
  • Systems
    • Mechanical
    • Electrical
    • Software
  • The Team
  • Blog

the Final Sprint

Mechanical: Final Box and Swiper Design

When testing our system last sprint, we noticed several design changes that could make our page-turning more reliable.  The box design used in Sprint 3 involved wedging the motor holders between the two walls of the box.  This was effective at first, but the sides of the holders ended up pushing the sides of the box.  This caused our box to become flimsy and fall apart.  At the beginning of this sprint, we brainstormed a new box design that would focus on ease of integration between the holders and the box.  This new design features press-fit holes in the bottom of the box for the holders to sit in.  A document with more information can be found here: 
boxdesignsummary.pdf
File Size: 403 kb
File Type: pdf
Download File

Picture
Picture
We also designed a new middle swiper during this sprint.  Our original swiper was too sharp on the end and would occasionally rip through the paper.  To fix this, the new swiper is curved and cut from acrylic for aesthetic and strength purposes.  

Finally, we decided to abandon the ability to turn backwards for the time being.  We believe that this is a worthwhile concession to get our forward system working reliably. 
​

Software: Beat Counting

Last sprint, we noticed some issues with our code tested with live music.  The beats per minute calculations weren't accurate enough for the variable playing of a live musician. The system we developed the previous sprint relies on a combination of beat detection and time-based turning, but is unable to adjust for changes in tempo. For the final sprint, we removed the time-based component and focused on counting beats on live music. We found open source software that managed to record music and find the amplitude of the music live. We added a threshold value that denoted that the tiny piece of music recorded had a beat in it. For example, if the software found an amplitude of 0.59 and our threshold was 0.4, then the program would recognize that as a beat.
Calibration Mode: In calibration mode, the program continuously counts beats using the technique described above. When the pedal is pressed, it stores the number of beats played since the last pedal press in an array. When the musician is done playing, this array is saved to a file.
Live Playing Mode: In this mode, the program is still continuously counting beats. However, instead of waiting for a pedal to be pressed, it looks at the elements in the array and checks to see if the amount of beats that have been played match the first element in the array. If it does, this means that the Arduino should turn the page so Python sends Arduino a message to do so. The first element of the calibration array is removed, and the process continues.

You can find our final code here:

GitHub Repository with final program
Create a free web site with Weebly Photo used under Creative Commons from J McSporran