Team Status Report for 04/25/2026

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.

Nasir’s Status Report for 04/25/2026

This week I completed intelligibility testing for the Focus Field system using our defined speech-to-text (STT) comparison method. I recorded baseline audio using a standard headphone microphone and compared it against audio processed through our system, then ran both through the same STT tool. I measured performance using word-level error metrics (missed words, extra words, and substitutions) and computed the overall error rate and relative improvement. Based on these results, our system meets the ≥20% ASR error reduction requirement.

At this point, we have completed testing across all major system requirements and have validated that the system meets our design goals. This week I plan to finalize contributions to the project poster and complete my sections of the final report. I also want to ensure that all testing results are clearly documented and presented in a way that supports our design requirements and overall system performance.

Cole’s Status Report for 04/25/2026

This week I focused on finalizing the physical enclosure and overall appearance of our capstone project in preparation for the final project report and demonstration. Since this is the final weekly status report before our Final Project Report is submitted, my main goal was to make sure the system looked complete, professional, and structurally stable.

A major part of my work this week was updating and 3D printing the revised camera mount. After identifying areas of the previous mount that could be improved, I printed the updated version and used it to reassemble the camera section of the project enclosure. This step was important because the camera mount is one of the most visible and functional parts of the system, and it needed to properly hold the cameras in position while also fitting cleanly with the rest of the enclosure.

After printing the updated mount, I reassembled the project enclosure with the new component installed. This involved carefully repositioning the cameras, checking alignment, and making sure the updated mount worked with the rest of the physical structure. I also reglued the necessary enclosure pieces to ensure that everything was securely attached and structurally stable. Since our system includes multiple hardware components, wires, and mounted devices, making sure the enclosure was solid and reliable was an important final step before testing and presenting the completed project.

Earlier versions of the enclosure were mainly focused on holding the components in place, but this week’s work focused on improving the final appearance, stability, and readiness of the system. 

Schedule

Our progress is currently on schedule. The remaining work is focused on documentation and preparing the final deliverables.

Next Steps

Next week I will be working on finishing up the demonstration video and completing the final project report.

 

Nasir’s Status Report for 04/18/2026

This week I focused on system testing and was able to fully complete testing for steering error, latency, target lock accuracy, and interferer suppression. I ran structured trials and verified that most of our system requirements are being met, with the exception of latency, which is currently slightly above the ≤100 ms target (currently at 104ms). I also spent time refining and debugging the testing process itself. Overall, this week was focused on collecting reliable performance data and ensuring that our testing methods are accurate and meaningful.

My progress is on schedule in terms of completing testing and validating system performance, but slightly behind on meeting the latency requirement. The next step is to optimize the system pipeline and reduce unnecessary processing delays. I am in a good position to quickly iterate and improve performance.

Next week I plan to run intelligibility testing. This will allow us to complete testing across all major system requirements. I also plan to continue refining system performance, particularly focusing on reducing latency to meet the ≤100 ms target.

Throughout this process, I had to learn more about system-level testing, especially how to correctly measure and interpret performance metrics like latency. One key realization was that designing a test is just as important as running it, since incorrect measurement methods can lead to misleading results. To learn these concepts, I relied on the strategy of troubleshooting through trial and error. This hands-on approach, combined with iterative debugging, helped me quickly identify mistakes and improve both my testing methods and overall understanding.

 

Team Status Report for 04/18/2026

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.

 

Cole’s Status Report for 04/18/2026

This week I focused on finalizing the physical fabrication of our system. The main work I completed involved laser cutting the base and final enclosure components for the system. This was an important step because it allowed me to move from earlier prototype structures to a more finished and fully enclosed design that can better support testing and demonstration.

Specifically my work focused on creating a new design for the base of the stand. Instead of relying only on previous fabrication ideas, I developed a new approach using laser cut wooden slices that could be stacked together to form the base component. This allowed me to build a stable structure while also using a more efficient fabrication method. I cut and assembled these layers to create the final base, which now supports the rest of the system more effectively.

In addition to fabricating the base, I also made sure that the enclosure design accounted for wire routing and full hardware integration. I cut holes for the wires and confirmed that the cameras, microphone array, and other necessary components could all remain enclosed while still functioning properly. A major part of this process was ensuring that the system was not only physically assembled, but also operational in its enclosed form. 

Plans for Next Week
Next week I plan to continue testing and validating the full enclosed system to ensure it meets all of our design requirements. I will also make any final adjustments needed to improve enclosure fit, wire management, or overall system presentation so that the prototype is fully prepared for demo.

Reflection on New Tools, Knowledge, and Learning Strategies

