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.
Reid’s Status Report for 5/8/21
This week I mainly worked on getting everything ready for our final video and report. I worked on the poster and helped with final debugging before we shoot our final video in the car tomorrow. Both the poster and raw video should be finished by tomorrow. I conducted some final tests to make sure our speed limit functions worked. We tweaked our API call to be more accurate to our exact location, since before we were using a set bounding box off of our known location, but we now just supply one coordinate to get one mph reading, which simplifies our system. I also found and added the PIDs for DTC (diagnostic trouble codes) to be shown as warning lights on the web application to substitute for the missing steering wheel codes we could not find. For presentation, I added velcro strips to the box to keep it from moving around in the car and looked into moving the box to underneath the steering wheel compartment to minimize wires interfering with the driver. Our product now looks very presentable with most wires contained within the box.
Reid’s Status Report for 5/1/21
This week I worked on the enclosure more and added more OBDII signals to the car end. The enclosure I laser cut last week was too small for our device and the base was not ideal for my car, so I made the enclosure larger, so that is now finalized. I checked for error signals which can be stored in the database now – these include engine lights and mechanic’s warnings. I also helped with the API for the speed limit and used the Open StreetView API and fed in points that we found using our antenna to generate results. I worked with Ryan closely to make sure our two systems worked alongside each other – correct values were being passed to the database after conducting more tests using my car. Our testing went well and I am confident that the OBDII codes subsystem are being placed in the SQLite database in the correct places. I also added error checking for OBDII codes that are out of range, as sometimes the on-board computer returns zeros very occasionally – in these cases I return the last recorded legitimate code so the database doesn’t include spikes that would set off false infractions.
Team Status Report for 4/24/21
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.
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.
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.
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.
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.
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.