Marble Music Machine
The Project
In a group of four students at Brigham Young University, we were tasked to create a piece of kinetic art. The product we conjured was an interactive music machine that made sound by dropping marbles onto instruments. We hoped this machine would attract the attention of someone walking past. A use could user the keyboard to record their own song, then watch the machine replay it on a xylophone with marbles. Simply turn on the ball return and watch the balls climb the spiral to continue playing. See the video below for a demonstration of the Marble Music Machine.
Team members: Michael Ottesen, Clayton Young, Sara Hatch, Anna Knutson
Demonstration
Click the video link here to see the machine in action! After a short 3 months to design, build, and test the music machine, we were pleased to see it it function the way that it did.
After recording a melody on the keyboard, the recording is stopped and played by the machine. The keyboard is equipped with a buzzer so the user can hear the notes being input, then the machine plays the same melody by dropping marbles onto a xylophone. This page will dive into the details of the work I accomplished to contribute to this project.
My Responsibilities
I had two major responsibilities with this project: electronics and code. The challenge was to minimize the supplies needed to accomplish the task while also maintaining a highly functioning music maker. The electronics needed to fit in small spaces and function well. The code needed to accommodate a user interface and allow for (seemingly) simultaneous operations. These challenges pushed me to learn new things and find solutions to difficult problems.
Electronics
Many design decision were made with the electronic setup such as what microcontrollers to use, which motors to use, how to connect motors to the microcontrollers efficiently etc. The most important task with this responsibility was making sure that the electrical connection were reliable, accurate, and easy to assemble.
The ball droppers were suspended 2 feet above the location of the microcontroller, and only had slim poles to hide any electronics connecting them. Also, there were 18 servo motors that required 3 wires each (power, ground, and signal). I was able to make this connecting compact and reliable by connecting a ribbon cable to each end and threading it through the slim pole. The ribbon cable easily connected to a custom printed PCB on either end of the pole. The image shows the compact wiring of the servo motors connecting to the ribbon cable next to the pole.
Screenshot of Arduino code demonstrating play button logic and code organization
Code
The code consisted of two main code scripts. One was for the master Arduino, and the other for the slave Arduino, consisting of over 800 lines of code. Having never used Arduino, I was forced to learn the syntax to complete the task. The code needed to satisfy many requirements for this machine, which presented several challenges.
The biggest challenge with the code was allowing for multiple tasks to occur simultaneously while using just one microcontroller. For example, if two notes were play at about the same time, then the dropper needed to drop the marbles at about the same time. Sequential tasks wouldn’t work because the time it takes to move a servo motor to a position and back is far longer than the time between two notes played close together. To overcome this challenge, I used a large loop that cyclically checks the time. The loop initiates a motor, but doesn’t move it all the way. Each following loop checks the progress of each motor and progresses it as it needs to. This was a great solution to allow for more simultaneous ball dropping. Some of that logic is shown in the image of code.
A sample of the code in this project is shown to demonstrate the organization of the way that I code. Notice that I have commented nearly every line of code so I can always remember the intent. As a coder, I find that clean, concise, and understandable code is important for transferability.
Iterative Design
Using the ball dropping mechanism as an example, we used an iterative design process to refine design decisions. Clayton was primarily in charge of the ball dropper, but I worked closely with him in the design process. We began with discussing many possible design ideas. Then we created cheap/fast prototypes for some rapid testing of the mechanisms. This was important to learn about our designs as fast as possible. Then we refined our designs and created some more robust prototypes for testing. Then the design was refined again and tested again. Some of the prototypes are shown in the images below. The process we used for the ball dropping mechanisms closely aligns with my personal design philosophy. Click the link to read my essay about my design philosophy.
From left to right, a progression of sequential prototypes. The first prototype we tested is on the left, and the final ball dropping mechanism is shown n the right.
Team picture with a partially constructed prototype 3 weeks prior to deadline
Working with a team
Working well with the team was imperative to complete the project within the limited time. We, like most teams, had our share of differences. We disagreed on several approaches to the engineering, and struggled to make decisions as a group. Occasionally, some contention arose between group members. To combat the adversity, we had team meetings where we could each discuss our ideas and opinions, and listen to each other. I am proud of our group and the way we handled these differences. We were able to listen to each other and make important design decisions. Ultimately, we completed the project by the deadline and produced a great product.