Difference between revisions of "S17: MyAutoHealth"
Proj user12 (talk | contribs) (→Team Members & Responsibilities) |
Proj user12 (talk | contribs) (→Team Members & Responsibilities) |
||
| Line 49: | Line 49: | ||
** Bump detection using an accelerometer | ** Bump detection using an accelerometer | ||
** Using Signal Processing- FFT and PSD analysis to assess if the detected bump is valid | ** 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 | + | ** Ensure critical section access is provided to all tasks created by team members. |
| − | |||
== Schedule == | == Schedule == | ||
Revision as of 06:46, 25 May 2017
Contents
Grading Criteria
- 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.
MyAutoHealth
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 behaviour 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 OBD2 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 | Assembly- Completed, testing - In progress |
| 9 | 05/16 | Ready for Demo |
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 |
Hardware Design
The SJOne board is the centerpiece of the hardware design of the project. It is used for communication with peripherals through communication protocols such as I2C and UART bus. The board is powered by Lithium Ion batteries. The peripherals involved are the ECU (vehicle) and the LCD. The communication with both peripherals is done over UART.
The following block diagram highlights the architecture of the project.
PCB Design
We designed the PCB using Autodesk EAGLE 8.1.1 software. The goal of the PCB design was to provide a connection from the external portal power supply to the SJOne board and to provide more I2C and power pins for external device connections.
Designing PCB in EAGLE is a two step process:
- Schematic Designing: Necessary connections and component connections were performed. Eagle Library was used for obtaining a basic footprint. We had to download specific libraries(.lbr) from adafruit and sparkfun which provided the appropriate component and board footprint. Using the wire function the necessary components were assembled.
- Board Designing: After completion of schematic design, the board view offered a black grid with the components clustered at one end. Efficient use of space and arranging the components so as to avoid any electrical shorts is a key factor. Once routing is done, check for errors using ERC (Electrical Rule Check) and DRC (Design Rule Check) checks. If there are no errors then the check should return "ERC: No Error" and "DRC: No Error". We added solder mask for protection.
The power supply required was designed to be housed on a PCB. The following are the schematics of the board. EaglePCB was used for design and development of the PCB.
.
Hardware Interface
UART Bus
1. Rx and Tx communication lines are used along with UART 2 connection which communicates between the SJOne board to UART. We used a UART to OBD board for interfacing the board with the vehicle.
2. The "TXD2"(P0.10) and "RXD2" (P0.11) of the SJOne Board interface with the OBD to UART board's RX-1 and TX-0.
I2C Bus
1. Alternative, I2C 2 connection between the SJ One Board and the LCD Display SJ One Board pins P0.10 "SDA2" and P0.11 "SCL2" to LCD Display J2 pin4 "I2C data" and J2 pin4 "I2C clock".
2. Observe that the pins interfere with the UART 2 connection so adaptation to a different UART port is necessary.
Software Design
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.
OBD Algorithm
Graphics LCD Design
The following diagram highlights communication between LCD and LPC17xx. the pinout diagram shows the interfacing between the board and the peripheral device. This is an example of Master-slave communication between the LCD and the microcontroller
An uLCD-32PTU from 4D Systems was used. It’s a graphic LCD with a resolution of 240x320.
LCD Graphical User Interface Design
Below are the snaps of the different LCD screen GUI:
LCD Home Screen: This is the first screen that comes up once you start the LCD.
LCD Screen 2: This screen displays the title of our project and the team members names that contributed towards the development of the same.
LCD Main Screen: This screen gives the necessary vehicle parameters for health diagnostics including Engine Load, bump detection warning, slow down warning, incline, decline and straight movement of the vehicle. To make it visually appealing, Red LED's light up every time any signal is received.
LCD Programming
The LCD was used for making quick GUI’s.
The LCD was programmed as follows:
1) ViSi Genie: This is a drag and drop mode. Objects available in the menu were drag and dropped onto the screen. These objects included switches, text boxes, gauges, thermometers, angular meters, etc. This mode didn't require any programming. IDE automatically generated the code required for the object needed.
2) ViSi: This mode is a combination of the 4DGL programming language assisted with drag and drop of objects.
3) Designer: This mode is a pure 4DGL programming language. Each object needs to be added using a programming language. The only benefit of using this code is the feature to use the peripherals and busses available on the Touchscreen. The uLCD-32PTU has onboard I2C and UART ports and also has buzzer and ADC. These functionalities were used with 4DGL programming language. These peripherals can also be used in the ViSi mode. A thorough documentation of 4D systems can be found on this link: http:/www.4dsystems.com.au/appnotes/ Refer the app notes in the ViSi-Genie category.
UART protocol was used to communicate between the LPC1758 and LCD screen. The screen displayed the information sent to it.The communication between the LPC node and the LCD device then works 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.
The following flowchart depicts communication between master and slave -
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
Discuss the issue and resolution.
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
Upload a video of your project and post the link here.
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
Adafruit website: https://learn.adafruit.com/pir-passive-infrared-proximity-motion-sensor/overview
SocialEdge Website: http://www.socialledge.com/sjsu/index.php?title=Main_Page
Appendix
You can list the references you used.
