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.

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.

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

Thomas’ Status Report for 2/10/24

Thomas Lee

  • I helped compose the Proposal Presentation slides, more specifically by helping come up with technical requirements & challenges, and researching sources to justify these requirements (refer to Proposal Presentation slides). Additionally I helped divide the work among the team members and made the Gantt chart. I also researched the specific hardware components we would be planning on using, and looked into microcontroller system to control the LED signals.
  • Progress is on schedule this week
  • In the next week we hope to begin ordering components and more specifically & clearly define our solution’s design for the Design Presentation coming up the subsequent week. More specifically we plan on picking a few different communication protocols, programming languages, and subsystem structure for the long-running processes we would be using to keep our system functioning and online