Difference between revisions of "S17: MyAutoHealth"

From Embedded Systems Learning Academy
Jump to: navigation, search
(1. Graphics LCD)
(Team Members & Responsibilities)
 
(193 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=== Grading Criteria ===
+
== MyAutoHealth ==
<font color="green">
+
MyAutoHealth is a product that uses various parameters of a vehicle and an accelerometer sensor to inform the driver of how well a vehicle is being driven. Below is a system diagram to show how the various modules interact.
*  How well is Software & Hardware Design described?
 
*  How well can this report be used to reproduce this project?
 
*  Code Quality
 
*  Overall Report Quality:
 
**  Software Block Diagrams
 
**  Hardware Block Diagrams
 
**:  Schematic Quality
 
**  Quality of technical challenges and solutions adopted.
 
</font>
 
  
== MyAutoHealth ==
+
[[File:CMPE244_S17_MyAutoHealth_SystemDesign.jpg|550px|thumb|center|System Block]]
Real-time vehicle diagnostics.
 
  
 
== Abstract ==
 
== Abstract ==
Wear and tear or aging of parts of an automobile may cause a malfunction which may lead to accidents, loss of life and property. Being able to pinpoint the issue in the automobile could be harder than actually fixing one. Most modern vehicles, just like a computer, have a central processing unit called the Engine Control Unit (ECU) which oversees all operations. This project aims to use an external OBD 2 module to communicate with the ECU using UART and display the status of all critical vehicle parameters to the user. This will enable the user to monitor the engine’s internal functioning. The module will suggest measures to improve driving efficiency and avoid damage. The module will also be used to analyze the driving habits of people, especially school bus drivers or those taking a driving test.
+
 
 +
Wear and tear or ageing of parts of an automobile may cause it to malfunction and this may lead to accidents and loss of life and property. Therefore, it is important to monitor a vehicle's internal systems continuously and report any spurious activity to the driver. Most modern vehicles, just like a computer, have a central processing unit called the Engine Control Unit (ECU). This microcontroller oversees all operations. The project uses an OBD 2 module to communicate with the ECU and display the status of all critical vehicle parameters to the driver. This will enable the driver to monitor the engine’s internal functioning. The module will suggest measures to improve driving efficiency and avoid accidents and damage. It will keep an eye on the engine to see if the instantaneous load on it is more than it can handle and warn the driver if so. This will provide real-time feedback to the driver and ensure that appropriate steps can be taken preemptively to avert any major accidents. The module also track the driver's habits. A bump detection algorithm has been developed using deterministic signal processing that the user can turn on to monitor himself or herself.
  
 
== Objectives & Introduction ==
 
== Objectives & Introduction ==
An OBD 2 module was used to communicate with the ECU of an automobile to read engine critical parameters. An LPC 1768 was used as the master for communication. The LPC node was powered using FreeRTOS. The master needed to issue a set of standard AT-commands to the OBD port. The LPC microcontroller doesn’t have the ability to communicate directly with an OBD port. Therefore, an intermediary communicator was used to facilitate smooth communication between the devices. The communicator was a UART to OBD fully-duplex converter. An OBD 2 port communicates with an ECU using CAN protocol. Therefore, in response to commands, an OBD terminal reads critical engine parameters like temperature, rpm, combustion efficiency, etc. from the ECU. The LPC master sent a byte of data to the OBD and in response to this command, the OBD terminal used CAN protocol to trans-receive a byte of data from the ECU. This byte was sent to the LPC. The master would then poll its registers to ensure that a valid byte is transmitted and received. Knowing the values of critical parameters can help a driver avert an engine seizure or prevent unforeseen accidents.
+
The main objectives of this project are as follows:-
The critical engine parameters were displayed on a LCD screen. The LPC master communicated with the LCD screen using I2C serial communication protocol. Care was taken to ensure that operating system queues were implemented efficiently to ensure that only after valid data was received from the OBD was it displayed on the LCD screen.
+
 
An accelerometer was used for bump detection. A dedicated task was created to read z-axis values and analyze this data. Signal processing techniques were employed to make a decision whether a bump was detected or not. The z-axis values were normalized and the autocorrelation of the sequence was taken. The time domain autocorrelation function was transformed to its frequency domain equivalent. This result of this operation was the Power Spectrum Density of the signal. A thorough analysis of the spectrum was done to identify the signal. A decision was taken based on its pattern.
+
* Develop a standalone system to communicate with the ECU
 +
 
 +
* Monitor critical engine parameters
 +
 
 +
* Measure road inclination against the vehicles torque-speed characteristics
 +
 
 +
* Detect careless driving habits using signal processing
 +
 
 +
* Display vehicle parameters and provide real-time updates about the same on a LCD screen
  
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
*  Manan Mehta
+
[https://www.linkedin.com/in/mehtajmanan/ Manan Mehta ]
** Interface Accelerometer and use appropriate algorithms to measure road dumps.
+
** BOM, PCB design, and assembly
*  Pushpender Singh
+
** Code testing and integration
** Soldering and connecting OBD II Uart components.
+
** Interface accelerometer to obtain inclination and declination of vehicle.
** Interfacing the serial port.
+
[https://www.linkedin.com/in/puspendersingh7/ Pushpender Singh ]
** Acquiring OBD reading from the vehicle.
+
** Interface OBD-II sensor to the SJOne Board over UART
** Translating received data to Graphs/meters.
+
** Acquire and translate ODB-II data to acquire engine load, vehicle speed, engine RPM and torque
*  Sameer Saran
+
** Integrating OBD2 code with and accelerometer code- worked with Shashank Iyer
** Worked on LED display
+
[https://www.linkedin.com/in/sameersaran97/ Sameer Saran]
* Sanman Pradhan
+
** Interfacing LCD Display
** Design a PCB to accommodate the various hardware components.
+
** LCD GUI design
** Schematic is being designed using EaglePCB.
+
** Integrating Display code to OBDII and accelerometer code
** The power supply circuit, designed to be the main power source, peripherals such as the LCD will be housed on the PCB.
+
* [https://www.linkedin.com/in/sanmanpradhan/ Sanman Pradhan]
** Assist with interfacing and programming of the temperature sensor.
+
** PCB Design
*  Shashank Iyer
+
** Edit the Wiki Report
** Acquiring a temperature sensor that can operate in the full range of temperature swing that an average engine fluctuates between.
+
[https://www.linkedin.com/in/shashankiyer/ Shashank Iyer ]
** Using a sturdy standoff to ensure it is able to read values accurately from the air around the engine.
+
** Bump detection using an accelerometer
** Supplying power to the sensor from the SJ1 board.
+
** Using Signal Processing- FFT and PSD analysis to assess if the detected bump is valid
** Processing sensor outputs through the onboard ADC to make them processor readable.
+
** Ensure critical section access is provided to all tasks created by team members.
** Creating a task that polls the value from the sensor at intervals of 10 ms and pushes it to a queue.
 
** Creating a second task that waits for the queue data and displays it.
 
** If the temperature exceeds safe limits, a software interrupt is triggered and decides whether to alert the driver or cut the ignition.
 
  
 
== Schedule ==
 
== Schedule ==
Line 73: Line 69:
 
! scope="row"| 4
 
! scope="row"| 4
 
| 04/11
 
| 04/11
| Interfacing OBD II sensor with SJ one board
+
| Interfacing OBD II sensor with SJ one board, LCD Communication Protocol setup
 
| Completed
 
| Completed
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
 
| 04/18
 
| 04/18
| Developing C code to retrieve data from Vehicle and PCB design
+
| Developing C code to retrieve data from Vehicle and PCB design, LCD GUI Design
|  
+
| Completed
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
 
| 04/25
 
| 04/25
| Integrating OBD and Sensor code into tasks and PCB design
+
| Integrating OBD and Sensor code into tasks and PCB design, LCD hex Codes Integration
| In-progress
+
| Completed
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
 
| 05/02
 
| 05/02
| Testing and debugging
+
| Testing, troubleshooting, debugging and optimization
|  
+
| Completed
 
|-
 
|-
 
! scope="row"| 8
 
! scope="row"| 8
 
| 05/09
 
| 05/09
 
| PCB Assembly and Testing
 
| PCB Assembly and Testing
| Assembly-  Completed, testing - In progress
+
| Completed
 
|-
 
|-
 
! scope="row"| 9
 
! scope="row"| 9
 
| 05/16
 
| 05/16
 
| Ready for Demo
 
| Ready for Demo
|  
+
| Absolutely!
  
 
|}
 
|}
  
 
== Parts List & Cost ==
 
== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components. Do not write long stories here.
+
A list of the cost of our project broken down by components.
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Item#
 +
! scope="col"| Part Desciption
 +
! scope="col"| Vendor
 +
! scope="col"| Part Number
 +
! scope="col"| Qty
 +
! scope="col"| Cost
 +
|-
 +
! scope="row"| 1
 +
| SJOne Board
 +
| SCE
 +
|
 +
| 1
 +
| $80.00
 +
|-
 +
! scope="row"| 2
 +
| OBD-II
 +
| SparkFun
 +
| WIG-09555 ROHS
 +
| 1
 +
| $49.95
 +
|-
 +
! scope="row"| 3
 +
| OBD-II to DB9 Cable
 +
| SparkFun
 +
| CAB-10087 ROHS
 +
| 1
 +
| $9.95
 +
|-
 +
! scope="row"| 4
 +
| uLCD Display
 +
| 4D Systems
 +
| uLCD-32PTU
 +
| 1
 +
| $79.00
 +
|-
 +
! scope="row"| 5
 +
| SD card and Adapter for LCD
 +
| Amazon
 +
| SDSDQM-016G-B35A
 +
| 1
 +
| $6.95
 +
|-
 +
! scope="row"| 6
 +
| FTDI Cable
 +
| SparkFun
 +
| DEV-09718 ROHS
 +
| 1
 +
| $17.50
 +
|-
 +
! scope="row"| 7
 +
| PCB
 +
| PCBWay
 +
| N/A
 +
| 1
 +
| $11.50
 +
|-
 +
! scope="row"| 8
 +
| SPDT Toggle Switches
 +
| Amazon
 +
| a14072300ux0371
 +
| 10
 +
| $8.83
 +
|-
 +
! scope="row"| 9
 +
| Li-po battery 3.7V 2000mAh
 +
| Adafruit
 +
| 2011
 +
| 1
 +
| $12.50
 +
|-
 +
! scope="row"| 10
 +
| Li-po battery charger
 +
| Adafruit
 +
| 2465
 +
| 1
 +
| $19.95
 +
|-
 +
! scope="row"|
 +
| Total
 +
|
 +
|
 +
|
 +
| $296.13
 +
|}
 +
 
 +
 
 +
 
 +
== System Development and Hardware Design==
 +
 
 +
The device was designed to operate standalone so that its working didn't depend on the availability of a free power port in the vehicle. A lithium ion battery was chosen as the power source. The device needed to be connected with the OBD port in the vehicle for all features to be available or just be placed on a flat surface inside the vehicle to enable some features.
  
== Design & Implementation ==
+
An LPC 1758 microcontroller was used as the master for this system. The master communicated with:
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
=== Hardware Design ===
+
* An OBD II terminal over UART to read critical vehicle parameters
Discuss your hardware design here.  Show detailed schematics, and the interface here.
 
  
=== Hardware Interface ===
+
* A LCD screen over UART to display real time values to the drivers
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
 
  
=== Software Design ===
+
* An onboard accelerometer using I2C to monitor driving habits and warn the driver about possible accidents.
This feature was added to enable monitoring a driver’s behavior. This could be widely used by schools to keep an eye on their drivers. An accelerometer was used to detect bumps. The accelerometer in the SJOne board was used to detect bumps in the vehicle travel path. The bump detection feature will also assist in mapping the driver's pattern and manner of driving. Depending upon the unevenness of the travel path, the LCD will display "No Bumps" or "Bump Detected". Accelerometer's z-axis value is read every 100 ms by creating a task.  
+
 
 +
The block diagram provides an overview of the system's architecture.
 +
 
 +
[[File:CMPE244 S17 MyAutohealth.JPG|750px|thumb|center|Block Diagram]]
 +
 
 +
 
 +
The lithium ion battery was to power the master and all peripheral devices. A current distribution circuit was designed and manufactured to enable this. Autodesk EAGLE 8.1.1 was the tool of choice to design the PCB's layout.
 +
 
 +
Designing the PCB in EAGLE is a two step process:
 +
 
 +
* Schematic Designing: A current distribution footprint was created. Prototyping components by Adafruit and Sparkfun were used for the battery charging circuit and the USB to serial communicator. Therefore, PCB designing libraries developed by these firms were downloaded and integrated with EAGLE to enable accurate footprint creation.
 +
 
 +
* Board Designing: The schematic design offered an overview of the board with a black grid and the components clustered at one end. The components were rearranged to avoid any short circuits that could have been caused due to the proximity of tracks or contacts. ERC (Electrical Rule Check) and DRC (Design Rule Check) checks followed. Solder masks were added for protection.
 +
 
 +
The circuit's layout is as follows:
 +
 
 +
[[File:CMPE244 S17 MyAutoHealth21.JPG|400px|thumb|left|Schematic]]                  [[File:CMPE244 S17 MyAutoHealth3.JPG|460px|thumb|center|Board Layout]]
 +
 
 +
.
 +
 
 +
== Monitoring Engine Parameters ==
 +
 
 +
OBD is the language of ECU that has been designed to detect system failures. This OBD2 standard was used to communicate with the ECU to acquire data about all critical engine parameters. This data was sent to the master over UART.
 +
 
 +
OBD2 trans-receives bytes of data with the ECU. Some of the OBD2 commands used are:
 +
 
 +
engineLoad= "0104", fuelPressure = "010A" engineRpm = "010c", vehicleSpeed = "010d"
 +
 
 +
The interpretation of the bytes of data are as follows.
 +
* Suppose the master wanted to access engine RPM. It would send “010c”.
 +
* The first hex pair represents the OBD mode and the second hexadecimal represents the PID(Parameter Identification).
 +
* In this example, Mode 01 and Pid 0c is used which returns the engine RPM.
 +
 
 +
The master will receive bytes of data and will have to interpret it. When “010c” is sent the master will receive a string of hexadecimal numbers: 41 0C 03 2E. 0x41 - State of board in mode one 0x0C - RPM parameters 0x03 and 0x2E, values used to calculate the RPM.
 +
 
 +
Testing:
 +
* The ODB2 module was interfaced with the master with an OBDII to uart converter.
 +
* An FTDI chip was used to allow communication with a pc.
 +
* Baud rate was set to 9600 bps and USB driver was configured to 8 data bits, 1 stop bit and no parity bit.
 +
* ATZ or init command was sent. If all connections are correct the master will receive "ELM327 v2.0".
 +
 
 +
Implementation:
 +
* The AT commands were sent to the OBD terminal.
 +
* Another string was obtained in response to these commands. The data was converted to integers for displaying.
 +
 
 +
== Driving habits and signal processing ==
 +
 
 +
'''BUMP DETECTION'''
 +
 
 +
This feature was added to enable monitoring a driver’s behavior. This could be used widely by schools to keep an eye on their drivers. An accelerometer is used to detect bumps in the vehicle path. Depending on the unevenness of the travel path, the LCD will display "No Bumps" or "Bump Detected". The accelerometer's z-axis value is read every 100 ms by creating a task.  
  
 
The bump detection algorithm operates in the following manner:
 
The bump detection algorithm operates in the following manner:
  
1.Threshold value recognition to identify a preset value beyond which a bump will be detected  
+
1. Threshold value recognition to identify a preset value beyond which a bump will be detected  
 +
 
 +
2. Acquiring values from the accelerometer.
 +
 
 +
3. Using signal processing to obtain its Power Spectrum Density.
  
2.Values acquired by accelerometer sensor.
+
4. Analyzing the power spectrum of the signal.
  
3.Acquiring Power Spectral Density(PSD) and analyze power spectrum.
 
  
=== 1. Graphics LCD ===
 
  
We have used the uLCD-32PTU from 4D Systems. It’s a graphic LCD with a resolution of 240x320 which is very simple to use.
+
'''ACCELEROMETER READING'''
  
[[ Image:CmpE244 S14 SWC Environment.JPG|700px|thumb|right|Software IDE for Graphics LCD]]
+
The onboard accelerometer was used for gathering readings. The algorithm was designed such that if z-axis values were greater than a preset threshold then a bump event is triggered whereas if the readings were lesser in value than the threshold then no bump event is triggered.
  
The LCD can be used for making quick GUI’s. We need the IDE which is available on the website to program the LCD.
+
The readings from the z-axis were normalized, this helped in easing the computations. The readings were stored according to the following steps
We can program the LCD using three methods:
 
  
1) ViSi Genie: This is a drag and drop mode. There are objects available in the menu which can be drag-dropped on the screen. These objects include switches, text boxes, gauges, thermometers, angular meters, etc. This mode doesn’t require any programming. Just like the name, it’s a genie. We use the object which we want and the IDE automatically generates the code required for it. We have used this mode for programming the LCD.
+
--> An array a[8] initialized to '0' used to store the normalized readings.
  
2) ViSi: This mode is a combination of the 4DGL programming language assisted with drag-drop of objects. Since we had a deadline to meet, we didn’t learn the 4DGL programming language. But this can be done if you have enough time.
+
--> New readings are appended to the array while performing a simultaneous left shift operation.  
  
3) Designer: This mode is a pure 4DGL programming language. Each object needs to add using the programming language. The only benefit of using this code is we can make use of the peripherals and busses available on the Touchscreen. The uLCD-32PTU has onboard I2C and UART ports and also has buzzer and ADC. We can make use of these functionalities by using the 4DGL programming language. These peripherals can also be used in the ViSi mode. Once you’ve made up your mind with the environment you wish to use (mostly you would go with the ViSi Genie environment), we will show you how to use the IDE and the LCD from scratch. 4D systems have very well documented app notes which can be found on this link: http:/www.4dsystems.com.au/appnotes/ Refer the app notes in the ViSi-Genie category.
+
--> If a bump is detected, the array will then have a value of a={0,0,0,0,0,0,0,1} whereas if no bump is detected, the array will have a new value of a={0,0,0,0,0,0,1,0}.  
  
