Team B3: BikewardsView

This week I figured out how much capacity the battery for our system would need. To do so, I found the current draw from each of the components. In doing so, I learned about luminous efficiency and determined that the LEDs that we were planning on using were extremely inefficient. Considering that our system is run off of a battery, conserving power is very important, so I picked out another set of LEDs. I decided to go with addressable LED strips because they had a higher luminous efficiency (above 100 lumens/W, which is acceptable for red LEDs) and they would allow us to output more light over a wider area, as well as adjust their output if necessary.

Once I found the LEDs that we were going to use, I combined their current draw with that of the other components, giving us a maximum current draw of 5.5 A. This number is much higher than what our average current draw should be, considering that the lights won’t always be on and they won’t be outputting their full RGB spectrum. Additionally, we will have an on/off switch for the system overall, so we won’t need to power 5.5 A for 10 hours. Thus, with 1 hour of on time and 8 hours of standby/off, that should give us at least a 5Ah battery.

This week I also worked on the slides for the presentation. I updated the schedule, the overview drawing, and added some drawings. I also will be giving the presentation so I practiced presenting.

For most of the week I have been looking into sensors with my team to make final determinations for what should be used for our blind spot sensor. At the time of my last status report we were looking into a mix of long range single point LIDAR sensor and ultrasonic sensors, so I started the week by coming up with a possible arrangement for an array of sensors that used two of each kind. This arrangement is can be seen in document V2: V2SensorPlacementLIDARULTRA

However, following a suggestion for the use of a 24GHz microwave sensor from Jason, and some research into that solution and discussion of the pitfalls and merits of all solutions we had discussed prior to it, we decided to make our primary solution an array of at least two microwave sensors which we filled out the form to order during class on Wednesday. I have since been familiarizing myself with how that sensor presents distance information. It appears as though the sensor will allow us to determine the distances of multiple objects, but not their particular look directions. With two sensor this means that though we can cover our entire FOV as the sensors have a 3db beam width of 78 degrees, the most information we can give back to the user is which sensor detected the object. However, this still allows us to tell the user if something is behind them to the right or left. Further, by looking at a possible overlapped area of the sensors, a third sector for objects seen by both sensors could be achieved. Some of my initial thoughts into the example code provided by the manufacturer for multi-object detection and a basic layout of the signals processing code to handle information can be seen in document V3: V3ManCodeCustomCodeStructureMicrowave

Me and my teammates are planning to get together later today to edit/create our design presentation slides and I hope to also determine with Jason who is in control of the device drivers what language we plan to use so that I can code up most of the signals processing code this week. Possibly with the exception of the code to filter out any “noise” from the ground as some baseline data from the sensors will be useful before adding that section.

Because we have decided to change a lot of the hardware components of our system, I’ve looked into options for those changes.

We also have a concern about distracting the cyclist with the LEDs on the handlebars, so I’ve also looked into other indicator options. Vibration was suggested, but for a safety critical system, vibration is too unreliable considering that roads aren’t smooth and that in different weather conditions, the rider might be wearing gloves that could dampen the vibration. Audio was also suggested as a method of communicating to the rider. Audio queues would have to be repeated and run the risk of being too quiet to be heard clearly over city noise. There would also be cases of emergency vehicles causing very loud noise and cyclists wearing earphones. I looked into ways of mitigating the dangers associated with the LEDs, specifically their brightness in the dark. We can use diffusers so that the light doesn’t shine directly into the eyes of the cyclist. The diffusers will require that we pick out brighter LEDs since they decrease the output by 2-6%.

We have also decided to move away from the planned PCB for the system and to use an eval kit instead based on TA advice. This will allow us to better make changes to the system as problems arise. I haven’t used an eval kit before, so I spent some time looking into how to use/build with them. Overall, my schedule can now be moved forward somewhat since we won’t have to wait for shipping and can assemble and debug as soon as the parts are in. I’ve started work on the schematic, but the changes to the sensors and the LED response system need to be finalized before I can finish.

This week we’ve had a lot of hardware updates to our project idea based on the feedback that we received from our project proposal. We are looking into using a static sensor array rather than a single 360-degree LIDAR sensor. This will hopefully allow us to update the system of new inputs more often.

We are also looking into using both ultrasonic sensors and LIDAR. LIDAR gives us more detection distance (up to 40m in favorable conditions) yet is less reliable in bright lighting conditions and could be affected by our LED indicators on the back. The ultrasonic sensors can’t cover as much distance as the LIDAR sensors but aren’t affected by the LED indicators. We plan on using them as the primary short-range sensor, ~10m or less. That way, when we have the LED indicators on, we know that the sensing isn’t being adversely affected.

We had originally planned on using a LED strip because the 360-degree LIDAR would give us enough information to report where the nearby objects were with more granularity. However, especially since we are switching to static sensors, we decided that we aren’t going to attempt to provide that much information. This will help us not overload the cyclist with excess information: the cyclist doesn’t need to know the width of the object closing in behind them, they just need to know that there is something generally to the back left, the back right, or behind them. More to this point, we have decided to go with zone LED indicators-similar to what you’d see for the side indicators for a car.

We received some questions about how exactly we are going to communicate to the cyclist about the conditions behind them. We plan on using a system where a steady light in a zone indicates the presence of an object that is tracking behind them, while filtering out stationary objects. Then, when there is what we consider a danger, like something closing in fast or that is very close to the bike, we are going to flash the LED of that zone. We are cognizant that we need to pick out LEDs that are bright enough to work in daylight conditions, while also not blinding/distracting the cyclist, especially at night.

From here, we are going to research these changes and their practical brand options, and integrate them into our design.