S17: MyAutoHealth
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
MyAutoHealth : A product that provides the driver with various information on how well the car is being driven
Poor driving can deteriorate a vehicle's health rapidly and cause mechanical and electrical failures in the long run. The advances in modern automobile technology have provided a distributed network of control units for vehicles which controls and reports most of the critical operations of the vehicle. This project communicates with this network by using an external OBD-II module to communicate and retrieve vital information pertaining to the vehicle. Our project reports the engine load, when the car hit a hard bump or if the vehicle is driving too fast on a decline or too slow on a decline.
MyAutoHealth uses the multithreading benefits of FreeRTOS, the power of an ARM cortex and peripheral devices such as accelerometer, OBD-II to UART converter and an LCD display to help a driver improve the health of the vehicle.
Objectives & Introduction
The main objectives of this project are classified as:-
- Use FreeRTOS API's to acquire data from the accelerometer and determine bumps in the travel path of the vehicle.
- The data of the accelerometer is used to calculate FFT and PSD.
- Further, this data is used to determine whether the vehicle is going on an elevation or entering a depression.
- The driver to be notified via alerts on LCD.
- The LCD interface will display diagnostic information pertaining to the vehicle.
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
- Sameer Saran
- Interfacing LCD Display
- LCD GUI design
- Integrating LCD, Accelerometer and OBDII code
- Sanman Pradhan
- PCB Design
- Main Wiki Report editor
- 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 | Completed |
| 5 | 04/18 | Developing C code to retrieve data from Vehicle and PCB design | Completed |
| 6 | 04/25 | Integrating OBD and Sensor code into tasks and PCB design | Completed |
| 7 | 05/02 | Testing and debugging | 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 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.
OBD-II to UART Interface
Hardware Interface
UART Bus
Rx and Tx communication lines are used along with UART 2 connection which communicates between the SJOne board to UART. 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 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". Observe that the pins interfere with the UART 2 connection so adaptation to a different UART port is necessary.
We also used a UART to OBD board for interfacing the board with the vehicle.
Software Design
BUMP DETECTION
This feature was added to enable monitoring a driver’s behaviour. 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. Analysing 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.
Graphics LCD
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
We have used the uLCD-32PTU from 4D Systems. It’s a graphic LCD with a resolution of 240x320.
The LCD can be used for making quick GUI’s. We need the IDE which is available on the website to program the LCD.
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. 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.
2) ViSi: This mode is a combination of the 4DGL programming language assisted with drag-drop of objects.
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. 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.
I2C protocol is used to communicate between the LPC1758 and LCD screen. The screen displays 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 -
OBD Algorithm
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.
