Final report PDF: Team_A3_Lu_Tian_Wang_final_report
Final Video
Team Status Report for 4/27
Risk and Plans
The biggest risk right now is something does not work as intended during integration, as we have little time to correct it. We were facing issues with our turn signals, which we realized were due to the misuse of the transistors. It turned out that we were putting way too much current through them. This could have been mitigated if we read the datasheet carefully. This was a good reminder for us to rely on datasheets instead of our “confirmation bias” while integrating, and minimizing the unnecessary risks. However, as the deadline approaches, there are only little things we can do if anything goes out of plan. If this happens, we will try to mitigate the effects by identifying the key components that need to work first and prioritizing their functionality. This will let us reach our MVP.
Changes in Design
- Due to testing, we notice there are times where led will slightly light up when the gate is connected to source. From our 220 knowledge we know this shouldn’t be the case for a N mosfet. After testing, we notice there are current going from Vcc(5v) to the gate into pi. This little current is driving the leds and make them very dimmly lightup. Hence we suspect the MOSFET could be broken. Also we checked the datasheet, the max current going through each of the transistor needs to be no greater than 500mA. However, we are only putting 6 ohm resistor in series with them, which is driving almost 1A of current. Then we switched to 10 ohm resistor, which solves this problem. Even thought this can lead to the leds not running on their full capacity (1W each), through our testing, this is still able to satisfy our visibility requirements.
Schedule Updates
Here’s the Gantt chart as of writing on 4/27:
Here are the schedule updates since last week:
Completed tasks 
- Enclosures have all been printed out and installed onto the bicycle (“Prototyping/Refinement/Final Build” task and “Bike Installation” task are complete)
- There was an accident on 4/27 where we broke the left rear turn signal mount due to the bicycle falling over, so that will need to be fixed
Lagging tasks 
The following tasks are behind:
- Turn signal development – Some movement on this the past week, but still not complete – see Jason’s update for more details.
- Road Testing + Testing/Metrics Capture – We are behind on both of these tasks. We haven’t had a chance to take this out onto the road for real world testing. Furthermore, we’ve completed about 35% of the testing we need to do, whereas both tasks are due tonight. Work will have to continue this next week and will therefore run in parallel with final polish
Miscellaneous task changes
- For the “Prototyping/Refinement/Final Build” task and “Bike Installation” task, we are going to exclude sealing the system for waterproofing until as late as possible, as once that happens we will not be able to easily access the internals of the systems.
- Feedback capture task deleted since we’re no longer having ease of installation as a use case requirement anymore
Special Topics
List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.
- Power consumption: We have tested the power consumption of the system. The results were 1.64 A peak current draw (which gives us a good idea of the worse case current usage) and 1.14 A average current draw, with the Raspberry Pi’s current draw being mostly responsible for the difference between the peak and average current draw. During the initial tests, we realized that the current going through the transistors was too high which were destroying them (we were pushing more than double the current limit), causing us to change to larger resistors for the LEDs.
- Radar distance: We have conducted some radar tests, including max detection distance to the rear and the side. For the rear, we can detect a car up to 25.14 m on average, whereas on the side (edge of car is 6 feet away from center of bicycle, simulating being in another lane), the range drops to 11.84 m on average which is below our 14 m requirement. Interestingly, the car was actually detected out at 18 m and again around 14 m briefly, which suggests that perhaps the radar is capable of picking the car that far out but we just need to tune the system.
- Turn Signal Range: We were able to test the daytime visibility of the turn signals, reaching a result of > ~112 ft (if measuring using Google maps) or at least 104 ft (since we measured 98 inches of width per parking spot, and there were at least 13 parking spot widths of distance). Either way, this exceeds the 100 ft daytime visibility requirement. We still need to test the night time range. At this moment, no changes are needed.
- Distance Accuracy: This test needs to be redone, but preliminary results show that on average the radar has about a 3% error in its reported distance compared to what we measured using the measuring tape, which is acceptable since it’s under the 10% threshold.
- Velocity Accuracy: This test also needs to be redone, but preliminary results show that on average the radar has about a 7% error in reported velocity, although given the difficult of maintaining a precise speed in a vehicle this may not be that reliable to cite.
Jack Wang’s Status Report for 4/27/24
Personal Accomplishments:
- 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.
- 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.
- 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.
Next Week:
- Integration
- Demo Preparation
Jack Wang’s Status Report for 4/20/24
Personal Accomplishments:
- 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.
- 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.
- 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?
One of the new tools that I learned is how to properly send data between the radar and the UI. I learned how to use Named Pipe and how to pack my raw data from the radar into JSON format. I learned this by first researching strategies that could achieve our desired outcome, from which I picked the simplest solution given that we are not processing tonnes of data. After identifying the tool, I read through the implementation documentation on how to implement such a pipe. Then, I did some simple experiments and basic testing before fully utilizing it on our system.
Next Week:
- Integration
- Demo Preparation
Team Status Report for 4/20
Risk and Plans
Although we are making good progress in integrating the system, unexpected problems are popping up, which might jeopardize our plan. At the final stage of the project, unexpected delays remain the biggest risk that we need to mitigate. Much of the mitigation of the last-minute delays has already been in place throughout the project. We made sure each component functions as desired and have plans on how to integrate them. However, we could not predict everything, as in every other engineering project. For example, we found the dimensions of the 3D-printed parts were slightly off. This meant that it would take us extra time to fix the issues, increasing the risk of running over the project deadline. We can mitigate this because we intentionally have not planned a lot of work for each member, other than integration, during the final phase of the project. So when an issue arises, the entire team can focus on addressing the issues and solving them more efficiently. We also make sure that we have a priority list of items that need to be working for our MVP, which allows us to address more important issues first when challenges come. With such planning, we hope that the chances of running over time are low as we still have some slack time for the project.
Changes in Design
No changes to design.
Schedule Updates
Here’s the Gantt chart as of writing on 4/20:
Here are the schedule updates since last week:
Completed tasks
- FCW implementation
- Electrical/software integration – We have communication with all electrical components and between software
Lagging tasks
The following tasks are behind:
- Enclosure prototyping/refinement/final build – This task is supposed to be done by EOD 4/20, but we’re not there yet.
- We have enclosures for the radars, buttons, Pi, battery pack, and display 3D printed, but adjustments need to be made to the battery pack enclosure so the battery pack can fit, the Pi enclosure so wires can be routed, and the screen enclosure needs a cover.
- The front radar also needs a mounting system
- We also have not sealed anything for waterproofing
- The turn signal lights are mounted onto the bike along with the rear radar, but we are considering redoing the mounts to use a thicker material for better stability.
- Bike installation – This task should also be done by EOD 4/20, but we’re not there yet either. Here’s the current status (✅ = installed, ⚠️ = technically installed but not fully functional, ❌ = not installed):
- Turn signal buttons: ✅
- Turn signal LEDs: ✅* (may need to redo mount)
- Rear radar: ✅* (may need to redo mount)
- Front radar: ❌
- Raspberry Pi: ⚠️* (installed but will need to modify enclosure design)
- Battery Pack: ⚠️* (installed but will need to modify enclosure design)
- Display: ⚠️* (partially, need cover)
- Turn signal development – See Jason’s update for details in the “Adventures in magnetometer calibration” section, but this is still not completed
Miscellaneous task changes
- For the enclosure, we combined the prototyping/refinement and final build tasks into one task
Jack Wang’s Status Report for 4/6/24
Personal Accomplishments:
- 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.
- 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
- 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.
- 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.
- 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:
- Integration
- FCW radar tuning
Team Status Report for 3/30
Risk and Plans
We are making good progress on the software, UI, and hardware connection of the devices. However, the biggest risk right now is the waterproof enclosure. This task was more complicated than we anticipated, and we were facing issues in finding the correct materials and the location to 3D print/laser cutting them. Although the CAD is done, the actual printing has not started, and the timeline is still unpredictable, which might easily drag us into more delays. To mitigate this, we are trying to move people around to help with this task. Originally, Johnny was taking all the load on this part of the project. However, since Jason and Jack are making some good progress, they might be able to help Johnny with this part to ramp up the speed if needed.
In addition, the risks that were discussed in last week’s report remain valid.
Changes in Design
No design changes for this week.
Schedule Updates
Here is an image of our updated Gantt chart for this week, although the enclosure status may be inaccurate:
Here are the schedule updates since last week:
Completed tasks :
- Initial UI complete
Delayed tasks :
- Radar implementation – We continue to slip on radar implementation. Note that we’ve changed the task from radar tuning to radar implementation, as at this point we’re just aiming to get the radars working (e.g., segmenting points into cars, determining lanes) instead of worrying about tuning. As of today, the RCW/BSM implementation is delayed until 3/31 (Sunday). The FCW implementation will most likely also be delayed but since we don’t have a plan yet for this it’s left on the schedule as is so its timeline is not accurate. One option is to run FCW implementation in parallel with electrical/software integration.
- Turn signal development – Turn signal development is started but is still behind, so we’ve extended the dates to the coming Wednesday. This has resulted in downstream delays in all tasks, eating into our slack time. We now have 1 day of slack time left.
- CAD design/prototyping –
Jack Wang’s Status Report for 3/30/24
Personal Accomplishments:
- 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.
- 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:
- Continuation of radar tuning
- Radar & UI Integration
Team Status Report for 3/23
Risk and Plans
The current risk that we encounter is still similar to what was discussed in last week’s report. Specifically, one of the risks that might jeopardize our progress would be running into issues that we did not expect. This week, when we were trying to tune the radar, we realized it was more complicated than originally thought to be able to detect cars that are traveling in different lanes behind the bike. Since the bike is constantly moving left and right, it would be very hard to use one distance cutoff to determine if a car is directly behind the bike or if it is left/right of the bike. We need to do more testing to find a proper metric. Similar to some issues we had last week, such unexpected issues might lead to lengthy delays. To mitigate this, we still have our built-in slack time in the project timeline, and we try to dynamically adjust the schedule and plan if needed. The adjustment is based on our MVP requirements. We also need to find a fine balance between the accuracy of the system and the time it takes to get it working. This will be motivated by our design requirements.
Changes in Design
- We have settled on using Plexiglass as the radome material
Schedule Updates
Here is an image of our updated Gantt chart for this week, although the enclosure status may be inaccurate:
Here are the schedule updates since last week:
Completed tasks :
- Turn signal schematics signed off
- Enclosure sealants have arrived
On track tasks 
:
- UI software development
Delayed tasks :
- Radar tuning – Due to delays in the radar tuning, we’ve punted the dates for all tasks to be from 3/23 – 3/29. This is a significant risk as further delays here could potentially cause downstream delays, and this is a complicated task.
- Turn signal development – We have not started on turn signal software development yet, so this has also been punted to 3/23 – 3/29.
As of now, this has not resulted in overall delays, but any further delays in any of those tasks beyond 2 days will cause downstream delays so we need to be careful not to incur any more.
- CAD design/prototyping – The initial CAD design has not yet been completed, but prototyping will begin on Monday which is later than intended but still within the assigned time slot.