Posted on

Aden’s Status Report for 3/11

In the past two weeks, I primarily worked on the design report. I spent the last few days of the week before spring break writing and editing until we were prepared to submit. Aside from writing the report, I have put together a circuit of five solenoids controlled by an Arduino to determine roughly how much power they consume. Five solenoids turned on at once is our worst-case scenario, so I wanted to ensure that our calculations were correct and that they it does not exceed 60W. I found that if we power the solenoids with their maximum voltage (12V), the five solenoids only draw 4A of current, placing their maximum power consumption around 48W. Additionally, I was testing it with PWM signals, and the solenoids draw even less current. If we are strapped for power, we can use PWM signals instead.

(The image is a bit blurry, but it says 12V and 4.009A.)

This progress is on schedule with our most up-to-date Gantt chart. After spring break, I will begin to put some serious thought into the design of the structure that will hold up the solenoid circuit.

In the coming week, I plan on having a well-thought-up sketch of the chassis. Additionally, since we were thinking about 3D printing the structure, I would like to play around a get a mockup on Solidworks. My goal for the week is to provide something substantial for the course staff on what our chassis will look like.

Posted on

Rahul’s Status Report for 3/11

Most of my time on the project this week was spent writing the design review report with my team. In addition to writing that paper, my task in the Gantt chart was to create the UI mockup for the accompanyBot application. Early on, I had made an initial design for the proposal. I decided to make modifications on that to make the colors more aesthetically pleasing as well as make the functionality more feasible.

For reference, this initial mockup had highlighted the note or rest that was currently being played or in queue on the accompanyBot device:

This functionality would require additional machine learning and synchronizing between the subsystems that would deviate from the rest of the project. Additionally, this design was lacking the tempo modifier that was specified in our use case requirements.

For our design review report, I updated our UI model to this version:

The new design incorporates a dark theme which will have less strain on users eyes, the tempo modifier which will be dynamic and prevent input speeds which are too fast, and a current measure display to replace the highlighted note(s) of the previous design. The current measure will be feasible as music21  allows image generation from segments of measures from the original score. So for a score with 100 measures, the system will create and store 100 small images of measures in local memory.

Inevitably, more changes will likely be made to the front-end design come implementation. To account for this, I decided to get started learning the pygame documentation and begin implementing. For now I have developed a proof of concept display:

Now, I know where to look to create the precise visuals such as rounded corners or underlined font. The main concern with visuals is that I found pygame’s image rescaler to very much degrade overall image quality. This results in missing music staff lines when displayed. I will likely delegate rescaling and other poor operations to be performed as OS jobs.

I will have to clean up the app code into modular sections to continue development, but so far I am in a good position to hopefully finish the bulk of the application by next week. Once we start integrating my team and I will have to figure out PyUSB and our data transmission protocol between subsystems so that I can successfully send signals to the RPi, and Nora and Aden can implement the reception of these signals to complete the control of the accompanyBot.