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.
Samraj’s Status Report for 4/24/21
This week I made some more modifications to the website. During our demo we noticed some issues with how the live data updates and the update rate was not as fast as it should be. This was mainly due to an issue that the service I was using to host the data was not set at the correct update rate, but I was able to fix this to update every second. Aside from this, I worked more on the live notifications and getting a solution working so that the data is sent in real time and pop’s up on the users screen. I am looking into an alternate solution to send real time push notifications to the phone rather than updated the website constantly, since this is harder than anticipated. This seems to be more feasible and I plan to get this working early this week. I also spent more time working with the team on integration and testing that the system all works together properly.
Ryan’s Status Report 4/24/21
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.
Reid’s Status Report for 4/24/21
This week was a little slow on my end. I went through of the PIDs but wasn’t able to find the right ones for steering wheel angle. I am not sure if my method is working because I have not received data from any of the non standard PIDs in mode 06. We may need to get rid of the steering wheel angle calculations in our analysis functions if it comes to that. In the meantime, I designed an enclosure in SketchUp for our RaspberryPi so I can laser cut it from acrylic in the lab later this week. The enclosure includes the openings for our necessary wires and is a bit taller if we ever use the PiCan again. The enclosure would sit on the dash with removable velcro strips so it can hold steady while the car is moving.
Ryan’s Status Report 4/10/21
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.
Reid’s Status Report for 4/10/21
This week I integrated my code with Ryan’s database so the data is fully stored on the Raspberry Pi. I also worked with the non-standard PIDs that we need and quickly realized that Odometer might be impossible to find: https://github.com/brendan-w/python-OBD/issues/194. This was confusing because on Wikipedia it is listed as a Standard PID in mode one (0x01A6) but that doesn’t yield any data on my Honda. It may be a non-standard PID but it is more likely that it is not available but I will keep checking. I am working with Ryan to discard the odometer data and instead get distance from mph reading and time.time() recordings in Python to find distance averaged across timestamps. We also limited testing to my car since the RAV-4 was not responding to our fuel level requests. This week I did some rudimentary road testing with my laptop and OBD2 cable with results being written to a .db file on my laptop to make sure the unit formatting was correct. I also tried to get the non-standard PIDs that we need (steering wheel angle, turn signal) but it was much more difficult that I thought. I wrote a test script to go through service 06 (CAN mode) to sniff all the possible PIDs from 0x0601 to 0x06FFF and found 300 or so possible PIDs (which will be a lot to go through). Other PIDs for older Civics that were tested on the internet didn’t yield success either and the 2016 Civic non-standard PIDs that is publicly available here: https://github.com/commaai/opendbc/blob/master/honda_civic_sedan_16_diesel_2019_can_generated.dbc doesn’t correlate with my 2020 model. I am still looking at alternatives but it is likely that I will have to go through the PIDs that I narrowed it down to.
Team Status Report 4/10/21
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.
Samraj’s Status Report 4/10/21
This week I worked on integrating my work on the website with the OBD-II data stream. In order to visualize the data, I found a website called Thingspeak, which makes it easy for me to store the data and format it into a graph or chart. Using this, I can embed an iframe of the graph that is generated in Thingspeak into our main website and we can visualize all the data the is coming in that way. So far, I am able to visualize most of the raw data and outputs of of the infraction check functions, but there are a few more I need to add in in the next few days. Aside from this, I helped out with integrating the OBD-II logger with the infraction checking functions but putting the code together so they run in sync. Next week, I plan to continue working on integrating the website with the data so we can see all the data we need. I will also add more features if time permits such as user log in and exporting tools.
Ryan’s Status Report 4/3/21
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.
Reid’s Status Report for 4/3/21
This week I was able to get data from the car and store each data point locally in variables in my program. I was able to get RPM, vehicle speed and fuel level data via USB. The data was then formatted to the correct units (RPM, MPH, gals). I tested the Python program in Samraj’s garage by revving the engine in park and slowly driving the car backward while not ruining our setup to get speed. We switched from the PiCan2 to the ELM327 with USB connection to get the data because we had serious issues with the PiCan2 and was never able to see any data. Next week I need to work with Ryan to integrate his SQLite database with my program and carefully look through the returned PIDs to find the non-standard PIDS (turn signal and steering wheel angle). Finding and formatting non-standard PIDs will likely take most of my week. I also received the USB breakout cable which I soldered to the rest of our power system (cigarette lighter outlet converter and UBEC Buck converter) so our entire system can be powered from the car battery. The power is successfully stepped down from 12V to 5.3V. Now that this is done, we can do testing from entirely within the car next week.