The main risk we have at the moment is getting the dimensions of the chassis correct. We do not have very accurate measuring equipment, so we had to resort to mostly eyeballing the dimensions of the keys/keyboard using a measuring tape. The measurements appear accurate enough when looking at the Solidworks rendering, but we will not be sure until we print it out. Additionally, placing the chassis on the keys may prove to be a challenge, and we may need to adjust the design of the chassis, but otherwise, the physical portion of the system seems to be coming along smoothly.
One change we have made to our design is the decision to use secure copy through ssh to transfer the XML files to the Raspberry Pi. We decided on this route because we found that the latency for sending one page of an XML file through serial communication was too slow (over 13 seconds) to be acceptable. We tested manually scp-ing files to the Raspberry Pi with success. This may require some extra work in running a powershell script to scp to the Raspberry Pi. We believe this will not incur a heavy cost since one of our team members, Rahul, has gotten some experience writing powershell scripts earlier in the semester. From the user’s standpoint, this may require the user to configure the Raspberry Pi on startup to connect to new networks, but we believe the tradeoff of a one time setup in exchange for much faster file uploading speeds is justified because the user will want to upload many files for all the different pieces they will play during the product’s lifetime.
Another change we have made to the design is to no longer support placing the accompanyBot on any starting key. Originally we wished to have the capability of placing the solenoids over any configuration of white and black keys by adding extra solenoids and remapping the GPIO pins. However, based on the physical measurements and differences between the spacing of the black keys, we found that it is physically impossible to account for that, so instead we will have to fall back on our original constraint of a fixed starting key. However, we will still be able to move the accompanyBot up and down octaves, so there is still the ability to play all the notes on the keyboard.
Lastly, a change was made to the pipeline of how the xml file gets processed. Previously we had intended for it to get immediately shipped off to the notes scheduler. After feedback from our interim demo, we allowed for digital playback of the xml via midi signals before the accompanyBot solenoids receive the information to begin playing. This requires operation of the computer speakers which were previously not factored into our design.
For the interim demo, we created an updated Gantt chart showing the tasks that we will be working on for the last three weeks of the semester. The updated schedule is attached here.
During our interim demo, we were able to successfully show the end-to-end communication for starting the music, pausing the music, and updating the current measure number (both from the computer to the RPi and sending the measure number back so that the GUI could update the state). Here is a video of the current implementation in action.