S17: MyAutoHealth

From Embedded Systems Learning Academy
Revision as of 03:26, 20 May 2017 by Proj user12 (talk | contribs) (→‎Acknowledgement)

Jump to: navigation, search

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

Real-time vehicle diagnostics.

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.

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 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.

Team Members & Responsibilities

  • Manan Mehta
    • Interface Accelerometer and use appropriate algorithms to measure road dumps.
  • Pushpender Singh
    • Soldering and connecting OBD II Uart components.
    • Interfacing the serial port.
    • Acquiring OBD reading from the vehicle.
    • Translating received data to Graphs/meters.
  • Sameer Saran
    • Worked on LED display
  • Sanman Pradhan
    • Design a PCB to accommodate the various hardware components.
    • Schematic is being designed using EaglePCB.
    • The power supply circuit, designed to be the main power source, peripherals such as the LCD will be housed on the PCB.
    • Assist with interfacing and programming of the temperature sensor.
  • Shashank Iyer
    • Acquiring a temperature sensor that can operate in the full range of temperature swing that an average engine fluctuates between.
    • Using a sturdy standoff to ensure it is able to read values accurately from the air around the engine.
    • Supplying power to the sensor from the SJ1 board.
    • Processing sensor outputs through the onboard ADC to make them processor readable.
    • 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

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
6 04/25 Integrating OBD and Sensor code into tasks and PCB design In-progress
7 05/02 Testing and debugging
8 05/09 PCB Assembly and Testing Assembly- Completed, testing - In progress
9 05/16 Ready for Demo

Parts List & Cost

Give a simple list of the cost of your project broken down by components. Do not write long stories here.

Design & Implementation

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

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

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

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 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.Values acquired by accelerometer sensor.

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
Software IDE for Graphics LCD
which is very simple to use.


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. 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.

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.

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.

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.

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.

• Once you have interfaced the LCD using the USB to SERIAL cable now comes the fun part of making beautiful GUI on the LCD.

• After selecting the appropriate model of the LCD (uLCD-32PTU in our case), select the ViSi – Genie environment.

• 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 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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?

Steps to program the LCD:

• 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.

• 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.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.

• 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.

• 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?
Form Properties
We need to use those index numbers to address the object.


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

• 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).

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.

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.

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 )

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

• 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.

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

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?

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

List any references used in project.

Appendix

You can list the references you used.

Retrieved from "http://socialledge.com/sjsu/index.php?title=S17:_MyAutoHealth&oldid=36430"