Personal Accomplishments:

1. Final Presentation: Together with Johnny and Jason, we finished the slide deck for the Final Presentation. I made the slides about testing metrics and set up templates for other slides. During lab meeting time, I listened to other teams’ presentations, asking questions and providing feedback. I was able to hear about other people’s projects while reflecting on our project to see what to be cautious about during the final testing and integration.
2. System Integration: I spent the rest of the time this week helping Johnny to finish the integration of the system onto the bike. I helped with soldering wires and making sure they were connected correctly. We had a mishap with properly using the MOSFET, where we put too much current through it. This was quickly fixed by reviewing the datasheet and changing the circuit design. The bike is fully integrated at this point.
3.  Testing: I did tests on the max current draw of the system, radar detection accuracy, and the visibility of the turn signals. Together with Jason, we drafted test plans and executed the tests one by one. However, more tests need to be done in the coming week, including real-world testing.

Progress:

I am currently on track to finishing the integration of the system.

1. Integration
2. Demo Preparation

Personal Accomplishments:

1. Radar: In the past two weeks, I finished the work of the both rear and the front radar. Two radars were able to work independently, providing data like distances and velocity. In addition, I worked on the integration of the radar with the UI that Jason developed. I introduced that we will be using Named Pipe from the last status report, and I was able to configure the set up so that the information I sent from the radar matched with the desired format that Jason was looking for in his UI. In addition, I also implemented some basic strategies to de-noise the radar detection. I did so by looking at 3 consecutive detection frames and filtering out data points that only appeared in 1 frame, which is defined as noise. I would only forward the data to the UI if the target is appearing in all 3 frames. At this point, the full radar-UI pipeline is working as desired.
2. Integration: Together with Johnny and Jason, I integrated the system onto the bike. This included making sure the wiring was correct, and each module was functioning as it should be.
3. Testing: We did some tests for our system based on the design requirements. I drove the car behind our bicycle setup, and we recorded data like detection distance and velocity. These results will be shared in the final presentation.

Progress:

I am currently on track to finishing the integration of the system.

Special Topic:

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?

Next Week:

1. Integration
2. Demo Preparation

Personal Accomplishments:

1. Interim Demo Set Up (2 hrs): I spent some time this week setting up the radar portion of the interim demo.  In addition to plotting the data points, I printed out the possible warning types (collision/blind spot) based on the location of the target. I then presented the setup on Monday.
2. Radar Tuning and UI Integration (10 hrs): I spent the majority of time last week processing the radar signals to make them useful for our needs and integrating the radar with the UI that Jason has been doing. I discussed with Jason about what is the relevant data that should be sent to the UI and how to pack the data. We agreed that I would be doing the majority of the data processing. Specifically for the rear radar, I will divide the region into three sectors as discussed before. For the areas of blind spot detection, I will send a positive flag if the radar detects an object within the threshold. This is because the UI only cares if there is an object approaching the “blind spot” and does not require detailed information; for the region of rear collision detection, I will send over the object that has the closest absolute distance to the bike, where the UI will be using the distance and velocity information to alert the rider of a possible collision. I discovered that we could use Named Pipe to send the information between my radar processing script in Python and Jason’s UI implementation in JavaScript. I packed the data into JSON format and did some basic testing with Jason to verify the communication. As of Friday, we were able to transfer data from the radar detection script to the UI.

Progress:

I finished the radar tuning and some basic UI integration, so I am on track for now. I will be taking over Jason’s task of tuning the forward radar, given the similarity of its functionality to the rear radar. This is to keep us on track with system integration. The latest schedule in our group report reflected this change.

Verification

1. Basic Radar Detection: I have run some tests to benchmark the basic functionality of the radar. This was done by setting up the radar in a controlled environment and having people running/walking toward the radar from different angles to simulate incoming traffic. Using the plot generated, I verified that the radar could accurately detect the approaching people with reasonable distance output. The result is analyzed by recording the output x-y distance that the radar is reporting and comparing them with the actual location of the people, which is measured with meter sticks. This data is used to benchmark the metrics mentioned in the Radar Accuracy Baseline section of the design report. This verification task indicated the basic functional success of my radar implementation.
2. Integration Verification: I verified that the output data of the radar was correctly communicated with the UI. This was done by printing out the raw data in the radar processing script and the information that the UI received. This is to make sure that the system is updating data correctly, which indicates the functionality of the communication pipeline.
3. Radar Detection in Real World Environment: This will be a verification task that I will do soon, since I just finished tuning the rear radar. The goal of this verification task is to make sure that the radar will provide the desired detection results in the real traffic environment. I will mount the radar onto the bike and drive a car approaching the bike in a parking lot. I will then analyze the result to see if the radar output makes sense. This includes comparing the distance and the velocity output of the radar with the ground truth data, which is measured by tape measure and speedometer.

Next Week:

1. Integration
2. FCW radar tuning

Personal Accomplishments:

