Castle of Air

Intro

We are the creators of Castle of Air. Our name was originally Goblet of Water, but evolved over time as our project shifted through different phases.

Our project began with the desire to make something impressive and aesthetically pleasing. We shifted between various ideas, but finally settled on what eventually became our final product, Goblet of Air. Five towers, five fans, five lights, thousands of foam balls, and infinite entertainment. Our Harry Potter themed acrylic channels utilize real time music visualization to brighten the room and enhance the user’s musical experience.

Our minimum viable product, or MVP, was to create an aesthetic music visualizer with at least two frequency channels that adjust the height of small foam balls. We wanted our MVP to have LEDs (lights) flashing according to the tempo and controlled by preloaded data from Spotify. The foam ball height is controlled by live analog audio input. We were able to build up from our MVP to create an awesome demo day experience for users. Our final structure had 5 frequency channels incorporated into our clean, beautifully-designed 3D-printed castle structure.

Data Flow

The flow diagram below shows the flow of information based off of the user's interaction with our apparatus.

Process

Sprint 1

In Sprint 1, our team decided that we wanted to visualize music on a physical medium. We had not at this point decided what that medium should be, but we knew it would be either water or air and foam balls. We decided that our MVP would be at least two visualizer channels with non real time visualization, but we knew we wanted to be aesthetically pleasing.

Sprint 2

In Sprint 2, we decided that we wanted to use foam balls as our visualization material. We came up with a vision of our demo day product, as well as a new MVP. We wanted our demo day product to at least allow users to choose songs from a set playlist, and then the song would be played from a speaker positioned near the microphone, which would activate the frequency channels. Our MVP now required the height of the foam balls to be controlled by analog audio input.

Sprint 3

In Sprint 3, we finally pivoted from Goblet of Air to Castle of Air, because of our decision to make the 3D printed parts form a castle shape. Our MVP still included two visualizer channels, and still only required preloaded data. Aesthetics were still a priority for us.

Sprint 4

Our final design surpassed our MVP requirements by operating on data that didn’t have to be preloaded and controlling five channels of frequency based foam ball manipulation. Our vision of demo day was able to be implemented and was successfully carried out on demo day.

Team

Audrey Lee - Electrical Subteam

Audrey is a sophomore at Olin College of Engineering majoring in Electrical and Computer Engineering. She is fascinated by electricity, but not when it shocks her.

Casey May - Software Subteam

Casey is a sophomore at Franklin W. Olin College of Engineering majoring in Engineering with a focus in Computing. He is especially interested in working with scraping and utilizing scraped data in software. He plans to move as far north as possible and live in the mountains with his three Australian Shepherds soon after graduation.

HK Rho - Software Subteam

HK is a sophomore (Class of 2022) majoring in Engineering with Computing at Olin College of Engineering. She is a fanatic of the Harry Potter series and still is secretly waiting for her Hogwarts letter.

Julia Benton - Mechanical/Design Subteam

Julia Benton is part of the Olin College class of 2022 and majoring in Engineering with a concentration in Design. She previously thought her calling was mechanical engineering and possesses some CAD and fabrication skills that she was able to utilize in this project. Her lifelong dream is to bring joy and wonder into the lives of people all across the world by working for the Walt Disney Company. She found a similar magic in this POE team!

SeungU Lyu - Mechanical Subteam

SeungU is a sophomore at Franklin W. Olin College of Engineering majoring in Engineering with a focus on Robotics. He is interested in designing mechanical structures with CAD program and fabricating them. He also loves to develop software, so that his structures can interact with a human!

Blog

Links to different Sprint sections in the blog.
Sprint 1
Sprint 2
Sprint 3
Sprint 4

Sprint 1

• 10/17/2019
  Today was the first day of writing our blog of our meetings, as well as our first organized meeting to start planning and fabricating for Sprint 1. We divvied up our tasks between the different subteams on our Trello board, and were able to get an idea of a first-cut prototype. For our Sprint 1 idea, we would use a medium of air and different colors of paper to visualize music. We decided to use POE supplied motors and a sheet of acrylic from the scrap bin for our testing purposes. With this first-cut model, we would be able to gauge what can be achieved for this project and how all sub-teams (electrical, mechanical, and software) will be integrated. The electrical section will sense audio input, mechanical will create the chambers for the fan and paper, and software will analyze the audio input and control the fan.
  This is a sketch of our idea for the first-cut prototype.
  -Audrey Lee
• 10/18/2019
  Today we hopped into initial research and design. We discussed scalability and feasibility with two NINJAs, and solidified our thought process on where the project was heading. During our check in with the teaching team, we talked about the difficulty of using water, but ended on an optimistic note. Our team just has to be careful not to get to engrossed in water control. The mechanical team launched into CAD and fabrication, the electrical team pushed into circuit diagrams for audio sensing, and the software team started work on interpreting the Spotify API and brainstormed how to interpret the external audio input.
  
  -Casey May
