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.

 

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

This week, I spent my time mainly on system setup and integration, which is the basis for my partner’s work in dealing with the hardware components.  To facilitate the programming of our Raspberry Pi, I set up the Raspberry OS Desktop and enabled VNC, I2C and SPI for communication. The VNC is for connecting to the Raspberry Pi with Mac laptops. Connecting our Audio HAT to I2c, I identified the slave address of the component, enabling my partner to verify the stable output of audio. However, I am still in the process of making sure radar can properly interact with Raspberry Pi. Though efforts are made, there seems to be some issue remaining that does not allow me receive the signals. Another thing I helped with is the GPS setup. While the GPS should be able to use USB connection, we failed in getting the connection. The reason why it failed still needs to be figured out.

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, my schedule is a bit behind due to unexpected delays with the RPi4 setup, which has taken longer than anticipated. This setup is critical because it involves integrating key components like the radar, speaker, and accelerometer, which are essential for the system to function. My partner’s tasks, including testing and validating the system, are dependent on this integration being completed. The delay in getting these components connected has created a bottleneck, and we cannot move forward with system testing until the integration is finished. To catch up, I plan to prioritize the integration process over the coming week, focusing on resolving any remaining issues with the RPi4 and ensuring that the radar, speaker, and accelerometer are fully operational. I will adjust my schedule to allocate more time toward these tasks, as completing this integration is crucial for allowing my partner to proceed with their work. By expediting this part of the project, I aim to prevent further delays and ensure that we can move forward with testing as planned, ultimately bringing the project back on track.

Upcoming Deliverables

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

Next week, my primary goal is to continue on the system integration by fully connecting and verifying the radar and accelerometer (not received) with the RPi4. This involves running initial tests to confirm the stability and output of each component, ensuring they can interact properly with the Raspberry Pi as planned. Once the components are reliably integrated, I aim to begin component testing, focusing on verifying sensor accuracy and communication. This will involve checking the radar’s obstacle detection, the accelerometer’s fall detection, and the audio system’s response. Starting component testing is critical for assessing how well the system functions under real-world conditions, so finishing the integration will be my top priority.

Team Status Report for 10/26/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? 

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.

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

This week, I focused on setting up the Raspberry Pi with teammates, completing various configurations, syncing our remote servers with local setups, and integrating an audio hat for audio output. After successfully installing and testing the audio hat, I delved into sample codes provided in tutorials to understand how the Raspberry Pi OS interacts with these components. Following the tutorials, I adjusted the audio volume to around 40 decibels, which aligns with our research on maintaining an audible yet non-intrusive sound level. Additionally, I wrote a Python script that leverages an AI package to automatically generate audio outputs. These outputs provide information about the distance and direction of obstacles, an essential feature for enhancing accessibility. The progress included understanding component integration, code testing, and balancing audio settings.

Alongside my technical work, I completed an ethics assignment. This involved engaging with readings, watching relevant videos, and reflecting on ethical considerations within our project.

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 made solid progress on my individual tasks, keeping the project on schedule. Last week, I set specific goals: to support my teammates with system integration and to begin working on the audio hat. We achieved a good portion of the integration tasks. For the audio hat, I managed not only to complete the initial installation but also to fine-tune it, adjusting settings and exploring its functionality within our project constraints. The audio hat is now integrated, performing well in initial tests, and prepared for further development stages. Overall, each of these accomplishments contributes to our overarching goals.

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.
  • Learning if the GPS component can be integrated to Raspberry Pi: if feasible, I’ll support teammates in setup and testing; if direct integration isn’t possible, I’ll help shift to exploring GPS via smartphones, ensuring accurate, synchronized location tracking with the Raspberry Pi for navigation support.

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

I completed design report’s Use-Case Requirement, Technical Requirements, and Testing&Metrics sections in the last past week. To be more specific, in Use-Case Requirement, I detailed the needs of both direct and indirect users. For direct users, I outlined requirements such as the need for real-time audio alerts that enable visually impaired individuals to react to obstacles. This includes specifying alert parameters, like detection ranges and acceptable false negative and false positive rates, to ensure user safety. I also addressed battery life and wearability, emphasizing the need for a lightweight and long-lasting device. For indirect users, such as caregivers, I defined requirements around emergency alerts and GPS accuracy to ensure they can quickly locate and assist users in emergencies. In Technical requirements, I focused on translating these use-case needs into concrete design goals according to the implementation architecture. This included setting benchmarks for the radar’s detection range, accuracy, and response time for audio alerts. I defined power consumption targets to ensure that the device can operate for at least 3 hours on a single charge, addressing efficiency needs without compromising performance. I also specified technical parameters for the fall detection system, including sensitivity thresholds and the maximum acceptable time for emergency alerts to be sent. In Testing&Metrics, I developed a comprehensive plan for verifying the device’s functionality. This involves unit testing individual components like the radar’s accuracy, audio response time, and power consumption. I outlined specific test procedures, such as simulating falls to evaluate the accuracy of the fall detection system and ensuring that GPS coordinates provided in alerts are accurate within a 10-meter range. Additionally, I planned integration tests that simulate real-world use, with volunteers using the device to evaluate its performance in obstacle detection and fall detection scenarios.

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 own progress is on schedule so far, but due to the delay in the progress of each component’s integration, there is a risk that the overall project timeline may be affected. To address this, I plan to allocate extra time for helping in integration tasks in the upcoming week and will collaborate closely with team members responsible for each component to ensure smooth and timely integration. Additionally, I will assist in troubleshooting any issues that arise during the integration phase to prevent further delays. This proactive approach should help bring the project back on track.

