Risk and Plans
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
- Inconsistent Audio Alerts: Audio playback occasionally generates random buzzing noise and refuse to play sound.
- GPS Indoors: GPS loses connection in indoor environments, which affects the system’s reliability in scenarios requiring emergency alerts.
Risk Management
- Audio Alerts:
- Conducted detailed debugging of audio playback configurations.
- When the subsystem is running individually, it works fine. If we use sandboxes for pipelining, it performs better than threading so that’s our alternatives for now.
- Tested multiple audio outputs under varying conditions to isolate and address the issue.
- Exploring alternative methods, including direct smartphone speaker integration as a fallback.
- GPS Indoors:
- Implementing fallback mechanisms using accelerometer-based motion tracking for emergency alerts in indoor environments.
Change in Design
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
- Obstacle Detection Threshold Refinement: Adjusted the radar system to detect only obstacles with a normalized magnitude larger than 100 relative units.
- Reason for Change
- Background Noise Filtering: During initial testing, the radar detected minor obstacles (e.g., small debris) that were irrelevant to the user’s navigation. These false detections led to unnecessary alerts.
- Focused Detection: By normalizing the radar magnitude relative to the distance and setting a magnitude threshold, the system now filters out insignificant objects, ensuring only relevant obstacles trigger alerts.
The updated obstacle detection function considers:
- Distance Range: Objects must be within a valid range of 0.5m to 10m.
- Normalized Magnitude: Objects must have a normalized magnitude (magnitude scaled by distance²) exceeding a threshold of 500
Schedule Updates
Provide an updated schedule if changes have occurred.
Despite the technical challenges, our project remains on schedule. The hardware and software components have been tested individually, and integration work is beginning as planned. Next week, we will focus on:
- Integration Testing: Finalize and validate the entire system in real-world environments.
- Emergency Alert Performance: Conduct extensive fall detection and GPS-based alert accuracy testing.
Testing Summary
| Unit Test | Requirement | Testing Plan | Results |
|---|---|---|---|
| Obstacle Detection | ≤ 15% false negatives, ≤ 20% false positives | Simulated walking tests with radar in diverse environments (e.g., sidewalks, narrow hallways). | 12% false negatives, 18% false positives. |
| Audio Response | ≥ 40dB, ≤ 1 second response time | Measured radar signal processing to audio response time and decibel levels over 100 iterations. | Avg: <0.3 sec, 45dB. Random audio dropouts identified. |
| Fall Detection | ≤ 5% false negatives, ≤ 20% false positives | Simulated falls and non-fall movements with accelerometer-based tracking. | Testing ongoing; initial results within acceptable limits. |
| GPS Alert Accuracy | ≤ 10m error, alert within 5 seconds | Measured time to send alerts and GPS precision in on-road scenarios. | Testing ongoing; initial accuracy within 10m radius. |
| Wearability | Weight < 3kg | Measured total vest weight with integrated hardware. | Vest weight: 1.2kg. Comfortable fit. |
| Battery Life | ≥ 3 hours | Calculated battery life under average and peak loads. | Estimated uptime: 24 hours with 26,800mAh power bank. |
Integration Test Plan
| Test Case | Purpose | Procedure | Results |
|---|---|---|---|
| Fully Integrated System Navigation | Validate obstacle detection and user guidance. | User wears the vest and navigates an obstacle course while blindfolded. | Clear audio guidance provided; users avoided obstacles. |
| Emergency Alerts | Ensure accurate caregiver notifications. | Simulate falls and monitor real-time alerts via web interface. | Alerts triggered within acceptable time. |
| Real-Time Obstacle Alerts | Validate pipeline efficiency. | Introduce dynamic obstacles and measure system response times. | Response time consistently under 0.5 seconds. |
| Extended Runtime Test | Evaluate long-term system stability. | Run the system continuously for 4 hours, monitoring all metrics. | System operated with no crashes for first several hours. However our rpi refused to connect through vnc. We are trying to debug this. |
During testing, we encountered connectivity issues with rpi4. The RPI refused to connect remotely via VNC, timing out consistently. While we could still access the system by connecting the RPI to a monitor directly, this limitation affects the flexibility of remote debugging and system adjustments. We are investigating network configurations and potential firewall issues to address this problem. Additionally, the audio system remains unstable. While it generally functions as intended, it occasionally produces buzzing sounds, which could confuse or distract the user. This issue seems intermittent and may be related to audio port configurations or signal interference. To mitigate this, we are conducting detailed debugging of the audio playback system and also send a new order of speaker to check if our hardware is broken.
Our integrated system image:
