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