Upcoming Deliverables

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

My goal next week is to support my teammates in system integration and unit tests for each component. While they focus on fully connecting the radar, speaker, and accelerometer with the RPi4 and conducting initial tests to ensure stable operation, I will assist with troubleshooting any integration challenges that arise. Additionally, I will help verify the interaction between components, particularly focusing on validating sensor accuracy and ensuring smooth communication between the devices and the Raspberry Pi. I will also contribute to the unit testing of each component, including checking the radar’s obstacle detection and the accelerometer’s fall detection performance, and I will assist in testing the audio system’s response time.

Team Status Report for 10/20/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 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.

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.

 

Zhixi’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 week, I devoted significant time to both the design review report and setting up the physical system. For the report, I worked extensively on the design trade studies, comparing alternatives for components like the radar and accelerometer. I also detailed the system implementation, specifying how each part (radar, speaker, accelerometer) would connect to the RPi4 and their respective roles in the system. Additionally, I reviewed the entire report to ensure consistency across different sections, particularly making sure there were no conflicts between the subsystems. Beyond documentation, I made progress in the hardware setup. The RPi4 is now successfully powered by a portable battery, and the radar, speaker, and accelerometer are all connected. However, I still need to verify the stability and output of these components, ensuring they function correctly before proceeding with testing.

Schedule

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

At present, my work is on schedule, particularly with respect to my designated tasks. However, we have encountered a dependency in the project that may require extra effort to ensure timely progress. My partner’s tasks rely heavily on my completion of the system integration—specifically, having the radar, speaker, and accelerometer connected and operational with the RPi4. This means that while I am on track with my own tasks, I will need to accelerate the integration process so that we can begin testing other components. We cannot fully test or validate the system until all parts are connected, and delays in my integration work could potentially impact the overall timeline. To avoid falling behind, I will prioritize this integration work in the coming week, ensuring my partner has the necessary setup to proceed with their own testing and tasks.

Upcoming Deliverables

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

Next week, my primary goal is to complete the system integration by fully connecting and verifying the radar, speaker, and accelerometer with the RPi4. This involves running initial tests to confirm the stability and output of each component, ensuring they can interact properly with the Raspberry Pi as planned. Once the components are reliably integrated, I aim to begin component testing, focusing on verifying sensor accuracy and communication. This will involve checking the radar’s obstacle detection, the accelerometer’s fall detection, and the audio system’s response. Starting component testing is critical for assessing how well the system functions under real-world conditions, so finishing the integration will be my top priority.

Eleanor’s Status Report 10/05/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).

  • I began working on the design report, taking responsibility in the Use Case Requirements, Design Requirements, partial Design Trade Studies, and the Test & Validation sections. Especially, in the use sase requirements, I identified and documented the various scenarios in which our design would be utilized, and for the design requirements, I outlined the features and specifications that our system need to meet to ensure optimal performance and achieve the use case requirements (both requirements are also listed concisely in the presentation slide).
  • I recorded audios for the sound alert system. I categorized these audio files based on direction and distance. They are divided into three directional categories: left, front, and right, and cover five distance ranges: 1m, 2m, 3m, 4m, and 5m, which resulted in a total of 15 distinct audio files. Each alert conveys the message: “Detecting obstacles in your {direction} about {distance} away from you. Please be careful to avoid it.” To facilitate the playback of these audio alerts, I researched and watched several YouTube tutorials on connecting our audio hat to the  raspberry pi and then transmit and play the audio files during operation.
  • I picked up and returned components which we agreed to relinquish.

Schedule

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

Since my tasks are typically focused on the middle or later stages of the project, the delay in receiving those components does not  impact my individual progress very much. However, I recognize the need to prepare for a potential reduction in my work time in the future and to assist my teammates more, as the delay affects the overall progress, especially the first stage, of our project.

Upcoming Deliverables

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

  • Set up the audio hat as soon as it arrives, and then mock different radar detecting results to test the audio message playback to ensure the files display correctly.
  • Assist teammates with setting up the radar and accelerometer, and support data collection during the initial stage. My primary work will begin in the next phase, once the initial setup is complete.

(due to the components arriving delay, similar upcoming deliverables as last week)

 

Team Status Report 10/05/2024

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.