Zexi Yao Status Update Post 10/19

Capstone Status Update

Software Design

  • Algorithm design has been finalized
  • Work began on the basic algorithm using Python. Python was chosen because it was a simple programming language to use, and existing software for running python code on an android device exist
  • Installed and verified Python compiler on Android device.
  • Implemented basic socket connection code to enable communications between both Android devices.
  • Developed equations for calculating trajectories for vehicles (see design review report.

Schedule

On the software side, we are on schedule, however, we have been having delays regarding our bluetooth connection between the sensors and the android device.

To Do

  1. Implement code for bluetooth connection with Raspberry Pi to pass sensor data.
  2. Pull localization data off the decawave app for the collision detection algorithm.

Weekly Status Report – Week of 10/6 from Kyle

  • This week I have begun work on potential designs of sensor systems to compliment the data collected by the MDEK.  The MDEK provides relative position fairly reliably, but additional sensors to collect absolute velocity and information on steering are being selected.
  • It became abundantly clear this week that the MDEK alone does not provide enough information to support a machine learning collision prediction algorithm.  Without such an algorithm, we do not believe we can reliably and quickly predict collisions. This risk is being mitigated with the design of the additional sensor system.
  • My progress is behind schedule.  We have the batteries for testing, but are not yet certain if we need additional MDEK sensors.  To compensate, I am working on competing designs, on of which uses extra MDEK sensors. and another which does not.
  • Our main deliverable this week is finishing the Design Review Report.

Weekly Status Report – Week of 9/29 from Kyle

  • This week I investigated the capabilities of our core sensing system, the Decawave MDEK1001 by reviewing the available documentation and manuals, and papers on other relevant projects using the same system.  Additionally, I looked into methods of powering and testing our system, and ordered  batteries and assembled a chassis for a simple robot car.  Any additional design into the sensor system is heavily dependent on the decision of purchasing more MDEK nodes.
  • This level of focus is being given to the MDEK because its capability is the most significant risk to the project.  The pairing behavior of sensors in its network could limit its range and potential.  We are prepared to add sensors of a different type to compensate for this if it happens, or to add 12 additional MDEK nodes to our existing 4.
  • My progress is behind schedule.  We are hoping to get the batteries we need this week to more conclusively test the MDEK.  Our parts list is heavily dependent on this testing because if our tests show that we need more sensor modules, it will take half of our budget to get more, limiting the other sensors we can incorporate.
  • I intend to have two competing designs this week that differ based upon whether or not we need the additional sensor package.

Zexi Yao Status Update 10/5/19

Design Proposal for Software

As the primary designer for the software side of the project, I have spent this week identifying the workflow for collision detection, and also the required input from the hardware side of the project.

Required Input

  • Relative Location and Distance of Car and Bicycle with respect to each other
  • Absolute velocity of the car and bicycle.
  • Steering input on bicycle and car

Workflow

  1. Bluetooth decawave sensors do automatic pairing once the cyclist and driver are within range
  2. This prompts phones that the decawave sensors are connected to, to also pair with each other and begin sharing information.
  3. The bluetooth sensors send the data over the decaWave app to the phones (for both the car and the bicycle)
  4. The software computes the relative position and velocity of both vehicles.
  5. Machine learning determines based on current steering and velocity if the vehicles are going to turn in the near future and determine the probability of a collision in the future
  6. If a collision is imminent, the phone will send an audio alert to its owner.
  7. The phones will then check with each other to ensure that the other party has also been alerted.

Collision detection algorithm.

The non ML part of the collision detection algorithm has been fully designed. The current algorithm uses trigonometry between the different sensors to determine not only the position, but also the heading of both vehicles.

I am still looking into various options for the ML algorithm, currently I am looking into predicting steering by looking at vehicle velocity before a turn.

Schedule

We are somewhat behind schedule, since a vital part of our design process hinges on testing the capabilities of our sensors first, and we need our batteries delivered in order for us to conduct the testing. We aim to make up for this lack of progress next week, since the testing will give us experience with the sensors in order to finish the document.

On the software side, this setback is not a considerable one for the design, as we can work with black box input for the algorithm for now.

About Our Project

A major cause of cyclist injuries on the roads is due to collisions with vehicles, oftentimes due to drivers that simply did not notice the cyclist until it was too late. Our project aims to improve cyclist safety by creating a collision avoidance system that provides advanced warning for drivers and cyclists, alerting them to each other’s presence and enabling them to take evasive action.

We will use bluetooth technology to provide accurate real time position and velocity of both vehicles. When the system determines that a collision is imminent, it will send an audio alert, drawing the attention of both parties and prompting them to take the necessary actions to avoid a collision.