Category: Team Status Report

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? 

1. Inconsistent Audio Alerts: Audio playback occasionally generates random buzzing noise and refuse to play sound.
2. 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:

1. Distance Range: Objects must be within a valid range of 0.5m to 10m.
2. 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:

1. Integration Testing: Finalize and validate the entire system in real-world environments.
2. 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:

 

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? 

Risks and Plans: One of the most significant risks to the project is the inconsistency of audio alerts, where the playback sometimes misaligns with what it should be or produces random, unexpected noise. This issue could hinder the reliability and usability of the system, particularly for the intended users who rely on accurate and timely alerts.

Risk Management: We are currently investigating the root cause of the issue, especially on the audio port configuration and playback synchronization. Multiple tests are being conducted under different conditions to isolate the problem.

Contingency Plans: As a backup, we will test alternative audio output methods, such as the smart phone’s speaker.

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?

Change in Design: A change was made to the audio hat configuration to ensure it consistently identifies the correct port for audio output.

Costs Incurred: Time: Additional time was spent troubleshooting and reconfiguring the audio hat. Testing Overhead: Additional testing was done to confirm the new configuration works reliably across various conditions.

Mitigation Going Forward: Further tests are being conducted to validate long-term reliability, and as a backup plan, we are exploring alternatives, such as directly configuring multiple ports to ensure at least one of them could work.

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:

• • Testing GPS and Phone-Based Geolocation: Evaluate the feasibility of GPS and phone-based geolocation for indoor positioning, and use in locations beyond Hamerschlag Hall.
  • Integration Testing: Conduct comprehensive testing of the fully integrated system to ensure all components work seamlessly together.
  • User Feedback Interviews: Interview individuals with visual impairments to gather feedback, refine our design, and identify improvements to go beyond the MVP.
  • Component Integration with Vest: Finalize the integration of all components into the wearable vest, ensuring usability and practicality.

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? 

• Accelerometer only works using C code 

The integration of the accelerometer gives challenges as it required a different programming approach compared to the rest of the system. While all other components and functionalities were implemented in Python, the accelerometer could only be configured and operated through C code using SPI. The python library for SPI does not work for weird reasons. This created a layer of complexity in our setup, as we had to bridge the gap between the C-based accelerometer data and the Python-based logic driving the rest of the system. The accelerometer’s dependency on C necessitated careful handling of its output, which was streamed in real-time and needed to be parsed and interpreted by the Python script. This approach introduced additional steps, such as running the C program as a subprocess, parsing its output in Python, and ensuring seamless communication between the two environments. Furthermore, debugging and troubleshooting the accelerometer involved navigating both the intricacies of C programming and its interaction with Python, which added to the technical complexity of the project. Despite these challenges, we successfully integrated the accelerometer into the system for now. However, the compiling and bridging of C code has a obvious delay in setup, which might potential mess up the system at integration and pipelining everything together.

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?

There is no change to the existing design from this week.

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:

• Accelerometer calibration for improved fall detection accuracy.
• Testing gps and phone-based geolocation to determine its feasibility for indoor positioning (continue from last week).

We are now almost for the first subsystem, the obstacle detection system using radar and audio hat. We could further improve the accuracy and make sure all use case scenarios are met with more fine tuning. As of now, the system is stable and robust for normal cases. Edge case scenarios still remain to be determined.

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? 

• Radar Angular and Distance Limitations

