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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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

Risk and Plans

Continuing from last week, we are making good progress on the software, UI, and hardware connection of the devices. In addition to the risks that were discussed in last week’s report, the biggest risk right now is to make sure that our system will meet the design requirements that we set up. We are just starting the final system integrations. Although individual complements are functioning, we are still unaware of the functionality of the full system. We need to run validation tests to ensure the specs are met. However, since we have limited time, if the system performs suboptimal, we do not have a lot of time to address the issue, which could jeopardize the project. To mitigate this risk, we have adjusted the schedule so that we can keep on track with the system integration. This allows us to start validation testing of the whole system as soon as possible. We have done some good research and implementations on the individual comments based on our requirements, which is a positive aspect to ensure the design of our system will meet the requirements in the end.

Changes in Design

No changes to the design this past week.

Schedule Updates

Here is an image of our updated Gantt chart for this week:

Here are the schedule updates since last week:

Completed tasks 

• Enclosure CAD designs
• RCW/BSM radar implementation

Delayed tasks 

We forgot to account for no work during Carnival previously, but that is now accounted for. Unfortunately, with all the schedule changes we have no more slack time.

• Radar tuning – We’ve shifted FCW radar implementation to run in parallel with electrical/software integration and final bike installation due to delays
• Turn signal development – Turn signal development has been extended to this upcoming Wednesday (4/10) to give Jason time to work out the remaining issue. We’ve also shifted this to run in parallel with electrical/software integration and final bike installation
• Enclosure prototyping/final build – We’ve extended those deadlines and changed them to run in parallel with electrical/software integration and final bike installation
• Total time for polishing has been decreased from 7 to 5 days

At risk

• Electrical/software integration is a little delayed but we may be able to finish it on time. However, we need to be careful not to slip on this, although if it’s just software left to be integrated we can run it in parallel with bike installation

Planned Validation

1. Radar:
   1. Detection Accuracy: We are planning to validate the radar detection results on the full system to determine if it meets the Radar Accuracy Confusion Matrix discussed in the design report. This will be done by riding the bike with the system installed and recording the number of warning triggers in a run. We will video-record the test run so that we have the ground truth of the environment. We will then compare the warnings and the ground truth to calculate the false negative and positive rates of the system to validate the setup.
   2. Maximum Range: After mounting the system on a bicycle, we can park a car and have a measuring tape extended out from the front of the vehicle. Then, with the bicycle moving backwards towards the vehicle parallel to the measuring tape, we can see where along the measuring tape the system first picks up the car.
   3. Distance Accuracy: This is similar to the range check, except we continue to move closer to the car once it’s picked up and verify that what the system is reporting is close to the distance from the car as indicated by the measuring tape.
   4. Speed Accuracy: We will have a driver drive a vehicle past the radar (which is stationary) at a fixed speed. Then, we’ll check that the reported speed is within the accuracy requirement.
   5. Data Update Frequency: To ensure the radar data update frequency is at least 10 Hz, we will have the radar be stationary and have a car drive slowly towards it. Then, we will see how often we receive updates about the car’s distance by counting the number of data updates from the radar to the UI in a certain time period.
2. To validate the durability of our bike safety hub system, we will ensure it’s able to run for two hours with our power bank. This involves both lab and real-world scenarios to ensure functionality and durability in typical usage conditions.

3. To assess the waterproofing of the final enclosure, we will conduct a series of tests gradually increasing in difficulty. Starting with a slight sprinkling to simulate light rain, we will then progress to more challenging conditions, ultimately reaching an IPX4 rain test level. This comprehensive approach ensures that the enclosure can effectively withstand varying levels of moisture exposure, guaranteeing its durability and reliability in diverse environmental conditions.

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 –

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.

Risk and Plans

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:

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

Risk and Plans

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:

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.

Risk and Plans

1. Software bring-ups: We have received all the parts that are needed for this phase of the project. We have dedicated this time in the schedule to do some initial software bring-ups and tests. For example, we need to make sure that the radar will produce the data that will work with our system; finding a suitable framework is another thing that we are working on. These are risk factors because even though we have dedicated time to do the initial bootstrapping, we might run into different situations along the way that will delay the project. Working with software is unpredictable, especially for a project like this. In addition, although each component might work at this stage, the integrating results are still pending. So we still run into the risk of things not working later on in the pipeline. We are managing these risks by doing careful research and making sure we have slack time and backup plans when things go off. For instance, Jason has done a wonderful job of looking into the best UI framework for our purpose. You can see more details on his status report this week. Jack searched for previous usage of K-LD7 radars with Raspberry Pis, trying to avoid issues that people ran into before. He was able to find some useful information for processing data. You can see more on his status report.
2. Hardware designs: Johnny had some amazing ideas for the design of the enclosing box. However, as we ordered the other components, we might need to readjust the hardware design ideas we had in mind to fulfill the shape and size of those components. We have some risks on the timeline for the enclosure and mounting issues because it might be a bit more complex than what we originally expected. We will mitigate this by moving the design timeline up and extending the time available for designing the enclosures. Please see the schedule updates section for more details.