• 10/20/2019
  Today we made progress in all the mechanical, electrical, and software for Sprint 1. All the mechanical components except the fan were assembled and put together. We struggled quite a bit with the fan, for it was not pushing the air upwards, but rather downwards and also sidewise. To mitigate this issue, we worked on changing the angle of the fan and started a reprint on the 3D printers. For the electrical side, we soldered together basic wiring composed of resistors and capacitors for the microphone sensor. The next step to this would be soldering the microphone sensor to what was done today. For the software side, we worked on learning how to use the “spotipy” library and played around retrieving data from songs, user’s playlists, etc. This was mostly research for the future sprints; therefore, the software goal for Sprint 1 is to control the speed of the fan (e.g. with tempo) and work with the electrical components.
  
  Pictures of the assembly of the components.
  -HK Rho
• 10/22/2019
  During today’s meeting, the team continued working hard to make mechanical, software, and electrical progress with the knowledge that our first sprint review is coming up soon on Friday. The things we need to accomplish in our next meeting and before our report-out is integrating the mechanical, software, and electrical parts and creating a presentation that communicates our work and future plans clearly. We received advice about Friday’s report from the POE instructors that we will be sure to utilize to planning for our presentation. The software team is currently tackling the issue of getting multiple access tokens for the song playing and the features of the song playing. Currently, separate requests must be made to access the song’s data, but the team is trying to figure out how to not have to pull up another website to make each request. The software team also began trying to communicate between Arduino and Python.
  
  For the electrical component, we got microphone audio input, but the voltage difference isn’t high enough so we are doing lots of circuit building on our breadboard to amplify the signal. The mechanical team started today’s meeting working with version 2 of the 3D printed structure, which involved a bigger, more powerful fan. After attaching the motor, however, the air was still not blowing upwards like we wanted, which we realized after consulting the teaching team was due to the fact that there is a solid 3D printed structure below the fan that does not allow for air to be gathered. We considered drilling holes through the 3D printed base, but then decided designing and reprinting our structure to allow more air flow would be more efficient and effective. We remodeled and began printing version 3 of the structure.
  Audrey’s circuit building progress!
  -Julia Benton
• 10/24/2019
  During today’s meeting, we focused on finishing the sprint 1 presentation slides and discussed which medium we will be using for the final product. We decided to use air as our medium since it can be done with better designs compared to water. By using air, we can use the money on more DC motors which means we can have more frequency channels. By choosing air, we realized that we have to discuss the team what can we put more into the electrical part since a lot of LED circuiting is temporarily removed from our todo list.
  
  We received advice from the teaching team on how to make the mechanical component working, and from the feedback, we saw the possibility of our old mechanical structure functioning with little modification. We are trying to reprint some parts to test out whether they will work or not.
  
  -SeungU Lyu
• 10/25/2019
  Today, we presented what we accomplished in Sprint 1 to our peers and the teaching team. We were able to get very helpful feedback and new approaches to concepts from our peers and the teaching team. For the electrical and software sub-teams, realized that our initial plan of having two “modes” between the electrical and software parts were not really integration. We re-evaluated our ideas, and decided to keep our idea for the Fourier Transformed audio inputs for the frequencies of the songs while combining it with lights for the bass and beat of the songs. This combines both electrical and software beautifully while also making sure that we do not overscope for this project. The mechanical sub-team decided on a “leaf-blower” type fan design instead of a “computer fan” one. This newer design would help concentrate the air flow for us and make sure that the air goes directly into our frequency/visualizer channels.
  -Audrey Lee

Sprint 2

• 10/27/2019
  Today, in the mechanical direction, we were working on shopping and ideation. We are wary about buying new materials, because of our limited budget, so plenty of research is necessary to determine whether certain motors are appropriate for our designs. In terms of software, today was highly efficient! Progress was made on debugging our Python to Arduino IDE. We also solved the problem of repeat authentication. Then, we went on to automate the identification of song BPM, and furthered our understanding of the structure of the song features (a dictionary, full of lists, some of which contain dictionaries). Today in the electrical team, we accidentally burnt out a few Op-Amps. We also finalized the rest of the circuit for getting the frequencies from our microphone component.
  
  -Casey May
• 10/29/2019
  Mechanical:
  We tested with a blower fan instead of the previous fan designs that had trouble pushing air through the triangular opening. When at the highest RPM, the blower fan design pushed a significant amount of air out. Thus, we discovered that the motor was even faster when directly connected to power instead of power and arduino (suggested by Professor Aaron). Aaron also suggested exploring with speakers or compressed air to prevent us from only struggling with fans throughout the entire final project.
  
  Electrical:
  Circuit is at a stance where can receive audio input, amplify the input, extract the peaks of the frequencies, and amplify that again. Is also debugging the program that does all the aforementioned functions.
  
  Software:
  For the data-processing side, we were able to sweep through the information per songs. However, we discovered that the sweeping takes too much time that by the time we get the information at a specific point of a song, it has moved onto a different point of a song. We also learned about a library called “Madmom” that takes about 5 seconds of processing and predicts music features with its neuralnet. For the serial communication, we realized that the Serial.isavailable() may not be responding instantly when a new input is given since it is in a while loop. Therefore, we are going to explore using Serial.interrupt().
  -HK Rho