Testing revealed that the KLD7 radar sensor effectively detects motion and speed within ±80° horizontally but fails to capture objects at the extreme edges (±90°) and vertical detection is limited to 34°, as confirmed by the data sheet and initial tests. The radar sensor’s narrow detection field creates potential blind spots that could limit its ability to detect obstacles early enough for the user to safely detour around them. This is acceptable as the primary purpose of the vest is to detect obstacles from a distance to allow for detours. This range complements the white cane by providing early warnings. With the current setup, obstacles within ±80° are effectively detected, aligning with our goal of alerting the user in advance rather than detecting objects immediately to the side. However, in testing, we identified two specific areas—at approximately -60° and -20°, and at distances around 3m to 4.5m—where the radar did not consistently detect movement. Interestingly, we found that obstacles in these areas could sometimes be detected only when backing away from them, indicating a sensitivity limitation in detecting approaching objects within certain angles and distances. Additionally, we noticed that physical barriers such as tables, computer monitors, and chairs can block radar signals, creating detection gaps when the radar is close to these objects. However, since the user will be wearing the device while walking, these obstacles (like chairs and computers) will be detected relative to the user and trigger an alert as intended. What’s behind these obstacles does not need to be detected, as it lies outside the immediate path of the user. The empty space circled in red in the image below demonstrates this intentional detection gap:

To manage detection gaps (-60, 3) and (-20, 4.5), we will adjust the radar positioning and conduct additional tests with carefully marked angles and distances on the floor to better capture a consistent detection field. During our last test, we notice that adjusting the tilt and height can help cover critical areas more effectively. We will also fine-tune the sensor’s sensitivity settings to balance between detecting desired objects and minimizing false positives. We plan to adjust parameters such as detection range, speed thresholds, and angle sensitivity which requires us to refer to the sensor’s documentation for guidance on these adjustments. If these adjustments do not fully resolve the issue, we may apply advanced signal processing methods to filter out noise and enhance target detection. We found techniques like supervised learning can improve range precision by reusing learned patterns.

• GPS Indoor Signal Loss

The GPS module demonstrated very accurate signal acquisition outdoors, where it was able to consistently track precise longitude and latitude coordinates. This reliable outdoor performance is shown in the graph below:

GPS testing confirmed limited functionality indoors, with no signal detected even when near windows, which restricts the usability of WalkGuard in indoor settings. Given GPS’s reliance on line-of-sight to satellites, this limitation could affect location accuracy for users within buildings or obstructed areas.

To address this, we will first try optimize Antenna Placement. We will test with positioning the GPS module or its external antenna near windows or areas with minimal obstructions to improve signal reception again. While this may not guarantee a fix, it can enhance the chances of acquiring a signal. We are also considering using phone-based geolocation (via cellular networks and Wi-Fi) as a fallback for indoor positioning. This would allow the app to maintain a general location estimate even when GPS is unavailable. In the upcoming week, we’ll experiment with this method to evaluate its accuracy and feasibility for indoor tracking. If we pursue this approach, we will need to incorporate device permissions and ensure data integration between the phone’s geolocation data and our backend system.

• Accelerometer Calibration for Fall Detection
  Initial accelerometer testing showed it can capture movement, but distinguishing between minor movement and actual falls will require tuning. Fall detection relies on accurate thresholds and pattern recognition, and without proper calibration, it may either miss falls or generate false alarms.
  We will test and refine calibration settings to isolate the specific accelerometer data patterns that indicate falls, including adjusting sensitivity levels and applying filtering algorithms to exclude incidental movement. This process will involve multiple rounds of testing with simulated falls and adjustments based on data review. We’ll also create a fallback system where users can manually cancel alerts with a button to reduce false positives. Button has arrived already.These strategies will allow us to proceed effectively.

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?

While we haven’t formally modified the core design, the need for reliable location data indoors has prompted us to explore additional layers of geolocation beyond GPS. If we confirm phone-based geolocation is viable, it would integrate into the app as a complementary feature rather than a replacement, making sure location tracking is consistent without compromising GPS’s outdoor accuracy.

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:

• Structured radar testing with standardized angle and distance markers.
• Accelerometer calibration for improved fall detection accuracy.
• Testing gps and phone-based geolocation to determine its feasibility for indoor positioning.

We are preparing for a cohesive integration phase in the coming weeks, targeting a smooth transition into full-system testing before the demo.

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? 

The project faces several risks that could potentially impact our timeline and overall success:

1. Component Availability: A recent error led to the wrong component being ordered, delaying our accelerometer setup hardware integration. We are closely tracking component orders and have emphasized the need for accurate ordering processes. If the correct component does not arrive soon, we will explore other components testing first. We will also integrate manual fall alert activation in our webapp incase of this risk. For the long term, we are identifying other suppliers as a backup source for essential components.

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?

One change to the design of the system is the button. The previous button is the simple GPIO button for PCB board. The issue with it is that it is too small to be properly pressed on normally though we tried to extend it. Therefore, we now switched to a larger button purchased on line, while the onboard GPIO initialization remains the same.

Schedule Updates

Provide an updated schedule if changes have occurred.

Integration and initial testing are now pushed to the upcoming week, contingent upon receiving the correct component. Hardware testing will proceed immediately upon its arrival. Backend API development and GPS integration tasks have been extended by one week to accommodate testing and debugging of the Google Maps API. We aim to have the core functionalities, including GPS-to-address conversion, completed within this extended timeline.

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? 

One risk to our project is the limited compatibility of Python packages with the Raspberry Pi 4 (RPi4) operating system, largely because pip, the package installer, is not available or functional on the RPi4. This limitation impacts our workflow; while we can develop and test code locally, some libraries that work seamlessly on our local machines are incompatible with the RPi4 environment, requiring us to find alternatives or workarounds. For example, we initially used the pyttsx3 library for AI-driven audio generation to create spoken alerts. Although it performed well in local tests, pyttsx3 cannot be installed or used on the RPi4, hindering our ability to generate audio dynamically in real-time on the device.

To manage this risk, we’ve developed a contingency plan to pre-generate multiple audio files on our local machines, categorizing them based on obstacle distance and direction, and then transferring these files to the RPi4. This approach allows us to use pre-recorded audio cues rather than generating audio directly on the RPi4, maintaining essential functionality while bypassing package compatibility issues. On the contingency planning side, we are also proactively researching compatible packages and frequently testing setup code directly on the RPi4 before full implementation. Hope by doing so, we can identify and resolve compatibility issues early in the process, and then minimize disruptions and making smooth integration.

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?

This week, we focused on a potential adjustment to our system’s design related to GPS integration with the RPi4. Our main goal was to assess the feasibility of connecting the GPS module directly to the RPi4. However, if stable integration cannot be achieved due to protocol limitations, our backup plan is to use the user’s smartphone GPS for location tracking. This change would require minor software updates to process location data from the smartphone, ensuring functionality remains seamless without additional hardware.

No design changes have been implemented at this stage. However, if the smartphone GPS becomes necessary, we will update the block diagram and system specifications to reflect this alternative approach. This contingency plan effectively manages the GPS integration risk while maintaining our project timeline.

Schedule Updates

Provide an updated schedule if changes have occurred.

Our schedule remains on track with no significant changes at this time. In the coming week, we plan to accelerate system integration across all components. With the audio hat integration successfully completed, our next priority is the radar component, which we aim to finish by the end of next week. If the newly ordered accelerometer arrives as expected, we also plan to initiate GPS integration.

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? 

The most significant risk currently is uncertainty regarding the GPS integration. Although the GPS module is connected to the RPi4 via USB, we discovered that it still operates using the I²C protocol. This poses a problem since the RPi4 is already using its two I²C ports for the accelerometer and audio hat. Managing multiple I²C communications on the same bus remains a challenge, and if this does not work, we are considering using the user’s phone GPS as a contingency for location tracking.

To manage the risk posed by the GPS integration issue, we are focusing on exploring the ability of the RPi4 to handle multiple I²C communications on a shared bus, as both the accelerometer and audio hat are already using the available I²C ports. We will test if the GPS module can coexist with the other components, potentially through multiplexing or reconfiguring the communication protocols. If this approach fails, our contingency plan involves using the user’s smartphone GPS as an alternative for location tracking, ensuring seamless functionality without needing additional hardware modifications.

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?

