Emmanuel’s Status Report for March 8th, 2025

WORK ACCOMPLISHED:

This week I spent time working on our team’s design report, refining the device encasing mount design, and getting setup with RPi4 to use the sensors.

Refinement of our design through working on our report took a significant amount of time. It led to me doing more research on other sensors like the doppler radar sensor. This might be used in the future if I struggle to develop an algorithm that allows use to differentiate incoming versus stationary objects with the the ultrasonic sensors. Creating a compatible Nite Rite bike mount for the device encasing seems more complicated than creating one for the GoPro bike mount so I decided to switch and order a GoPro mount since my AutoCad skills aren’t super strong. Lastly, I set up our RPi4 for my laptop and ran some test scripts in Thonny in preparation to program the sensors.

PROGRESS:

I’m currently slightly behind with tasks, I wanted to have the basic distance detection script for sensors working by now. I think I can make up time next week. We found out parts for the wristband got lost in delivery so we had them reordered and will pick them up after spring break.

NEXT WEEK’S DELIVERABLES:

Next week, I aim to establish basic object and distance detection functionality with the sensors and setup circuit for the wristband.

Akintayo’s Status Report for February 22nd, 2025

WORK ACCOMPLISHED:

This week, I tried to work on setting up the Raspberry Pi 4, but I realized I would require a micro SD card reader; hence, I was unable to move forward as I was missing the device. I also worked more on the Google Maps API.

Additionally, I decided to modify the design of the system by removing the web server and localizing the navigation and audio system to the Raspberry Pi instead. This drastically reduces the latency required for our system.

PROGRESS:

Due to some issues I faced, I’m currently behind schedule as I had expected to finish up with how to record audio files from the Raspberry Pi and also begin to work on integrating the Google Speech-to-Text AI.

NEXT WEEK’S DELIVERABLES:

I am mostly will try and catch up on last week’s deliverables. So, I will working on how to record audio files from the Raspberry Pi and sending it to the Navigation endpoint. I will also begin to work on integrating the Google Speech-to-Text AI.

Emmanuel’s Status Report for February 22nd, 2025

WORK ACCOMPLISHED:

This week I spent time familiarizing my self with the CMU’s 3D printing process and AutoCad in order to help tweak our device encasing design.  Additionally, I took time to look at different bikes around campus to get a better understanding of how our device will be attached.

Through my time exploring and even riding a bike during the city’s busy periods I realized a velcro strap would be unstable for securing our device. Additionally, our encasing protrusions will be difficult to design in way that keeps our sensors secure and in place when hitting bumps while riding. I did research into existing bike mounts that can clamp to the bike seat shaft and we aim to pivot so our encasing can clip into one of those mounts (specifically NiteRider design). Working in AutoCad for the first time in years too longer than expected but a rough idea of our new bike encasing (newer than in team status report) is below. Edits have yet to be made for the sensor holders (protrusions) because we just got the sensors at the end of the week.

PROGRESS:

I’m currently on schedule with my tasks. Still waiting on the mini bread board and the vibrations, hopefully they arrive next week.

NEXT WEEK’S DELIVERABLES:

Next week, I aim to establish basic object and distance detection functionality with the sensors, submit order for bike mount, and complete written design report.

Team Status Report for February 22nd, 2025

This week we started receiving materials for our project and began testing their functionalities. We received our sensors, blues starter kit, microphone, batteries, and our raspberry pi hat. Our current risk is  stable mounting of our device to bikes. Our current implementation relied on a velcro strap which we realized after using bikes this week will be unstable.. Most bicycles use a mounting clamp to add accessories so we’ll do the same. We’re redesigning our encasing to be compatible with the NiteRider Tail Light Strap Mount. 

Since last week we decided to eliminate the web server aspect and will have all of the server processing happen on the raspberry pi. Two main reasons for this: sending audio to blues cloud is very inefficient due to the round trip latency from sending back and forward through the cloud to an internet-hosted server.  Thus not using the Blues cloud will reduce latency and it’ll be cheaper since we won’t be charged for each block of data being sent to the Raspberry Pi.

Sample Design of Encasing for Navigation/Audio System

 

Sample Design for Wristband  

New framework for navigation portion

NEXT WEEK DELIVERABLES:

Main tasks for upcoming week: complete setup for raspberry pi, finish setup for blues starter kit, get basic object detection with sensors.

Forever’s Status Report for February 22nd, 2025

WORK ACCOMPLISHED:

This week I worked on initial design sketches for our attachable to the Bike device and for the wristband. We wanted to give an idea of what the goal of our project was. So I showed the wristband with a small hole section for the vibrating motor to stick out of. For the main Rid3 device, I added holes for the speaker to be mounted to and same for the microphone. I also included antenna’s for the sensors to be mounted. This is just a tentative sketch and will be updated in the future.