• 10/31/2019
  During our ~spooky~ meeting today, we discussed logistics for what we want to accomplish in our next few meetings in order to meet the goals we set for Sprint 2. On the mechanical side, SeungU has designed a new blower fan that he plans to 3D print for tomorrow’s meeting. We have received the foam balls and mesh wire we had ordered. We are wondering about using actuators versus fan, which we are planning to test after fabricating a round acrylic tube during tomorrow’s meeting. We are trying to figure out what motor we are going to use, since we need a motor that can handle large amounts of current without melting. We are expecting that the motor will need to be controlled with PWM. The software team has been working on resolving git issues while merging their work. They have succeeded in getting serial communication working to control an LED! For electrical progress, we made a circuit schematic in KiCad (pictured below).
  
  -Julia Benton
• 11/1/2019
  Mechanical:
  We created a better fan structure that can blow more air out compared to the last structure. We also worked on creating a circular cylinder, but we had to pivot and create a hex cylinder instead due to material issues. With the teaching team’s help, we were provided with a power supply that can measure the voltage and current, so now we can measure the current flowing to the motor with the load.
  
  Electrical:
  The sensor is working now, being able to get input from the surrounding sound. We assumed that the sensor was not working, but hopefully, it was not the case.
  
  Software:
  Software: We succeeded in controlling the fan speed using the Adafruit motor shield. Also, we figured out how to solve an issue with Spotify API so we not can get whatever data we want from the song.
  -SeungU Lyu
• 11/3/2019
  Electrical & Software:
  Today, the Electrical subteam integrated the sound waves captured with the microphone with the Software subteam to move the fan. We also worked on the Fast Fourier Transform code to capture the individual frequencies from the sound waves. We used an Arduino sample code for the Fast Fourier Transform. While we have not done anything yet with the information received from the Arduino, we now know how it will be formatted.
  Fourier Transform displaying the frequencies and amplitudes respectively.
  Fourier Transform graph of the sound waves’ individual frequencies.
  The Software and Electrical team strived to get analog values from the microphone via the Arduino to control the fan speed. First, we successfully converted analog values from the Arduino to a Python script. Then depending if the value is above a certain value (500 for example), the Python script will send a value of 1 back to the Arduino Serial to test if the LED light on the light on the Arduino will turn on. The light would turn off if the analog value from the microphone was below the designated value. From this, we were able to control the speed of the fan with this concept.
  The Electrical subteam also created a circuit for LED lights for the Software team to control. The Software subteam made advancements with visualizing the beat of the music with LED lights. The LED circuit for the Software subteam to utilize and control.
  
  Mechanical:
  The Mechanical subteam designed and fabricated a hex cylinder pipe to test the structure. We made the base and the structure as well as put in the mesh to make sure that the foam balls do not escape. We also measured the current and discovered that the motor only drew approximately 0.3 Amperes maximum. This means that we can use lower current control, which will help us in the long run.
  SeungU is happy that his fan works and he can check the Amps drawn from the motor.
  
  Amperes drawn from the motor. The leftmost number is the current being drawn by the motor.
  
  Structure is working with fan blowing the little foam balls around in the chamber!
  -Audrey Lee
• 11/5/2019
  Electrical:
  Today on the electrical team, we debugged the lighting board used to connect to Spotify to verify that the lights were correct, and ended up switching out the breadboard, and started working on sprint 2 presentation layout.
  Mechanical:
  Today we discussed the design of our structure, and decided we might pivot from a hexagonal tube to a square shape, which will be easier to raster stuff onto and be less money. We also started working on fixing the problem with static electricity. We considered pivoting from the Goblet of Fire design to a Hogwarts castle structure to incorporate the visualizer channels in a more aesthetic way.
  
  Software:
  Today the software team worked on calibrating the fan speeds with the height of the foam balls. Much of the work involved airflow manipulation. We also worked on serial communication from the Spotify code to the LEDs, but didn’t quite completely manage to make the LEDs respond actively, but in the end was able to turn them on from python.
  -Casey May
