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.