As I designed, implemented, and debugged my part of the project, I had to learn new tools and new knowledge in several areas. One major area of learning was fabrication strategy. Earlier in the project, much of my work was focused on 3D printed enclosure design, but this week I expanded that by using laser cutting as a practical fabrication method for the final base and enclosure. I had to learn how to adapt my design thinking to a layered construction approach, where individual wood slices could be cut and stacked to form a stable final component. This required a better understanding of how to design parts specifically for laser cutting rather than only for 3D printing.

I also gained more knowledge about physical system integration. It was not enough to simply create parts that looked correct on their own; I needed to ensure that the full hardware system could function while enclosed. This meant learning more about wire routing, spacing, component fit, and how enclosure decisions affect usability and testing. Designing holes for wires and confirming that all hardware could remain operational inside the enclosure helped me better understand the relationship between mechanical design and system functionality.

Another area where I built new knowledge was prototype validation. As the project progressed, I learned that building a physical component is only one step; it is equally important to test whether the fully assembled system still performs correctly. This required me to think more carefully about designing for both assembly and testing, rather than treating them as separate tasks.

To acquire this knowledge, I used several learning strategies. One of the most important methods was hands-on experimentation. By creating the design, laser cutting the parts, assembling them, and then checking how well they worked with the real hardware, I learned through direct trial and iteration. I also used online resources and examples to better understand fabrication options and practical enclosure design methods. In addition, I relied on problem solving through observation when I encountered design constraints, I adjusted the structure based on what I saw in the physical build rather than only relying on the original concept. Team discussion was also valuable, since talking through integration needs and testing requirements helped me better understand how my enclosure work supported the full project.

Overall, this project required me to expand my knowledge of fabrication, enclosure design, and system integration. I learned not only new technical skills, but also how to use practical, hands-on learning strategies to solve real design problems effectively.

 

Schedule Changes

None.

Omar’s Status Report for 04/18/2026

A major part of the week was hardening the production boot path and reducing dependence on local machine state. I generated Pi-local runtime config during service boot, resolved cached model paths against the service user, accepted cached runtime models in boot validation, and relaxed service shutdown timing so the service can stop more cleanly. I also tightened the production defaults so the main appliance path is more deterministic at bring-up.

In parallel, I separated the production and demo flows more cleanly. I expanded the demo-safe configuration, added explicit Pi demo profiles for live and observe modes, and tuned the UMA-8 capture path for stability while reverting one audio-tuning regression. I also updated the Pi runbook and demo launch workflow so the demo path is repeatable without weakening the production settings.

Another important thread was making the hardware probe path less brittle on Raspberry Pi. I fixed the camera probe to open concrete V4L2 nodes, allowed probing when sysfs capture metadata is absent, and tightened the Pi contract behavior around those edge cases. That lowers the chance of false negatives during hardware detection on the target platform.

I also expanded the test surface around the areas that changed most: boot validation, production defaults, and Pi hardware-probe behavior. The result is a better guardrail against regressions in the appliance path, especially around cached-model handling and config correctness.

Verification
Verification this week centers on boot correctness, config determinism, and probe reliability. The relevant checks are the updated boot-validation, contract, and production-default tests, plus live boot and shutdown validation on actual Raspberry Pi hardware.

Validation
Validation for this work is whether the system behaves like an appliance instead of a dev box. The main questions are whether a Pi can boot cleanly under the service user, load the correct runtime config, probe cameras consistently, and enter production or demo-safe mode without manual intervention.

Analysis of Results
The main result is a narrower failure surface. The boot path now depends less on ambient state, the demo path is clearly separated from production defaults, and the camera probe is less likely to fail on Pi-specific metadata gaps. That should translate into fewer field failures, less bring-up friction, and a safer operating model for demos.

Schedule
On track with the current Pi hardening and demo-stability push.

Next Steps
Next week, I’d run the updated boot and demo flows on real Raspberry Pi hardware, confirm the production versus demo-safe split in practice, and keep tightening camera and audio defaults until the appliance path is stable enough to treat as the default operating mode.

Nasir’s Status Report for 04/04/2026

This week I focused on running system tests and continuing development of our testing infrastructure for the Focus Field project. I conducted 67 human trials for target lock accuracy with 1–4 users and recorded results, achieving a 77.6% success rate (52/67), which shows the system is functional but still needs improvement. I also performed steering error testing by physically measuring angular offsets using a protractor in a 2D horizontal plane at 1 meter, aligning with our intended use case. In addition, I continued working on our testing suite, including debugging and fixing an issue in one of the automated test files. I also prepared the system for upcoming tests, including interferer suppression and latency, which already have implemented testing scripts.