This week I also worked through redesigning the concept for information transfer for our design. In the beginning we had decided to have our design work on an information system where data was sent through to the blues cloud, to our hosted server, back through the blues cloud, and then to the raspberry PI. But I addressed an issue where audio information could not be sent through the blues cloud due to the fact that it only takes information in as a json. So we decided to pivot our system to use the raspberry PI as the main host, that way we do not have to deal with sending through the cloud, but instead could do our main computing on the Raspberry PI device. I’ve also been playing around with the blues starter kit, by assembling it together and attempting to do sample test runs, however this was hindered by the fact that the usb cable I had could not do data transfers.

PROGRESS:

This week I accomplished most of my tasks, except testing with the blues starter kit to see how Information is delivered, due to the usb cable not being able to do data transfers.

 

NEXT WEEK’S DELIVERABLES:

Successfully run the blues starter kit process, and collect gps longitude and latitude data. Help program the raspberry pi to be compatible with the other devices that we are using such as the sensors and bluetooth modules.

 

Team Status Report for February 15th, 2025

This week we decided to flesh out the overall design for our project and made final decisions regarding the materials that we needed, which led to us submitting our requests for hardware and software. The most significant risk that exists at the current stage of our project would be processing power and latency. We currently have a lot of moving pieces connected to the raspberry pi for our design. Which means it needs to be able to sufficiently supply enough power to each of these pieces as well as respond quickly enough for information sharing. This is why we decided to use a Raspberry PI 4 versus our previous usage of the Raspberry Pi 3A+. It is a lot more capable, but still does not require as much processing power / energy as the Raspberry PI 5. We are also looking into usage of resistors + transistors for managing of power, so that we don’t have too much energy flowing in areas where we don’t need it. Another design change we made was switching from ToF sensors to Ultrasonic sensors. This was due to the fov of the sensors, we wanted to make sure we were able to capture a breadth of information instead of less. We also decided to use a USB microphone, just to simplify the pin out process, and make it easier to connect other pieces. The changes didn’t create a noticeable cost difference as the pieces were around the same price.  See below updated block diagram and schedule.

Additional Questions:

Part A: … with respect to considerations of public health, safety or welfare. Note: The term ‘health’ refers to a state of well-being of people in both a physiological and psychological sense. ‘Safety’ is the absence of hazards and/or physical harm to persons. The term ‘welfare’ relates to the provision of the basic needs of people.

By giving bicyclists a hands-free, real-time navigation and blind spot detection system, our solution improves public health, safety, and welfare. Conventional navigation techniques, such as looking up instructions on a phone, can be distracting and raise the risk of accidents. By wirelessly delivering obstacle alerts and directional indications to a vibration-based wristband, our device removes this risk and enables bikers to focus on the road. This improves rider awareness and considerably lowers cognitive overload, which benefits both physical and mental safety. The incorporation of ultrasonic sensors guarantees prompt identification of cars or other objects in blind spots, averting possible collisions and promoting safer interactions between motor vehicles and bicycles.

Furthermore, by promoting safer and more effective cycling, which is an eco friendly and healthful form of transportation, our solution advances public welfare. Our device adds to urban mobility solutions that benefit communities and individuals by increasing bike accessibility through a cheaper navigation tool and lowering the chance of accidents. Accurate route guiding is ensured by the Blues Starter Kit’s GPS tracking and server-based navigation system, which keeps riders from getting lost and lowers stress, both of which can improve general wellbeing. In the end, our product promotes a more secure and safe riding experience, enhancing public safety and encouraging a more sustainable and healthy transportation culture. A was written by Emmanuel.

Part B: … with consideration of social factors. Social factors relate to extended social groups having distinctive cultural, social, political, and/or economic organizations. They have importance to how people relate to each other and organize around social interests.

One important social factor that needs to be considered in regards to the project is the speech component. Specifically, the system will be receiving the user’s destination for their journey via their voice. As a result, different people have different speech intonations in their voice. In the same vein, people speak in different languages. For the scope of the project, we are solely focusing on ensuring the speech recognition and the audio response is functional primarily for English speakers. To handle different speech tones, we are using the Google Speech-to-Text AI system to handle this as it is optimized to identify a variety of speech types.  B was written by Akintayo.

Part C: ... with consideration of economic factors. Economic factors are those relating to the system of production, distribution, and consumption of goods and services. 

One of the general themes that our group wanted for our project was the idea of a low cost low profit  model. Essentially, we aim to prioritize consumer satisfaction and accessibility to our product over company profits. Therefore, important factors that we must consider to achieve this goal are cost of production and cost of labor. At the moment the cost of our product seems kind of high relative to the alternative options that are our there. For example, google maps navigation paired with an apple watch. However, most of the products do not come with a haptic feedback feature that provides additional safety for bike users. So as we’re building we’re looking for cost efficient parts, that are lightweight and user friendly, but also aren’t too unreasonable due to the safety the product provides. Our highest priority is safety and ensuring that those needs are met before all else.  C was written by Forever.

 

 

Akintayo’s Status Report for February 15, 2025

WORK ACCOMPLISHED:

This week, I primarily worked on designing the workflow for using the user’s voice commands to extract the destination for the trip and also began thinking about the relevant data that will be required for the Google Maps API call.

Google Maps API url

(Cleaned) API response  with locations and navigation instructions

Additionally, I decided to change the type of microphone being used for the system from a MEMS Omnidirectional Microphones to a standard USB microphone. The main reasoning behind this was that the USB microphone is easier to configure and has better sound quality compared to the initial microphone.

PROGRESS:

I am in progress for the moment.

NEXT WEEK DELIVERABLES:

For the upcoming week, I will be working on how to record audio files from the Raspberry Pi and sending it to the Navigation endpoint. I will also begin to work on integrating the Google Speech-to-Text AI.

Forever’s Status Report for February 15th, 2025

WORK ACCOMPLISHED:

This week I made final decisions for the parts needed for the GPS tracking for the our Rid3 device. I had to find a way to connect the Blues tracking device to the raspberry pi which was something we hadn’t considered before because we assumed they would be compatible. But I found a PI hat available that would allow the two to be used together for our programming.

A good portion of my time was also spent looking into alternatives for our design. I spoke with 3 potential users about how they felt about the design, and took their feedback back to my team to decide on potential designs we could pivot to. I brought up the option of potentially having the GPS information come directly from a phone device and having our application work on a web app. This would leave most of our focus on the haptic feedback wristband. We ended up sticking with our idea, but it helped in generating potential avenues we considered and further added to why we decided on our design choices. I also mapped out pinout connections with the raspberry pi as the central focus, and remodeled some of the pin out choices for our wristband as well ( see below ).

PROGRESS:

I’m currently on schedule with my tasks, this week was primarily research and finalizing design plans + making orders.

NEXT WEEK’S DELIVERABLES:

For next week, the goal is to begin hardware implementation. We currently don’t have the hardware which is my primary focus, so as things start coming in, I’m confirming their specs and see how they work. Also measuring out the power consumption needed by each of the individual parts.

 

Emmanuel’s Status Report for February 15th, 2025

WORK ACCOMPLISHED:

This week I focused on finding and comparing quantitative measurements for the hardware materials of our device in order to justify our use case requirements in our design presentation.  I focused on exploring current/power draw, baud rates, and pinouts  to solidify how the wristband mechanism will receive information from the Raspberry Pi wirelessly, and how the wristband will be held together for the user.  Also, I spent time building our design presentation.

I spent time researching different specifications for our batteries, sensors, and vibration motors. I started with current draw to make sure our batteries could sufficiently power our circuits for a decent amount of time. Next I fleshed out the pinouts for our components to refresh myself on creating circuits with a breadboard and to know if we had enough space to build our system on a mini breadboard . Additionally, we need to know if he had enough pins on our raspberry pi. Lastly I looked at baud rates for bluetooth module (HC-05) and average transmission times for our other components and they seem to be adequate to meet our latency goals. Between last week and now we decided to make this device only for bicycles that way we can attach our device underneath the bike seat so the rider isn’t blocking the sensors,

PROGRESS:

I’m currently on schedule with my tasks. We ordered  parts and hope to see somethings arriving next week.

NEXT WEEK’S DELIVERABLES:

Next week, we hope to make any adjustments based on our design presentation feedback. Additionally, we hope to start tinkering with parts that may come in.

Forever’s Status Report for February 8th, 2025

WORK ACCOMPLISHED:

This week I focused on researching components for the software and hardware components of our device. I mainly focused on the GPS aspect of our device, which involved figuring out how the sensor data would be read, parsed, and filtered. Then ultimately sent to a cloud server for data processing. I also did research on the cloud server we plan to use + databases for storage of data.

The decision making for parts was based around price, efficiency, and integration capabilities. We’re using the Blues Starter Kit which comes with an Arduino board, dual cellular and GPS antenna, and a modem for connecting to WiFi. Blues focuses on efficient power usage, which allows for continuous use, but the ability to have energy saving modes for the tracking device. We’re using their cloud service to receive information regarding the sensor data, and transferring that to our own server which will most likely be a ubuntu server with a python web-framework due to the simplicity.

Most my time was spent interconnecting this device with the other moving pieces that we have, which was shown in the solution approach diagram that we had for our presentation. Specifically the Raspberry PI as the main center piece. Making sure there is streamline communication between our Raspberry PI device and the Blues cloud server. Using the cellular data on the Blues device also allows us to communicate directly with the sensors on the vibrating wristband, to allow for wireless connection between the motors and the raspberry PI.

PROGRESS:

I’m currently on schedule with my tasks, this week was primarily research and finalizing material needed which was accomplished. We plan to have a finalized parts list by Monday (02/09).

NEXT WEEK’S DELIVERABLES:

For next week, the goal is to have put in the orders for the materials needed. As well as starting to build the software systems that we need in order to receive and parse the data. I also plan to start working with what we currently have in the lab, to see how pieces of the Arduino connect with software, as a baseline to start with before our pieces arrive.