Author: zhixihua

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

This week, I worked closely together with my teammates on debugging the whole pipelined integration system and progressing the final report, poster, videos, and demo. For the integration system, I collaborated with my team to identify and address an issue where running the two subsystems simultaneously caused the audio output to fail with random frequency of speech. While we initially suspected the audio hat hardware, we determined that the root cause was signal interference during integration. We were using two threadings, one for the radar-audio subsystem, and the other for the gps. To resolve this, I helped replace threading with subprocesses, which allowed the subsystems to run in isolated environments. The current integration seem to work better than before based on our integration tests with the whole system. Additionally, we modified the system to operate immediately upon pressing a button on the vest, eliminating the need for external control via a laptop.

I also actively participated in extensive testing, including unit tests for individual components, integration tests for the subsystems, and comprehensive testing of the fully assembled vest. By adhering to the testing protocols outlined in our design report, we validated the system’s functionality and performance under expected conditions (see group report for detailed results). The testing also lead to the fine tuning and modification of our system, adapting more to our use case requirements. I changed the code logic for obstacle detection – the radar would have a memory of old obstacles for 3 seconds without reporting it repeatedly, however, would report and consider the obstacle as a new one after 3 seconds even if it is the same one detected before.

Schedule

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

Our project is slightly behind schedule due to minor unexpected issues. To address this, I have been working closely with my team to ensure we dedicate sufficient time to catching up. With the final deadline next week, I will continue focusing on optimizing our workflow to deliver all required deliverables on time.

Upcoming Deliverables

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

  • Perform additional functionality checks to ensure all components are working reliably.
  • Finalize and submit the final video, poster,  demo, and report

Zhixi’s Status Report for 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).

  1. Interim project demo (2 hours): My teammates worked together to practice our interim demo to make sure that every demo is covered and challenges are mentioned. We also got together and practiced to make sure that we are able to demo everything within the 10 minutes period, ensuring a smooth workflow on the demo day.
  2. Prepared for the final presentation slides (6 hours): I worked together with my teammates to finalize our final presentation slides.
  3. Pipelining components and subsystems (3 hours): While for the interim demo, all components and subsystems are demoed separately, I started pipeline them together in a single main file combining the radar-audio subsystem and the accelerometer. Since the accelerometer still have issue with python implementation (spidev library incompatible), we still need to use C code for that. Therefore, I used subprocess to pipeline it into all other python code implementations and precompile the C code to make it work. The details still need to be adjusted to make it work according to use-case requirements and to improve the user friendliness.

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 on schedule. We are almost there for the project and just need to do the final integration testing.

Upcoming Deliverables

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

  1. Final system integration testing as a whole.

 

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

To implement and debug the ADXL345 integration with my project, I had to learn how to use Python’s subprocess module to execute precompiled C files within a Python script. This became necessary as the I2C communication was not functional, and the Python spidev library failed to provide reliable SPI communication. I explored how to precompile the C files for SPI communication with the ADXL345, ensuring the logic was correct and efficient, and then pipelined the execution in a single Python file to streamline the workflow. My learning strategy included reading official documentation, experimenting with simple examples to understand subprocess calls, and iteratively debugging by adding print statements to ensure seamless communication between Python and the C implementation.

Team Status Report for 11/16/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? 

  • 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.

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

  1. Accelerometer testing (4 hrs): I spent time working together with my partners testing the accelerometer. While this was originally not my work, I helped out as there was some issue. We initially decided to use the spidev library from python to setup the accelerometer. However, the readings are sometimes all zeros or sometimes of the same value for all three directions. The values are also extremely large which is clearly not related to gravity. Therefore, we decided to switch to C code using libraries in C, and everything worked well. Therefore, we might need to do more work on putting things together since all of our other code is in python. We need to precompile the C code first and using subprocess to link to python if the python library for SPI still does not work.
  2. Radar tuning (4 hrs): I spent time fine tuning the radar together with my partner. We basically had one person holding the radar, looking at the radar reading, and listening to the audio output. The rest two people pretended to be people walking in front of the radar to simulate different situations and see if the detection was accurate and met our use case requirements.
  3. Button setup (1 hr): I set up the button (solder the button with wire) for cancelling resolved fall alerts. We bought new buttons that are bigger and more user friendly to press on. I connected it to the RPi4 using GPIO ports with internal pull up resistors. I also set up the code for cancelling false alerts with button debouncing and verified that it could properly cancel the alerts locally.
  4. Prepare for demo next week (3 hrs): I spent time discussing and making slides for the demo next week. We specified what can be demoed and who to demo which part since our work somehow overlapped most of the time.

 

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 on schedule. I helped out on testing for radar since often times the testing  need multiple people working together.

Upcoming Deliverables

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

  1. Fine-tuning for radar in real-world scenario.
  2. Help teammates test other systems if needed.

Zhixi’s Status Report for 11/9/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. Accelerometer setup (6 hrs): I spent time working together with my partners setting up the accelerometer that arrived late. Initially, we were trying to get it connected with I2C to the RPi4. However, due to some undetermined issue, the connection via I2C was never detect by the RPi though we made sure we were using the correct GPIO pins, and that all setting for I2C on RPi4 was properly enabled. Therefore, we switched to SPI and rewrite the code that reads the accelerometer output. Luckily, we were able to get it to work with desired readings.
  2. Radar software setup (6 hrs): I spent time fine tuning the radar together with my partner. We built our code on top of an existing starter code for the KLD7 radar. We added a plot of obstacles detected so help us tuning and understanding the data. We mainly worked on understanding and fine tuning the radar parameters such as FoV of reading, max speed of object to be detected, and distance for detecting. One thing worth noticing is that the KLD7 is only able to detect obstacles with relative speed. In other words, objects might seem to “disappear” from the radar is relatively static. To overcome this, we figured out that the radar does have some extent of memory (the “HOLD” parameter) where it is able to continuously report the detection for certain period of time.

 

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 on schedule with all systems set up done. I am now in the process of doing unit test and tuning for the radar together with my teammate.

Upcoming Deliverables

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

  1. More radar tuning for obstacle detection based on obstacle magnitude and obstacle message generation.

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.

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/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.

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.

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.