• 11/7/2019
  Today we all worked on the presentation for Sprint 2, and clarified questions amongst ourselves.
  
  Mechanical:
  The mechanical has worked on designing a final structure (not done yet) for the visualizer. We ordered eight RS-555 12V 6100RPM DC motors (we ordered a few extra in case some breaks). The mechanical team has also tried emptying the assembly to get rid of the static friction inside the acrylic.
  Electrical:
  Researched affordable LEDs suit for our visualizer.
  
  Software:
  Tested the fan control before the demo tomorrow. We discovered two major problems: the microphone is not only sensitive to frequencies but also the air flow (e.g. wind we blow with our mouth), and although the fan usually reacts to the changes in the audio input it fails to react sometimes (even though the audio input goes over the bounds, the fans do not show changes). One assumption to this is the delay in transferring information between Arduino and Python.
  -HK Rho
• 11/8/2019
  Today, the team reported what we accomplished during Sprint 2 to our peers and the teaching team. We got helpful feedback on our current model and recommendations for moving forward from classmates and the teaching team. The team received feedback that we need to be very clear about what we want our demo day experience to look like. We got the recommendation of using a flow chart to clearly communicate whether preloaded Spotify data or live analog input is controlling the different features of our visualizer. The teaching team reminded us that Sprint 4 is extremely short and we must get very close to a final deliverable in Sprint 3. We also realized that we need to start making our team’s website and are considering using Jekyll through GitHub Pages. We started thinking about a cool raster design for the acrylic Hogwarts towers and began looking into ordering acrylic, LEDs, and marble 3D print filament.
  -Julia Benton

Sprint 3

• 11/10/2019
  Mechanical:
  Figured out design of the tower (chamfer vs fillet) and discussed about which PLA filament to use. Decided to lower the height of the tower to prevent massive waste of time on fabricating.
  
  Electrical:
  Worked on circuit design on KiCAD
  Software:
  Ordered the mini LEDs to put on the towers. Broke Ubuntu, researched on hashtables, dictionaries, and visualizing FFT.
  -SeungU Lyu
• 11/12/2019
  Software:
  Tried sweeping through dictionaries to access the beats of songs. Used computer output to control lights instead. We have the light respond actively to the song that is currently playing. In this meeting, we tried to figure out more about dictionaries in C and accessing the values in them. After discussing with Amon, we discovered what Serial communication and what the baud rate means. We realized that a higher baud rate means faster communication which may be fast enough to transfer data from the Arduino to Python.
  
  Electrical:
  Made finishing touches to the sound receiving PCB. Made sure to reduce space used and make sure that copper lines do not cross if they are on the same layer. We also made sure that the copper lines were connected to the correct places, and was able to catch some mistakes before ordering the PCB. Gerber files viewed in GerbView KiCad.
  PCB preview of the PCB ordered through OSH Park.
  Mechanical:
  Working on design and general structure of our apparatus so it looks nice. Used Blender to create a rock like model for appearances to fit our Harry Potter Hogwarts Castle.
  Design in progress that will be 3D printed.
  -Audrey Lee
• 11/14/2019
  We collectively worked on looking at different themes for our website to choose the one that is simplistic, aesthetic, and easy to navigate. The mechanical team will 3D print the fans to make sure there if there are any more modifications that needs to be made in the CAD. The software team has continued working on extracting the maximum amplitudes of six frequency ranges to control the motors.
  -HK Rho
• 11/15/2019
  Today in the software team we made progress in a pivoted direction for how to scrape the majority of our information for the lighting, using PulseAudio. We also made progress on getting the frequencies divided into six channels. There are some formatting issues we’re running into in terms of frequency samples.
  In the mechanical team we spent a long time trying to get a 3D print that was stuck off the printer. We’re focusing on the aesthetics of the castle and planning on trying to get some free filament by writing a review on the filament site.
  In the electrical team there was a bit of a lapse because of waiting on parts, so most of the progress made was on initial website work, because that deadline is coming up fast.
  -Casey May
• 11/17/2019
  During today’s meeting, the team continued working hard to achieve our MVP with the knowledge that our Sprint 3 review is in just five days. The software team tackled two challenges, one of which is that when sending data from Arduino to Python, a null value appears while decoding the data that introduces us to an index error. This results in breaking out of the loops and making the program think there is a problem. Many members of the team worked together in trying to solve this problem. The other area that the software team made progress in is moving information from Spotify through serial delay into a new database to preprocess information for lighting without delay during visualization.
  
  The mechanical team continued doing lots of CAD and moved forward in the manufacturing process by 3D printing with the marble colored filament that we purchased. We are planning to cut and raster the acrylic towers during Tuesday’s meeting. We redesigned the blower fan and are troubleshooting mechanical problems as they arise, one of which is the sheer amount of time that our numerous 3D prints are going to take.
  
  There is still not much electrical work to be done at this point, so the focus has shifted to website design. We decided on a Jekyll theme and to use html rather than JavaScript.
  -Julia Benton
• 11/21/2019 & 11/22/2019
  On the 21st, we decided to schedule an extra meeting to ensure that we would be able to integrate our parts correctly. The electrical subteam was able to put in the lights into the tower that the mechanical subteam manufactured, and the software team was able to control the lights and the fan speed. We discovered that the lights can be programmed to do a variety of colors and patterns. However, depending on the brightness, lower wavelengths of light may not show up. We discovered that unless the NeoPixels were at full brightness, the color red would not show up. After this discovery and putting everything together, we turned off all the lights and admired our creation. Testing the five NeoPixels needed for our towers.
  The whole team is admiring our work.
  On the 22nd, we still worked on perfecting the NeoPixel blinking tempo and fan speed for the Software subteam as well as finishing up the second tower for the Mechanical subteam. The Electrical subteam helped both subteams with the lights, fan, and tower assembly. We now have two towers with lights and the fan speed can be controlled. -Audrey Lee

Sprint 4

• 12/3/2019
  Today in the mechanical team, it was down to the nitty gritty assembly of our final product. With deadlines approaching, the mechanical team has 3 more towers to assemble and some foreground structures to put together. We’re slightly short on materials so we’ll have to do some scavenging.
  
  In the electrical team, today was focused on getting the electrical parts of the final three lights together. We also started working on the website!
  
  In the software team, today was time to work on ironing out the foam ball visualization levels and website work! We still have some stuff to figure out with the foam balls, because there’s a lot of noise.
  -Casey May
• 12/5/2019
  Mechanical:
  The mechanical team continued to work on assembling the 3D printed parts and also finished laser cutting the necessary components (the acrylic for the fifth tower and hardboard for the base of the entire assembly).
  
  
  Electrical:
  The electrical team worked on a lot of the website and also took part in controlling the LEDs to behave in our desired way.
  
  Software:
  The software team continued working on controlling the LEDs and the third tower along with the first two towers. While attempting to improve/understand what the motors are doing, have confirmed that the microphone picks up the sound of the motors.
  -HK Rho
• 12/6/2019
  Today’s meeting was our final instructional period before demo day on Wednesday! The POE teaching team checked in with us to discuss our progress and their expectations for the five minute rocket talk we will give to classmates and guests. Our team feels that we are on track to deliver a product that we are proud of in addition to an aesthetic, informational website. In our last class period, the electrical team made progress in developing our website and creating the circuit PCB, shown in the picture below. The PCB is a replacement for the breadboard circuit and is cleaner, smaller, and should work better.
  The mechanical subteam cleaned the support off our 3D prints and acquired several screws from the Weissman Foundry, the open-door design studio that can be used by Babson, Olin, and Wellesley students and is a short walk from our Olin classroom. They were able to assemble the remaining two towers and are still 3D printing a few more castle pieces.
  
  The software team worked on editing the light code to work for all five lights. They also researched AUX output control, debugged the code that controls the channels, and ordered soundproofing foam eggcrate tiles so we can better test our microphone.
  -Julia Benton
• 12/8/2019
Software team focused on controlling the LED, since a new issue popped up with using the spotify API. We worked on fixing it, and we were able to figure out the reason why and manage to fix the problem. Also, we decided to use extra motor shield for the motors, so we worked on attaching extra motor shield to the arduino so that the motors do not use too much current for single motor shield (2A limit) and because there is only room for four motors per shield. For Mechanical team, we focused on creating remaining parts of the structure (roof for the building) so that the mechanical part is 100% done.
Other than that, we worked on the website with general design (Font, Background image) and the content so that we can finish the website by the deadline.
-SeungU Lyu
• 12/10/2019
  Today was a very eventful day as it was the day before demo day. Under a lot of pressure to make everything look presentable, we also encountered a lot of problems. The first thing we did was work on the rocket pitch slides for demo day. This was straightforward and were able to get them done. Our next step was to hook up all of the motors to the motor shields and control them with audio input. When hooking up the motors to the motor shields, we noticed that something was amiss. The green light on the top motor shield was flickering, so we unplugged it for a bit, and then plugged it back in. We thought it was alright since the green light stayed constantly on, but then we saw smoke and smelled something burning. We immediately unplugged the power supply and looked at the motor shields. One of the h-bridge chips was completely melted and fried. The smoke from this chip charred a bit of the motor shield on top. While we believe that the top motor shield did not sustain any damage, the bottom one most certainly did.
  Top motor shield is the one that we believe is still functional. The bottom motor shield sustained damage to the h-bridge chip.
  Before we even plugged in our motors, we calculated and tested to make sure that the motors did not draw too much current. They seemed fine when we tested them, but unfortunately we burned out a chip and we learned from this experience. In order to solve this problem, and make sure that we do not burn out any more motor shields, we decided to stack five motor shields on top of each with each one containing a single motor as to ensure that they would not draw too much current. This proved to be effective and we were able to control the motors effectively (although we still try and keep an eye on the motor shields just in case).
  The next problem we encountered was with printing/sending data from the Arduino to Python to see the motor speeds change as a result of the audio input. Before we put in all five motors and only had two, this part of the code worked well. However, when we changed our setup, this code did not work as well, and one of the channels would not work properly. We deleted the line that prints the motor speeds, so we cannot see the motor speeds, but now the channels work.
  Through the hardships, we were able to stick together as a team and persevere. We were able to get a video of our finished product and a team photo to commemorate our progress!
  
  -Audrey Lee

