Author: wenjunz2

Team’s Status Report for 12/07/2024

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:

 

Connie’s Status Report for 12/07/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

    • Presentation:
      On Wednesday, I presented the progress and outcomes of our project during our final presentation.
    • Debugging Chrome Issues:
      • Deployed the web app using Firebase to ensure accessibility for testing.
      • Encountered and debugged issues with Chrome browser compatibility. Specifically, the app failed to connect due to the error: “Cannot safely connect to WebSocket (ws).” This issue arises because Chrome enforces stricter privacy policies compared to Safari and Firefox.
      • Attempted to resolve the issue using the API workaround provided by Firebase with wss instead but am still troubleshooting. Notably, the web app functions without issue on Safari.
      • Resolved several CORS-related bugs to enhance the app’s stability across different environments.
    • Email Notification Feature:
      Implemented the functionality to send email notifications to caregivers when the accelerometer detects a threshold-triggering event. There are some minor triggering issue with this function which I am actively solving.
    • Integration Work:
      • Assisted in integrating all components into the vest.
      • Participated in integration testing, ensuring that the hardware and software components work together seamlessly.
    • Raspberry Pi Connectivity:
      Investigated the ongoing issue with the Raspberry Pi failing to connect via VNC, where the connection times out. Despite direct access through a monitor, the remote access issue remains unresolved. Efforts included debugging network configurations and checking for firewall or permission-related constraints.

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

There are minor delays with resolving the Chrome compatibility and Raspberry Pi connection issues. Integration and testing are progressing as planned, and the system functionality is improving steadily.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

In the coming week, I plan to achieve the following deliverables:

  1. Resolve Chrome Compatibility Issues:
    Implement and validate the API workaround provided by Firebase to address the WebSocket connection problem on Chrome. Test extensively to ensure consistent performance across all major browsers.
  2. Fix Raspberry Pi Connectivity:
    Identify and resolve the root cause of the Raspberry Pi’s inability to connect remotely via VNC, ensuring reliable remote debugging capabilities.
  3. Finalize Integration Testing:
    Conduct comprehensive integration testing of the system, focusing on edge cases and user scenarios. Validate that the vest performs seamlessly in real-world environments.
  4. Enhance Notification System:
    Optimize and validate the email notification feature to ensure it triggers accurately and consistently when the accelerometer threshold is breached.
  5. Prepare for Final Demonstration:
    Compile the results of integration testing and finalize system refinements based on any issues identified. Ensure the system is ready for final review and demonstration.

Connie’s Status Report 11/30/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I focused on preparing for our interim demo, ensuring the integration and functionality of various components of the WalkGuard project, and advancing toward our final presentation. Key accomplishments include:

  1. Interim Project Demo
    • Ensured that individual components (accelerometer, GPS, radar, and web app) were fully operational and demonstrated effectively.
    • Created slides summarizing the challenges faced during development, including technical limitations and integration difficulties.
  2. Final Presentation Preparation
    • Contributed majorly to the preparation of final presentation slides.
    • Worked on preparation of the presentation.
    • Practiced delivering the presentation, refining flow and key talking points.
  3. Pipelining Components and Subsystems
    • For the interim demo, components were demonstrated individually. I contributed by pipelining the subsystems together into a single main file.
    • Ensured connectivity between the web application and the Raspberry Pi pipeline.
    • Identified areas where robustness testing is still required and began addressing these challenges.

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Currently our project is on schedule. The interim demo was successfully completed, and preparation for the final presentation is progressing well. However, robustness testing for the pipelined subsystems and web-to-RPi connection needs further focus.

Plan to Stay on Schedule:

  • Conduct thorough robustness testing and debugging of the pipelined system in the upcoming week.
  • Allocate dedicated time for refining the presentation and addressing any last-minute technical issues.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

For the next week, I aim to complete the following:

  1. Robustness Testing and Refinement
    • Test the integrated pipeline to ensure stability and reliability under various conditions.
    • Address any issues with subsystem communication or failure handling.
  2. Final Presentation Slides
    • Finalize slides with results, lessons learned, and future directions.
  3. Full System Demo
    • Ensure the entire system (accelerometer, GPS, radar, web app) works seamlessly in an integrated manner for the final demo.
  4. Documentation
    • Prepare and submit a detailed report on system design, integration, and results.
  5. Visit the library for visually impaired people and conduct interview with them.

 

 

