Team Accomplishment
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?
Most significant risk: Difficulty in Testing the Walking Aid Vest
As we move forward with the WalkGuard project, a significant risk we expect to face in future is the difficulty in properly testing the walking aid vest under realistic conditions. None of the team members have experience navigating with a white cane or walking blindly, which could make it challenging to simulate real-world scenarios for visually impaired users. This presents a challenge in evaluating whether the vest provides effective obstacle detection and safety features in a normal street environment. Additionally, the fall detection testing carries safety concerns, as we will need to mimic falls without causing injury to the volunteers who will be helping with the tests.
Risk Management Strategies: Extensive Testing
To mitigate these risks, we plan to take two key actions:
- Reaching Out to the Pittsburgh Community: We aim to collaborate with individuals who have experience navigating with a white cane. By working with people who already face these challenges, we will get more accurate feedback and insights into how the vest performs in real-world conditions. This will also ensure that our tests better reflect the true needs of our target users.
- Controlled Fall Detection Testing: For fall detection, we plan to set up a safe testing environment by providing soft cushions or padded surfaces to ensure volunteers do not get injured during testing. This will allow us to simulate falls more safely and fine-tune the system’s sensitivity and accuracy.
Contingency Plans: Possibly adjusting Final Project Goals Based on Radar Capabilities
If we encounter difficulties in accessing real-world testers or fall detection simulations, we have a few contingency plans in place:
- For the walking aid tests, we could work with trained professionals or mobility instructors who can provide expertise on how the device would perform in real situations.
- If fall detection tests prove too risky, we may use controlled simulations or dummy falls with mechanical devices to mimic real human falls safely. Additionally, adjusting the vest’s sensitivity settings based on collected test data could ensure the system functions effectively without requiring extreme physical tests.
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?
In recent developments, we made two key adjustments to our system design based on the capabilities of the radar sensor and further analysis of how it performs in real-world conditions.
- Radar Confusion Matrix (Performance Criteria):
We established a more precise performance criteria for the radar, specifically aiming for a false negative rate of no more than 15% and a false positive rate of no more than 20%. These figures are still tentative since they will largely depend on how the radar performs once we receive the hardware. Since we were unable to find detailed specifications in the datasheet, we referenced data from past project groups who worked with the same radar model. This allowed us to set more informed and realistic benchmarks for our system, ensuring the radar’s performance aligns with the needs of our users. - Detection Range Adjustment (1-5 Meters):
Initially, we planned for the radar to detect obstacles within a range of 1 to 3 meters, but after reviewing the radar’s capabilities, we extended this range to 1 to 5 meters. This change was necessary because the radar can handle longer distances, and given that a normal walking speed is approximately 1 m/s, a 5-meter range would provide more timely alerts. This adjustment better matches the expected use-case scenarios for the walking aid and ensures that users have enough reaction time to avoid obstacles.
Schedule
Due to a delay in receiving our hardware components, we have adjusted our schedule accordingly. Tasks that do not depend on these components, or that we can start with partial resources, have been moved up to earlier phases of the project. These tasks include webpage setup along with the detailed UX/UI design and radar data analysis starter code, which allows us to make progress in areas such as software development, algorithm design, and system integration, ensuring that we stay on track as much as possible while waiting for the components to arrive. By shifting our focus to these elements, we aim to minimize downtime and maintain momentum on the overall project timeline.