Category: Reid’s Status Reports

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.

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.

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.

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.

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.

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.

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.

This week was a little slower since our team has been waiting for parts, which I put in orders for on Wednesday. So far we have received our OBDII to VGA cable in the mail via Amazon, and I was able to find my OBDII port on my own car for testing. The wire is long enough for our device to fit on the dash. We also decided  to pivot from our camera idea since it didn’t have enough value for the end consumer. I also solidified which data I was using from the OBDII port so I can target specific sections of the CANBus data string, and came up with a data schema for my part of the project for our final design presentation. I researched more about the makeup of the OBDII string and where the specific data is located, and made some bit shifting masks that we will be using on our Raspberry Pi to find velocity, accelerator position, hazard lights and steering wheel information.

This week, I worked on presenting and preparing the slide deck that we worked on. I worked on the technical requirements slides about navigation and infraction detection, as well as technical challenges and preliminary design. I was a little rushed on the presentation but overall I think I was able to communicate Drivaid’s purpose and technical components. One question that arose was how we needed a GPS tracking device connected to the Arduino that sends info to the Google Maps API to tell if a driver is slowing down for a stop sign/traffic light. I settled on the Adafruit ultimate GPS because of its precision and 10Hz updates, which should be frequent enough for precision mapping and location updates. I worked on a preliminary parts list as well which we plan on submitting to the TAs, which includes the PiCan, cables, GPS, and RaspberryPi. I also started researching how difficult it would be to not use the PiCan2 at all and instead use a OBD2 to USB to hook into the RaspPi’s USB port – we will discuss this as a team either later tonight or tomorrow since it would be a substantial change to our initial design.

This week, I worked on researching the OBD2 port and finding an optimal technical solution to our problem. After shifting from our initial smart heater idea, I thought of this idea as something that built off a past internship that tracked hard braking and turning to improve street design. I helped design our initial outline of which devices we will be using and how they communicate with each other. I was able to find a OBD2 to Bluetooth device that could communicate directly with our onboard Raspberry Pi, one of the port alternatives that we are looking at. I also researched the OBD2 communication protocol to see the feasibility of reading directly from the port, which looks like it can be manageable using correct bitshifting. I also looked at some gyroscopes and IMUs, as Professor Mukherjee suggested, but am still unsure if they can provide the same data accuracy and breadth that CAN data does.