The remaining risks are primarily related to presentation quality and clearly communicating our results in the final poster and report. We are managing this by organizing our data, refining how we present metrics, and making sure our results clearly map to our requirements. Since the system itself is stable and validated, there is minimal need for contingency planning beyond ensuring all results and visuals are properly documented. If any issues arise, we can fall back on our tested data and MVP demonstration.

No major changes have been made to the system requirements, block diagram, or overall system specification. The team has remained consistent with the original design and focused on executing testing and validating performance. Any minor adjustments made were related to testing procedures and measurement methods to ensure accurate and reliable results.

Our unit tests included steering error measurement using a protractor-based 2D setup, interferer suppression testing by comparing input/output dB levels at a 60° offset, and latency testing using input-to-output timing measurements. Our system-level tests included target lock accuracy testing through repeated human trials and overall integration testing of the full pipeline. Based on results, the system meets all major requirements, including target lock accuracy (91.4%), steering error (12.3° AAE), interferer suppression (8.7 dB), latency (84.9 ms), cost (~$447), and setup time (1.5 minutes). Intelligibility testing was completed separately and confirmed that the system meets the ≥20% ASR improvement requirement.

No major design changes were required, as the system architecture proved effective. The improvements were focused on refining testing methods, ensuring accurate measurement, and stabilizing system performance. Overall, experimentation validated that the system meets its engineering requirements and performs effectively for its intended use case.

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.

 

This week our team focused on finalizing the physical integration of our system and preparing for our upcoming demo. 

Most Significant Risks & Mitigation Plans

Risk: System Integration Issues
As we combine all hardware components into a single enclosure, there is an increased risk of connection failures, loose wiring, or misalignment that could impact system performance.

Risk Management:

• Secured all components to enclosure parts
• Strapped internal wiring down to reduce strain and disconnections
• Performing tests to ensure connection stability

Contingencies:

• Quickly disassemble and re-seat components if failures occur
• Keep spare mounting materials and connectors available

 

Risk: Software/Hardware Communication Errors
Even if components are physically connected, there is still a risk that the system may fail to properly detect or utilize them within the software.

Risk Management:

• Verified all devices appear correctly in the UI
• Tested full system operation under realistic conditions
• Monitored output to detect failures early

Contingencies:

• Debug using terminal outputs and device recognition tools
• Isolate and test each component individually if needed

Changes

No changes made to the design.

System for Demo

Plans for Next Week

Next week, our team will focus on refining system performance and preparing for the final demonstration. This includes improving reliability, addressing any issues identified during testing, and ensuring consistent system operation. Additionally, we will work on finalizing documentation and polishing both the hardware presentation and software interface to ensure a smooth and professional demo.

 

The most significant risk right now is not having the full physical system assembled and stable in time for the interim demo, mainly because the chassis and 3D printing have taken longer than expected. Since the cameras and microphone array depend on the chassis for secure mounting and alignment, delays in this step affect our ability to fully demonstrate the integrated system. We are managing this risk by keeping the team focused on interim demo priorities, preparing all other subsystems in parallel, and planning to move quickly into final assembly and testing as soon as the chassis is ready. Our contingency plan is to present the most complete version of the system possible, even if the full physical integration is not finalized, by demonstrating subsystems, test infrastructure, and the progress already made toward the final prototype.

At this time, no major changes have been made to the core system requirements, block diagram, or overall system specification. The team’s effort has been concentrated on preparing for the interim demo and completing implementation rather than revising the design itself. Any adjustments made recently have been limited to practical integration details, particularly around the chassis and mounting approach, in order to ensure the hardware can be assembled securely and demonstrated effectively. These adjustments do not create major additional cost beyond minor time and iteration, and we plan to mitigate those costs by finalizing the physical design as efficiently as possible so the team can return focus to testing and validation.

One of the most significant risks at this stage of the project is designing a chassis that securely mounts the cameras while maintaining proper alignment with the microphone array. Because the system relies on visual detection and directional audio working together, even small shifts in camera positioning or misalignment between the cameras and microphones could negatively affect speaker identification accuracy and steering performance. Ensuring the physical stability and precision of the hardware layout is therefore critical to achieving reliable system behavior during testing and operation.

