Author: sunac

What are the most significant risks that could jeopardize the success of the
project? How are these risks being managed? What contingency plans are ready?

HW: I am a little scared that with all of the testing, we have been doing that our solenoids will burn out (from “too much” use). However, we have some extra solenoids and have been using MIDI in place of the solenoids for testing at home.

SW (CV): I think the biggest risk at this point is integration between mine and Lances part, but it should be fine. We still have a working MVP either way.

SW (Music): Serial pipeline failure. It’s robust and can accurately handle errors, but during recent testing with a robotics capstone project it has had some strange errors where it randomly disconnects (from a Raspberry Pi). A disconnect during our demo wouldn’t be the end of the world, but it would be annoying, especially since both programs would need to be restarted. Integration isn’t much of a concern in my opinion. I just need to know what values to expect on the Python side, and I just need pins on the Arduino side.

Were any changes made to the existing design of the system (requirements,
block diagram, system spec, etc)? Why was this change necessary, what costs
does the change incur, and how will these costs be mitigated going forward?

HW: N/A — but if the solenoids were to burn out, then we will be using MIDI keys as a replacement.

SW (CV): Working on symbol detection, as mentioned before, but thinking of combining it with color detection as described in my post.

SW (Music): Not really a huge design change, but I’m no longer representing music in 32nd notes. Instead I’ve jumped down to 8th notes so that we can play at higher tempos and jump through more chord progressions quicker. This will lead to a smoother user experience in generative mode as well.

Provide an updated schedule if changes have occurred.

HW: N/A

SW: N/A

SW (Music): N/A

This is also the place to put some photos of your progress or to brag about a
component you got working

HW: N/A

 

(Extra question for this week) List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

HW: when building the circuit, I tested individual solenoids to ensure that they were connected correctly and tested them with the rest of the system to ensure that they were connected/integrated correctly with the entire system. Some of the unit tests I conducted were: just turning on one solenoid at a time, randomizing the arduino keys and playing at most 4 at a time. For “old” solenoids, I noticed that when more than one key was playing concurrently, there was a bit of lagging time, which I roughly timed it as < 100ms — this latency issue was purely from the age of the solenoids. As for the general latency between the arduino code and the solenoids, 40ms latency was observed — which was not significant in our system. I am hoping to measure the latency between the user playing the key using our object-detection system to the actuators playing the keyboard this week — however, in our informal testing, the latency was approximately 150ms (this was measure as soon as we saw in the print statement that a certain key was detected — however, there is definitely some latency in reading/detecting the object itself).

SW(CV): One test I needed to run was the time from when the user puts the color into the right box and when the code recognizes it. This is a test that I expect to change when I am finished with the final implementation of combining symbol detection + color detection, but I doubt it will change very much. I measured about 600 ms on average, which is not bad, but I do think it will change by demo time. The other test I ran was the rate of detection. This can be negatively affected by other objects that have a red hue that the camera picks up. I measured it to be accurate about 92% of the time. However, I do expect to get a better value when I fully integrate the symbol detection in.

SW (Music): I’ve done a lot of unit testing for both music and serial code. For music, my main concern was the generative mode. There’s only one thing to test, and that’s the generation output. I use normal distributions to pick notes and rhythms, so what I did was just generate a bunch of melodies and checked to see if they made sense with the progressions that they were over. This was mostly opinion based, so I just vibe checked all of them. I also checked to make sure that the rhythms were reasonable. I wasn’t really satisfied with those results, but since I’m switched to a slower model, I have a lot of chances to tweak generation probabilities. I did do some brief tests on generating rests, but honestly it just wasn’t really worth it. Notes naturally die out anyways, so there’s not much point in actively “playing” the rests (even though good musicians should do that!) since our project is more geared towards simple things. For serial/Arduino, a huge majority of my tests were done during the heat of debugging, so I don’t really remember them exactly. However, it was things like “stepping through each and every byte I’m supposed to send using the Serial Monitor” and “sending a single byte and tracking every location it goes to.” This evolved into tests with Python interfacing like “sending a sequence of data and having the Arduino report success back” which inevitably evolved to “sending the same string of data and then reading in as much data as humanly possible from the Arduino so that I can figure out where my bytes are going.” Then once the pipeline worked (or was at least half-functional) I started sending melodies off to the Arduino, then chords. For the majority of the semester, I haven’t had any solenoids to test with, so at first I started off with just having the Arduino report what notes it was playing. Then, after Professor Sullivan recommended trying out MIDI output as well, I remembered a MIDIUSB library I briefly used when trying to build an electric vibraphone a few years ago. I shook the dust off of that and made it so that I could have the Arduino interface with FL Studio, and I started testing notes and melodies that way. FL Studio doesn’t really ensure that circuit integration will go well though, so I also set up a simple LED circuit that I could use to test melodies on. It’s currently 7 LEDs, and I was going to extend it to 14, but since we only have about 10 solenoids, I’ll most likely just stick with the 7 and pass extra notes into FL studio. The tests here were just in sending notes, chords, melodies, everything. I also did some simple timing tests by flashing LEDs at various tempos, etc. As long as the Arduino is in time, aged solenoids will sound rubato at best and drunk at worst, which still isn’t terrible at lower tempos. I plan on continuing with these tests throughout integration and up until the demo.

What are the most significant risks that could jeopardize the success of the
project? How are these risks being managed? What contingency plans are ready?

