Team B0: Vehicle Cyclist Collision avoidance System

Software

• Working on UI and app interface for the user.
• Finished testing of collision detect algorithm, ready for final integration
• Socket connection code verified and tested for data transmission

To Do

• Finish UI interface for user experience
• Integrate sensor data into app.

Capstone Status Update

Hardware Design

• Bicycle sensor system heavily damaged, repairs underway
• In process of repairing or replacing the phone for the bicycle sensor system
• Bicycle system progress currently halted

Schedule

• Sensor system schedule harmed by loss of phone
• Integration delayed until phone recovered
• Calibration will be continuing until the end

To Do

• Still continuing with car sensor system, needs integrated with Android system
• Need repairs to bike phone ASAP

• Parts for car, as well as extra decawaves came in. Beginning installation of hardware for car now.
• Tested reliability of bicycle sensors, started integration of software and hardware of bicycle sensors.

• Wrote socket integration into collision detection code, awaiting debugging and live testing
• Started working with the API of the apps and sensors on the bicycle, and am working on passing live feed data from the sensors to the app.
• Waiting on hardware installation on the car side before integration can commence for the car

Team Status

• Individual hardware and software parts are currently making good progress. We estimate to be able to start integration by Monday, and to have all subsystems ready to begin integration by the Monday after that
• Plans for integration have been laid out, we know exactly what data needs to be transmitted from the hardware side to the software side
  • Speed for the car and bike
  • Location for the car and bike
  • Heading of the car and bike

Software 

• Basic Collision Detection program completed.
• Started testing of socket code between phone and laptop – theoretically should work fine between phones. Behavior is identical with regards to sockets.
• Prepared software for midterm demo! 😀

Schedule

We are on track to our goals for the midterm demo, however we need to work on integration ASAP, as we expect to encounter some bugs in the future.

To Do

1. Touch up on the final parts of the mid term demo.

2. Begin integration with hardware side ASAP.

Capstone Status Update

Hardware Design

• Evaluated various sensor options needed to obtain necessary data for algorithm
• Bicycle sensor system designed for demo
• All necessary parts have been ordered and are ready in lab
• Assembly on bicycle finishing tomorrow for demo

Schedule

• A delay in obtaining parts has forced a delay in independent parts and testing bluetooth
• This has been simplified by switching to bluetooth-enabled parts and removing the need for the RPi

To Do

• Confirm bluetooth connectivity
• Preliminary hardware integration

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.

• 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.