Changes in Design

• We have settled on a UI framework, Electron (see Jason’s status report for details)
• We also changed the power to the turn signal auto-cancellation system to use 3.3V as the high side input from the Pi, not 5V due to 3.3V being the max GPIO voltage (link 1, link 2)
• We also need to source an ADC converter with I2C communication, since the PI gpio doesn’t have analog input.

Schedule Updates

Here are the updates to the schedule from last week:

• Completed tasks 🎉:
  • Radar parts have arrived
  • Turn signal schematics have been designed
  • Raspberry Pi initial software bringup is complete (see Jason’s status report for this week)
• Schedule changes 📅:
  • The Verification/Simulation step for turn signals has been deleted, since the circuits seem simple enough that we can skip that step
    • This change is motivated by the fact that we’re behind and this step seems non-essential
  • The CAD design start date for the enclosures has been moved up to today (from 3/13), and the time for prototyping/refining the enclosures has been extended to two weeks
    • There are some concerns that the original allocated time may not be enough since the things we need to build appear complex, so we wanted to move it up to get more time to work on it
  • Total slack time has increased from 5 days to 7 days

We are currently behind on the turn signal stuff due to incomplete schematic review, although we may be able to catch up by obtaining parts from ECE stock. On other aspects, we are currently on track.

Risk and Plans

1. Parts: The quality of parts remains the biggest risk at this stage of the project. We have done a lot of research on the components that are required for BikeBuddy, and we made decisions based on documentation and logical reasoning. However, a part that looks good on paper may not perform the way we want it in reality. For example, the turn switches that we purchased did not meet our expectations, where the switches need to be toggled to both turn on and off.  This was just a small part of the project, so our contingency plan was to revert to a simple button instead of a fancy turn switch. However, this could be a huge issue if it happens on more time-critical parts like radar. Until we check out all the parts and make sure they are compatible with each other, this remains our biggest risk.  We hope that our careful research for each part will mitigate such risk. However, we have backup parts that can be ordered if our original parts do not work out.

2. Scheduling: In our schedule, we left one-week time for the parts to be shipped. However, the unpredictable shipping speed is another risk that can pull us into schedule issues. The radar is taking a bit longer than we expected to arrive. If a part takes a significant amount of time to arrive, it might lead to a knock-on delay in our progress. To mitigate this, we still have slack time that we can use to smooth things out. We will follow up with the shipping status so that we know if we need to order new parts as backups.

Changes in Design

• We’ve altered the requirement from being portable to simply being easy to install. We realized that we wouldn’t expect the end user to need to frequently move our safety system around so the portability requirement wasn’t necessary. However, we would still like this system to be easy to install hence the change in requirement.
• The motorcycle turn switch we bought turned out not to be what we wanted as the switch didn’t return to the neutral position when activated, rendering our turn signal auto-cancellation system useless. Other turn switches on Amazon (some include example 1, example 2) seemed to have the same issue where the turn signal switch is latching which wouldn’t work for our case. In hindsight, that actually makes sense as how would the turn signal know to deactivate automatically on a motorcycle without being able to sense the handlebar position? Therefore, we pivoted to using motorcycle momentary button switches to activate the turn signal, such as this switch.
  • The wiring diagrams such as the ones listed here indicate that the button shorts the two inputs together which should work for us as a GPIO input into the Raspberry Pi to sense a button press (e.g., put 5V on one side of the switch, on the RPi side have a pulldown to ground).
• We’ve settled on choices for several of our components:
  • Screen choice of a 5″ HDMI screen – We wanted a screen that used HDMI to simplify the interface with the Raspberry Pi (unlike other ones that used raw RGB data!) and this screen met that requirement.
    • There was some concern about whether this would be sunlight visible, but we weren’t able to find a screen that was bright enough, yet cheap and used HDMI (some sources said 1000 nits or 800 nits – I recall seeing 700 nits somewhere but can’t locate the source now :/). The decision we ended up with was that it looked bright enough in photos so we’ll try out this screen and worst case we’ll put a shade/visor over it.
    • We selected the 5″ over the 7″ one because we felt that the 7″ was unnecessarily large.
    • The current draw is acceptable for our use case (the 7″ screen states 0.62 A draw) which is able to be supplied from the RPi 4 which has a 1.2 A USB limit
  • Radar choice of the K-LD7 – According to its product page and datasheet, it supports up to 30 m range for car detection which is more than we need, it mentions blind spot detection as a use case which gives us more confidence that this will work for that, and it performs on board signal processing and gives serial output instead of raw sinusoidal data which simplifies the work we need on our end. The current draw is also minimal (200 mA peak) according to the datasheet.
  • Battery system of the Anker 337 – Initially suggested by Professor Tamal, we settled with this one because it was capable of 3A output on each USB port which was recommended for powering the Pi 4 and output 5V which was what everything we used ran off of. Additionally, the capacity was very large.
• We’ve created an initial block diagram of the system as well:

 

Schedule Updates

There have been no schedule updates since last week and things are currently on track.