First, you need the uUSB-PA5: microUSB Programming Adaptor OR the Programming Cable: USB to Serial UART Bridge Converter Cable. IMPORTANT NOTE: Without either of these you cannot program the LCD.
+
--> Depending upon the movement of the vehicle there could be multiple '1's in the array, indicating multiple bumps.
 +
 
 +
 
 +
'''SLOPE AND BUMP DETECTION'''
 +
 
 +
If the road on which the car was moving was inclined, then it was observed that the z-axis readings would cross the threshold. But these events were not to be considered as bumps. The algorithm was to be designed to ensure that it didn’t consider the occurrence of such an event a bump. Some examples of cases that needed differential treatment are as follows:
 +
 
 +
--> The array a in case the vehicle in ascending a slope will have values like a={0,1,1,1,0,0,0,0}.
 +
 
 +
--> If the vehicle has climbed a slope and after this, due to negligent driving passes over a bump, then the array’s value could be a={0,1,1,1,1,0,1,0}.
 +
 
 +
To be able to distinguish between the two cases and make a decision that there is no bump in the first case and a clear bump in the second, signal processing was used. The array a needed to possess certain characteristics so that the signal processing techniques could produce a meaningful output.
 +
 
 +
 
 +
'''WIDE SENSE STATIONERY SIGNAL'''
 +
 
 +