HW: one of the unexpected risk that we encountered this week was us needing to buy more solenoids. Another thing that I noticed was some latency issues with the actuators. I noticed that some of the old solenoids were actuated with a bit of latency and I think it’s just due to us using it “too much.” I marked it in case this becomes a bigger issue. As long as I just connect everything correctly to the first octave, we should have some extras to replace the “lagging” actuators with new ones.

 

SW/Fabrication: One risk is that the adhesive we ordered could not work as well as hoped on acrylic and the mounting system could fall apart like last time. Our contingency plan can just be superglue, because I think it will probably work well enough. Worst case, I have some super strong T-Rex tape.. it will just not look very pretty. Software wise, same as last week. If the symbol detecting isn’t good enough, I will fall back on the color detection.

Were any changes made to the existing design of the system (requirements,
block diagram, system spec, etc)? Why was this change necessary, what costs
does the change incur, and how will these costs be mitigated going forward?

HW: n/a — we did have to buy more solenoids due to my carelessness.

SW: no

“ Provide an updated schedule if changes have occurred.

HW: n/a

SW: n/a

“ This is also the place to put some photos of your progress or to brag about a
component you got working.

HW: https://youtube.com/shorts/Cnb2aESx0gw

 

What are the most significant risks that could jeopardize the success of the
project? How are these risks being managed? What contingency plans are ready?

HW: I am a little scared that we might have to order more solenoids in case of burnout? We currently have 7 working solenoids and ordered 7 more because we had leftover solenoids in the toolbox but now they are gone. It’s not the worst risk since we can always order new ones. However, I am also a little worried about the power supply availability. If we can’t get the 30V/3A power supply, we can’t run this system.

SW: I am still worried about object detection, but like before, my backup is using the color detection that is already working.

MSW: I’m a little worried about melody generation. Generating random things isn’t that difficult, but I think that even generating mediocre melodies will be difficult. I don’t think that it will be possible to generate great melodies, at least consistently. Great melodies are difficult to write by hand, so creating an algorithm to do so would be an achievement by itself (and something I could probably sell for a large sum of money).

Were any changes made to the existing design of the system (requirements,
block diagram, system spec, etc)? Why was this change necessary, what costs
does the change incur, and how will these costs be mitigated going forward?

HW: nope

SW/Fabrication: I did redesign the mounting system because the 3mm did not hold the weight of the solenoids very well. The cost is going to be around $30, but hopefully this is the last redesign. SW – no.

MSW: Nothing major. Just small data structure changes to accommodate new data/changes.

Provide an updated schedule if changes have occurred.

HW: n/a

MSW: No change.

This is also the place to put some photos of your progress or to brag about a
component you got working.

What are the most significant risks that could jeopardize the success of the
project? How are these risks being managed? What contingency plans are ready?

HW: I am a little worried that we are not able to solder the components to a protoboard. However, as long as we keep our wires organized, I think we can keep building our circuit on a breadboard. However, this is not a very significant risk in terms of running the system.

Music SW: Melody and chord generation have me somewhat worried. I don’t want to generate unusable garbage, but I don’t want to make everything predictable either. Our generative mode is one of the two main modes we want to implement, and if it’s not good, that’s going to be a problem.

Software (note that my stuff was overwritten earlier so I am resubmitting now): The object detection is the biggest risk still, as I have tried a lot of methods but nothing is working well still. The contingency plan is to use the color detection that is already working.

Were any changes made to the existing design of the system (requirements,
block diagram, system spec, etc)? Why was this change necessary, what costs
does the change incur, and how will these costs be mitigated going forward?

HW: we have decided not to solder.

Music SW: None since last week. I’ve been changing up struct internals to see what works best, but it doesn’t affect the overall system.

SW: Not since last week.

Provide an updated schedule if changes have occurred.

 

This is also the place to put some photos of your progress or to brag about a
component you got working

HW: N/A — will show our working circuit on Wednesday!

Music SW: Nothing here. I did sync the Arduino LED to an interesting rhythm but it wasn’t much to write home about.

SW/FAB (Katherine): added photo of the mounting system I designed in the slack.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

HW: I am a little concerned about my lack of ability to implement this hw system without burning components and possibly running out of money. Also, for some reason, when I soldered the components to the proto-board, it wasn’t working as well. Unclear why that was happening though. For now, we are using the breadboard.

SW: I am concerned about creating the dataset needed to detect my symbols. However, my contingency plan is using the color detection that is already working if I can’t get that to work.

Music SW: I’m vaguely worried that in changing a lot of things around both for integration and improvements that I may break the code, leading to large delays without rollbacks. I have been backing up my code, but I’m not satisfied with its current performance.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

HW: I originally wanted to solder my components but for the upcoming demo, we will just use the breadboard to do it. There is no change in cost.

SW: I changed how we detect movement, because using color was hard if there were any colors in the background and colors on the perosn’s clothes. Now I am trying to use symbols. No additional costs.

Music SW: I changed a lot of the internal working of the code, mostly for ease of representation and modularity, but overall it has not changed any large portions of the project.

Provide an updated schedule if changes have occurred.

HW: N/A

SW: I can’t upload photos in WordPress for some reason… It is just giving an error. But we had my schedule end now anyways so I am just adding a week for symbol detection and creating the mounting system, and the following week for more advanced feedback using the symbol detection.

Music SW: My schedule has an added week for code refinement, but overall it has not changed much.