Here is the Gantt chart as of Feb. 17, 2024 (click for a full-sized view):

 

Weekly Special Questions

Note: Part A was written by Jonny Tian, Part B was written by Jack Wang, and Part C was written by Jason Lu

A. Public health and safety

Incorporating our project into bicycle design helps mitigate the risk of accidents and promotes overall road safety. Blind spot monitoring systems alert cyclists to potential dangers, reducing the likelihood of collisions with vehicles or pedestrians. This not only protects the individual cyclist but also contributes to the broader public health by minimizing the occurrence of accidents. Additionally, turn signals on bicycles enhance communication between cyclists and other road users, promoting a more predictable and organized flow of traffic. This increased visibility and communication can prevent misunderstandings, reducing the overall risk of accidents and creating a safer environment for all road users.

B. Social factors

Our project will primarily target the social group of urban cyclists and motorists who share the roads in densely populated areas. BikeBuddy is designed so that people from this cohort can afford this product and enhance their safety in their day-to-day lives. This group of people rely on bicycles or share the road with cyclists. The system that we are offering such as the blind spot detection and display addresses the critical need for improved awareness of surrounding traffic, particularly in urban environments for this group of people. In addition, our solution to enhanced bike safety will also promote a safer cycling environment, encouraging more people who rely on bikes to cycle more. Since the design is modular and has user-friendly interfaces, the system can be accessible to a wide range of cyclists.  Overall, our system considers the core needs of this group of people, offering inclusivity and equitable access to safer cycling experiences.

C. Economic factors

Our target price point of less than < $200 was intended to make this affordable for regular commuters who may not be willing to spend as much on a safety system instead of for professionals who have deeper pockets. As a result, we didn’t use arguably better systems such as the TI series of automotive radars which are specially designed for the blind spot monitoring use case in vehicles but are significantly more expensive to use (ex: one EVK for a TI radar cost $358 from Digikey).

Admittedly, at this point, we’re not certain if we can hit the price target, but one hope is that if we calculate the cost to consumer using the bulk pricing then that target  will be feasible. For example, we are currently buying radars for around $86 per unit since we are buying small quantities, but if this is commercialized and we buy larger quantities for production (e.g., hundreds) we can bring it down to ~$65 per radar.

The requirement of being easy to install (which we changed from being portable) also means that the end user should not require specialized equipment or need to go to a bike shop to install the system which further reduces the cost of obtaining this product.

We also do not anticipate significant operating costs to the end user with the exception of electricity bills from charging the battery pack, so there should not be a long term economic burden to the user. The intended ruggedness of the system also should ensure that the system won’t need replacing too quickly which would be expensive.

On a macroeconomic level, another thought we had was that this could reduce total healthcare and vehicle repair costs. If we lower collision rates between vehicles and cyclists, we reduce the number of hospital visits needed for cyclists and the repairs needed to repair vehicles damaged in collisions which will hopefully result in an overall reduced average cost to cyclists and drivers alike (e.g., expected value of repair costs will go down because the probability of a repair being needed is reduced).

Risk and Plans

1. Compatibility and Availability of parts:

This is a major risk for the project at this time because the parts are the foundation of the project. The risk lies in the discrepancies between the advertisement online and the actual product. If the product comes in as not what we are expecting, this could cause delays to our schedule and alter our plans.

We are mitigating these risks by asking people who are familiar with the parts that we are looking for, hoping for a more accurate review. We also plan to order more quantity than needed for each component in case there are manufacturing issues. In addition to the parts that we want, we also have several backup plans that we can order quickly.

2. Integration:

We need to make sure that each part that we plan will integrate properly with others. It might look good on paper, but the actual integration of HW and SW is challenging. We risk taking longer than expected time to solve those issues. These risks are managed by having slack time to troubleshoot the issue.

Changes in Design 

1. No more 9V battery pack, use normal power bank instead since most of our components use 5V
   • Benefits:
     • Eliminates need for DC voltage converter
     • Easier to find off the shelf parts, or people can just use their own power bank
   • Drawbacks:
     • Need to design our own tail light to fit 5V power source
2. Settled on RPi 4 for main embedded system
   • We felt that the performance uplift of the RPi 5 (2 – 3x) was unnecessary for our project when the RPi 4 might provide enough performance at a lower power draw (both idle, under load, and peak power usage)

Schedule Updates

There as been an adjustment to the start date from 02/02 to 02/12 for the turn signal schematic design to give Johnny more time to work on it. This pushes back the start of the CAD design for the enclosures which in turn pushes back the integration date and reduces our slack time to .

We are exploring whether we can do the enclosure design in parallel with the turn signal design so we can move the integration date back up again.

Here is the updated schedule:

Documents

https://course.ece.cmu.edu/~ece500/projects/s24-teama3/wp-content/uploads/sites/270/2024/02/Team_A3_Tian_Wang_Lu_proposal.pdf

https://docs.google.com/document/d/1qXdcfVPIODVeR-x2SSulSoF8A1yPflvq7Hq1ibca5z0/edit