To analyse the power spectrum density of an array, it must be WSS or Wide Sense Stationery. The array a:
 +
* Has a constant mean from which instantaneous values may deviate but will eventually return to:
 +
  m(n)=m
 +
 
 +
If the mean deviates from the constant value, then the equation indicates that at some time n the mean m(n) will return to its constant value m.
 
   
 
   
'''VERY IMPORTANT NOTE: DO NOT USE THE STANDARD USB TO 232 CONVERTER! THIS WOULD INSTANTLY DAMAGE THE LCD. YOU NEED THE USB TO TTL CONVERTER AND NOT 232.'''
+
* The autocorrelation depends only on the difference (k-l) and is given as:
 +
  r(k,l)
 +
 
 +
* The normalised values from the z-axis have a value of either ‘1’ or ‘0’. Thus the variance of any new reading from the accelerometer from the previous value can be utmost ‘1’. The variance is given by c(n) and its value must be:
 +
  c(n)<∞
 +
 
 +
Since all three conditions are satisfied, the array a is WSS. To obtain the PSD of a wide sense stationery array, the following procedures are followed:
 +
 
 +
--> The autocorrelation sequence of the array is calculated.
 +
 
 +
--> It is transformed to its frequency domain equivalent using Fast Fourier Transform which has a running time of O(nlogn).
  
• Once you have interfaced the LCD using the USB to SERIAL cable now comes the fun part of making beautiful GUI on the LCD.
+
--> The Fourier Transform of the autocorrelation sequence is the Power Spectrum Density of the Signal.
  
• After selecting the appropriate model of the LCD (uLCD-32PTU in our case), select the ViSi – Genie environment.
+
'''AUTOCORRELATION'''
  
• You will see the screen on the left. This screen is for our reference and it gives us an idea how our GUI would look on the LCD without actually programming it.
+
The autocorrelation sequence of the sequence is obtained using matrix multiplication and then summing up the lower triangular elements. This process reduces the time complexity by a fourth as compared to the traditional approach. The autocorrelation matrix R is computed by multiplying the array with it’s transpose. The elements of the matrix are as follows:
  
• The way it works is that we can make FORMS on the LCD. Forms are like different pages which are used for displaying information or taking inputs from the user.
+
r= (1,1) (1,2) ⋯ (1,8)
 +
    (2,1) (2,2) ⋯ (2,8)
 +
      ⋮      ⋮  ⋱  ⋮
 +
    (8,1) (8,2) ⋯ (8,8)
  
• We will start with the first and default form. You can see the different tabs on the top in the IDE. These tabs contain objects such as buttons, angular meters, etc. We leave the exploration of the different objects on you.
+
Each element of the autocorrelation matrix is obtained by:
  
• To start with select the “Fancy Button” under the buttons tab. Draw the button of your desired size anywhere on the screen. On the right side, you can see the “object inspector” of the button. You can change the name of the button (under “captions” field), the background and foreground color, the font size and style. It is very flexible.
+
--> Summing up all the elements along the right diagonal upto the left diagonal.
  
• An important thing to note is the name which would “Winbutton0” since it’s the first button. The ‘0’ here is the index which acts as a reference to address the button.
+
--> This summation is multiplied by two.
  
• Now add an “angular gauge” to the screen. Resize it, change the color, the digits size, color, the span of the arc, the range in the “object inspector” section. We leave the exploration on you. Note the name of the meter and more important the number at the end of the name – the index. (e.g. angularmeter0). We will give more light on the index field later on.
+
--> The element on the left diagonal is added to the summation.
  
• Your first Form is now ready. Let’s add one more form from the “system/media” tab. This form is named as form1. Now we will link the button created on the first form to the Form1 such that by pressing the button, Form1 will be displayed.
+
An example of this operation is as follows:
  
• Goto the Form0. Select the button. In the object inspector, select the “Events” tab. Each press on the screen creates an event and we can configure the event whether to go to a new form when pressed or report a message to the host controller.
+
--> For an even index, the value of the autocorrelation is
 +
   
 +
    r(2)=r(2,1)*2.
  
• On clicking on the handler, we can see the various options available. Select the “Form1 activate”. This means that the Form1 would be activated when the button is pressed. Your basic GUI is now complete! It’s simple, isn’t it?
+
--> For an odd index, the value of the autocorrelation is  
  
'''Steps to program the LCD:'''
+
    r(3)=(r(3,1)*2)+r(2,2)
  
• Once the LCD is properly interfaced (you need to cross the Rx and Tx lines), goto “COMMS” tab and select the proper COM port and you should see the name of the LCD on the top left corner of the IDE. There would be a green symbol which means the IDE has detected the LCD.
 
  
• Press the “Copy/Build” button. NOTE: You would need a microSD card. The IDE stores the user images on the microSD. Even though we are not using any images, we still need a microSD card. The microSD should be formatted in FAT file format only.
 
  
• Just follow the steps on the dialogues popped in the IDE and you should be just fine.
+
The value of the array when a bump is detected is a={0,0,0,0,0,1,0,0}. This is an impulse signal.
 +
 +
This impulse signal is displayed in the adjoining image:
  
• After the process is finished, the LCD won’t show our GUI unless we insert the SD card. It would keep flashing an error message.
+
[[File:CMPE244 S17 MyAutohealthBD1.JPG|1000px|thumb|center|Unit Impulse Response]]
  
• After inserting the SD card, our GUI would be up and running. Press the button, you can goto the next screen.
 
  
Interfacing this LCD with a host processor - SJOne Board.  
+
The autocorrelation of this unit impulse response signal is the signal itself. This is shown in the following image:
  
• To interface LCD with the processor the UART port is used, which was initially used for programming the LCD.
 
  
• Cross connect the Rx and Tx pins of SJ-One board and the LCD.
+
[[File:CMPE244 S17 MyAutohealthBD2.JPG|1000px|thumb|center|Autocorrelation of an impulse signal]]
  
• But to send the data on the LCD and specifically to objects like thermometers and gauges, we need to follow the specific frame format for the LCD.
 
  
• Remember the index which we talked about previously? We need to use those index numbers to address the object.
+
If no bumps are detected but the vehicle is either ascending or descending a slope, the value of the array is a={0,0,0,1,1,1,0,0}. This is a rectangular pulse of unit height. The rectangular pulse is displayed below:
  
[[Image:CmpE244 S14 SWC FORM0_with_properties.JPG|600px|thumb|right|Form Properties]]
 
  
We would recommend you to go through the ViSi-Genie Reference manual available on the app notes section of the website to understand the frame format in detail. Here’s the link: http://www.4dsystems.com.au/downloads/Software/4D-Workshop4-IDE/Docs/ViSi-Genie/ViSi-Genie-Reference-Manual-REV1.pdf
+
[[File:CMPE244 S17 MyAutohealthBD3.JPG|1000px|thumb|center|Rectangular pulse of unit height]]
  
• You can Write objects ( e.g. sending some data for the angular meter), or Write Strings or Read Objects.
 
  
• Just to give you a basic idea of the UART frame format required: We will give you an example on how to write objects (angular meter in our case).
+
The autocorrelation of this rectangular pulse is a triangular pulse:
  
1) Byte 1: CMD (0x01) which is the write object command.
 
  
2) Byte 2: OBJ-ID. This is the ID that tells the LCD that we are addressing the Angular meter and the Thermometer or anything else. The list of ID’s can be found on page 7 of the “Writing to Genie Objects from Arduino” file in the app notes section. Here’s the link to the PDF: http://www.4dsystems.com.au/downloads/Application-Notes/4D-AN-P4018_R_1_0.pdf . The ID for the angular meter is 0x07.
+
[[File:CMPE244 S17 MyAutohealthBD4.JPG|1000px|thumb|center|A triangular pulse]]
  
3) Byte 3: OBJ-INDEX. This is the index number previously mentioned. The index is ‘0’ in our case. So this field would be 0x00.
 
  
4) Byte 4: The Most Significant Byte of the value to be sent.
+
Based on the visual analysis, it is clear that if a triangular pulse is present in the autocorrelation sequence, the vehicle is probably on a slope and therefore the z-axis values do not indicate a bump.
  
5) Byte 5: The Least Significant Byte of the value to be sent. (e.g. to send a value 360 (0x168) to the meter, MSB : 0x01 and LSB : 0x68 )
+
If the input array has a sequence like a={0,0,1,1,1,0,1,0}, then the autocorrelation sequence obtained will look like:
  
6) Byte 6: CHECKSUM. The checksum byte is used for verification of the frame. Calculating the checksum is fairly simple. Just XOR (using the ^ operator) all the bytes from byte 1 to byte 5.
 
  
• So our UART frame would be: 0x01, 0x07, 0x00, 0x01, 0x68, 0x6F
+
[[File:CMPE244 S17 MyAutohealthBD5.JPG|1000px|thumb|center|A distorted triangular pulse due to a bump]]
  
• When we send this frame, the LCD will automatically move the needle of the meter to the value 360.
 
  
• Another thing to note is, that if the LCD receives the frame without any errors, it will send one byte of ACK (0x06) back to us. If there is data corruption or invalid frame format sent by us, it sends a NACK byte (0x15). This can be used as a trigger to resend the data to the LCD or give some warnings.
+
The autocorrelation sequence is completely distorted in this case and thus it is evident that the vehicle went over a bump.
 +
 
 +
If the array’s value is a={1,1,0,0,0,0,0,1}, the autocorrelation sequence obtained will have both a triangular pulse and an impulse both clearly separated as follows:
 +
 
 +
 
 +
[[File:CMPE244 S17 MyAutohealthBD6.JPG|1000px|thumb|center|A triangular pulse and an impulse present due to a time gap]]
 +
 
 +
 
 +
 
 +
'''Power Spectral Density'''
 +
 
 +
The PSD of the autocorrelation array was analysed. This helped in making a decision if a valid bump was detected. The PSD analysis helped overcome most of the drawbacks that an analysis of the autocorrelation array would have resulted in.
 +
 
 +
The frequency domain representation of an autocorrelation WSS signal is its power spectrum. The following cases were observed while analyzing various inputs:
 +
 
 +
* If no bumps were detected at all and if the vehicle was moving on a flat road, the array sequence had only zeros. Therefore, its autocorrelation sequence was also zero and its power spectrum was flat with amplitude zero.
 +
 
 +
* If single or multiple bumps occurred, the autocorrelation array would consist of impulse response functions. The Power Spectrum Density of such a signal was an impulse whose magnitude was the sum of the magnitudes of all the impulses. No phase shift was observed in this case. A plot representing the PSD of two bump signals is shown in the figure below.
 +
 
 +
 
 +
[[File:CMPE244 S17 MyAutohealthPSD1.JPG|600px|thumb|center|Figure representing magnitude plot of two impulse responses’ PSD]]
 +
 
 +
 
 +
* If the car was moving uphill or downhill, then the autocorrelation sequence was a triangular pulse. The Fourier Transform of this pulse is a sinc-squared function. This is as shown below:
 +
 
 +
 
 +
[[File:CMPE244 S17 MyAutohealthPSD2.JPG|600px|thumb|center|A sinc-squared function in the discrete time domain]]
 +
 
 +
 
 +
* The amplitude of this sinc-squared function is the amplitude of the triangular pulse times its width. The function detection program checked the value of the amplitude. It also checked for zero crossing. If both these conditions were present in the PSD, then a decision was made that there was no bump.
 +
 
 +
* If the autocorrelation sequence has both a triangular pulse and multiple impulses, the PSD will be distorted as shown below:
 +
 
 +
 
 +
[[File:CMPE244 S17 MyAutohealthPSD3.JPG|600px|thumb|center|A distorted PSD due to bumps]]
 +
 
 +
 
 +
 
 +
== The Display ==
 +
 
 +
The critical engine parameters were displayed on a LCD screen to provide real time updates to the driver.
 +
 
 +
'''LCD Graphical User Interface Design'''
 +
 
 +
The LCD display displayed the following the parameters:
 +
 
 +
* The orientation of the vehicle- Incline, Decline, Horizontal
 +
 
 +
* The total load on the engine.
 +
 
 +
* Careless driving behaviour by displaying 'Bump Detected'
 +
 
 +
* If the vehicle is at an incline and the vehicle speed is reducing, it prompts the driver to accelerate. If the vehicle torque is not increasing with acceleration it sounds an alarm bell.
 +
 
 +
* If the vehicle is at an decline and the vehicle speed is increasing, it prompts the driver to decelerate.
 +
 
 +
An image displaying the LCD's output is as follows:
 +
 
 +
{|
 +
|[[File:CMPE244 SP17 MyAutoHealth homescreen.PNG|250px|left|thumb|LCD Home Screen]]
 +
|[[File:CMPE244 SP17 MyAutoHealth secondscreen.PNG|250px|right|thumb|LCD Screen 2]]
 +
|[[File:CMPE244 SP17 MyAutoHealth mainscreen.PNG|250px|right|thumb|LCD Main Screen]]
 +
|}
 +
 
 +
 
 +
The LCD was programmed as follows:
 +
 
 +
* ViSi Genie: This is a drag and drop mode. Objects available in the menu were added to the screen. These objects included switches, text boxes, gauges, thermometers, angular meters, etc.
 +
 
 +
* ViSi: This mode is a combination of the 4DGL programming language assisted with drag and drop of objects.
 +
 
 +
* Designer: This mode is a pure 4DGL programming language. Each object needs to be added.
 +
 
 +
 
 +
The LCD module worked as follows:
 +
 
 +
* The LCD sends in acknowledgment to the LPC node once it receives the device ID
 +
 +
* The LCD acknowledges that the register address has been sent and communication to begin writing data starts.
 +
 
 +
==Future Developments==
 +
 
 +
There is ample of data available over the OBD-II tools and along with many more sensors we can diagnose more in depth about the various parameters of a vehicle.This information can help the driver to know more about his/her driving skills and about the vehicle's conditions.
  
 
== Testing & Technical Challenges ==
 
== Testing & Technical Challenges ==
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
 
Make a smooth transition to testing section and described what it took to test your project.
 
  
Include sub-sections that list out a problem and solution, such as:
 
  
=== My Issue #1 ===
+
'''Issue 1'''
Discuss the issue and resolution.
+
 
 +
We had created multiple producers and consumers to share information between tasks. A specific task was created to read values from the accelerometer, another to normalize the data and a third to perform signal analysis. We noticed that there was an issue with context switching and that the tasks weren't running synchronously. It was noticed that at least one task was getting blocked forever although they were all of the equal priority.
 +
 
 +
'''Resolution'''
 +
 
 +
This problem was solved by forcing a producer to sleep for a fixed duration.
 +
 
 +
'''Issue 2'''
 +
 
 +
We had another set of tasks that needed to access the LCD screen to display data. We noticed that there was bus contention when multiple tasks tried to access the UART2 ports.
 +
 
 +
'''Resolution'''
 +
 
 +
We overcame this issue by integrating all LCD write calls into a separate task and gave it a semaphore. It would thus print on the LCD screen after all other tasks had finished updating the variables to be printed.
 +
 
 +
'''Issue 3'''
 +
 
 +
While working on the OBD-II to SJOne communication to retrieve the data from each incoming OBD-II frame, we were missing some of the data and the OBD-II would return a fault in the system signal
 +
 
 +
'''Resolution'''
 +
 
 +
We tried various methods to solve the issue such as mutex to prevent multiple accesses to the bus and queues to wait for a task to complete one transaction before starting another but the easiest solution was to sleep the task for a short duration to allow for the OBD-II tool to process our PIDs and respond with the appropriate values.
 +
 
 +
'''Issue 4'''
 +
 
 +
Since most of the data from the OBD-II frames required bit manipulation and mathematical formulas to decode we had to make multiple trips to the car to run and test our program
 +
 
 +
'''Resolution'''
 +
 
 +
We broke the mathematical conversions and bit manipulation programs into smaller functions and created and tested those functions on Xcode (you can use any IDE to compile C/C++ programs) so as to reduce debugging time and reduce our trips to the car.
  
 
== Conclusion ==
 
== Conclusion ==
Conclude your project here. You can recap your testing and problems.  You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
+
The whole setup was placed inside a Honda Civic for an acquiring relevant data. The readings from the accelerometer were documented and the values observed were passed as input for FFT calculation and PSD calculation, these values were further . We recorded accurate values and observed a steady pattern while driving
  
 
=== Project Video ===
 
=== Project Video ===
Upload a video of your project and post the link here.
+
* [https://youtu.be/LGjHW27fo-A Project Video Link]
  
 
=== Project Source Code ===
 
=== Project Source Code ===
*  [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]
+
*  [https://sourceforge.net/projects/myautohealth/ Sourceforge Source Code Link]
  
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.
+
We would like to acknowledge Professor Preet Kang for simplifying the concepts of FreeRTOS, clearing our doubts and guiding us with our coursework and project.
  
 
=== References Used ===
 
=== References Used ===
List any references used in project.
+
[1] CMPE 244 Lecture notes from Preetpal Kang, Department of Computer Engineering, San Jose State University (Spring 2017)
 +
 
 +
[2] SparkFun Website: https://learn.sparkfun.com/tutorials/obd-ii-uart-hookup-guide
 +
 
 +
[3] SocialEdge Website: http://www.socialledge.com/sjsu/index.php?title=Main_Page
 +
 
 +
[4] Hayes, M. (2002). Statistical Digital Signal Processing and Modelling. Singapore: John Wiley & Sons (Asia) Pte. Ltd.
 +
 
 +
[5] OBD-II PIDs (Wikipedia) :https://en.wikipedia.org/wiki/OBD-II_PIDs
 +
 
 +
[6] LCD Start-Up Guide: http://www.4dsystems.com.au/productpages/uLCD-32PTU/downloads/uLCD-32PTU_productbrief_R_1_2.pdf
  
=== Appendix ===
+
[7] LCD Screen Datasheet: http://www.4dsystems.com.au/productpages/uLCD-32PTU/downloads/uLCD-32PTU_datasheet_R_2_1.pdf
You can list the references you used.
 

Latest revision as of 07:00, 27 September 2017

MyAutoHealth

MyAutoHealth is a product that uses various parameters of a vehicle and an accelerometer sensor to inform the driver of how well a vehicle is being driven. Below is a system diagram to show how the various modules interact.

System Block

Abstract

Wear and tear or ageing of parts of an automobile may cause it to malfunction and this may lead to accidents and loss of life and property. Therefore, it is important to monitor a vehicle's internal systems continuously and report any spurious activity to the driver. Most modern vehicles, just like a computer, have a central processing unit called the Engine Control Unit (ECU). This microcontroller oversees all operations. The project uses an OBD 2 module to communicate with the ECU and display the status of all critical vehicle parameters to the driver. This will enable the driver to monitor the engine’s internal functioning. The module will suggest measures to improve driving efficiency and avoid accidents and damage. It will keep an eye on the engine to see if the instantaneous load on it is more than it can handle and warn the driver if so. This will provide real-time feedback to the driver and ensure that appropriate steps can be taken preemptively to avert any major accidents. The module also track the driver's habits. A bump detection algorithm has been developed using deterministic signal processing that the user can turn on to monitor himself or herself.

Objectives & Introduction

The main objectives of this project are as follows:-

  • Develop a standalone system to communicate with the ECU
  • Monitor critical engine parameters
  • Measure road inclination against the vehicles torque-speed characteristics
  • Detect careless driving habits using signal processing
  • Display vehicle parameters and provide real-time updates about the same on a LCD screen

Team Members & Responsibilities

  • Manan Mehta
    • BOM, PCB design, and assembly
    • Code testing and integration
    • Interface accelerometer to obtain inclination and declination of vehicle.
  • Pushpender Singh
    • Interface OBD-II sensor to the SJOne Board over UART
    • Acquire and translate ODB-II data to acquire engine load, vehicle speed, engine RPM and torque
    • Integrating OBD2 code with and accelerometer code- worked with Shashank Iyer
  • Sameer Saran
    • Interfacing LCD Display
    • LCD GUI design
    • Integrating Display code to OBDII and accelerometer code
  • Sanman Pradhan
    • PCB Design
    • Edit the Wiki Report
  • Shashank Iyer
    • Bump detection using an accelerometer
    • Using Signal Processing- FFT and PSD analysis to assess if the detected bump is valid
    • Ensure critical section access is provided to all tasks created by team members.

Schedule

Week# Date Task Action
1 03/21 Research Project design and Finalize concept Completed
2 03/28 Purchasing BOM and Assign Tasks Completed
3 04/04 Developing C code to read Accelerometer readings Completed
4 04/11 Interfacing OBD II sensor with SJ one board, LCD Communication Protocol setup Completed
5 04/18 Developing C code to retrieve data from Vehicle and PCB design, LCD GUI Design Completed
6 04/25 Integrating OBD and Sensor code into tasks and PCB design, LCD hex Codes Integration Completed
7 05/02 Testing, troubleshooting, debugging and optimization Completed
8 05/09 PCB Assembly and Testing Completed
9 05/16 Ready for Demo Absolutely!

Parts List & Cost

A list of the cost of our project broken down by components.

Item# Part Desciption Vendor Part Number Qty Cost
1 SJOne Board SCE 1 $80.00
2 OBD-II SparkFun WIG-09555 ROHS 1 $49.95
3 OBD-II to DB9 Cable SparkFun CAB-10087 ROHS 1 $9.95
4 uLCD Display 4D Systems uLCD-32PTU 1 $79.00
5 SD card and Adapter for LCD Amazon SDSDQM-016G-B35A 1 $6.95
6 FTDI Cable SparkFun DEV-09718 ROHS 1 $17.50
7 PCB PCBWay N/A 1 $11.50
8 SPDT Toggle Switches Amazon a14072300ux0371 10 $8.83
9 Li-po battery 3.7V 2000mAh Adafruit 2011 1 $12.50
10 Li-po battery charger Adafruit 2465 1 $19.95
Total $296.13


System Development and Hardware Design

The device was designed to operate standalone so that its working didn't depend on the availability of a free power port in the vehicle. A lithium ion battery was chosen as the power source. The device needed to be connected with the OBD port in the vehicle for all features to be available or just be placed on a flat surface inside the vehicle to enable some features.

An LPC 1758 microcontroller was used as the master for this system. The master communicated with:

  • An OBD II terminal over UART to read critical vehicle parameters
  • A LCD screen over UART to display real time values to the drivers
  • An onboard accelerometer using I2C to monitor driving habits and warn the driver about possible accidents.

The block diagram provides an overview of the system's architecture.

Block Diagram


The lithium ion battery was to power the master and all peripheral devices. A current distribution circuit was designed and manufactured to enable this. Autodesk EAGLE 8.1.1 was the tool of choice to design the PCB's layout.

Designing the PCB in EAGLE is a two step process:

  • Schematic Designing: A current distribution footprint was created. Prototyping components by Adafruit and Sparkfun were used for the battery charging circuit and the USB to serial communicator. Therefore, PCB designing libraries developed by these firms were downloaded and integrated with EAGLE to enable accurate footprint creation.
  • Board Designing: The schematic design offered an overview of the board with a black grid and the components clustered at one end. The components were rearranged to avoid any short circuits that could have been caused due to the proximity of tracks or contacts. ERC (Electrical Rule Check) and DRC (Design Rule Check) checks followed. Solder masks were added for protection.

The circuit's layout is as follows:

Schematic
Board Layout

.

Monitoring Engine Parameters

OBD is the language of ECU that has been designed to detect system failures. This OBD2 standard was used to communicate with the ECU to acquire data about all critical engine parameters. This data was sent to the master over UART.

OBD2 trans-receives bytes of data with the ECU. Some of the OBD2 commands used are:

engineLoad= "0104", fuelPressure = "010A" engineRpm = "010c", vehicleSpeed = "010d"

The interpretation of the bytes of data are as follows.

  • Suppose the master wanted to access engine RPM. It would send “010c”.
  • The first hex pair represents the OBD mode and the second hexadecimal represents the PID(Parameter Identification).
  • In this example, Mode 01 and Pid 0c is used which returns the engine RPM.

The master will receive bytes of data and will have to interpret it. When “010c” is sent the master will receive a string of hexadecimal numbers: 41 0C 03 2E. 0x41 - State of board in mode one 0x0C - RPM parameters 0x03 and 0x2E, values used to calculate the RPM.

Testing:

  • The ODB2 module was interfaced with the master with an OBDII to uart converter.
  • An FTDI chip was used to allow communication with a pc.
  • Baud rate was set to 9600 bps and USB driver was configured to 8 data bits, 1 stop bit and no parity bit.
  • ATZ or init command was sent. If all connections are correct the master will receive "ELM327 v2.0".

Implementation:

  • The AT commands were sent to the OBD terminal.
  • Another string was obtained in response to these commands. The data was converted to integers for displaying.

Driving habits and signal processing

BUMP DETECTION

This feature was added to enable monitoring a driver’s behavior. This could be used widely by schools to keep an eye on their drivers. An accelerometer is used to detect bumps in the vehicle path. Depending on the unevenness of the travel path, the LCD will display "No Bumps" or "Bump Detected". The accelerometer's z-axis value is read every 100 ms by creating a task.

The bump detection algorithm operates in the following manner:

1. Threshold value recognition to identify a preset value beyond which a bump will be detected

2. Acquiring values from the accelerometer.

3. Using signal processing to obtain its Power Spectrum Density.

4. Analyzing the power spectrum of the signal.


ACCELEROMETER READING

The onboard accelerometer was used for gathering readings. The algorithm was designed such that if z-axis values were greater than a preset threshold then a bump event is triggered whereas if the readings were lesser in value than the threshold then no bump event is triggered.

The readings from the z-axis were normalized, this helped in easing the computations. The readings were stored according to the following steps

--> An array a[8] initialized to '0' used to store the normalized readings.

--> New readings are appended to the array while performing a simultaneous left shift operation.

--> If a bump is detected, the array will then have a value of a={0,0,0,0,0,0,0,1} whereas if no bump is detected, the array will have a new value of a={0,0,0,0,0,0,1,0}.

--> Depending upon the movement of the vehicle there could be multiple '1's in the array, indicating multiple bumps.


SLOPE AND BUMP DETECTION

If the road on which the car was moving was inclined, then it was observed that the z-axis readings would cross the threshold. But these events were not to be considered as bumps. The algorithm was to be designed to ensure that it didn’t consider the occurrence of such an event a bump. Some examples of cases that needed differential treatment are as follows:

--> The array a in case the vehicle in ascending a slope will have values like a={0,1,1,1,0,0,0,0}.

--> If the vehicle has climbed a slope and after this, due to negligent driving passes over a bump, then the array’s value could be a={0,1,1,1,1,0,1,0}.

To be able to distinguish between the two cases and make a decision that there is no bump in the first case and a clear bump in the second, signal processing was used. The array a needed to possess certain characteristics so that the signal processing techniques could produce a meaningful output.


WIDE SENSE STATIONERY SIGNAL

To analyse the power spectrum density of an array, it must be WSS or Wide Sense Stationery. The array a:

  • Has a constant mean from which instantaneous values may deviate but will eventually return to:
 m(n)=m

If the mean deviates from the constant value, then the equation indicates that at some time n the mean m(n) will return to its constant value m.

  • The autocorrelation depends only on the difference (k-l) and is given as:
 r(k,l)
  • The normalised values from the z-axis have a value of either ‘1’ or ‘0’. Thus the variance of any new reading from the accelerometer from the previous value can be utmost ‘1’. The variance is given by c(n) and its value must be:
 c(n)<∞

Since all three conditions are satisfied, the array a is WSS. To obtain the PSD of a wide sense stationery array, the following procedures are followed:

--> The autocorrelation sequence of the array is calculated.

--> It is transformed to its frequency domain equivalent using Fast Fourier Transform which has a running time of O(nlogn).

--> The Fourier Transform of the autocorrelation sequence is the Power Spectrum Density of the Signal.

AUTOCORRELATION

The autocorrelation sequence of the sequence is obtained using matrix multiplication and then summing up the lower triangular elements. This process reduces the time complexity by a fourth as compared to the traditional approach. The autocorrelation matrix R is computed by multiplying the array with it’s transpose. The elements of the matrix are as follows:

r= (1,1) (1,2) ⋯ (1,8)
   (2,1) (2,2) ⋯ (2,8)
     ⋮      ⋮   ⋱   ⋮
   (8,1) (8,2) ⋯ (8,8)

Each element of the autocorrelation matrix is obtained by:

--> Summing up all the elements along the right diagonal upto the left diagonal.

--> This summation is multiplied by two.

--> The element on the left diagonal is added to the summation.

An example of this operation is as follows:

--> For an even index, the value of the autocorrelation is

   r(2)=r(2,1)*2.

--> For an odd index, the value of the autocorrelation is

   r(3)=(r(3,1)*2)+r(2,2)


The value of the array when a bump is detected is a={0,0,0,0,0,1,0,0}. This is an impulse signal.

This impulse signal is displayed in the adjoining image:

Unit Impulse Response


The autocorrelation of this unit impulse response signal is the signal itself. This is shown in the following image:


Autocorrelation of an impulse signal


If no bumps are detected but the vehicle is either ascending or descending a slope, the value of the array is a={0,0,0,1,1,1,0,0}. This is a rectangular pulse of unit height. The rectangular pulse is displayed below:


Rectangular pulse of unit height


The autocorrelation of this rectangular pulse is a triangular pulse:


A triangular pulse


Based on the visual analysis, it is clear that if a triangular pulse is present in the autocorrelation sequence, the vehicle is probably on a slope and therefore the z-axis values do not indicate a bump.

If the input array has a sequence like a={0,0,1,1,1,0,1,0}, then the autocorrelation sequence obtained will look like:


A distorted triangular pulse due to a bump


The autocorrelation sequence is completely distorted in this case and thus it is evident that the vehicle went over a bump.

If the array’s value is a={1,1,0,0,0,0,0,1}, the autocorrelation sequence obtained will have both a triangular pulse and an impulse both clearly separated as follows:


A triangular pulse and an impulse present due to a time gap


Power Spectral Density

The PSD of the autocorrelation array was analysed. This helped in making a decision if a valid bump was detected. The PSD analysis helped overcome most of the drawbacks that an analysis of the autocorrelation array would have resulted in.

The frequency domain representation of an autocorrelation WSS signal is its power spectrum. The following cases were observed while analyzing various inputs:

  • If no bumps were detected at all and if the vehicle was moving on a flat road, the array sequence had only zeros. Therefore, its autocorrelation sequence was also zero and its power spectrum was flat with amplitude zero.
  • If single or multiple bumps occurred, the autocorrelation array would consist of impulse response functions. The Power Spectrum Density of such a signal was an impulse whose magnitude was the sum of the magnitudes of all the impulses. No phase shift was observed in this case. A plot representing the PSD of two bump signals is shown in the figure below.


Figure representing magnitude plot of two impulse responses’ PSD


  • If the car was moving uphill or downhill, then the autocorrelation sequence was a triangular pulse. The Fourier Transform of this pulse is a sinc-squared function. This is as shown below:


A sinc-squared function in the discrete time domain


  • The amplitude of this sinc-squared function is the amplitude of the triangular pulse times its width. The function detection program checked the value of the amplitude. It also checked for zero crossing. If both these conditions were present in the PSD, then a decision was made that there was no bump.
  • If the autocorrelation sequence has both a triangular pulse and multiple impulses, the PSD will be distorted as shown below:


A distorted PSD due to bumps


The Display

The critical engine parameters were displayed on a LCD screen to provide real time updates to the driver.

LCD Graphical User Interface Design

The LCD display displayed the following the parameters:

  • The orientation of the vehicle- Incline, Decline, Horizontal
  • The total load on the engine.
  • Careless driving behaviour by displaying 'Bump Detected'
  • If the vehicle is at an incline and the vehicle speed is reducing, it prompts the driver to accelerate. If the vehicle torque is not increasing with acceleration it sounds an alarm bell.
  • If the vehicle is at an decline and the vehicle speed is increasing, it prompts the driver to decelerate.

An image displaying the LCD's output is as follows:

LCD Home Screen
LCD Screen 2
LCD Main Screen


The LCD was programmed as follows:

  • ViSi Genie: This is a drag and drop mode. Objects available in the menu were added to the screen. These objects included switches, text boxes, gauges, thermometers, angular meters, etc.
  • ViSi: This mode is a combination of the 4DGL programming language assisted with drag and drop of objects.
  • Designer: This mode is a pure 4DGL programming language. Each object needs to be added.


The LCD module worked as follows:

  • The LCD sends in acknowledgment to the LPC node once it receives the device ID
  • The LCD acknowledges that the register address has been sent and communication to begin writing data starts.

Future Developments

There is ample of data available over the OBD-II tools and along with many more sensors we can diagnose more in depth about the various parameters of a vehicle.This information can help the driver to know more about his/her driving skills and about the vehicle's conditions.

Testing & Technical Challenges

Issue 1

We had created multiple producers and consumers to share information between tasks. A specific task was created to read values from the accelerometer, another to normalize the data and a third to perform signal analysis. We noticed that there was an issue with context switching and that the tasks weren't running synchronously. It was noticed that at least one task was getting blocked forever although they were all of the equal priority.

Resolution

This problem was solved by forcing a producer to sleep for a fixed duration.

Issue 2

We had another set of tasks that needed to access the LCD screen to display data. We noticed that there was bus contention when multiple tasks tried to access the UART2 ports.

Resolution

We overcame this issue by integrating all LCD write calls into a separate task and gave it a semaphore. It would thus print on the LCD screen after all other tasks had finished updating the variables to be printed.

Issue 3

While working on the OBD-II to SJOne communication to retrieve the data from each incoming OBD-II frame, we were missing some of the data and the OBD-II would return a fault in the system signal

Resolution

We tried various methods to solve the issue such as mutex to prevent multiple accesses to the bus and queues to wait for a task to complete one transaction before starting another but the easiest solution was to sleep the task for a short duration to allow for the OBD-II tool to process our PIDs and respond with the appropriate values.

Issue 4

Since most of the data from the OBD-II frames required bit manipulation and mathematical formulas to decode we had to make multiple trips to the car to run and test our program

Resolution

We broke the mathematical conversions and bit manipulation programs into smaller functions and created and tested those functions on Xcode (you can use any IDE to compile C/C++ programs) so as to reduce debugging time and reduce our trips to the car.

Conclusion

The whole setup was placed inside a Honda Civic for an acquiring relevant data. The readings from the accelerometer were documented and the values observed were passed as input for FFT calculation and PSD calculation, these values were further . We recorded accurate values and observed a steady pattern while driving

Project Video

Project Source Code

References

Acknowledgement

We would like to acknowledge Professor Preet Kang for simplifying the concepts of FreeRTOS, clearing our doubts and guiding us with our coursework and project.

References Used

[1] CMPE 244 Lecture notes from Preetpal Kang, Department of Computer Engineering, San Jose State University (Spring 2017)

[2] SparkFun Website: https://learn.sparkfun.com/tutorials/obd-ii-uart-hookup-guide

[3] SocialEdge Website: http://www.socialledge.com/sjsu/index.php?title=Main_Page

[4] Hayes, M. (2002). Statistical Digital Signal Processing and Modelling. Singapore: John Wiley & Sons (Asia) Pte. Ltd.

[5] OBD-II PIDs (Wikipedia) :https://en.wikipedia.org/wiki/OBD-II_PIDs

[6] LCD Start-Up Guide: http://www.4dsystems.com.au/productpages/uLCD-32PTU/downloads/uLCD-32PTU_productbrief_R_1_2.pdf

[7] LCD Screen Datasheet: http://www.4dsystems.com.au/productpages/uLCD-32PTU/downloads/uLCD-32PTU_datasheet_R_2_1.pdf