Android Application To Check Your Car Performance (FYP)
TO SUBMIT YOUR OWN ARTICLE AND EARN MONEY CLICK HERE
FINAL YEAR PROJECT ( CAR HEALTH )
Number of cars is increasing day by day and taking good care of the car is becoming a bigger concern. Every one doesn’t have that amount of technical knowledge or skills to understand what is going on in the car, however if neglected the consequences maybe adverse. The car owners require some frequent updates of their car condition, way more frequent than the monthly visit to the car mechanic.
All modern cars have a computer attached inside which is further connected to different sensors placed in car by the car manufacturers. This computer, or the Engine Control Unit (ECU), takes decision regarding different tasks based on the data it receives from sensors. We take advantage of this data transfer and request the ECU to share the information with us so we may share it with the driver. To make this possible there is a port present in car, named the On Board Diagnostics two OBD-II port, that gives you access to the ECU. To this port we connect a Bluetooth module so we can transfer data wireless and show it to the user.
Other than displaying the data of inbuilt sensors, considering the traffic situation of our country, we have incorporated a driving assistance system. This system measures and shows the distance of your car form the nearby objects, this keeps you at a safe distance while driving and parking car.
To conceptually understand our project we may divide it in three parts, first of all is a Bluetooth module it needs to be connected to the On Board Diagnostics two (OBD-II) port present in all modern cars. By modern cars we refer to OBD-II compliant cars after the year 2009. After being connected to OBD-II port module is now internally connected to the car’s Engine Control Unit (ECU), ECU is the cars brain or computer taking decisions according to the response of the sensors attached to it. Second part is the Arduino board connected to six ultrasonic sensors. Arduino receives data from the sensors and sends it to the application by using a wired link. Last part is the android application, this application is responsible to communicate wireless with the Bluetooth module and serially communicate with the Arduino board.
Observing the data shown on the android application, the driver will be in a situation to draw results or get assisted in getting his car parked. The ultrasonic sensors are shown as indication lamps on the application as the distance from an obstacle is below a suitable predefined threshold the lamp changes its color to red.
Our project will provide continuous real time data, that is constantly being updated by communication with ECU or the Arduino board connected.
The client has an Electronic Fuel Injection (EFI) car and intends to keep it fault free all the time. When he visits his mechanic for the monthly tune-up, his car is declared perfect just after five to seven minutes of casual inspection. But it occurs occasionally that his perfect car gets heated up all of a sudden, gives sudden jerks and is standing in the middle of the road, doesn’t start when he needs it the most, is burning too much fuel etc. Mostly when the car is towed to the workshop the problem that has caused the break down was a small issue but left unaddressed now requires capital and time.
It is also difficult, by simply looking at the tire, to tell if the tire air pressure is appropriate or not? And it isn’t feasible to go to a tire shop every time you feel air’s going low in tire. Other than this parking car in a go has become a wish, several times the client has to get out and see how much space is left before he parks.
He wanted us to solve these problems by making a device that tells him the true condition of his car and assist him in parking. He should be able to use this device with not much technical knowledge in hand. The device should be easy to install and remove.
We had meetings with our client twice a month on average the details are:
|1.||26th August, 2016||· Introducing ourselves to the client
· Hearing the problem from the client
|2.||9th September, 2016||· Approval form our side to deal with and solve the problem
· Noting the exact issue and its details
|3.||23rd September, 2016||· Telling the client about our approach
· Approval from client’s side to start work on it
|4.||7th October, 2016||· Showing our progress to the client
· Request from client to generate expected cost
|5.||21st October, 2016||· Gaining more clarity on specifications
· Approval of calculated expected cost
|6.||4th November, 2016||· Telling client about the issue hindering our progress and how we plan to deal with the issue|
|7.||18th November, 2016||· Updating client with our progress|
All meeting were held at FAST-NU, Lahore.
To get a clear picture most important of the initial questions we asked the client was if the car he has or is expected to buy in future is, or will be, an EFI car? If the client is interested in keeping old cars like cars of eighties or seventies then the approach in our mind won’t work as that old cars don’t have the Onboard Diagnostics two port. Our Product specifications:
The Onboard Diagnostics two (OBDII) port:
- A 16 pin port
- Has some not all pins active, depends on manufacturer
- Introduced in all cars in year 2000, previously OBDI was used
- Cars after 2008 have the port in fully working and advantageous condition
- Located in the drivers locality, mostly below the dash board where the acceleration paddle is
|ELM 327 Bluetooth Module
· ELM 327 is available in different types and versions, we will be using the Blue tooth type and version 1.5a
· It is sized 1.5″ x 1″
· Works on 12V that is provided by car battery, no external wire is required but supply is given by OBDII port to which it is connected.
We will be required to make a mobile, android, application. Application once installed on your phone will detect the ELM327 plugged in your car and will show you the data from different sensors present. The application specifications are not yet decided.
The installation process of our product will be:
- The client will first have to locate the OBDII port in his car.
- He will install the ultrasonic sensors outside the cars and connect it with Arduino.
- After it he will have to start his car.
- Plug in the ELM327 module in the port, an indication light is present on the module if it is not lit it means the car’s port is not active and needs mechanic’s assistance to be activated.
- Turn on the phone’s Bluetooth and scan for ELM327, it might appear as OBDII port in your device.
- Add the device by pairing it.
- Start the application in your phone and start diagnosing.
- Ultrasonic sensor will be showing its data on the application through otg cable attached to our mobile.
After successfully connecting the application with your car the user may now start diagnosing. The application will give values of different sensors present in car from which the user can easily interpret the things going wrong. For example if the coolant temperature sensor is giving an unexpectedly high value it means the car is going to heat up or the radiator fan isn’t working well or the radiator has less water and it will be indicating that if car has safest distance from the hurdles around the car.
Our main competitors are various applications on the Play Store, for android users, and the App Store, for Apple users, the applications present are many. It isn’t possible to analyze all applications so we have to choose some among all. Our selection process depends on the application ratings. These are the average of the rating, out of five, provided by the people who have downloaded the application.
As told previously there are different types of ELM 327 available in market mainly: Bluetooth, USB and Wi-Fi. Many software are available that can be installed on windows, most of them have to be purchased and few are available for free which are too hard to find.
A lot of work has been done by the android application developers in our field of interest, after searching the play store we have found hundreds, an approximate count, of similar applications. Analysis of some of competitors:
|Application name: Torque Lite
Torque Lite is one of the competitors we found on the Play Store. Some of the key features were:
· It was the easiest to use
· Representation of two, small and medium, sizes were available.
· The data could be showed in form of a dial, graph or a display
· The Dials could be easily interpreted and units were made clear
· Data that could be obtained was: coolant temperature, intake air temperature, Speed, Acceleration, Engine Load, RPM, Throttle position, trip distance etc.
· A pro version is also available but it isn’t for free
FAST-NU pervious project
Other than these applications found over the internet, while looking in our university Library we found a project done by BS (CS) students. We studied the project report and saw it was more an application oriented project, we couldn’t find information regarding the cars they tested. As knowing the protocol isn’t a big deal, the issue comes when you have a car and don’t know the protocol it is using. Other than this no external sensors were used, just those present in car were used to obtain data or results.
|Application name: Car Fault Diagnosis
The name of the Application and the category of search under which it is coming is deceiving, as we explore the application it doesn’t turn out to diagnose your car itself. Instead it is as a book or a guide telling you what to do when a so and so problem occurs for example what to do when the battery fuse goes brown?
So it is hard to use as you have to read what possibly has caused the problem you are facing and what are the possible solutions, in addition you need to know the technical terminologies.
|Application name: Smart Control Free(OBD2 Auto)
The application has a very attractive interface, but it’s almost only concerned about the fuel related things like: it tells about the fuel remaining in tank, mileage (in liters per 100Km), the distance covered after refill maybe, the cost of fuel. A spreadsheet can be maintained keeping log of your fuel refills, other than this the engine load torque and power is also given.
|Application name: Piston (OBD2 & ELM327)
Simplicity is the key characteristic of this application data is arranged in rows stating name data and the unit. The application is quiet similar to “Torque Light” discussed above. Giving an option to view the battery voltage, engine load, fuel pressure, intake air temperature, throttle position and the oxygen sensor value etc.
|Application name: AutoCodes
A thing not discussed yet but plays a vital role is the Diagnostic Trouble Codes (DTC), some elaboration on DTC: DTC are five character alphanumeric codes the first character is always an alphabet and next four are numerical digits. There is a look up table made carrying a column of the codes and a column of how to interpret the code or what does the code mean. Some code *generalizations are:
‘xx’ are the two digit numbers,
This application takes care of DTC, as you enter a DTC it searches and tells you what it means and gives extensive details to make the issue clear, again it doesn’t connect to your car. The results for a particular code are many and may also contain some supporting material like videos from YouTube etc.
If we talk about the computer installable software, the distinguishing feature we have is portability. Surely it isn’t feasible to purchase a long wire and connect it between your PC and car. A smarter approach, using a laptop, won’t bring much ease as you need to have a delicate, bulky and expensive machine whenever you desire to scan your car. So the computer software will not be a preference.
If talking about the android applications: from the description stated above it is seen that, for example, some applications are good at maintaining the fuel record or others at giving details about the DTC.
For our project what we have is:
- Our application will provide constant logging of live data
- We will try designing a more user friendly interface
- If time permits we plan to make a cloud based record and updating for a busy user having multiple cars
In the hardware design, we connect additional (Ultrasonic sensors) sensors to car controlled by Arduino UNO. Arduino UNO is a microcontroller board based on the ATmega328. It has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a 16 MHz crystal oscillator, a USB connection, a power jack. Its operating voltage is 5V and recommended input voltage is 7-12 V. Its DC Current per I/O pin is 20 mA. Ultrasonic sensor emits an ultrasound at 40 000 Hz which travels through the air and if there is an object or obstacle on its path it will bounce back to the module. Considering the travel time and the speed of the sound we can calculate the distance. We install these ultrasonic sensors in vehicles. 
So, collectively six ultrasonic sensors will send data to Arduino UNO. We will use ultrasonic sensors two will be in front bumper, one on right side of the car, one on left side of the car and two in rear bumper. Operating voltage of each ultrasonic sensor is 5V DC and its maximum current consumption is < 2mA. These sensors send data to Arduino UNO microcontroller through wires which will manipulates the data.  Each ultrasonic senor has 4 pins i.e. trigger, echo, VCC, ground. Following table shows the hardware pin configuration of these sensors to Arduino
|VCC||External source||External source||External source||External source||External source||External source|
Arduino is connected to our application using Arduino cable.
Most of our time was spent on designing the project’s software. As we were totally new to android development and we were supposed to make an android application, we had to review a lot of online resources and tutorials.
To communicate with the ECU or ELM327 attached to the OBD-II port a Bluetooth connection was to be established. First a Bluetooth Adapter, device and socket was made. The adapter is simply the default Bluetooth adapter; device contains all the useful information about the device like its MAC address or name etc. For simplicity and following the convention of already existing applications we assumed that the phone’s Bluetooth is on and ELM327 is already paired, the pairing key being 0000. The Bluetooth socket is what that is to be connected with the other device; it is connected using the inbuilt function .createRfcommSocketToServiceRecord (uidValue). The 128 bit uidValue parameter passed is the Universally Unique Identifier (UUID), this is type of connection ID to be known to both devices being connected. This connection code is run in a thread, with appropriate check for handling exceptions. After a successful Bluetooth connection is, the user is notified regarding it.
With the connection established, next we start sending and receiving data. For sending purpose we have the function named sendDataToOBD, the message to be sent and the connected socket is passed as the two variables. The commands sent can be categorized as the AT commands or the OBD commands , the AT commands are for the ELM327 configuration and OBD commands are mostly the data requests sent to the ECU. The sending procedure is same for both type of commands but the way response is received or interpreted is different. The response of AT commands doesn’t carry and information to be presented to the user, but are confirmations the settings are successful. The AT commands we used are:
|Sr.no||Command||Description||Response from car|
|1.||ATD||Set all to defaults||?|
|2.||ATZ||Reset All||ELM327 v1.5a|
|5.||ATS0||Printing of Spaces Off||OK|
Table 1.0: showing the AT commands we used
These commands were run for once and served our purpose there is a complete set of around 120 different AT commands easily available on the internet.
Next and the most important AT command is the protocol command, there is a communication protocol used inside every car. There are four universally defined protocols used, with some having their subversions with minor variations. The protocols are:
|5 baud init ISO_9141_2||3|
|Fast init ISO_14230_4_KWP_FAST||5|
|11 bit ID, 500 kbaud ISO_15765_4_CAN||6|
|29 bit ID, 500 kbaud ISO_15765_4_CAN_B||7|
|11 bit ID, 250 kbaud ISO_15765_4_CAN_C||8|
|29 bit ID, 250 kbaud ISO_15765_4_CAN_D||9|
Table 1.1: Showing protocols, their subversions and integer to be passed in AT command
To know which protocol is being used in a particular car there are three ways, the first is the easiest but doesn’t tell the Sub-version: it involves locating the OBDII port of your car and viewing its connected pins and referring to the table shown below:
The second way is to use an AT command to know the protocol, the command is ATDP. This sends the protocol in form of a string. After knowing the protocol being used we send out last AT command which is: ATSPx, where x is an integer we get from table 1.1.
After the configuration being done we are ready to send the OBD commands, sending an OBD command basically means sending the Parameter Identifier (PID) of the sensor we want data from. The PID is a 16bit instruction sent in hexadecimal form, the first two hexadecimal digits define the mode of operation and the different modes are:
As we are interested in knowing the current data our first two hexadecimal digits will be fixed to 01(hex). The next two hexadecimal digits vary from 00-C4, each pair having a unique purpose. Some examples of PID and their details are:
After sending the PID we get a response from the car, for example if we send the PID 0105(PID for coolant temperature) we won’t get a number that can be displayed to the user but is a string having the structure:
This is received as string but was sent in hexadecimal form, the first byte is the success code it remains fix, next byte is the PID you sent received without the mode. Last four bytes is the data we are interested to show, data can be of size one to four bytes depending on the PID sent. Once received the data needs some processing, the processing steps are:
- Separate each byte from the string
- Convert each byte to decimal
- Apply the formula shown in Table 1.3
- Show it to the user
To separate the bytes we us the function substring(int beginIndex, int endIndex) this returns a string that contains the element of the original string between the indicated indexes. Then to convert to decimal we use the function integer.parseInt. Referring to the PID table we apply the formula and show data to user
For ultrasonic sensors, we connect the sensors with Arduino and Arduino was connected to mobile phone through Arduino cable and OTG. In code, we initialized 12 pins for every ultrasonic sensor 4 pins were required i.e echo, trigger, VCC and ground. Following are the pins configuration we did in our code for each ultrasonic sensor. VCC and ground are described hardware design.
To calculate the distance of the obstacles in code first of all we set the trigger pin high for ten micro-seconds so that it would send out eights cycle of sonic burst towards the obstacles and then we set the trigger pin to low at the mean time the echo pin is set as high and it receives the sonic burst and calculate the distance at the speed of sound and to get the time taken for one way of the burst by dividing the duration taken by the burst coming back to echo by 2. To convert the distance in centimeter we divide it by 29.4.This is how we get the distance for one ultrasonic sensor and in order to get the distances of 6 ultrasonic sensors we have used this functions six times. Then this data is send to our mobile application using Arduino cable where it receives the data. In the application we have used the thresholds to indicate whether the car has safe distance from the obstacle or not. Following are the thresholds we set.
|Green||Safe||Greater than 90 cm|
|Blue||Warning||40 cm to 90 cm|
|Red||Stop||Less than 40 cm|
|Car Tested: Toyota Belta|
· Model 2012
|Test Results: Connection successful, showing data
|Car Tested: Honda City|
· Model 2016
|Test Results: Connection successful, showing data
|Car Tested: Honda FIT|
|Test Results: Connection successful, showing data
Please follow the following steps to use our product;
- Please ensure you have an OBD-II compliant car
- Start your car engine
- Plug in the ELM327 after locating the OBD II port
- Install the ultrasonic sensors
- Connect it with Arduino
- Connect the mobile application with Arduino using Arduino cable
- Turn on phone Bluetooth and pair the ELM327 before launching application
- Launch the application and get live data
Some things to be taken care of:
- Please ensure you have an OBD-II compliant car
- The lights on ELM327 should get lit after you plug it in your car
- Ensure your phone is of android version later than 4.0
- Ensure that your phones Bluetooth is working fine
- Ensure that ultrasonic sensors are installed at correct location
The client will be given:
- An android application
- Ultrasonic sensor
- ELM327 Bluetooth module
- Controller (Arduino)
|Sr.no||Name||Quantity||Price per item||Total|
|Sr.no||Name||Quantity||Price per item||Total|
The objectives set were achieved to an extent that we successfully extracted data from the car, however we are not displaying data from each and every sensor as the same procedure is to be followed for each sensor. We couldn’t analyze the data to predict some trends or to generate some alarms we leave it up to the driver to interpret the data and use it accordingly.
We successfully interfaced the proximity sensor.
Figure 1 http://mechanics.stackexchange.com/questions/23047/obd-ii-power-when-key-not-in-ignition
Figure 3 Play store
Figure 4 Play store
Figure 5 Play store
Figure 6 Play store
Figure 7 Play store
|DTC||Diagnostic trouble codes|
|OBDII||On Board Diagnostics two|
|ECU||Engine Control Unit|
|EFI||Electronic Fuel Injection|
|VCC||Voltage at the Common Collector|