To manage this risk, the team plans to carefully evaluate multiple design options for the device’s chassis before finalizing a solution. We will use an iterative prototyping approach, gradually refining the physical design to ensure the cameras remain stable and correctly aligned with the microphone array. This process will involve testing different mounting approaches and making adjustments based on observed performance and stability.

At this time, no contingency plan is necessary because the risk is manageable through design iteration and careful prototyping. No changes have been made to the system requirements, block diagram, or overall system specifications in the past couple of weeks.

A was written by Cole Franklin, B was written by Nasir Crownie and C was written by Omar Ghabayen. Nasir reviewed and edited for unity.

A. Global Factors

The Focus Field project considers global factors by addressing a communication challenge that affects people in many different regions and work environments around the world. As remote work, virtual meetings, and online collaboration become more common globally, many people participate in calls from noisy homes, shared offices, or public spaces. By designing a low-cost system that improves speech clarity without requiring specialized infrastructure, the project aims to support clearer communication for users across different countries, professions, and levels of technical experience.

B. Cultural Factors

The project also considers cultural factors by recognizing that communication technologies should support speakers of many different languages and backgrounds. People participate in meetings, classes, and collaborations using a wide variety of languages and accents, so the system is designed to improve speech clarity without relying on language-specific processing. By focusing on isolating the active speaker’s voice rather than interpreting the language itself, the device can support clearer communication for users regardless of the language they speak, helping make the technology more inclusive and accessible across diverse cultural communities.

C. Environmental Factors

The Focus Field project has minimal environmental impact because it is designed as a small, USB-powered desktop device. It does not require large infrastructure, high energy consumption, or specialized installations, and it operates using standard computing hardware that is already common in many work environments. As a result, the system does not significantly affect natural resources or the surrounding environment beyond typical low-power electronic device usage.

This week our team received all of our ordered components. These components include the 8-channel USB mic-array and the three USB cameras. This was a huge week for our team since we were finally able to put our work together and test it on some real components. The main work we focused on this week was setting up and testing out the components to ensure they were working properly. Additionally, our group has been finalizing the details of our design report. 

Most Significant Risks & Mitigation Plans

Risk: Processing Overload

This remains our biggest concern in our design. The simultaneous use of the 3 USB cameras with the 8-channel mic-array requires a lot of processing and may overload the CPU and USB bandwidth of the Raspberry Pi 4.

 

The risks associated with this processing overload can lead to potential frame drop, increased audio latency, and overall system instability.

Risk Management:

• Switched from CSI camera plan to UVC USB cameras for easier driver support.
• Reduced camera resolution target from 1080p at 30fps to 720p at 30fps
• Raspberry Pi Cooling system

Contingencies:

• Adding an additional Pi for vision processing and communicate via Ethernet
• Lower camera frame rate (20–24 fps).
• Using hardware-accelerated vision libraries

Design Changes Made Since Last Report

None.

Schedule Changes

None.

 

Most Significant Risks & Mitigation Plans

Risk: Processing Overload

This is by far the biggest concern within our project. Right now our design will process three 1080p USB cameras and an 8-channel microphone array in order to achieve vision detection with audio direction of arrival tracking simultaneously on a Raspberry Pi 4.

 

The risks associated with this processing overload can lead to potential frame drop, increased audio latency, and overall system instability.

Risk Management:

• Switched from CSI camera plan to UVC USB cameras for easier driver support.
• Reduced camera resolution target from 1080p at 30fps to 720p at 30fps
• Raspberry Pi Cooling system

Contingencies:

• Adding an additional Pi for vision processing and communicate via Ethernet
• Lower camera frame rate (20–24 fps).
• Using hardware-accelerated vision libraries

Risk: USB Bandwidth & Power Limitations

This is our second main concern with our design. Since we plan on using a single Raspberry Pi, with all three cameras using USB connections can lead to possible power instability and audio glitches.

Risk Management:

• Using 27W power supply
• Ensuring cameras all UVC
• Planning controlled USB port distribution
• Monitoring power draw under full load.

Contingencies:

• Using an externally powered USB hub.
• Reducing camera resolution
• Moving mic array to dedicated USB controller

Design Changes Made Since Last Report

Change:  Raspberry Pi 4 Model B instead of Raspberry Pi 5

This is by far the biggest change in our design. Our original design was set on using a Raspberry Pi 5 in order to maximize CPU headroom, USB bandwidth capabilities, and any future scalability. Our updated design will now use a Raspberry Pi 4 Model B with 8GB of RAM as the primary processing unit.

 