Budget

System Overview

Architecture

The diagram below characterizes the pieces of our system by flow of information. Mechanical components are in blue, Electrical components in red, and Software in green.

Subsystems

Electrical

We developed and prototyped a system which is capable of visualizing analog sound input. We started with prototyping a sound receiver on a breadboard. We worked towards a functional PCB, that would receive sound input, filter, amplify it. This amplified signal would then be sent to be processed by the Software and Electrical Subsystems by applying Fourier Transform to extract the frequencies from the signal. With these extracted frequencies, we would be able to control the fan speeds to visualize the frequencies in our channels built by the Mechanical Subsystem.

We also developed the light system that would be utilized to visualize the beat of the song. This relied on the Software Subsystem’s algorithm to get the rhythm of the song.

Design Process

We first started off with a circuit that could just detect sound waves. It worked like it was supposed to, but it was hard to see if there were any discernible sounds caused by the team.

Next, we moved on to amplifying the signal so we could see noticeable differences in pitch changes. We plugged the circuit into a breadboard that contains the microphone and preamplifier. As an added measure, we also wanted to include a peak detector and a buffer amplifier. The schematic of the circuit can be seen in the schematic section of this page. The picture below is the breadboard circuit of the schematic.

After we found that our breadboard circuit worked, we moved on to designing a PCB on KiCad. We converted the KiCad schematic to a KiCad PCB format to get Gerber files, and ordered it from OSHPark:

When we received our PCB two weeks later, we unfortunately found out that the op-amp we had in stock was too big for the surface-mount pads on our PCB. This was because we accidentally put an LMV324 as our op-amp instead of an OPA4353UA op-amp.

Since we could not use our PCB, we decided to make the circuit neater by using a proto board.

We decided that we only needed the first half of the circuit since that was all that was needed for processing the signal.

Schematic

The Mic and Preamplifier takes the sound wave AC voltage input, and rides a DC offset of approximately one-half of the supply voltage. As we found in the design process section, we found that the microphone’s output voltage is very small, so we included an amplifier with a gain of 100 (20 dB). We made the gain adjustable by having the option to add another resistor in the R17 slot. The audio output is DC coupled and can be directly connected to an analog input of a microcontroller. In perfectly quiet conditions, it will ideally output one-half the supplied voltage units (or around 512 on an Arduino).
The Peak Detector and Buffer Amplifier gets the peaks of the sound wave and amplifies that. The op-amp inverts and amplifies the signal so when its output swings high, D2 turns on, and charges C1. When the op-amp is high or not swinging, D2 is turned off, and C1 discharges through R9. This means that C1 tracks the peaks of the input signal.

Referenced Sparkfun Sound Detector

Future Iterations

If we continued this project, we would like to get the PCB working with getting the correct Op-Amp part. We would also like to experiment more with sound processing and how we could filter and amplify the signal better.

Other Subsystems

Mechanical

The Castle of Air has a mechanical structure with five towers to visualize five distinctly different frequencies of sound waves for our visualization project. The mechanical team started with building a simple fan structure, which later developed into a blower fan structure powered by a 12V DC motor. Each tower is now attached to a blower fan, so that it can change its RPM to control the height of foam balls to visualize the music.

We also developed an aesthetic design of a castle to make the whole structure appealing. We implemented a design from Harry Potter’s Hogwarts Castle, showing that the visualization of music really is magical!

Design Process

The Castle of Air went through several design and mechanical iterations, including 2 name changes, to become the magical music visualizer that it is today. The first design decision the team (originally called Goblet of Water) made at the very beginning of our project was deciding to elevate our music visualizer, which we were already very enthusiastic about, by incorporating a Harry Potter ⚡ design. All our team members are still secretly waiting for the delivery of the letter inviting us into the Wizarding World, so we were quite excited about bringing some magic into the Muggle world with our Harry Potter themed music visualizer.

Our team decided from the beginning that our priority was to create a final product with a very clean, aesthetic design. We acknowledged that our tradeoff would be producing something that might not be super technically challenging. We initially envisioned our structure imitating the colorful, flaming Goblet of Fire from the fourth Harry Potter movie. We originally wanted to have water as our main visualization material, but we soon learned from discussions with professors and course assistants that water control is extremely difficult. We also took into account the budget we were given for this whole project and after researching the price of a decent water pump, we realized that we would only be able to purchase two or three water pumps. Only having two or three visualizer channels did not align with our goal of creating an epic music visualizer. We decided that a pivot from water to air was a good move because we wanted it to be able to dedicate our time and energy to other aspects of the project, rather than spending the majority of our time water-proofing electronics and dealing with water control. Thus, our team name changed to become Goblet of Air.