My progress is on schedule in terms of development and testing, but slightly behind in meeting performance targets, specifically target lock accuracy. However, this is expected during the testing phase as we begin identifying system limitations. Moving forward, I plan to use the collected data to refine the system, focusing on improving accuracy through better alignment and potential algorithm adjustments.

Next week I plan to run interferer suppression and latency tests using the testing suites that are already implemented. I also want to begin intelligibility testing using our defined speech-to-text comparison approach. The goal is to collect full performance data across all requirements and continue improving the system based on those results.

At this stage, I have focused on verifying that individual components of the system meet their defined requirements through structured testing. For target lock accuracy, I verified system performance by running 67 trials and comparing the measured success rate (77.6%) directly against the ≥90% requirement. For steering error, I verified the system’s directional accuracy by measuring angular deviation using a protractor-based setup in a 2D horizontal plane at 1 meter and comparing results to the ≤15° threshold. I have also prepared verification tests for interferer suppression and latency, including implementing and debugging the corresponding testing scripts, although full results have not yet been collected. Additionally, I have defined the verification approach for intelligibility using ASR error comparison, which will quantify performance once executed. Overall, my verification work ensures that each subsystem can be quantitatively evaluated against its specific engineering requirements.

Team Status Report for 04/04/2026

At this stage, the main risks are improving target lock accuracy to meet our ≥90% requirement and finalizing a stable chassis structure for consistent hardware alignment. While we currently have a viable MVP that demonstrates core functionality, performance tuning and physical stability are the key areas that could impact final success. We are managing these risks by continuing structured testing, analyzing results, and iterating on both the algorithm and physical setup. The chassis is being refined through iterative design to ensure proper camera and microphone alignment.

No major changes have been made to the overall system requirements or architecture. However, we are refining aspects of the physical design, specifically the chassis, to improve stability and alignment, which directly affects system performance. These adjustments are necessary to ensure consistent and reliable testing results.

For validation, we are focused on demonstrating that the system meets its intended use case of improving speech clarity in multi-speaker environments. We have testing suites ready for interferer suppression and latency and have resolved initial bugs, with testing to be executed next. Intelligibility testing is also planned using speech-to-text comparisons to measure ASR error reduction. Moving forward, we will analyze results by comparing measured performance directly against our defined thresholds and iterating on both system design and hardware setup. Overall, while some metrics like target lock accuracy still need improvement, we have a solid MVP and a clear path to validating the system against our requirements.

Cole’s Status Report for 04/04/2026

This week I focused on preparing our system for the interim demo and continuing to refine the enclosure design as we move toward a finalized product. With the system now fully assembled and operational, my work shifted toward ensuring that everything is properly set up for testing and demonstration.

A major portion of my work involved setting up and organizing testing for our device. Since we now have a working system, I focused on making sure all components could be consistently run and evaluated. I verified that all hardware components were properly connected and stable, and that when running the code, the cameras and microphone array were correctly detected and displayed through the UI. This helped ensure that we are able to clearly observe system behavior and identify any issues during the demo.

In addition to testing preparation, I worked on developing the final version of the enclosure design. Based on previous iterations and physical assembly, I refined the design to improve overall fit, organization, and usability. The goal of this work is to have a finalized enclosure ready by next week that is both functional and presentable.

At this point, the system is not only operational but also being prepared for reliable demonstration and final design completion.

Verification

While my primary responsibility is the mechanical design, it is important that the enclosure not only functions correctly, but also supports the system’s goal of enhancing audio through accurate visual and audio input.

To validate this, I evaluated how my enclosure design performs when the system is used in realistic conditions. This involved observing whether the physical structure allows the cameras and microphone array to operate effectively when identifying and tracking a speaker. I ensured that the positioning and orientation of the cameras—determined by the mount—provide adequate coverage of the intended field of view, which is critical for accurate speaker localization.

Additionally, I assessed whether the enclosure supports consistent and reliable audio capture. Since the effectiveness of beamforming depends on clean and unobstructed input from the microphone array, I verified that the enclosure does not introduce physical obstructions, unwanted reflections, or interference that could degrade audio quality.

To analyze this, I compared system behavior with the enclosure fully assembled versus earlier testing configurations. This included:

  • Observing whether speaker detection remains consistent across different positions
  • Ensuring that audio clarity is not negatively impacted by the enclosure design
  • Confirming that the physical layout supports stable and repeatable system performance

Through these validation steps, I determined that my enclosure design not only meets its structural requirements, but also supports the overall system objective. The design enables proper sensor alignment, maintains input quality, and contributes to a stable platform for accurate speaker detection and audio enhancement.

Schedule

Currently on schedule.

Next Steps

Next week I plan to finalize the enclosure design and implement any remaining improvements identified during testing. I will also continue supporting system-level testing and debugging to ensure the system performs reliably for the final demonstration.