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:
Gantt chart as of 3/23 (click for full screen)
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.
Continued UI development (see “State of the UI” section below)
Schedule
I was unable to complete any tasks from this week:
Complete initial implementation of main screen code (with faked sensor data)
Start integration with Jack’s radar code
Start implementation of turn signal control
Start radar tuning for forward collision warning
I’m close to completing the UI, the remaining tasks on my plate are (at least what’s needed for integration):
Add UI elements for rear and forward collision warnings
Finish up code to simulate turn signal button presses (almost done at time of writing)
Allow overriding a radar zone’s data to show no car detected, currently we can only control the range and velocity of the car detected in the zone but not whether a car is present or not.
With respect to the UI itself, I am currently on track although there is a risk of slippage depending on how long these remaining tasks take. According to the schedule, I have until tomorrow to complete the visualizations, so there isn’t much time left.
Because of the delay in starting the other tasks, I’ve shifted the dates for the radar tuning (forward collision tuning) and turn signal implementation to 3/23 – 3/29. This has not resulted in any delays, but further delays (which is a high risk!) in these tasks runs the risk of delaying the overall electrical/software integration such that it results in a cascade of delays downstream. I’m hoping that I can make good progress on these during the lab times this week.
Upcoming Deliverables
The main deliverables for this week are similar to last week except for removing integration with Jack’s radar code since that task doesn’t start until 3/30, and changing “start” to “complete” for turn signal implementation and radar tuning since their deadlines are soon:
Complete initial implementation of main screen code (with faked sensor data)
Complete implementation of turn signal control
Complete radar tuning
State of the UI
Please see this video I recorded for the current state of the UI: Google Drive link (you will need a CMU account to see this).
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.
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.
We are trying to bring more components of the project together. Some current tasks are making sure the software bring-ups are successful, and that hardware design will fulfill our needs. One of the risks that might jeopardize our progress would be running into issues that we did not expect. For example, the radar software bring-up took a bit longer because we had to resolve some basic UART communication issues that were related to the Pi. In addition, we were trying to find optimal materials for our radar cover, which we did not initially believe to be this time-consuming and challenging. However, it turned out there are a lot of details like the permittivity and the thickness that we need to consider. Such unexpected issues might lead to lengthy delays or, even worse, change of plans. We tried to do as extensive research as possible beforehand to minimize such things from happening, but it is unavoidable like any other engineering project. 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 hope to minimize the impact of unexpected errors by staying on top of the game, and making sure we work through other simple, non-technically intense parts of the project efficiently.
Changes in Design
We do not have any design changes since last week.
Schedule Updates
Here is a screenshot of the Gantt chart as of this week:
Gantt chart as of this week (click for a larger view)
Here are the schedule updates since last week:
Completed tasks :
Initial radar software bringup complete
UI software mockup complete
All remaining parts (buttons, magnetometer) have arrived
On track tasks :
Tuning BSM
UI software development
CAD design
Delayed tasks :
Tuning FCW – Jason may not have time to complete this within the next week, we may need to adjust schedule based on discussion – we have also about 1 week of slack time to delay this without delaying electrical/software integration, and even if that is delayed we have a couple of days of additional slack time before bike installation occurs.
Turn signal development – Turn signal schematics signoff is still incomplete, so we will push to ensure that is done soon. We also have not started on turn signal software development yet – that will result in a delay for that specific task although we have sufficient slack time in the schedule to absorb a delay of ~1 week without affecting downstream tasks
Out of the 4 targets from the last update, I’ve completed 2 tasks (highlighted in green) and 2 tasks are unstarted (highlighted in red).
Complete UI mockup
Start implementation of the UI in code
Last time I set the target as “Start implementation of the UI in code (with faked sensor data)” but I realized that didn’t make sense so I removed the “with faked sensor data” for this update.
Start implementation of turn signal control
Start radar tuning
With respect to the software side of the UI, I am currently on track. However, I am behind with respect to the turn signal control software and radar tuning as both should have been started at this point. I plan to discuss with the rest of the team on the radar timeline as I may not have time this upcoming week to tune the radar.
Upcoming Deliverables
The main deliverables for this week are:
Complete initial implementation of main screen code (with faked sensor data)
Start integration with Jack’s radar code
Start implementation of turn signal control
Start radar tuning
Updated UI Mockup
After last week, I realized that the range indicator for a bicycle which looked similar to a wifi indicator could be ambiguous as to the meaning. For example, if the range indicator is full strength, does that mean the car is near or far?
Therefore, I redesigned the range indicator to be similar to what Toyota has for their parking assist proximity sensing system (see “Distance Display” under this page from the 2021 Venza manual). Under the new system, an arc will light up corresponding to the range of the detected car, with further arcs indicating a longer distance. The color of the arc will also serve as a visual cue, with green indicating far, yellow indicating medium, and red indicating close range.
Other changes this week include:
Removing the vehicle indicator, previously indicated by grey boxes on the old UI
Fixed empty space above emergency braking background
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.
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.
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:
More radar tuning for blind-spot detection and collision detection.
Out of the 2 targets from the last update, I haven’t completed either (highlighted in red):
Complete the UI mockup by 2/28 – I completed an initial mockup after the 2/28 deadline, but I just realized I need to make some pretty big revisions to it so it isn’t complete
Start implementation of the UI in code
I am a little behind as I haven’t started on the UI implementation nor completed the UI mockup. I aim to complete the mockup and start the implementation this week.
Therefore, I needed to extend the due date of the mockup from 2/28 to 3/13 (which also pushes the UI implementation start date back), along with changing the UI implementation end date from 3/15 to 3/24 as I’m not confident I can finish it in the original time frame of 1 week (the new allocated time is 1 + 1/2 weeks). This should be OK as I had extra slack time anyways, so there aren’t any delays due to this. There are a lot of tasks going on now so there is a risk of further slippage, but for now this is the plan.
Upcoming Deliverables
The main deliverables for this week are:
Complete UI mockup
Start implementation of the UI in code (with faked sensor data)
Start implementation of turn signal control
Start radar tuning
UI Mockup
For the UI mockup, I built it using Figma. I’ve heard of Figma but never used it before, but thankfully it seems quite easy to get up and running. Here’s a picture showing mockups of various scenarios:
Mockup of various scenarios
Note that the UI uses portrait orientation and is inspired in part by Tesla’s visualization (a little bit like the image under “Driving Status” in the Tesla Model Y Owner’s Manual). From left to right, the screens display:
Vehicles detected both in front and behind. The signal strength indicates how close the car is, although as I’m typing this I realize that this can be very confusing (e.g., is max signal strength close or far?). I will explore how to redo this. The grey rectangles are placeholders for vehicle symbols (e.g., like how Tesla has grey vehicle models for other cars) and show up only if a vehicle is detected.
No vehicles detected in front or behind
Forward collision warning triggered
Rear collision warning triggered
Blind spot monitoring – A vehicle is in the left lane besides us
Time management is the greatest risk for the current phase of the project. In the past week, the heavy workload caused us to be slightly behind the overall schedule. We are having a slight delay in enclosure design and manufacturing. If we stick with the previous plan, we might be causing massive delays in our project. Hence, while Johnny is speeding up finishing the CAD design, we are also making backup plans of running system integration in parallel with the enclosure design. We are currently running with a reasonable slack time. But if the delay continues, we will run into scheduling problems. We are communicating between team members to make sure that the schedule is updated, and that it is within the tolerances of the slack time that we have. Another challenge is that a design change might add some time to what we have planned. For example, we are learning what kind of materials and specifications can be used for the radar cover as we go through the datasheet, which caused us to take extra time to figure out the new design. These are all managed by cross-checking out plans and splitting the work as needed to make sure that we meet the absolute deadline.
Changes in Design
We have changed our plan for radar radome material. Our current plan is to use closed-cell polyurethane foam to be water-proof while allowing radio waves to pass.
Schedule Updates
There have been some significant changes to the Gantt chart. Here is the updated Gantt chart:
Gantt chart as of 3/9, click for fullscreen view
Here is a summary of changes:
Extended deadline for software bringup for the radar to 3/11 since it isn’t complete
Renamed the turn signal task of “Benchtop Testing” to “Development” to better capture what we’re doing and added Jason to assist Johnny with that
Deleted the “Bike Installation” step from the radar and bike signals since we can’t do that until we have the final enclosures complete
Instead, we added a new task called “Electrical/Software System Integration” where we integrate all the electrical and software pieces together without actually installing them on the bike – this removes the dependency on having the enclosure being completed first
We renamed the “Full System Integration” step to “Bike Installation”, where we’ll install everything onto the bike – this depends on enclosure completion and electrical/software system integration
Extended CAD design time to 2 weeks since Johnny needs more time
This pushes back Bike Installation by a week, but because our original final demo date was 4/29 and is now 5/3, we only effectively lose 3 days
Set final demo date set to 5/3 based on final exam schedule
Due date of UI mockup extended 2/28 to 3/13 (which also pushes the UI implementation start date back) since Jason needs to make more changes to it
UI implementation end date extended 3/15 to 3/24 as Jason is not confident he can finish it in the original time frame of 1 week
Our slack time is now 4 days.
Weekly Special Questions
Note: Part A was written by Jack Wang, Part B was written by Johnny Tian, and Part C was written by Jason.
A. Global Factors:
Our BikeBuddy will have a great impact on the global scale. The system will be able to be installed on different kinds of bicycles, so each individual around the world could benefit from such a system. Bike safety is definitely not only a local concern in Pittsburgh, but an issue faced by all bike commuters around the globe. We try to make the system generic so that it will be able to perform things like blind-spot detection and illuminate turn signals in diverse road and weather conditions. People who utilize it will not need to be technologically savvy. Instead, it will be designed to be able to use and interpret the information easily. This system will not only be beneficial to the cyclist community around the world but to all the general public who shares the road. It will likely reduce the number of crashes between the car and the bike, creating a safer road environment. It will not just be a system that will contribute to those in academics, but a system that people can actually use, benefiting their day-to-day life on a bike, no matter where they are.
B. Cultural Factors:
Integrating blind spot monitoring and turn signaling features represents not only a technological advancement but also an innovation intertwined with cultural factors. In cultures where cycling is popular, these innovations can significantly enhance safety, reflecting a commitment to promoting responsible behavior on the roads and emphasizing cyclists’ well-being.
In diverse linguistic environments where individuals may not share a common language, visual cues become universally understood. Turn signals, as a non-verbal and standardized method of communication enabling drivers and pedestrians to anticipate and respond to upcoming maneuvers.
In addition, clear and consistent signaling enhances adherence to traffic regulations, contributing to a smoother flow of traffic and improved road safety. When riders consistently utilize turn signals, it becomes easier for law enforcement to monitor the traffic.
C. Environmental Factors
If we are able to encourage more people to bicycle instead of taking their car by giving users more confidence in their safety on the road, we can improve the environment by taking more vehicles off the road. This will hopefully improve air quality, reduce use of fossil fuels, and reduce noise pollution.
However, our product itself may have a slight negative environmental impact due to the materials involved in building the system. For example, I believe our battery (Anker 337) uses lithium, and the extraction of lithium can have negative impacts on the environment such as “[the] use [of] large quantities of water and related pollution; potential increase in carbon dioxide emissions; production of large quantities of mineral waste; increased respiratory problems; alteration of the hydrological cycle” (https://news.climate.columbia.edu/2023/01/18/the-paradox-of-lithium/). While our product does not use large amounts of lithium compared to things like electric vehicles or other resources such as rare earth metals that are perhaps needed for things like the Raspberry Pi, we nonetheless do contribute to these issues.
System Implementation for enclosure and turn signals.
Section 7 test and verification.
Part of section 8 project management.
Radar Cad enclosure design (5h)
Decided to go with polyurethane foam over polycarborate or abs board – radar have a very specific requirement for the thickness and density of the radome (cover for the radar). Off shelf sheets often don’t have required thickness for the cover and 3d printing abs will not provide a uniform density. Hence, the best option is to use polyurethane foam which is practically invisable to radar.
:
:
:
