Category: Ryan’s Status Reports

This week I changed the structure of our analysis functions. A few weeks ago I started using threading for each of our analysis functions along with the data collection function. This week I changed our program to only use two threads – one for the data collection, the other for data analysis. I realized that while having a thread for each individual analysis function is means they can all work independently, it also means that they have to send their results to the website separately. This trade-off is not worth it because the API calls take a long time relative to the analysis we do on the car data, so by making all the analysis functions sequential, we only have to make one API call to the website, which saves us time. We still use separate threads for the data collection and data analysis. We also did driving tests to work out any remaining bugs in our pipeline – making sure the raw data and infraction data were being collected and sent to the website properly. I also worked on our final presentation slides for class this past Wednesday and practiced presenting them many times.

This week I improved the speed limit analysis function by adding the capability of saving GPS coordinates and with their associated placeId. Whenever the speed limit function collects GPS data, I save the coordinate to placeId association in the SQLite database. Because our GPS is only accurate to three meters, having the GPS in the same location doesn’t necessarily mean it will output the exact same coordinates. To account for this device inaccuracy I search the table containing the saved GPS coordinates with a 1.5-meter range in all directions – increasing the number of coordinate-placeId cache hits. This decreases the number of API calls made, resulting in a lower cost final product for the user. Additionally, I fixed all bugs associated with the GPS, so it is fully functioning using the antenna attachment. The GPS regularly updates its position every second and using this data, we can regularly get the speed limit of the road the vehicle is on.

This week I debugged and tested the analysis functions for speed limit detection and turning detection on simulated car data to ensure they are logically correct. I have done some initial testing with the GPS connected to the RaspberryPi and have not been able to get a stable connection with the satellites. I just got an antenna that should improve the connection to satellites to get more reliable GPS data. I plan on testing the GPS with the antenna tomorrow. If it works correctly then we can move forward with it, and if I cannot get it to work, I have researched a few other options for GPS devices that we can use instead. Additionally, I established the return values for each of the analysis functions and successfully communicated them with the web application to be displayed on a graph over time.

This week I continued working on our data analysis program. I wrote the speed limit function which uses GPS coordinates and the speed of the vehicle to check whether the car is exceeding the speed limit. The function makes an API call with the GPS coordinates to get a “placeId” for each pair of coordinates. We make another API call using this placeId to get the speed limit of the road associated with it. We then compare the speed limit with our current speed to identify whether the car is speeding. Because each API call costs money, I added some database functionality that saves the speed limit associated with each placeId. This enables us to bypass the second API call if we have been in that location before. I am also in the process of adding functionality to save the GPS coordinates associated with each placeId so that we can bypass the first API call if we receive coordinates that we have received before. However, because of the accuracy of the GPS, I do not believe we will always get the same exact coordinates even if we are in the same place, which is why I implemented the placeId –> speed limit association first. Additionally, I refactored the analysis program to use threading for each of our separate efficiency/infraction checks instead of the checks happening sequentially. This is because they are all independent work, and I predict the speed limit function will take relatively longer than the other functions because it will have to wait on responses to the API calls. I do not want the speed limit check to be a bottleneck for the other functions, so threading seemed like the best option to avoid this issue. In order to implement the threading properly, I had to break up the main function into separate functions so that each thread calls a unique function for the separate checks our program makes.

This past week I was able to integrate the SQLite database I created into the RaspberryPi. I have tested the previously build functionality: creating a connection to the database, creating tables, inserting data, and reading new data as it comes in All these functions work as expected. Over the past week, we discussed how a few pieces of data should be gathered at a higher frequency from the OBDII port to get a more accurate analysis. Because of this, I have been redesigning the database to use many, separate tables that hold a specific type of data instead of one table with many columns to hold all the data.  This more complex database schema should save space because if we use one table but some data is collected more frequently than others, we will have many empty rows in the table. Additionally, I received the GPS unit and read more documentation about how to integrate it onto a RaspberryPi. I went to campus to solder the pins used for power and communication with the RaspberryPi. I have not connected it yet because the cable I need is currently in the mail, but I created the python program that should be able to periodically receive GPS latitude and longitude data and store that data in the database to be used in the speed analysis function.

This past week I added more functionality to the SQLite database. After reading some questions from the instructors we decided it would be useful to have the data stored in stable storage rather than volatile memory in the case that we are unable to send all the data to AWS before the trip ends and need to complete the transfer another time. I also added methods to insert data and select data we have not read yet. I have also written a basic implementation for the rpm analysis function which checks how close the rpm is to optimal torque as well as a basic motion analysis function that measures the efficiency of the vehicle’s acceleration and braking patterns. Additionally, I have been working on implementing the turning analysis function by using the steering wheel angle and specific specs about the vehicle we are using (steering ratio and wheelbase) to calculate the car’s orbital angular velocity to identify when a car has made a turn. Lastly, I received the GPS unit and started reading the documentation about how to physically attach it to a RaspberryPi and which dependency libraries need to be installed in order for it to work properly.

This week I set up the SQLite in-memory database to store information coming from the CANbus to be analyzed. I wrote the functionality to create a connection instance to the memory on the raspberry pi that we can send and receive SQLite commands through. Additionally, I created some functions to create tables, and made progress on the read and write functionality. This will allow the data collection to consistently write the deciphered data to memory while the analysis portion of the program is reading the collected data to analyze. Additionally, I figured out everything I need to do to set up AWS IoT on the Raspberry Pi to support communication with the web application. Because I haven’t received our team’s Raspberry Pi yet, I haven’t been able to run the setup processes on the device, but I have all the steps planned out and should be able to do execute them relatively quickly.

This week I created the outline for all the analytical functions that will be called on the various data elements gathered from the CANbus. I wrote descriptions and pseudocode for them but couldn’t write them fully because we hadn’t decided on the exact data formatting that I would receive from the preprocessing component of our pipeline until after I had written them. Additionally, I implemented and tested the weather and speed limit APIs, and came up with a few different methods for storing the speed limit data. We want to store this data because it is relatively expensive to query from Google compared to the query that tells us which road we are on.  I also decided that instead of a sequential process of collecting, decoding, and analyzing the data in one loop, we should have two parallel processes. One for collecting the data, and another one for analyzing the data, connected by a local database. This way the data collection process will never have to wait for the analysis, and the analysis can pull data from the database at its own pace.

At the beginning of this week, I worked on creating our team’s slide deck for our presentation on Monday. We came up with the requirements for our project and the schedule to track our progress using a GANTT chart. This week I created a GitHub repository for our project where we will store all the analytics code that will run on the RaspberryPi as well as the code for our web application. I also researched how the RaspberryPi will communicate with its data. We decided to store our data using AWS IoT and send it via the MQTT protocol. I spend some time getting familiar with different APIs to find which one works best for our group, including a weather API and a google API for road data to access speed limit.  I also read a few research papers that discussed data that teams had used from a vehicle to try and recognize good and bad driving.

This week we spoke with our professor and TA about the shortcomings of our initial idea. Since our meeting on Monday, I spent time considering other ideas for our capstone project. When we decided on a driving assistant I spent time researching the different ways of tracking car data. We discussed bringing in our own sensors that would attach to a RaspberryPi, but came to the conclusion that in order to get the widest range and most accurate data measurements, the best option would be to gather the information from the CANbus through the OBDII port. I researched a few methods for getting this data including commercial solutions that came with their own software, but decided that with a RaspberryPi and PiCAN attachment, we could collect and decipher the CANbus data ourselves. Additionally, I contributed to the proposal presentation slides we made.