- I started this week by helping prepare our Design Presentation. I made the wireframes for our website and also defined the protocol for how the front end will talk to the Raspberry PI. My main task for this week was to try and establish a WebSocket connection between a Raspberry Pi and a front-end client. I tried a few different things and none of them worked. I will continue to try and figure that out.
- I think my progress is a little delayed since I was not able to get the client and Pi talking this week, but nothing to be concerned about. I will try to finish this as soon as possible so I can get on to next week’s task which I have more experience in.
- Next week I want to first get the WebSocket connection working. After that, I want to make the queuing system work on the backend for one client. I will also be allocating a lot of time for the design report.
Team Status Report for 2/24/24
- The most significant risks that could jeopardize the success of the project have not changed much so far. More specifically, the first biggest risk is not being able to properly compile and run code for controlling our light fixture automatically through our control program, which would use Flask, Python, and the Open Light Architecture framework to transmit DMX signals to the lighting system. Our concerns are due to comments given on other people’s projects attempting to control lights using the DMX protocol that the OLA framework is a little finicky and difficult to bootstrap, even though after initial setup progress should be smooth and predictable. To mitigate this risk we will be testing our setup before committing completely to OLA. Secondly, another major risk would be not being able to maintain and reason about the different websockets our Users would connect to our DJ system through, as maintaining this live User network is a big part of our use-case. We are mitigating this risk by building these modules early. Finally, the last major concern would be making good persistent programs that thread well on the RPi’s without crashing, as we want our DJ to have near 100% uptime, as we consider even a brief stop in the music playing a fatal error. We can mitigate this risk by researching more into robust microservice programming.
- As we just recently gave the Design Presentation, within that presentation was our most up-to-date system design, and there were no changes made to our system design after that.
- The schedule has not changed significantly.
Luke’s Status Report for 2/24/24
As mentioned last week, I spent the majority of this week working on the ML module. The main goal was to be able to generate song recommendations from a generated seed containing info about a song. I was able to build a Java module that communicates with the proper Spotify endpoints to do exactly this. Below is an example of the generated song recommendations for an input seed that represents: artist = The Beatles, song = Help!, genre = rock. This is the full output
As we can see it works amazingly which is very cool to see. The generated songs from such a simple query are already very relevant to the input song. This shows very promising results for how much we will be able to fine tune our results with much more complex input seeds based on the listening session data we obtain. The next steps for this will be to create a cleaner class for building seeds to input into the model.
In addition to this coding, I helped my team prepare for the design presentation by working on the slides and contributing some important things. Mainly, I created the block diagram which took a lot of thought and effort.
As we can see, our system design is really coming together which is fantastic to see.
In terms of schedule, I would say that we did a great job in catching up on schedule this week and getting some important things done. Once we are done with the design presentation, we will be able to really buckle down and grind out a lot of the critical models for the design.
Next week, I plan to continue with the ML development, and will hope to integrate communication between the two pi’s because this will be important for the actual lifecycle of adding a recommended song to the queue.
Thomas’ Status Report for 2/24/24
Thomas Lee
- This week I took charge of the Design Presentation. I created the content for the solution approach, main RPi, physical interface, and testing slides, as well as edited and reorganized the design requirement slides. I compiled the presentation and developed the script for the presentation, and presented our Project Design to the class on Wednesday the 21st. I also began the persistent Java process for continuously listening on the web socket for requests issued by Web App clients, and researched more into the lighting system control protocols to double check that it would be feasible to program before we spent a considerable amount of the budget on a lighting fixture system.
- Our progress is mostly on schedule, however for our code base we may be slightly behind in terms of having extensive modules ready for basic testing. To catch up to the project schedule we have starting migrating code onto our main RPi, as well as organized and got our different code components initialized, and so this upcoming week we will be diligently programming as well as working on the design report writeup.
- In the next week, we hope to be able to have simple end-to-end functionality of a single client issuing a perfect song play request through our Web App and having it actually play on our bluetooth speaker. We also hope to start working on the lighting system.
Matt’s Status Report for 2/17/24
- I started this week by experimenting more with the Spotify API to better understand it. I also designed the wireframes for our web app. The rest of my time was spent researching and making the design presentation. I flushed out our website protocol, how the website will communicate with the PIs, and our veto protocol amongst other things. I also researched how we will connect our lights with the Pi since it seems pretty complicated.
- I think that I am on schedule. I said that I wanted to work on the Pi’s for this week but I did not take into account the time that making the design presentation would take.
- This next week I hope to start working on the Raspberry Pi. More specifically I would like to try to get communication between the web app and Pi to work. That also means I need to start on the web app.
Team Status Report 2/17/24
What are the most significant risks that could jeopardize the success of the project?
- Not being able to properly control the lights with our PI. This is for both actually connecting the lights / controlling them through a program and making them display what we want them to.
- Communication between different parts of the project. We still need to make sure that all of our parts can communicate efficiently.
- Note that the authorization with Spotify API without a GUI was a significant challenge last week, but we have seemingly solved this
How are these risks being managed?
- For the first one: We have been researching ways that other people have controlled DMX lights and found some pretty good resources
- For the second one: we can pick up the Rasberry Pi’s so next week (after we finish the design presentation) we can actually test if the Pi can communicate with the spotify API as well as with the other PI and the frontend.
What contingency plans are ready?
- If things go really bad with the lights (which I don’t think they will) we could always connect small LEDs to breadboards and make a light show that way. Since it is much easier to just connect the LEDs straight to rasberry pi pins
Were any changes made to the existing design for the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what cost does this change incur, and how will these costs be mitigated going forward?
- No major changes were made to the system at this point: no new User input features, modules added/reassigned/reorganized, and no new pieces of hardware added.
- Part A was written by Matt Hegi, B by Luke Marolda, C by Thomas Lee
- Part A:
Our project mostly targets health in a psychological sense. Everyone gets a chance to get their song heard without much effort, it promotes collective enjoyment amongst a crowd, and the music reflects the views of the majority which means that most people will be happy. Our project does not introduce nor help avoid things that cause physical harm, maybe if someone used to have to go up to the DJ to request a song they would have to go through a crowd which could be dangerous. Our product does not apply to welfare very much since music is not a basic need. - Part B:
Our project aims to bring groups together by allowing everyone to contribute to what is being played. This allows for a diverse representation of music preferences, acknowledging the varied social and cultural background of the guests. - Part C:
Our project aims to be a cost effective way to enhance events. It is a relatively cheap one-time cost that is meant to permanently replace costly DJs. Our product aims to do what DJs do, but more personalized to each customer, more targeted toward the crowd, and without bias.
Luke’s Status Report for 2/17/24
This week, I focused a bit more on the Spotify web player and authorization protocol rather than the ML model. The architecture of our server interactions with Spotify were more complex than initially expected so I had to come up with unique solutions that would work on a RasPi. The resulting solution was as followings: launching a NanoHTTPD server to send and receive requests, and then using Selenium WebDriver to authorize with the Spotify authentication endpoint. The tricky part here is that typically with Spotify web apps, there will be multiple users logging into your app with their own Spotify credentials via a web browser. But, we want to house this infrastructure in a Pi, with no graphic interface for the login credentials, since we will only be using a single Spotify account for the system. Thus, I needed to use web driver to automatically interact with the redirect URI that Spotify responds to an auth request with. This involves entering credentials, logging in, and then grabbing the session params after the successful login to retrieve the Authorization code that will be used to make future Spotify API requests that need user scoping. Below you can see this in action as we start the app:
Then, a Chrome WebDriver instance is launched, directed to the Spotify login page.
The credentials are then automatically entered. For this example, I am using my account but in the future we will have a premium account solely for the Music Mirror system.
And finally, the driver is automatically closed once the authorization code has been received.
In addition to this, I worked on more solution approach work to prepare for this week’s presentation
We are mostly on schedule, but I am a bit behind on the ML module development as this authorization solution took longer than expected to devise. However, we are on track in all other areas and should be making great progress next week.
Speaking of, I plan to now use this working auth infra to build the ML rec model wrapper that will communicate with our user’s input and the Spotify API to create song recs to add to the system queue. I also plan to solidify any other solution design decisions in terms of the ML modules for the system.
Thomas’ Status Report for 2/17/24
Thomas Lee
- This week I defined and fleshed out the major structural components of the Solution Approach & Implementation Plans for our Web App and the Main Raspberry Pi system in preparation for our Design Presentation. More specifically, I made important design decisions about which modules in the system diagram (such as the Request Receiver, Queue Structure manager, WebApp) would be coupled & communicate with which others, and in what order/priority data is forwarded throughout the User web app -> Internal System -> Spotify API -> Speaker & Lights pipeline, as well as for what functionality we would be exposing to the User on the web app side. To make these decisions I took into consideration the User experience (as they are the primary stakeholder) by making sure our system would feel intuitive, reactive (snappy), and powerful when interfacing with it. Please refer to our Design Presentation Slides (and accompanying writeup doc) for the specific design decisions and their exact User-focused justifications. Additionally I conducted more research into the specific party light fixture control protocols we would be capable of programming on and transmitting from our Raspberry Pi’s, and which actual pieces of hardware would accept those control signals within our budget. I have decided that our current plan would be to use the DMX mode on our lights, and transmit control signals using a USB to DMX cable from the Pi to the light fixture. The control signals would be generated by a Python server on the Main RPi and use the Open Lighting Architecture Framework to have our function calls actually transmit DMX encoded information along to the actual lights.
- Progress is on schedule, however in the upcoming week we need to be vigilant about starting to build our actual modules and to test if our toy examples will work with the actual runtime environment.
- Next week we hope to set up and test the basic functionality of each of the modules (besides the Recommender RPi), and possibly link them end to end. We will also begin writing lighting code for our LED controller and make final decisions about which lighting fixture and noise sensor we will use, and order them via the inventory form. Also next week we would be tinkering with the RPi to see how to manage various processes on the same core.
Matt’s Status Report for 2/10/24
- At the beginning of this week, I helped complete the content we needed for the proposal presentation. I helped research the requirements for our project, formulated use cases, and worked on the Gantt chart with Thomas. After that, I experimented with the Spotify API to get used to it to start making song requests (it took some time to figure out how to send the requests to the API).
- Progress is on schedule
- I hope to be able to test the connection between our RPis as well as the RPis with the Spotify API. I also hope to get a more defined approach for our different protocols (for example: how to handle user requests on the queue).
Team Status Report 2/10/24
B3: Music Mirror
Team Status Report
2/10/24
What are the most significant risks that could jeopardize the success of the project?
- We just started and have not fit the hardware with the software yet. So we think the biggest risk is not being able to make the hardware and software communicate effectively
- Another risk would be not receiving the proper hardware components early enough to allow for us to build and integrate all our subsystems
How are these risks being managed?
- This risk is being managed by researching if our pi can connect with the Spotify API as well as our website. So far it seems like it can.
- We will use the school’s Raspberry Pi, and come to a determination of which LED light system works best with the microcontrollers we intend to use for our system, as well as learning the communication protocols to allow for them to cooperate with each other.
What contingency plans are ready?
- At this point, it does not seem like we need a contingency plan for the pi connecting to our other components.
- As for other parts of our project. If something goes wrong / needs to be added we can quickly think of another feature to add since our project allows for a ton of added-on features.
- Nothing has led us to believe that it is infeasible to control different lights in an LED system in real time through signals from a Raspberry Pi and/or Arduino/other microcontroller unit.
Were any changes made to the existing design for the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what cost does this change incur, and how will these costs be mitigated going forward?
- Due to our TA helping us discover a way to make API calls to retrieve Spotify song recommendations, we started considering an option to use their machine learning recommendation service instead of tuning a model ourselves. This would allow us to pivot our recommendation node’s focus partially away from machine learning and into feedback systems, by increasing the weight of inputs from the sensors as well as User prompting options (such as “Play more songs like this/from this artist/from this album/in this genre). We would also potentially utilize Spotify’s recommendations as the baseline against which to test our more comprehensive DJ system for a greater User satisfaction rate.
- No other changes in the system design