Reason:

In order to maximize the use of our budget we were looking to get our Raspberry Pi 5 (8GB)  from the ECE inventory, however at the time of requesting for a Pi 5 there were none available. Raspberry Pi 4s were available with 8GB of RAM, which will still meet our project needs. This change was technically not necessary, as we do still have room in our budget to order a Raspberry Pi 5 if it is absolutely necessary.

Tradeoffs:

Switching to Pi 4 introduces a few key technical constraints:

• Lower CPU Performance
• Decreased USB Bandwidth
• Thermal Headroom

This increases the importance of software optimization and staged testing

Mitigations:

 

• Lowered Resolution – Setting camera default resolution to 720p instead of 1080p. This will decrease the total required processing of the Raspberry Pi

• Integration by Subsystem.

 

• Validating the visual system independently first
• Validating the audio system next
• Integration of fusion system at the end

 

• Performance Budgeting

 

• • Monitoring CPU usage during each subsystem test to ensure that we are on target for the final design.
  • Setting hard thresholds for CPU usage during tests
• Contingency Plan
  • Reduce frame rate (20–24 fps).
  • Use more lightweight detection models.
  • If necessary, disable one camera and reduce the system to 240° coverage.
  • As last resort: distribute workload across two Pi 4 units.

Overall Impact of Pi 4 Transition

• Reduces cost
• Slightly increases performance risk
• Forces stronger optimization on the software end
• Does not fundamentally change system architecture

The system remains feasible, but integration and benchmarking are now higher priority tasks.

Change: CSI Cameras to USB Cameras

Our original design had us using 3 CSI wide angle cameras to reach a 360 degree field of view. Our updated design will be using 3 UVC USB wide angle cameras.

Reason:

• The Raspberry Pi only 2 has two CSI ports. If we were to use three CSI cameras it would require multiplexing for the cameras. This would complicate the system and prevent simultaneous 360 visuals.
• USB cameras simplify driver management and scalability.

Cost Impact:

• There is a slightly higher per-camera cost
• THe total USB bandwidth load is now increased.

Mitigation:

• Reduced resolution target.
• Using efficient compression formats.
• Planning bandwidth testing early.

Schedule Changes

There are no changes that are being made to our schedule. 

Global Factor Considerations

A was written by Cole Franklin, B was written by Nasir Crownie and C was written by Omar Ghabayen.

A. Public Health, Safety or Welfare

This does not apply to our application.

B. Social Factors

The Focus Field project considers social factors by addressing how people communicate across different environments shaped by cultural, social, and economic differences. Many individuals work or study in shared spaces, crowded homes, or community settings where background noise can limit their ability to participate fully in conversations, meetings, or classes. By providing a low-cost, easy-to-use device that improves speech clarity without requiring specialized spaces or equipment, the project supports more inclusive communication and helps people engage more effectively within their social and professional communities.

C. Economic factors

The project also considers economic factors by prioritizing affordability, scalability, and practical deployment. Focus Field is designed to undercut expensive enterprise communication systems while still delivering meaningful performance improvements, making it accessible to students, remote workers, and small organizations. By keeping hardware costs low and setup simple, the system supports wider adoption and aligns with real-world constraints around the production, distribution, and use of technology in everyday work and learning environments.

There are two main risks that could jeopardize the success of our project: delays in receiving hardware components and the possibility that our initial proof of concept does not work as expected. To manage potential shipping delays, we planned ahead by identifying alternative components already available in our inventory so we can continue early testing/proof of concept while waiting for ordered parts to arrive. For technical risk, we are allocating sufficient time to build, test, and debug a minimal working prototype before scaling the system. If challenges arise, our contingency plan is to focus on engineering a simpler version of the design first, then iteratively expand functionality once core performance is validated.

Following our project presentation, we began reviewing our ASR error reduction requirement after Professor Qing questioned how directly it reflects system performance. The concern was that demonstrating a functional prototype may already imply improvements in speech recognition, making the requirement less meaningful as a standalone metric. As a result, we are refining how this requirement is framed so it better represents measurable system impact and aligns with our project goals. This requirement change does not introduce significant cost.

At this time, no changes have been made to the project schedule. Our development timeline remain aligned with the original plan.