No significant changes to the existing design of the system have been made this week. However, depending on the outcome of our GPS integration tests, we may have to revise the block diagram and communication architecture to account for the potential use of a smartphone for location tracking. This adjustment would affect the system specification but would not incur any significant hardware costs, as it relies on pre-existing smartphone capabilities. We would need to invest more time in modifying the software for seamless integration, which we plan to accommodate by reallocating time from other low-priority tasks if necessary.

Schedule Updates

Provide an updated schedule if changes have occurred.

At this point, our schedule remains unchanged. However, we are closely monitoring the GPS integration process. If further complications arise, we may need to adjust our timeline to allow additional time for testing or the implementation of our contingency plan.

Week-Specifics

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

From a global perspective, WalkGuard addresses the needs of the approximately 3.5% of the global population affected by visual impairment, particularly the 30-40% who must navigate their environments independently. This system provides essential support for users in both developed and developing countries, where access to advanced mobility aids may be limited. WalkGuard’s radar-based obstacle detection and fall alert system not only enhances safety but also promotes independence, reducing the risk of accidents. This technology also provides peace of mind to caregivers, especially in regions with limited healthcare infrastructure, by allowing remote monitoring of loved ones.

The global impact extends beyond just geographic considerations. WalkGuard helps users who are not technologically savvy by offering an intuitive design with audio-based feedback, making it accessible to individuals with varying degrees of technological comfort. Furthermore, as mobility and accessibility issues are universally recognized, WalkGuard aligns with international efforts to improve the quality of life for people with disabilities, contributing to a more inclusive society.

Part B: … with consideration of cultural factors. Cultural factors are encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.

WalkGuard’s design is sensitive to cultural differences in how disabilities are perceived and accommodated around the world. In many cultures, independence is highly valued, and individuals with disabilities strive to live autonomously. WalkGuard supports this cultural emphasis by providing visually impaired individuals with a tool that enhances their ability to navigate their environments safely, reducing their reliance on others. This aligns with the cultural values of independence and self-reliance found in various communities globally. Additionally, in cultures where caregiving is a family-centered responsibility, WalkGuard’s ability to provide remote monitoring through emergency alerts and GPS tracking can ease the emotional burden on family members, offering them reassurance about their loved one’s safety.

WalkGuard also acknowledges varying levels of technological adaptation across different regions. By providing a straightforward, audio-based user interface, it respects cultural norms where complex technology might be less familiar or preferred, making the device more accessible to users in regions where high-tech solutions may be seen as intimidating. Furthermore, WalkGuard’s unobtrusive design respects cultural sensitivities around appearance and dignity. In some cultures, the stigma around visibly using assistive devices can discourage people from seeking the help they need. WalkGuard’s discreet and wearable design addresses this by offering a solution that blends into everyday attire, allowing users to maintain their self-esteem and social confidence while benefiting from advanced assistive technology.

Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

The materials used in WalkGuard’s vest design are chosen to ensure durability while minimizing resource use. The electronic components used in WalkGuard, such as the radar sensor, accelerometer, and Raspberry Pi 4 (RPi4), are selected for their energy efficiency and minimal resource consumption during production and operation. The radar sensor consumes significantly less power compared to alternatives like LiDAR or ultrasonic sensors. With typical power requirements ranging between 25-60mA, the radar ensures continuous operation without draining the system’s battery quickly. This reduces the overall energy consumption, which is crucial for a wearable device that aims to operate on a single charge for extended periods. Lower power consumption translates to fewer charging cycles, which reduces the environmental impact related to battery production and disposal. The accelerometer is another low-power component, consuming only minimal energy (around 140μA in measurement mode). This ensures that the accelerometer can continuously monitor movement without significant impact on the system’s overall power budget. Efficient power management in components like the accelerometer helps reduce the frequency of battery replacement, further minimizing electronic waste. WalkGuard’s modular design allows for easy maintenance and replacement of individual electronic components, preventing the entire device from being discarded due to the failure of a single part. This approach minimizes electronic waste. The use of AWS cloud services for data processing and storage also contributes to environmental efficiency. AWS operates with a focus on sustainability, aiming to power its data centers with renewable energy, thus minimizing the carbon footprint of our web-based operations. Moreover, the design of WalkGuard promotes sustainability in urban environments by reducing accidents and promoting safer navigation for visually impaired individuals. This contributes to less resource strain on healthcare systems by potentially preventing injuries, thus reducing the environmental load associated with medical treatments and emergency services.

 