Connie’s Status Report for 11/16/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I focused on the accelerometer tuning and threshold adjustment for fall detection. This involves refining sensitivity thresholds to accurately differentiate between minor movements and falls. I implemented adjustments in the C code to better filter the accelerometer data, ensuring reliable signal detection while minimizing noise from incidental movements. I also completed the data pipeline integration. Now, when the accelerometer detects a fall signal, it sends the data to the web app through a web API. On the web app end, an alert is generated to notify users of the event. Finally I spent time to prepare for demo this week. This included adding content to our slides, testing components to ensure reliability, and preparing demonstrations that showcase the core functionality of WalkGuard, particularly its fall detection and alert system.

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am on schedule with my project. The accelerometer tuning and pipeline integration were major steps, and both were successfully completed this week. With these in place, I can shift focus to optimizing detection performance and preparing for further integration tests.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

  • Fine-tuning Fall Detection: Further refine the accelerometer thresholds to reduce false positives and ensure that the system reliably identifies actual falls.
  • Integration Testing: Perform comprehensive tests of the hardware-to-web pipeline to identify and resolve any latency or data accuracy issues.
  • Web App Enhancement: Improve the web app interface for displaying fall alerts.
  • Field Testing: Design and execute real-world test scenarios using the white cane to simulate practical use cases. This includes testing in varied environments to validate the system’s functionality.

 

 

Team Status Report for 11/09/2024

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.

Connie’s Status Report for 11/09/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

On the software side, I finished a working prototype of the website with React. This included connecting Google Authentication and the Google Maps API to manage user login and real-time location tracking. Google Authentication is our choice of login since it is secure and easy to use. We choose React for the front end for its modularity, allowing us to maintain clear code structure and scalability. Integrating the Google Maps API also gives us reliable, real-time location tracking incase our gps component end up failing. Our GPS is performing well outdoors but currently fails indoors due to typical limitations of GPS with line-of-sight requirements.

Image for web app prototype:

Hardware progress this week included testing and initial calibration of both the radar (KLD7) and the accelerometer. The radar testing revealed angular limitations aligning with the specifications in the data sheet, which confirms that detection reliability drops off at ±80° horizontally. During testing, we observed that vertical detection was limited to a 30° coverage range, as specified in the data sheet. To better understand these boundaries, we conducted both indoor and outdoor tests across various distances and angles. Indoor tests showed limitations in obstacle detection, as the radar struggles to detect motion when obstructed by physical barriers (e.g., tables, computers, chairs), which is expected for this sensor type. The outdoor testing was divided into defined sectors (left, mid, right) and distances (1m, 3m, and 5m) Notably, the radar consistently picked up signals within the set parameters, but some sections (e.g., -60°, 3m, and -20°, 4.5m) showed intermittent detection issues that require further exploration, likely due to signal interference or sensitivity at certain angles.

For the accelerometer, we setup the code in C, which allowed detection of  initial movement data, indicating that the device is wired and communicating as expected. However, raw movement detection isn’t sufficient for the intended fall detection functionality, which requires more nuanced data handling to differentiate between minor movement and actual falls. Additional tuning is necessary to filter and threshold accelerometer signals to isolate patterns unique to falls. I anticipate that refining these settings will involve adjusting sensitivity thresholds and possibly implementing an averaging algorithm to reduce noise from incidental movements.

In preparation for the final demo, I ordered a white cane, which will help simulate real-world use cases which is emphasizing the practical safety applications of WalkGuard for visually impaired users.

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am currently on schedule with my project. The website prototype is functioning as intended, and the hardware setup is progressing. I anticipate completing the necessary tweaks to the accelerometer in the coming days.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

I’ll focus on tuning sensitivity to detect falls accurately, adjusting settings to distinguish significant movement patterns from minor fluctuations. Also I aim to enhance our website’s functions and enable connection between our website and the rpi using api, considering both user’s phone and the device is using the same network. Finally I plan to map specific distance markers on the floor to standardize our testing parameters, allowing us to identify and potentially resolve inconsistencies in detection at certain angles or distances.

Team Status Report for 11/2/2024

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.

