This week I worked with Reid on getting the OBD-II data stream functioning properly. We had some issues with the data stream being cut short due to a buffer issue and we were able to target the issue to a header pin that was not connected. Besides this, the rest of the scripts are setup to log the data to a file to be stored on the database and seem to be functional. Once we resolve this issue, we believe our stream will be working properly and be ready for integration. Aside from working on this, I also spent some time working on the realtime notifications for the website. Since we constantly have to be reading and updating the page, I setup a MySQL database connected to the website, so we can simply use a PHP script to send the data at a set interval to the database which will display on the website. Since we are on a shared network, this is quite simple and is more efficient than our previous idea of using the AWS iOT Core which is far more complicated to setup. Using this, I was able to send some test data to be displayed, but I need to work on getting it to display faster and in a more visible style. Next week, I plan to continue this and also continue helping Reid on the OBD streaming.
Team Status Report for 3/27
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.
Reid’s Status Report for 3/27
This week I was working on my end of the project, connecting the OBDII port to the RaspberryPi. I am very close to seeing data on the RaspberryPi end. I set up a temporary lab in my partner’s garage with the OBDII wire going from my car to a desktop connected to the Raspberry Pi. I put in an order for a DB9 extension cord to make the environment easier to work in. While working with the PiCan2 documentation and library I ran into an issue where the Bitbucket link was expired so I emailed the inventor of the PiCan, Sukkin Pang, and he was very gracious and was able to send updated instructions. At the end of the week I was able to receive certain CAN messages once I started my car but the stream was not constant, and figured out that the issue was a missing soldered link to the 120 Ohm resistor on the PiCan. I visited TechSpark today to find pins for the board but couldn’t find any suitable pins for soldering, so I placed an order for the correct ones and will solder this week. The code looks to be working well with two threads for TX and RX but I will need to see more data to find the non-standard PIDs for steering wheel angle.
Ryan’s Status Report 3/27/21
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.
Reid’s Status Report for 3/13/21
This week, the parts started coming in so I was able to setup our Drivaid hardware in my car. I connected the RPi and the PiCan and connected that to the VGA – OBD2 cable in my car. I wrote some code for the Raspberry Pi to ping the PiCan for each PID we are looking for (velocity, engine lights, etc.) every second and store that data in the program. I also connected the UBEC to the PiCan but I am still looking into options for how to connect the ground and +12V wires to the cigarette lighter port. I am looking into how we can create a SQLite database in the Pi’s memory but I am still waiting on an Ethernet cable and adapter so I can interface with my laptop. Overall, I just need the small parts to come in that connect our project that I overlooked in the original parts list but our design is coming together. In the meantime, I also started designing a simple enclosure for our RaspberryPi and PiCan with appropriate cutouts for VGA, two Micro USB ports, and the USB ports on the Pi. This enclosure ensures that our device fits well within my car and doesn’t move around when testing.
Ryan’s Status Report 3/13/21
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.
Team Status Report for 3/13/21
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.
Samraj’s Status Report for 3/13/21
This week I worked on setting up AWS to host our website. Since our website involves displaying dynamic data and constantly updating the page, I will be hosting using Amazon EC2. Since I have not used AWS before, I followed a few different tutorials online to help with the process. Setting up the hosting server involves first creating an EC2 instance in the AWS portal. Once this is set up, I can connect and update the server, and then upload the files I need to display on the website. As of now, everything seems to be mostly working, but I need to do more tests with dynamic data to make sure the website can update appropriately. Aside from this, I was the presenter of our groups Design Review presentation so I spent a good amount of time earlier this week preparing for this. Next week, I plan to wrap this up and start working on the database integration/setup process. Also, now that we have all of our parts received, we can start setting up a data stream and I plan to do some preliminary testing with putting this data into a database and trying to read it on the website.
Samraj’s Status Report for 3/6/21
This week I worked more on the website which we will be using to display the real time notifications and user driving report. A lot of my work this week was done on planning out the exact process I will go about on working on this piece of the project and how to integrate it easily with my other team member’s parts, which involved a group effort of ironing out the design our overall system. We decided we will be using AWS as our database, since we can send the driving data to AWS via MQTT and also access this data from the website. Once the data is sent from the Raspberry Pi and received on the server, I can take the data and write Javascript code to interpret the data into different charts and lists to display on the website. For example, on the driving report page, we plan to have a complete summary of the user’s drive, split up into parts such as: a chart of their speed, amount of time and distance driven, list of infractions, chart of efficiency overtime, etc. Aside from planning, I also continued work on the actual development of the website and created the HTML and CSS for two static pages with the basic template of the final website. The infractions page is just a simple box on the screen where the text will update/flash when an infraction is detected from the server. The other page is the driving report page, and has the layout for where we will be placing the data also when it is received from the server. Apart from the website, I also spent time doing research on OBD-II data formatting and how exactly we can read this data. I found that the the data has a standardized format array of bytes where each block of the data represents some piece of the information, which is logged online. We simply can create a bit mask based on the data we need and extract it.
Next week, I plan to setup the website with AWS now that I have received credits so that we can host the website and start storing/retrieving data and be ready for when we get the ODB-II reader going.
Ryan’s Status Report 3/6/2021
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.