A was written by Zhixi, B was written by Eleanor, and C was written by Connie.

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:

1. 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.
2. 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.

1. 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.
2. 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.

 

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? 

The most significant risk currently is Uncertainty Regarding Component Integration and Performance. With all components ordered, including the K-LD7 radar, GPS, accelerometer, and microcontroller, the primary concern is to make sure of seamless integration and correct functioning across systems. For example, while the radar is expected to detect obstacles in real-time, interference from environmental factors or misalignment with the audio alert system could jeopardize the overall effectiveness. We also have some concerns with its accuracy and complexity of data processing.

To manage these risks, we are implementing a testing and verification process. We have planned 50-100 unit tests for each part. Each component will undergo individual testing followed by system-wide testing to ensure compatibility and accuracy, particularly for radar-based obstacle detection and GPS fall detection. If we encounter any integration issues, such as power consumption inconsistencies or sensor inaccuracy, we will explore alternative components, including LIDAR or optimizing software to compensate.

Contingency plans include switching sensors or adjusting system parameters to ensure functionality without compromising user safety or the project’s goals.

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?

Several design changes were made to the system based on further review of the component choices and project requirements:

• Sensor Selection: We opted for the K-LD7 radar sensor over ultrasonic and camera-based systems due to its performance in low-light environments and lower power consumption. The radar’s multi-target detection and direct serial output make it more efficient for continuous operation in all weather conditions. We also decide to go with K-LD7 instead of position to go considering costs and project complexity.
• Battery and Power Optimization: We made modifications to ensure power efficiency by balancing sensor performance with power consumption. Should battery endurance fall below the required threshold (3 hours), we have a mitigation strategy involving battery optimization or expanding the capacity with lower power sensors as alternatives.
• GPS Integration: Initially, we considered using mobile phone GPS through cloud service alerts. However, after testing concerns regarding the precision of the GPS data, we decided to include a separate GPS hardware module in the design to ensure the user’s exact location is communicated accurately during emergencies.

These design changes were necessary to ensure that the device is both reliable and practical for visually impaired users. While the addition of the GPS hardware introduces extra costs, these costs are mitigated by avoiding less critical components and focusing the budget on essential features.

Schedule Updates

Provide an updated schedule if changes have occurred.

We are on schedule with the project timeline. Key changes include:

• Component orders were adjusted to reflect the finalized design.
• Testing for radar performance and integration with the GPS system is underway and progressing as expected.
• We anticipate completing system integration testing in the coming weeks, with real-world validation tests scheduled thereafter.

Week-Specifics

Part A: … with respect to considerations of public health, safety or welfare.

From a public health perspective, WalkGuard fosters psychological well-being by empowering visually impaired users with greater independence and confidence to navigate their environment without needing constant assistance. By detecting obstacles in real-time and issuing sound alerts, the device reduces the risk of accidents, providing a sense of security and lowering anxiety. Besides, WalkGuard helps alleviate the constant concerns of caregivers; it provides them peace of mind by reducing their 24/7 responsibilities. Additionally, in terms of safety, the device offers advanced hazard detection that protects users from obstacles they might not perceive with traditional aids like white canes, such as the trunk of an approaching truck or other high-up obstacles. The forehead-level alerts give users more time to react, so the risk of collisions decrease. Moreover, the built-in fall detection system takes fast action in the event of an accident. When a fall is detected, the system automatically sends an email alert to caregivers, allowing for prompt intervention and reducing the risk of prolonged injury or delays in medical attention. Finally, regarding welfare, WalkGuard addresses the basic human need for care and security. By keeping caregivers informed of potential accidents, the system ensures that assistance can be provided in a timely manner so that meets the fundamental need for personal safety. The balance between encouraging user independence and offering caregiver support contributes a higher quality of life for both individuals.

