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.

Zhixi’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).

  1. Ethics lecture (2 hrs): I spent time on the ethics lecture and learnt quite a lot about political implication of engineering.
  2. Team meeting (3 hrs): My teammates and I spent time sync up on our individual progress both during the lab time and after the assigned class time. Issues on individual work were proposed, and after working together, we managed to solve what was previously not working.
  3. GPS hardware setup (2 hrs): I spent time setting up the GPS with USB connection. Initially, the reading was not available due to some port initialization issue with the RPi4. After correctly finding the USB port with the reserved serial communication, I was able to read the output from minicom and interpret the data from there.
  4. Radar software setup (5 hrs):I completed the initial software bring-up for the radar, enabling it to output basic detection results. During setup, I encountered communication issues between the radar and the Raspberry Pi. Initially, the default UART port on the RPi didn’t transmit or receive data. After confirming basic UART functionality, the radar still wasn’t communicating. I discovered that the RPi 4’sdefault mini-UART doesn’t support parity bits, which our radar requires for even parity. I reconfigured the setup to use UART2, which does support parity bits, and that resolved the issue. Now, the radar successfully outputs a list of detection targets with their distance and velocity, completing this bring-up phase.

Schedule

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

This week, I am back on schedule with all systems set up done (except accelerometer that we have not yet received). I am now in the process of doing unit test and tuning for the radar.

Upcoming Deliverables

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

  1. More radar tuning for obstacle detection and obstacle message generation.

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.

Eleanor’s Status Report for 11/02/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 integrating and setting up GPS component on the RPi OS with my teammates. We began by installing Minicom to detect GPS connectivity through the RPI interface. After configuring the GPS on the OS, we successfully accessed and displayed GPS data in the terminal. Based on this, I expanded a function to convert terminal GPS data into JSON format as {"lat": latitude, "lon": longitude, "time": timestamp, "addr": address}. Additionally, I modified a function to store this data in a JSON file, allowing us to log and track GPS data for testing purposes. For future usage, I set up a feature that retrieves only the latest coordinate data upon request, improving real-time data access. To provide real-world addresses for the coordinates, I integrated the Google Maps Geocoding API, enabling conversion of latitude and longitude into readable addresses.

We also identified an issue with the button component: it was too small, making it difficult for users to locate and press it quickly to cancel an email alert. I researched alternative options, discussed them with the team, and submitted a new order form for a larger, more user-friendly button.

Schedule

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

My individual work is currently on schedule, aligning with the project’s planned timeline. As mentioned earlier, I am in the mid-to-late phase of my assigned work. So far, we have made good progress in integrating and configuring key components, which has provided the foundation I need to proceed with my own tasks. The team’s progress has allowed me to begin work on specific functionalities. If any delays arise, I plan to collaborate more closely with teammates to identify any bottlenecks and redistribute tasks if necessary

Upcoming Deliverables

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

  • Assisting teammates set up and test radar: involves mounting, configuring, and validating the radar’s accuracy in detecting objects at various distances and angles (same as last week).
  • Once the accelerometer arrives, I will begin setting it up and developing algorithms to distinguish between actual falls and normal body movements, a critical feature for our project.
  • After completing the GPS setup, we confirmed that it functions only in outdoor environments, so we plan to conduct further testing to assess GPS performance outdoor and explore connectivity options for integrating GPS data with our website.