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.

Akintayo’s Status Report for February 8th, 2025

For this week, I was working on research for the speech and navigation aspects of our system. Specifically, I was identifying the different software components that would be required in translating the user’s speech, containing their desired destination, into inputs that can be used by the Google Maps API platform for retrieving the intended route. This is the tentative workflow for this process:

  1. Microphone receives location from user’s speech
  2. Google Speech to Text AI is used to extract destination from user’s speech
  3. Google Maps Geocoding API to translate location to Longitude and Latitude (Numerical Representation)
  4. Use the location information from JSON response with user’s GPS location to get route from Google Maps Direction API
  5. Each leg of journey is stored in a database so, each “leg” in the journey maps to an instruction at that point e.g. turn left on xxx road, turn right at yyy intersection
  6. The system will use the real-time GPS location to locate the closest leg of the journey and use that leg’s instruction for audio output to the user. The algorithm for figuring out closest leg to the current location is the R-tree algorithm.

For next week, I will be working on programming working demos that utilize the Google Speech APIs and Google Maps APIs. Additionally, I will be working on how to use the R-tree algorithm for the navigation system.For next week, I will be working on programming working demos that utilize the Google Speech APIs and Google Maps APIs. Additionally, I will be working on how to use the R-tree algorithm for the navigation system.

Emmanuel’s Status Report for February 8th, 2025

WORK ACCOMPLISHED:

This week I focused on researching components for the hardware aspect of our device.  I focused on exploring parts for the vibration motor, different sensors for detecting objects, how the wristband will receive information from the Raspberry Pi wirelessly, and how the wristband will be held together for the user.  Also, I spent the beginning of this week preparing and presenting our proposal.

My decision making  for parts was based around  price, accuracy, and integration capabilities. We’re planning on using a simple Eccentric Rotating Mass (ERM) vibration motor because of size and shape. We’ll need a transistor that connects this motor to the Arduino so we have enough voltage to activate motor but it doesn’t need much We’re going to be leveraging HC-05 RF Wireless Bluetooth Transceiver that will send and receive data from the Raspberry Pi to the Arduino that will be in the wristband.  Between our proposal and now we decided to make switch from the VL53L0X ToF Sensors because their field of view for object detection is minimal.  We plan on moving to A02YYUW Waterproof Ultrasonic Distance Sensors or JSN-SR04T.

I spent a lot of time envisioning how the different parts will connect on the wrist band. We plan on using a mini bread board and encasing the system (breadboard, Arduino, and transceiver) in a 3D printed case while have the ERM motor embedded in a strap that will secure the case to the user’s wrist. Although the connections should be minimal I’m concerned about pin space on the breadboard and ensuring the vibrations don’t disrupt the circuit.

PROGRESS:

I’m currently on schedule with my tasks. We planned to have a finalized parts list by Monday (02/09).

NEXT WEEK’S DELIVERABLES:

Next week, I plan to focus on outlining the software stack for the sensors and motors, along with having a more detailed design for the wristband pin out. A physical design for the band would also be ideal. Lastly, I also want to put in a purchase request for parts .

Team Status Report for February 8th, 2025

One of the main concerns for the project is ensuring the functionality of the sensors is fully in-line with the intended use case. Specifically, we still need to decide whether we are using either an ultrasonic, laser or LIDAR sensor for identifying objects in the blindside (rear) of the user’s vehicle. Based on which sensor is selected, it then determines where the system needs to be located on the vehicle. In the same vein, it is important that we research and test all possible options in order to make an informed decision.

Following this, another consideration for the project is connecting the data from the “object detection” sensor and sending this to the vibration system on the wrist band in a timely manner.

 

NEXT WEEK DELIVERABLES:

One main task for the upcoming week is making the purchase requests for the different hardware and software components for our system.