Part B: … with consideration of social factors.

By promoting greater independence in mobility, WalkGuard empowers users to engage more fully with their communities improving their  social inclusion. Many visually impaired individuals face isolation due to their reliance on others for safe navigation, which can limit their participation in social, cultural, or economic activities. WalkGuard bridges this gap by providing users with a sense of autonomy, enabling them to confidently participate in daily activities, attend social gatherings, and contribute to their communities without constant dependence on companions.

From a caregiver’s perspective, WalkGuard helps ease the emotional and social burden of providing constant care. In many societies, the care of individuals with disabilities is often placed on family members, which can strain social relationships and limit the caregivers’ ability to engage in their own social or economic activities. By allowing caregivers to monitor the safety of their loved ones remotely, WalkGuard enables them to maintain their roles in the workforce or social circles without the anxiety of being unavailable in case of an emergency. This product encourages a more balanced relationship between caregivers and visually impaired individuals, promoting healthier social dynamics and reducing the potential for caregiver burnout. Furthermore, in regions with limited access to assistive technologies, WalkGuard offers an affordable, accessible solution that helps equalize opportunities for visually impaired individuals across different economic backgrounds.

Part C: … with consideration of economic factors.

The WalkGuard system focuses on a cost-effective solution to address the mobility challenges faced by visually impaired individuals. Traditional assistive technologies, such as guide dogs or human caregivers, can be prohibitively expensive, with ongoing costs for training, maintenance, or caregiver wages. WalkGuard significantly reduces the economic burden by providing a single, wearable device that combines multiple functions—obstacle detection and emergency alerts—into one affordable package. Using a cost-efficient components like the K-LD7 radar sensor, microcontroller, and GPS hardware, the system is designed to be both effective and accessible to a broad range of users. Mass production of the vest and integration with smartphone technology ensures that WalkGuard remains affordable without sacrificing quality. This enables wider adoption among low-income users who may otherwise lack access to advanced assistive technologies. Moreover, by reducing the need for constant caregiver supervision, WalkGuard helps alleviate labor costs for families and institutions. WalkGuard also aims to improving independence for visually impaired individuals.

A was written by Eleanor, B was written by Zhixi and C was written by Connie.

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: Uncertainty Regarding Radar Sensor Performance

The primary risk facing our project this week is the uncertainty about whether the selected radar sensor will meet our specific needs. Despite thorough reviews of datasheet for multiple radar options, we are not entirely sure if the radar we choose will function effectively for our intended purpose. Specifically, there’s a risk that the radar may not accurately detect static or slow-moving objects, or provide the precise distance and angle information required for the walking aid designed for visually impaired individuals.

Risk Management Strategies: Extensive Testing

To address this uncertainty, we plan to conduct extensive testing of the selected radar sensor. This will involve setting up experiments to evaluate its performance in real-world scenarios, particularly focusing on its ability to detect objects at walking speeds and provide accurate positional data. Through rigorous testing, we aim to verify whether the radar meets our project’s technical requirements.

Contingency Plans: Possibly adjusting Final Project Goals Based on Radar Capabilities

If testing reveals that the radar cannot fully meet our initial objectives, we are prepared to adjust our final project goals accordingly. This may involve modifying the functionalities of the walking aid to align with what the radar can reliably deliver. Our priority is to ensure that the device remains practical and beneficial to users, even if it means refining our original plans based on the radar’s actual capabilities.

 

 

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?

One potential change we might make is that we might need a separate GPS hardware component connect to the microcontroller for the system. We realize that we could utilize the GPS on phone since we are already using cloud service to send alerts via phone. However, this change still need to be tested because we are not sure if the GPS location sent will be the location of the cloud service or the actual location of the user. Therefore, we will still purchase the GPS hardware component as a backup.

Schedule

No update on the current schedule so far as we are still on track.