Author: eeclayto

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.

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.

This week, I focused on researching for the project proposal slides. Starting with component research, I looked into what brightness of LED we should use for the cyclist indicators and the rear lights by looking into brightness standards for displays and car tail lights respectively. Then, I used our usage requirements and the current draw from the LIDAR, STM32F4, and the LEDs to estimate our power needs. I also assembled the GANTT chart from the information that Jason and Albany provided and made the system diagram chart.