After deciding on not using water for visualization, we explored what possible lightweight material could be used inside our frequency channels. We got the opportunity to ask our classmates and the teaching team for suggestions via a feedback form during our Sprint 1 report-out. Before choosing the best lightweight visualization material, we were able to test our fans by blowing pieces of ripped paper. Our team eventually came to the decision of using tiny, white foam balls inside our channels, which we were able to buy a large quantity of for a cheap price and could be colored by the LEDs in each channel. Another material we used in prototyping was fruit netting, but our final product utilized thin mesh wire to allow the fan’s air to pass through and also contain visualization material within the channel. Our team learned a great deal about how fans work in Sprint 2, realizing we needed to have open space to allow for airflow and pivoting to a blower fan, which concentrates the airflow to where we want to direct it to. We later had to redesign our blower fan because we learned it was impossible to get it off the 3D printer build plate without breaking the fan’s blades.

In the initial stages of ideation about the aesthetics of the project, a great deal of online research was done into materials that could be used to make a beautiful, realistic Goblet, utilizing YouTube tutorial videos and how-to’s from people who had built similar structures. A significant pivot was made during Sprint 3, when we changed from designing a Goblet of Fire structure to the Hogwarts castle. Thus, our final name change was made to become the Castle of Air team that you know and love. We decided to build the Hogwarts structure because it was easier to incorporate towers into the design of the whole structure. Changing to the castle design was also a good pivot because the small visualizer foam balls added to the snowy Hogwarts theme that we had started to make by placing white, 3D printed rocks that looked snow-covered at the base of our structure. The foam balls we purchased turned out to be extremely staticy and we spent a great deal of time researching how we might reduce the static electricity, considering dryer sheets, anti-static sprays, and grounding. Eventually, we decided to embrace the static, with the balls imitating snow sticking to the sides of Hogwarts towers.

An additional big design decision was pivoting from a circular or hexagonal tower shape to square towers. In previous iterations of the towers, we had attached laser cut acrylic pieces using duct tape or hot glue to create a hexagonal tower. After discussing with a course assistant how these were not very nice, clean attachment options, we decided to instead use marble 3D printed sides that could be attached to the acrylic with screws, hide the brown burn marks on the acrylic left by the laser cutter, and produce the aesthetic look that was a priority in our project. Since our structure is primarily 3D printed, we needed to allocate some of our budget to purchase a significant amount of aesthetic PLA. We researched PLA that would be very compatible with our 3D printers and look similar to castle material, and we decided on buying Solutech’s marble PLA. In this project, our mechanical team was able to gain experience with the fabrication methods of 3D printing and laser cutting. One exciting experimentation process was with different laser speeds to cut fully through the acrylic but not create large burn marks. Since aesthetics were a top priority for our project, the mechanical team spent much time using SolidWorks and Blender to design castle buildings and rocks that are true to the Hogwarts films.

An important pivot we made was from the 6 towers we originally planned to instead having 5 towers in our final design. We made this decision because of the remaining budget, the large quantity of time involved in 3D printing the parts for and assembling each tower that remained as our product deadline rapidly approached, and to celebrate how our team consists of 5 team members. A great deal of time and thought was put into the design rastered on the acrylic towers. Since the towers were thin and long, designs had to be carefully selected that wouldn’t need to be stretched to fit nicely onto the towers. We decided on rastering the names of the four Hogwarts houses, tracing the official Harry Potter font, and adding to this design by setting the tower’s LED color to be the main house color. For the center tower, we traced each house’s animal emblem: Gryffindor’s lion, Slyherin’s snake, Hufflepuff’s badger, and Ravenclaw’s eagle. The website design was also very important for our team, and our members spent quite a bit of time researching, discussing, and voting on the layout that would best deliver the magic of this project to you!

Iterations

Version 1

We first started with building a fan structure directly blowing air vertically. However, we soon realized that this structure limits the size of the fan, and also greatly blocks the airflow actually entering the cylinder. We couldn’t create strong upward flow to actually move materials inside the structure, so we decided to create a blower fan design for next version since it is far better at creating an airflow in a concentrated area.
Version 2

We created a blower fan structure with a backward-curved fan to create a high thrust. The structure worked amazingly well with a 12V DC motor, and it was able to blow foam balls up to the top of 1.5 feet tall structure just by using 6V with PWM control. We realized that we don’t need a 12V DC motor for this project but to reduce the amount of current drawn from the motor, we decided to keep on using the 12V motor. It was measured to use about 0.6A at maximum current draw from the motor, which is a safe range for the Adafruit Motor Shield to power.


Version 3

We kept on using the blower fan design from the previous version, just making small adjustments to the size. Other than that, we decided to use a tower structure, instead of only using acrylic, to build the structure for aesthetic purposes and to save money. The towers were originally planned to be 3 feet tall since we thought it will be more aesthetically appealing with taller structures, but we realized this height would be a difficult feat and decided to build 2 feet tall towers for the final structure.


