This week our team focused on two major areas of progress: refining the physical design of the system enclosure and finalizing the method for audio output from the Raspberry Pi to the laptop.
One of the most important updates this week was a change to the physical enclosure design. We redesigned the base of the system using stacked laser-cut wooden layers rather than relying on the previous approach. This change was made to create a structure that was easier to fabricate while still providing the support and shape needed for the full system. The new base design also better supports the enclosed hardware configuration and improves the overall practicality of the build.
The second major design update involved the system’s audio output. Initially, our team planned to output audio from the Raspberry Pi directly to the laptop using a USB B to USB C connection. However, during testing we found that the laptop was not able to recognize this connection as a microphone input, which created a major issue for the intended use of our system. To solve this problem, we changed our design approach and instead adopted a Bluetooth-based method using a software-based tool that allows the laptop to recognize the Raspberry Pi audio output.
Most Significant Risks, Risk Management, and Contingency Plans
One of the most significant risks to the success of the project remains system integration reliability. Since the project depends on multiple hardware and software components working together, there is always a risk that one part of the system will fail or behave unexpectedly when integrated into the full design. Our team is managing this risk through continued testing of the complete system rather than only validating individual parts. By testing the assembled design and the final audio path together, we are better able to identify issues before final validation.
Another important risk involves the audio output method. Because we had to move away from the original wired USB output plan, there is some risk associated with relying on a Bluetooth-based solution. This includes possible latency, connection consistency, and dependence on third-party software or a web-based tool. At this point, the added latency appears to be minimal and not significant enough to jeopardize the project, and the setup process is actually easier than the original approach. To manage this risk, our team will continue testing the Bluetooth output under realistic use conditions. If necessary, our contingency plan is to preserve a stable demonstration setup using the current working solution even if further technical refinement is limited.
A third risk is the possibility of late-stage design changes creating extra debugging work. Because our team is still refining the final physical and output design, any issue discovered during final integration could require additional iteration. We are managing this risk by locking in the current enclosure and audio-output decisions now and focusing on validation rather than large redesigns moving forward. Our contingency is to prioritize the core functionality of the system and avoid making unnecessary changes unless they are required for system operation.
Design Changes
Yes, our team made changes to the existing design of the system this week.
The first change was to the physical enclosure design, specifically the base of the system. We redesigned the base using stacked laser-cut wooden pieces. This change was necessary because it provided a more practical and manufacturable solution for supporting the full system structure. It also helped us move toward a more complete physical prototype while avoiding a more difficult or time-intensive fabrication process. The main costs associated with this change were additional redesign time and fabrication effort. These costs were mitigated by using accessible materials and a relatively efficient laser-cutting process.
The second design change was to the audio output method. Our original plan was to send audio directly from the Raspberry Pi to the laptop through a USB B to USB C connection. This approach proved unsuitable because the laptop did not recognize the signal as microphone input. As a result, we changed the design to use a Bluetooth-based output solution enabled through a software or web-based platform. This change was necessary in order to make the audio output usable in the way required by the project. The main cost of this change is the introduction of a small amount of latency and the need to rely on an additional software layer. However, this cost is being mitigated because the latency is not significant and the new solution is actually easier to set up than the original wired plan.
Updated Schedule
None.