Category: Team Status Report

This week our team mainly got ready for our final presentation and video. We ran more tests through Squirrel Hill to make sure our GPS/ Speed Limit functionality was working and in turn, made some tweaks to get a more accurate reading for the user. We also added more accepted PIDs to our database and backend for vehicle error codes which can alert the user if the car requires maintenance. We improved the UI and presentation of our Drivaid box for our video because earlier, too many wires were on the dash which could hurt usability and make installation more difficult. We are planning on finishing our filming tomorrow and have made progress already on our final poster. It has been difficult this week and weekend since we all have other commitments/projects and upcoming finals that require attention, so work balance has been difficult this week. Samraj also left for home today, so we will need to work remotely on the last bits of our project for the coming two days, which should not be terrible because the website UI is pretty much finalized.

This week our team continued working on the three subsystems – OBDII signal detection, OBDII data analysis, and web application data display. In the OBDII detection area, we found more data points to gather to improve our safe-driving analysis. Specifically, we started measuring a number of signals that detect internal problems with the vehicle’s mechanical and electrical systems that are not obviously apparent to the user. We realized that even though vehicles often notify the driver when there is a system error through the dashboard lights, it is important to track that data so the user knows not only what the problem is, but also when the problem started. In the data analysis section, we optimized the use of API calls, making sure they are only used in locations we have not driven before. This results in a faster, less expensive final product. Finally, we have improved the web interface by adding a page that displays the status of each infraction our analysis measures. We made sure to keep it simple so the user can quickly understand if they are making an infraction and in which category. We did this using binary light displays for each infraction – either the user is making the infraction or they are not. This is important because it gives the user the option to view their mistakes in real-time and correct them, instead of only knowing after the fact when the drive is over.

This week we worked more on our individual parts more to finalize all of our subsystems. We are fairly confident in our interconnect-ability of our subsystems because they worked in our demo well and we are just adding new features on top of what we demoed. The area of most concern so far is the missing non-standard PIDs that we need for the new analysis functions that Ryan has written and tested. On our website and frontend, we are making more adjustments to our website to bring our update rate up from 10 seconds to real-time. This will be important so that the driver can get real-time infraction notifications, but we will keep the 10 second update time for our logs which do not require real-time viewing. We have our GPS set up after ordering our antenna to receive more accurate data. In terms of presentation, we worked on an enclosure for our Drivaid device that can be mounted in the car using velcro strips, which will provide a safer and more user friendly interaction with our system with fewer exposed connections. For next week, we are going to integrate our systems again to make sure they work with Samraj’s updated website, and keep looking at different methods to obtain the correct non-standard PIDs.

This week our team continued working on the integration of our subsystems and we were able to make good progress on this. Now that our data stream is fully working, we are able to store all of the data into a local SQLite database on the Raspberry Pi. As the data is stored, the infraction detection program reads from the database and runs the analysis to output the different driving metrics. These metrics are then sent via POST request to the website and are displayed in real-time. The overall system seems to be working, but now we need to iron out small details and bugs that may arise. We also encountered an issue where some of the data we need for turn checking is not accessible since we are not able to read the steering wheel angle from the OBD-II stream. Since it is not a standard PID, we need a way to manually find the id since it is not published and differs between vehicles. We are still looking for a way to fix this but will leave it out for the demo. Next week, we will do more testing with our integrated systems and fix issues that come up, and add in the smaller details to finalize the system.

Over the past week, our team started integration of the main sections of our project that we have been developing separately. Over the weekend, we were able to start reading and collecting pieces of standard data from the car via the OBDII port. We are able to decipher the raw data and have started parsing it so that it can be placed into the database in the necessary formats.  We also started integrating the data collection subsystem with the analysis subsystem by setting up some of the database functionality onto the RaspberryPi. We have been able to create a connection to the database and create a table that test data can be stored in and analyzed by our infraction detection subsystem. We were able to simulate the test data and successfully store it in an SQLite database file on stable storage. One of the concerns described by the instructors was that we may have a hard time keeping track of our data if are in a location with a poor internet connection, but we created functionality that stores our data on an SD card and flushes all unsent data to AWS on the program restart if it was unable to send it prior to the system being powered off at the end of the previous drive.

This week our team set up a working environment in Samraj’s garage for testing our individual parts. We each split into our own section of the project, Ryan was able to set up the SQLite database and finish some of the infraction algorithms, Reid saw some OBDII data on the RaspberryPi, and Samraj set up the server for real time notifications on the web application side. Since the OBDII part of the project is crucial to our MVP, Samraj also assisted Reid on looking for the data and researching the PiCan device. We think we’re a small bit behind schedule because we are not seeing a constant stream of data from the OBD2 port yet, which is where we would have liked to be at this point in our project. But we are confident with soldering tomorrow at TechSpark we will be able to fix the problem and see a data stream. We also realized we might need to sample the steering wheel angle non-standard PID more than once per second since a turn can happen in that window of time. For purchases, we recently had to repurchase the GPS because the GPS was not originally delivered properly to Reid’s house, and a VGA extension cable to the car can be further from our workstation.

This week we spent time preparing our Design Review presentation. This process involved us planning out each aspect of our project in detail and now we have a very clear understanding of what we need to do and how it will be accomplished. One issue we discovered in the process is that the seatbelt sensors are not readily available through the OBD-II data stream, so we may not be able to use this as an infraction check. We have also received all of our required parts, so we are beginning to setup the Raspberry Pi and PiCan for some preliminary tests to see if we can read and print out a basic data stream from the OBD-II port of the car. Once this is successful, we can start the process of filtering the output and storing it for analytics and the webpage. Another task we are beginning to research and work on is our OBD-II test bench. We need to be able to simulate a data stream for testing so that we can feed this into our infraction checker to make sure it is working correctly. Creating this simulation involves us doing more research into how the data output is formatted so we can replicate it as needed. Next week, we plan to continue working on these group tasks and make good progress in OBD-II logging, infraction algorithms, and setting up the backend system for when the data is ready.

This past week we solidified the overall structure and flow of our data pipeline. We plan on having two processes running on the RaspberryPi at the same time. One process will be continuously receiving, filtering, and decoding the CANbus data and writing it into a local SQL database.  The other process will be reading and analyzing each new entry from that local database. After processing the data, we decided that the second process will send it to the AWS IoT console via MQTT protocol. Lastly, the web application will read all the data written to the AWS console and visualize it with charts and graphs. We also discussed how we are going to integrate the different software components. We decided on the format that the data would be in so that we could build our separate pieces of software knowing how the data will look when it is received. Lastly, we decided on the specific pieces of information we would need from the CANbus in order to perform a quality analysis of a person’s driving.

This week the members of our team spent most of our time pivoting from our initial idea. After a brief discussion with Professor Fedder, we came to the conclusion that our first idea didn’t have the teeth to be considered for a full capstone project. We met a few times to reconsider the direction of our project and landed on the idea to make a virtual driver’s ed application. Since we decided on our new idea,  we have researched how to gather the data from the car via the OBDII port and how to make a web application to display our data analytics. We are also considering adding cameras that record the environment around the individual’s car. This will be useful to add context to the analytics that we provide from the internal car data.