Version 4

A total of 5 towers were built for the final structure and aligned closely together. We placed enough space between each of the towers so that they would not disturb each other’s airflow.

Castle Design

Buildigs

All castle designs were created with SolidWorks by our team from scratch. Nothing was implemented from the external sources, but the design ideas were originally from Harry Potter’s Hogwarts Castle.
On the right side, the name of our project was added with the ‘Harry P’ font, which looks almost identical to the font used in the actual Harry Potter book.

Rock

To design a high polygon rock structure for the foundation of the buildings, we used Blender to create the landscape, decimate the landscape to lower polygons, and export it to SolidWorks.



Final Render

We were able to create full assembly of our structure before starting the fabrication process. The final render looks the same as the actual structure, except for the marble texture on the buildings. Due to having a nice assembly, there wasn’t a lot of issues while fabricating the whole structure.

Other Subsystems

Software

Links to the subsections:

Motor Control

The software system for controlling the motors beneath each of the five towers was dependent on the analog audio input from a microphone. The output from the microphone was a single frequency that was a combination of all the existing frequencies of a given sound input. To break down the output into different frequencies and their respective amplitudes, fast fourier transform (FFT) was applied to the output. Then we extracted the frequencies with the highest amplitudes and used the amplitudes to control the speed of the motors.

Serial Communication Between Arduino and Python Script

The software subteam first started by sending and receiving data between the Arduino and the Python script through serial communication. We decided to send data from the Arduino and then process the data in the Python script rather than sending and processing the data all in the Arduino. This decision was made based on the difficulty of data wrangling and processing in C++.

Selection of the Highest Amplitudes

Once the data from each timestamp was delivered to the Python script, we processed the data so that the five highest amplitudes would be selected from each timestamp, and those amplitudes would be sent back to the Arduino for controlling the motor speeds. The amplitudes were scaled up to show more visible changes in the motor speeds.
One of the challenges we had to deal in this process was involved dealing with empty data. When empty data was detected, we moved onto reading the next line of the data to prevent errors.

Controlling the Motors with Multiple Motor Shields

After the Arduino receives the five highest amplitudes, the amplitudes are used to control the motors. We used five different motorshields respective to each motor to prevent possible burning of the motor shields. A big difficulty we faced when visualizing music from the microphone was struggling to synch the height of the foam balls with the audio input. It was very difficult to detect sounds resulting from clapping, singing, whistling, etc. due to the noise in the background, which included the sound of the running motors. As a fix to this, we made a soundproof box and placed the microphone within it along with speakers.

LED Control

The lighting team designed a system that mimics the beat of the music currently playing through Spotify by accessing Spotify’s API in python and sending the relevant information to Arduino in order to manipulate the lighting output of our five Adafruit NeoPixels.

The lighting team also worked to automate the change of songs so that the software could run continuously instead of having to be rerun on song change and would automatically start analyzing the currently playing song when the code is first run.

if token:
    sp = spotipy.Spotify(auth=token)
    results = sp.audio_analysis(current_track_uri)
    print(results['beats'])
    print(results)
    tempo = int(round(results['track']['tempo'],0))

Design Process

The design process started off by figuring out how the Spotify API scraping library worked. This meant learning how to change the scope of the scraping process, how to enter my Spotify Premium credentials to set up the scraping process, and how the results of the scrape were formatted.

# export SPOTIPY_CLIENT_ID='***************************************'
# export SPOTIPY_CLIENT_SECRET='*********************************'
# export SPOTIPY_REDIRECT_URI='http://localhost/callback/'

scope = 'user-library-read user-read-currently-playing user-modify-playback-state user-read-playback-state'
username = 'thranxar'

try:
    beatEnd = noteDic[round(round(time.time(),1)-t,1)]
    arduino.write(str(round(beatEnd-round(time.time()-t,1),1)).encode())
    arduino.write('1'.encode())
        try:
            data = arduino.readline().decode('utf-8').strip("\r\n")
            print(data)
        except UnicodeDecodeError:
            pass
    except KeyError:
        arduino.write('2'.encode())

Future Iterations

The most prominent thing we would want to improve upon in the lighting software is making the processing more adaptive based on changes in the music. Since Spotify doesn’t fully provide each change in tempo in every song, sometimes the lighting is trapped in the wrong tempo which ruins the viewing experience. A good way of dealing with this would be to sense the tempo actively by checking for the change in time between prominent beats from the Spotify scrape.

Source Code (Click on the Github icon):

Other Subsytems

Gallery

Videos

• Electrical
• Mechanical
• Software
• Gallery

i = 0;

while (!deck.isInOrder()) {
    print 'Iteration ' + i;
    deck.shuffle();
    i++;
}

print 'It took ' + i + ' iterations to sort the deck.';