1. Radar and Integration (9 hrs): I continued working on radar and integration this week. While plotting the data points from the radar, I realized that it was plotting with delays. I suspected that was due to Pi’s performance and caused by plotting along, not the actual detection speed. I verified this by setting the radar to different baud rates. After raising the baud rate, the lagging during plotting still existed. However, when testing with just print statements, it seemed that we were getting data fast enough, prompting me to believe that this was just due to the Pi’s performance on plotting. I also kept working on radar tuning, processing the data the way that we wanted. I discussed with my team again on when to trigger the Blind Spot Warning or the Rare Collision Warning. We came down to a plan that we only trigger the RCW when there is an object directly behind the bike (i.e., the x-coordinate is +/- 3m from the bike). All objects in the other areas will trigger BSW based on their location. This was a bit simple compared to the “drawing box” method that we were thinking of last week. This should also reduce my workload on tuning the parameters. I do not have a visualizable demo for such progress yet, but I have been modifying the code to play around with the output of the radar. I also adjusted the wiring of the hardware setup, since now we have more devices connected to the Pi.
2. Interim Demo Plans (3 hrs): I spent some time thinking about my part of the interim demo that is coming up next week. I will be demoing the radar, so I planned for a similar plotting setup like the one shown last week. However, I will add some flags to let the user see which kind of warning is triggered. I met with Jason and Johnny to discuss how to present our work during the demo. The focus will be on individual parts of the project for now, meaning that we will start integration after the demo.

Progress:

The radar tuning took longer than I expected last week, so I am a bit behind on that. However, the basic implementation will be done before Monday. I might need more time to do the tests. The integration should also start this coming week, so I am not terribly behind schedule. I am still able to manage my work given the current slack time.  We have also adjusted the plan (please see the group’s status report) so that the downstream task will not be affected by the delay.

Next Week:

1. Continuation of radar tuning
2. Radar & UI Integration

Personal Accomplishments:

1. Ethics Lecture & Activities (3 hrs): During lecture time on Monday, I attended the ethics session and participated in the in-class activities. We analyzed some of the worst-case scenarios for our projects and discussed them with other teams.
2. Radar Work (9 hrs): The primary work this week was on the radar tuning. After the software bring-up was done last week, my goal was to figure out how to tune the radar parameters and make them useful to our needs this week. I started by plotting the radar output using some codes provided by RFBeam. Here is an example output:

There are a lot of parameters that can be tuned for the radar to achieve different detection outcomes. I researched the ways to tune the parameters based on the datasheet. There is a Python driver that contains some helper functions to tune these parameters, but I think we do not need to rely on that as the tuning should be very simple based on the datasheet. Another thing that I was exploring this week was how to process the radar targets. I did some brief tests on Wednesday to figure out how the radar is outputting the target. In the raw target mode, it would show the target in reference to the local x-y locations. Since the radar is mounted toward the back of the bike, the y-axis indicates how far the car is from the bike and the x-axis shows if the car is left or right on the bike. This work will be continued next week.

Progress:

I am currently somewhat on track with the radar tuning, although more work might need to be done, so it might go over the time that we originally budgeted. There were some delays to get the tuning started as it was complicated. However, I am on track after the adjusted schedule. Please see the team status report for more details.

Next Week:

1. Continuation of radar tuning
2. Preparing for the interim demo.

Personal Accomplishments:

1. Lab Meetings (3 hrs): During the lab meeting time, Jason, Johnny, and I touched base on our current schedule and discussed more about what material the radar cover should use. We felt happy about the adjustment we made last week. See last week’s group report for more details. We met with Prof. Fedder and received feedback about our design review paper.
2. Ethics Assignment (4 hrs): I took some time to reflect on the ethics articles that are related to the ethics assignment. I learned the political implications of engineering and analyzed technologies like autonomous aircraft and facial recognition technology.
3. Radar software bring-up (5 hrs): I finished the initial radar software bring-up by allowing the radar to read out some basic detection results. Here is some basic output:

There were some issues in establishing the communication between radar and RPi during the process. Initially, the default UART port for RPi did not transmit nor receive data. This was resolved by updating the firmware of the Pi after reading a post in the forum. After the basic UART functionality was checked out, the radar still was not able to communicate. I realized that the default UART for RPi 4 was a mini-UART, which does not support parity bits based on this chart. 

Our radar requires even parity, so the default UART would not work. I reconfigured the hardware setup so that the radar used UART2, which supports parity bits. This resolved the communication issues. In this phase, I let the radar print out a list of detection targets with their distance and velocity. This concluded the radar’s initial software bring-up task for the project.

Progress:

I am back on schedule from last week’s slight delay. The initial software bring-up for the radar was completed early this week, and I am in the process of tuning the radar for our needs.

Next Week:

1. More radar tuning for blind-spot detection and collision detection.
2. Ethics lecture

Personal Accomplishments:

1. Design Review Paper (11 hrs): Together with Johnny and Jason, we finished the design review paper during the regular lab meeting time and some extra time outside the lab. I wrote the introduction, use-case, system implementation of radar, design tradeoffs of radar, and previous works sections. You can see more about this paper here. During the writing, I researched more on the parameter tunings of the radar. Specifically, what parameters can we tune, and what they are for based on the datasheet. I created the flow chart for communication between the radar and the RPi. I also found the requirements for the radar dome that we are trying to build for water-proofing purposes. This includes the thickness and the type of materials we need to use. I shared this information with Johnny, who will be designing the case.
2. Radar software bring-up (2hrs): I continued the progress of the radar software bring-up by establishing communications successfully using the GPIO pins and UART.

Progress:

My progress is a bit behind schedule on the radar setup due to the heavy workload for this week. However, I am only a little behind so I will be able to catch up with the schedule by this Monday, without affecting the overall progress of the team. The parameter tunings will start then.

Next Week:

1. Finish radar software bring-up by Monday
2. Start radar parameter tunings

Personal Accomplishments:

1. Presentation (6 hrs): Together with Johnny and Jason, we finished the slide deck for the design review presentation. I made the slides about testing metrics and why we chose to use radar instead of other distance-measuring equipment. During lab meeting time, I listened to other teams’ presentations, asking questions and providing feedback. I was able to hear about other people’s projects while reflecting on our project to see what can we improve in terms of hardware and software design.

2. Miscellaneous (2 hrs): I set up the team GitHub repo for version control. The link to that repo is omitted here since we are not releasing the source code yet. Johnny, Jason, and I did a quick functionality check with the screen that we purchased. I set up the hardware connection between the K-LD7 radar and the Raspberry Pi using a breadboard. This is not the final setup for our system; it is used for software bring-ups and tests that will be discussed in the next section.

3. Radar Initialization (4 hrs): I began the software bring-up process for the K-LD7 radar. The first phase includes setting up the radar and getting some basic detection results. I did some research on how to get the radar module working with Raspberry Pi and how to get useful output. In the datasheet for K-LD7, I learned the signal processing flow of the module and different parameters such as speed/direction measurement, angle measurement, and distance measurement that we can tune. I discovered a Python API for K-LD7, which is very handy. According to a post from the Raspberry Pi form, RFBeam provided a simple testing script to test the basic functionality of the radar. The script is based on a setup with an evaluation kit. I modified the script to make it work with Raspberry Pi. However, until the time of the blog post, I have not tested the radar setup yet. This will be done before the team meets on Monday.

Progress:

I am still on schedule, but running tight on time. The radar bring-up was started this week. However, it was delayed a bit due to the later-than-scheduled arrival of the radar module. The deadline for the software bring-up is this coming Monday. However, given the current progress, I might not be able to fully test the software functionality of the module, although the basic initiation will be completed by the deadline. To solve this matter, I will prioritize solving issues related to radar software bring-up next week. We have some slack time during spring break as well, so I still have some buffer to fix any remaining issues without disrupting the main schedule. Overall, the work on the radar is still going as planned.

Next Week:

1. Finish radar software bring-up
2. Simple radar detection tests
3. Varying parameters to see how the results change.

Deliverables: We should be able to get some serial outputs from the radar on some basic detection. The output should be displayed using pyserial. We should also have a better sense of how to use this radar module in general, and what will be our challenges in this phase.

Personal Accomplishments:

1. Lab Meetings (4 hrs): With my team members, I finalized the BOM of the project, especially the choice of radar. We have discussed the benefit of the K-LD7 radar based on the datasheet. It provides us with the range that we need, along with a nice serial output that is easy for us to process. I have also identified a Python driver for the radar to help us process the output data of the radar. The radar and the other components were ordered. During the lab meeting, we presented our ideas to Prof. Fedder and the TA, where we received the acknowledgment of the radar choice.
2. Presentation Prep (4 hrs): Together with my teammates, I prepared the design review presentation.  Please see here for more details on our presentation. I am mainly in charge of the design requirements, radar, and testing slides.
3. Project Meetings (4 hrs): I discussed the power source of our project with Jonny, and with the help of Prof. Mukherjee, we decided to use a large enough power bank as the power source. I researched the requirements for using radar frequency bands based on the FCC regulations. I also reached out to Prof. Sullivan to confirm the regulations. I also tested our LED blinker with Jonny.

Progress:

My progress is on schedule so far.

Next Week:

1. Software bring-up for the radar if they arrive
2. General course assignments and documentation

Personal Accomplishments:

1. Presentation (4 hrs): Together with my teammates, I prepared and presented the proposal presentation on Monday.  Please see here for more details on our presentation.
2. Lab Meetings (4 hrs): I listened to other teams’ proposal presentations during lab sessions, asking questions and providing feedback. I was able to hear about other people’s projects while reflecting on our project to see what can we improve.
3. Project Meetings (4 hrs): I met with my teammates outside the mandatory lab meetings and discussed the bill of materials (BOM) for our project. I spent time researching possible radar modules that we can use to do blind spot detections. As of the time of the post, I have narrowed down the choices to two radars (K-LD7 & HB100). I will continue to discuss with my teammates to make a final decision.

Progress:

My progress is on schedule so far.

Next Week:

1. Review and finalize parts on our BOM.
2. Review the documentation for the radar that we choose and search for compatible libraries if needed.