’Every once in a while, a new technology, an old problem and a big idea turn in to innovation.’
– Dean Kamen
National Highway Traffic and Safety Administration or more commonly known as NHTSA is a federal agency of the US state government. The agency did a survey in 2018 to estimate the speed for all types of motor vehicles on freeways, arterial highways, and collector roads across the United States. At 677 sites speed of close to 12 million vehicles were sampled across the united states. The survey  mentions that “Overall, speeds of free-flow traffic on freeways averaged 70.4 mph and were approximately 14 mph higher than on major arterials, which at
56.4 mph were in turn about 7 mph higher than the mean speed of 49.7 mph on minor arterials and collector roads. Most traffic exceeded the speed limits. Sixty-eight percent of the traffic on limited-access roads, about 56 percent of the traffic on arterials, and about 58 percent of the traffic on collectors exceeded the speed limit. About 16- to 19 percent of traffic exceeded the speed limit by 10 mph or more on freeways, arterials, and collector roads. While speeds of most vehicle size classes remained constant since 2009, the longest truck class (80-100 ft.) showed a 2 mph increase on limited-access highways.” The results were almost the same in the survey
done in 2015 .
This survey helps to understand the driving trend on the roads. In most cases, the vehicles traveling on the highways or the minor arterials travel at a considerably higher speed than the assigned limit. A thing to observe here is that drivers try to maintain the speed the vehicle with the flow of traffic. Going slow or too fast may result in a ticket. So, as the speed of the traffic flow itself is high, anyone trying to maintain that traffic speed is bound to be above the speed limit. Thus, it is not fair to the ticket only a few drivers for over-speeding. This also means that the over-speeding ticket citation is more of a relative process than absolute. There are cases where the drivers are let go with a warning or sometimes given a ticket for going a mere of 1 mph above the speed limit. The idea of this project is to bring in the robustness to the decision making the process. This is done by giving the sheriff a tool to identify the type of driver. If the sheriff has proof of speed statistics over a certain amount of period about the driver in question, he/she can identify whether the driver is aggressive or a good driver and then take the decision on the citation. This data will also be available in the judicial system, in case the driver decides to fight the ticket in the court. This will also provide as a second check before anyone being given an over-speeding citation.
In this project, a system is developed to address and fix these issues using the currently available technology. In this project, a raspberry pi 3b+ is used to implement a black box. A black box will always be present in the car and will record the actual speed of the vehicle along with the time stamp via OBD-ii port. The speed is sampled at one sample per second. Another raspberry pi 3b is used to implement an IoT device. This IoT device will be present with the sheriff. The IoT device will request the speed reading from the car for the past 20 minutes (1200 data points) over the Bluetooth. This data is then pushed to the secure cloud and can be accessed on a website or by a tool in real-time for the particular vehicle in focus. In this project, a tool is implemented to fetch the data from a cloud and plot it on a graph with clear, distinct speed limit
of the car. The data fetched from the car is used to verify the speed of the vehicle in question. Thus, reducing the human error of misidentifying vehicle. Such a mechanism will help sheriff make a much-informed decision as he/she will have drivers speed statistics over a period of time, helping them to identify if the driver is aggressive or not and then give them a ticket.
One more advantage of this system is that as the data will be present in the cloud and anyone in the judiciary system can access it. So, in case the driver is given an over-speeding ticket and decides to fight it. He/she can have proof to present in the court. Hence, making the process more robust. In this system, the decision is not solely dependent on judgment on a single person but multiple cross-verification supported by proof.
• Chapter2discusses the motivation for the project, discussion about the current speeding violation rules and research, and systems available to tackle the problem so far.
• Chapter3discusses overall system architecture in detail. It will cover various components used, why they were used? Cost of the system etc.
• Chapter4discuss various protocols used such as CAN, BLE, MQTT. It will cover the brief description and mode in which they are used and a few important specifications.
• Chapter5discusses the various method in which all the scripts were tested individually. The difficulty faced during the project integration and the comparison between the actual and expected output.
• Chapter6discusses the future work and conclusion of the project.
The over-speeding ticket is one of the most common traffic citations given in the United States. According to the statistics, every year, close to 34 million speeding tickets are issued. The United States has close to 227 million  licensed drivers. This means that every year, one in every six drivers receives an over-speeding ticket. These numbers are on a higher side. So, does the United States have so many drivers who willingly Overspeed? The answer is no. Let’s see the bigger picture. Any traffic citation (in this case, over-speeding ticket) can result in a fine and increase in driver’s insurance rate. Thus, anyone breaking the traffic law knowing the consequences is highly unlikely. The problem here is the way over-speeding vehicles are identified. Currently, a handheld RADAR or a LIDAR gun (most commonly known as speed gun) is used to measure the speed of the car . The gun is pointed at the target vehicle number plate to measure its speed. Using speed gun has few disadvantages:
- The gun has to be held with steady hands.
- There are chances that the sheriff may issue a ticket to the wrong vehicle.
- RADAR reading is affected by weather conditions and the color of the car/number plate.
Moreover, the major drawback of the current Overspeed ticketing system is that the driver does not have proof to counter the sheriff’s claim, in case he/she is innocent. Thus, making him/her vulnerable if they decide to fight the ticket in the court.
In the past year, three over-speeding tickets were given to someone or the other I know. Although sure that they were not over-speeding, two of them decided to pay the fine in upwards of $240 reluctantly. They decided to do pay the fine because the area where the citation was given to them was around one to one and a half hours away from the place they stay. Fighting the ticket meant them to travel back to that particular county court where the citation was given. If the sheriff who gave them the citation is not present, then it meant they had to travel back again for the next trial. Thus, in order to avoid the hassle, they ended up paying up for the tickets. The third person decided to fight the ticket. The person traveled to county court thrice, and the sheriff who gave them the citation never showed up in the court once. This resulted in the judge let go of the ticket. As it can be observed from these incident fighting the over speed ticket is a tedious process and also even if the driver is sure that he/she was not over speeding they end up paying the fine in order to save time and lack of proof. After discussing the issue with them, I realized the gaps in the current system and tried to fill them using this project. But before going in deep with the issue first, we will discuss current over-speeding vehicle identification mechanisms and loopholes.
A LIDAR or RADAR guns are used by the sheriff to identify the over-speed vehicle. The gun can be handheld or car-mounted. RADAR guns use the Doppler effect  to identify the over-speeding vehicle. The gun is pointed at the vehicle in question, and it will transmit a radio wave. This radio wave will bounce back from the vehicle and is received by the gun . Due to the Doppler effect, the frequency of the transmitted wave will be different, and comparing both of them will help identify the speed of the vehicle. These guns suffer from a problem of beam divergence , which makes it difficult to which an individual vehicle cannot be targeted. Thus, the operator has to be trained and certified before using such guns . To avoid such a problem, a LIDAR gun is used . It does not suffer from beam divergence problems, and the speed of the
individual vehicle can be determined. The speed identification using both the guns takes around half a seconds. The gun may have a screen or viewfinder which have a pointer to focus on the vehicle in question. It displays the speed of the vehicle on the screen. A sample view is shown in Figure2.1. From the figure, it is evident that if the traffic is less than it is easy to identify the over-speeding vehicle. But with a high volume of the vehicle on the road, there are chances of misidentification of the vehicle. Also, a slight movement when the gun is pointed at a vehicle in question may result in the wrong vehicle identification; thus, although the LIDAR or RADAR gun is an excellent method to identify the over-speeding vehicle with skilled hands and eyes but not the most accurate one.
Whenever any individual is identified for over-speeding, no proof or cross verification method is present at either party i.e., with the sheriff or the driver. Hence, in the current system, there is no method available to verify if the vehicle in question is misidentified. This is a big problem. Because if the driver wants to fight the ticket in the court, he/she does not have proof to defend there claim. And during the trial, it becomes more of sheriff’s word to drivers word. Sheriff being a part of the judicial system, will always be given more emphasis. Also, the sheriff always assumes that he/she has identified the vehicle correctly as no cross-verification is present. In such a scenario driver is entirely at a losing end of the bargain. Hence, we see that the current system does some dangerous loopholes and not robust.
In this project, a system is designed to fill these loopholes. As discussed in the introduction, a black box will provide the speed statistics of the driver to the sheriff. The sheriff can fetch the data over IoT device push it on to a cloud so that it is available to anyone in the judicial system. Data is represented to the sheriff in the simple graph with clear distinction in speed limits. A sample image is shown in Figure3.7. This will just make sure that the decision, accusation, and citation are crosschecked, making the entire process more robust.
The system is divided into three separate sections, as shown in Figure3.1viz Black Box, IoT Device, and AWS Environment. A black box will always be present in the car. It is implemented using a CAN shield (PiCAN2) and a Raspberry pi 3b+. Raspberry pi does not have a CAN interface. So, a CAN shield is used as a gateway module to interface CAN protocol from OBD-ii port and the SPI protocol of the Raspberry pi 3b+. This is discussed in Subsection3.1.3. The Raspberry pi 3b+ is programmed to fetch the speed, timestamp, and accelerator pedal position data from OBD-ii port and store it in a log file. IoT devices can request this data from a black-box whenever necessary. A black box will read the data only when the car is in motion. The vehicle data is sampled at one sample per second. A black box will share only the latest 1200 samples of vehicle data with the IoT device i.e., past 20 minutes before the vehicle came to a standstill.
IoT devices will always be present with the sheriff. IoT device is built using a Raspberry pi 3b and a Raspberry pi screen. It is programmed to initiate the request and fetch data from the black box over the Bluetooth. It will then send this data to AWS IoT Core over the internet using the MQTT protocol. MQTT is an abbreviation for Message Queuing Telemetry Transport. It is a lightweight messaging protocol designed specifically for communication between sensors, IoT devices, or mobile devices. This protocol is discussed in detailed in Section4.4. The IoT device acts as an MQTT protocol publisher, and AWS IoT core acts as an MQTT broker. The AWS IoT core is used as it can receive data from multiple IoT devices. It then sends this data to an AWS S3 bucket. AWS S3 bucket is used to store vehicle data. Each message received from AWS IoT core is stored as a file with a user-assigned device-specific unique name in the AWS S3 bucket. This helps to maintain the files from different vehicles. The IoT device then downloads the data from the AWS S3 bucket and will make a plot of speed and gas pedal position versus time. This plot contains vehicle data for the past 20 minutes before it came to a standstill. A thing to note is that none of the user data is stored locally on the device; this is done to protect the user’s privacy.
3.1 Black Box
Figure3.2shows the black box architecture. The CAN shield sits on the Raspberry pi 3b+. The connection is established using a 40 pin on board male-female connectors on Raspberry pi and CAN shield, respectively. The CAN shield has a DB9 female connector present on the board. Every car has an OBD-ii port as mandated by the California Air Resources Board or generally known as CARB. The details about the OBD-ii port will be discussed in Section4.1. An OBD-ii to DB9 connector is used to connect CAN shield to the car. A thing to note is that the black box is powered from the car itself. OBD-ii port provides a 12V supply, and the CAN shield has a switch-mode power supply, which will convert this 12V to 5V and draws a current up to 1 Amp.
3.1.1 CAN Shield
For CAN shield, a PiCAN2 with Switch Mode Power Supply board from SK Pang electronics is used. A simple CAN shield outline is shown in Figure3.3. The board consists of MCP 2515, a standalone CAN controller with SPI interface, and MCP 2551 CAN transceiver. Both the chips are compatible with ISO 11898 standard set for CAN protocol. A CAN controller requires CAN transceiver to convert received transmission signal to digital signal and vice versa when sending it over a CAN channel. MCP 2551 suffice this need on the PiCAN2 board. MCP 2551 is compatible with 12V and 24V systems. In this project, we use a 12V system drawn from the OBD-ii port . It can handle up to 1 Mbps of data . MCP 2551 can be operated in 3 different
modes viz High Speed, Slope Control, and Stand-By Mode [9,10]. As the name indicates, the high-speed mode and standby mode are used for high-speed data transfer and sleep, respectively. The mode can be selected using Rs pin on the chip. On the PiCAN2 board, the MCP 2551 chip is used in Slope Control mode . This mode can be achieved by connecting a resistor between the Rs Pin and the ground. This mode is used to keep EMI emissions low by restricting the rise time and fall time at both the CANL and CANH pin low.
MCP 2515 standalone CAN controller is used for transmitting and receiving standard/ex- tended data frames and remote frames. A CAN controller acts as a gateway to connect CAN protocol from the OBD-ii port to the SPI protocol on Raspberry pi 3b+ side. CAN controller consists of three main blocks :
- CAN Module: It consists of a CAN engine block, Tx and Rx buffers, masks, and filters block. Masks and filters block is used to remove unwanted messages and reduce host (Raspberry pi in this case) overheads. The CAN engine block is used for reception and transmission of the message. To initiate message transmission, appropriate control regis- ters and buffers are loaded. Control registers initiate transmission via SPI interface or by using transmit enable pins. Received CAN message is checked for errors and then verified against the filter values and then is transferred to the next buffer.
- SPI Interface Engine: SPI interface is used to connect the micro-controller(Raspberry pi in this case). The read and write to all the registers is done using a standard and specialized SPI commands.
- Control Logic: This block is used to provide setup and sequential operation of the other blocks in order to pass the information. A multi-purpose interrupt pin is available to indi- cate the reception of a valid message into the buffer. There are also three pins available for transmission of a message from one of the three transmit registers.
For this project, CAN and SPI are used at 500Kbps. This is a standard OBD-ii CAN speed for most of the vehicles available in the market.
3.1.2 Raspberry Pi 3b+
Raspberry Pi 3b+ is used as it is one of the most affordable powerful computers available in the market. Raspberry Pi 3b+ has 1.2 GHz 64-bit quad-core processor, an onboard IEEE 802.11n Wi-Fi, 5.50 Bluetooth, and four USB ports. For black-box Bluetooth and SPI interface are the only two peripherals used. Raspberry pi uses CAN shield with an SPI interface to fetch the data from the OBD-ii port over CAN protocol whereas Bluetooth is used to transmit the vehicle data to the IoT device. For Bluetooth PyBluez and for CAN PyCAN, Python package is used. The details of the Bluetooth is discussed in Section4.3. A Python script is used to perform the fetch and transfer of the vehicle data from the car and to IoT devices, respectively. The settings needed for the interface of CAN shield and Raspberry pi is discussed in the next Subsection3.1.3.
3.1.3 Interface between CAN Shield and Raspberry Pi 3b+
In Raspberry pi, a device tree is used to enable the peripherals. So in order to enable the SPI interface, dtparam is used. In second-line dtoverlay are used to set the parameters for the peripherals that should be enabled. In this case, MCP2515 is connected to the SPI interface. Also, the chip has an 8 MHz quartz, so the frequency of the oscillator has to be twice the crystal, which is 16 MHz . GPIO pin 25 is connected to the interrupt pin of MCP2515, hence interrupt = 25. On the Raspberry pi side, the BCM 2835 SPI controller is used. It is enabled in the third line.
3.2 IoT Device
The architecture on the IoT side is shown in Figure3.5. It consists of two sections a Raspberry pi 3b and AWS IoT and Cloud infrastructure. A Python script is implemented on Raspberry pi, which will perform tasks such as fetching of the vehicle data from the black box, sending this data to the AWS infrastructure over MQTT, fetching data from the cloud and creating the plot of the data.
3.2.1 Raspberry Pi
A Raspberry pi 3b and the Raspberry pi screen is used as an IoT device. Bluetooth and Wi-Fi are the peripherals used from the Raspberry pi. Python package PyBluez, AWS IoT SDK, AWS Boto, and Boto3 are also installed. PyBluez is used for Bluetooth; AWS IoT SDK is used to set up and configures MQTT protocol, whereas AWS Boto and Boto3 are used to fetch the vehicle data files from AWS S3 bucket. Three different files with encryption keys are used for secure communication between Raspberry pi and AWS IoT Core. The generation of these keys and using them will be discussed in Appendix AI. IoT device will initiate the request for vehicle data i.e., speed, timestamp, and gas pedal position from the black box over the Bluetooth. It will fetch the latest 1200 data points and then send it to AWS IoT Core over MQTT protocol. IoT device then will download all the vehicle data from the cloud and create a speed and gas pedal position versus time plot. Both these tasks are done using a single Python script. A thing to note here is that once the data is sent to AWS IoT Core, it is instantaneously sent AWS S3 bucket.
3.2.2 AWS Infrastructure
Following are the components of used from AWS :
- AWS IoT Thing: A thing is a block that will communicate directly with the sheriff’s IoT device. The communication between AWS IoT Thing and IoT Device is encrypted. A private and RootCA1 key and certificate are required on both the ends for reception and transmission of the messages. These keys are unique for each IoT thing. Thus, for multiple IoT devices, multiple IoT things should be created, and each pair are having its own unique set of keys. Keys are created by AWS IoT Core.
- AWS Policy: A policy is used to enable connection, subscription, reception, and publish- ing for the IoT thing. These terms are MQTT protocol specific and will be discussed in
Section4.4. The same policy can be attached to multiple IoT things.
- AWS Rule: A rule is used to extract a specific information form the received message for a particular topic. As seen in Figure fig:Rule-created-for, the information extracted for the topic Vehicle-Data is VIN number, Time Stamp, and Gas Pedal Position. Similar to the policy, the same rule can be attached to multiple IoT things.