The most significant risk related to the audio portion of the project is the consistency and reliability of Accomplice. While it’s been working for the most part through my testing, there’s been an issue with receiving OSC messages (mentioned more in individual reports) that should be fixed soon by Professor Dannenberg. Although this challenge should be addressed presently, there’s a worry that other issues could pop up in a variety of circumstances, and we’d have to prepare and solve each of them. This shouldn’t be impossible, but it might be difficult and annoying, especially because we wouldn’t know if it’s an issue on our side or in the Accomplice software unless we check in with Professor Dannenberg continuously. Another possible risk we have is that the VESC motor controller we’re currently using had one of its micro-usb ports for communication break off, so we’ll try to solder it back on. If that fails, we plan on trying to use the UART communication ports with the GPIO pins to control. We also had one of our printed parts for the rail system break recently, which delayed our assembly by a bit. To counteract this, we plan on printing extra parts for high strain areas of our design to ensure that if any future parts break, we’ll have a quick way to replace them and get back to testing/building.
One minor change that was made to the design of the audio system was the usage of a USB-B to USB-C adapter instead of the predetermined MIDI interface for connecting the MIDI keyboard to the Mac. Our idea is to have a RPi 5 connect to the keyboard and send cues to the central Pi, and so we will check that the USB-C port on the RPi keyboard can be used for a non-powering purpose. If this doesn’t work, we’d have to purchase an adapter from USB-B to a different USB type that’s available on the RPi. This causes one of the nodes to be used as a middle communication device as it’ll provide key information for the AutoCam system to change scenes. This upcoming week we hope to finalize the hardware integration of the AutoCam. As we finalize the hardware integration, we can bring all the systems together. From the audio cue system to the UWB tracking system. We will utilize both systems to finalize the motor controller software. This will be specifically done through the mathematical work of homography. For validation, we look to confirm the durability and the consistency of our product. We will be running the entire system at expected workloads to determine that it can work accurately for the full length of an opera or a theater performance. Each subsystem’s accuracy will be vetted thoroughly, and descriptions have been included in the individual reports. Validation testing will be done to measure the latency between the completion of the performer’s dialogue, the triggering of the cue, and the actual movement of the motors, which can then be used to optimize and minimize the time required. Additionally, final UWB accuracy testing will be performed from ground truth location to the filtered estimated location of the node. Finally, we will be testing the waterproofing nature of our wearable components and ensure that they are wearable and durable based on survey feedback from the performers and stress testing with water at different intensities. Noise levels will also be measured to ensure that our design won’t be overpowering the important audio in either the opera performances or stageplays. We’ll be spending the next couple weeks working with the opera students to ensure that our system meets their needs and fine tuning our subsystem integration.