Connie’s Status Report for 11/2/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week I worked on these areas:

  1. Website Development and GPS API Integration:
    • Continued coding the website’s interface, focusing on accessible design principles to enhance usability for visually impaired users. This included refining HTML layouts for clarity and ease of navigation.
    • Connected and configured GPS settings within our backend API to support real-time location logging with teammate. I am also working on integrating the Google Maps API to translate GPS coordinates into human-readable addresses (e.g., street names, building names) in JSON format with teammate, which will be essential for our web app’s location display feature.
  2. Component Management:
    • Checked in with Quinn regarding the accelerometer component. However, due to an error, a GPS module was ordered instead. I will follow up to ensure the correct accelerometer is acquired.

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Due to a recent mix-up in ordering, the correct accelerometer component was not delivered. Instead, another GPS module was mistakenly ordered. This has set back the hardware integration timeline slightly, as the accelerometer is crucial for our system. I’ve coordinated with Quinn to reorder the correct part, and I am actively following up to ensure we receive it promptly. To mitigate any further delays, I plan to focus on testing and refining other aspects of the project that don’t rely on the accelerometer, such as API integrations and backend functionalities. I will also integrate manual fall alert activation in our web app. Once the correct component arrives, I will prioritize its setup and testing to catch up on any lost time. On the web development side, I’m on schedule with the accessible design updates, and the API integration for GPS location data is progressing as planned. The accelerometer delay and Google API complexities are two areas I’m actively managing. I’ll continue to monitor these issues closely and adjust our timeline as needed to maintain steady progress.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

For the upcoming week, I need to:

  1. Accelerometer Integration: Once the correct component arrives, I will integrate it into our system, testing both connectivity and data transmission capabilities.
  2. Google API Integration Completion: Finalize the Google Maps API integration to enable location details from GPS coordinates on the web app, enhancing usability.

Connie’s Status Report for 10/26/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Currently, I am on schedule with our planned timeline. Each task has been completed as anticipated. The only potential delay is awaiting the reordered accelerometer component, which I will track closely to prevent any disruption in our hardware development.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

For next week, I plan to:

  • Integrate the accelerometer once it arrives, testing connectivity and data transmission.
  • Further refine the website interface to align with accessibility standards based on user feedback.
  • Begin initial tests on token-based authentication to verify its effectiveness in securing our application.

 

Connie’s Status Report for 10/20/2024

Personal Accomplishment

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This past week, I completed the design report sections for Introduction, Architecture/Principle of Operation, Project Management, Related Work, and Summary. For the Introduction, I researched the challenges faced by visually impaired individuals in urban environments, including hazards like cluttered sidewalks and unexpected obstacles. I outlined how WalkGuard is designed to address these challenges through advanced technologies like radar for obstacle detection and an accelerometer for fall detection. The goal is to enhance the independence of visually impaired users while reducing the burden on caregivers by providing real-time alerts. In the Architecture and Principle of Operation section, I detailed the technical design of the system, particularly focusing on how the radar sensor detects obstacles and how the accelerometer triggers emergency alerts. I explained how these components integrate with the Raspberry Pi 4, which processes the data and provides real-time feedback to users and caregivers. I also included specific calculations for radar signal processing and time-to-collision estimates. For Project Management, I outlined the team’s schedule and individual responsibilities, including system integration timelines and testing phases. I also identified potential risks, such as inaccurate fall detection or Bluetooth connectivity issues, and proposed mitigation strategies, ensuring that the project remains on track. In the Related Work section, I conducted research on similar assistive technologies, such as wearable devices using haptic feedback and ultrasonic sensors, highlighting their limitations. This research helped justify the selection of radar for WalkGuard, as it offers superior performance in all-weather conditions and longer detection ranges. The Summary section synthesized the key benefits of WalkGuard, emphasizing how it improves mobility for visually impaired individuals and provides peace of mind for caregivers. I also outlined future steps for enhancing the system through extensive field testing and iterative development. I also finished the website functionality that connects the system to send alerts to caregivers, as outlined in the project’s emergency alert system. I demonstrated this by integrating the connection on the WebApp that transmits the emergency alerts triggered by the system.

 

Schedule

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Currently, my progress is on schedule. I have completed the tasks planned for this week as indicated in our Gantt chart. To stay on track, I will begin working on the accelerometer integration next week as planned.

Upcoming Deliverables

What deliverables do you hope to complete in the next week?

  • Start the accelerometer integration with the fall detection system to refine emergency alert accuracy.
  • Ensure accurate emergency alerts with minimal false positives/negatives.
  • Complete unit testing on the WebApp to ensure robust performance under various simulated fall detection scenarios.