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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *