F14: Team2-Self Driving Car - AUG

Self Driving Car

Abstract

This report focus on creating self navigating RC car. The project is implemented using SJOne board which has Cortex-M3 LPC1758 controllers on it. It uses CAN bus protocol to communicate between six different nodes( SJOne board ) which are connected through CAN bus. Various modules are Master controller, motor controller, Geo module, sensor controller, Display controller and android bluetooth bridge. The navigation direction is being provided by GPS android app over bluetooth.

Based on the source and destination coordinate values, Geo controller computes the difference between car heading (current direction) and bearing (required direction). Based on the difference value, master drives the motor controller to the destination. Intermittently any obstacles are avoided based on the sensor controller data indicating obstacle.

Objective and Scope

Objective

The objective of this project is to demonstrate and implement the learning of CMPE243 Embedded System class. Other objective was to prepare students according to industry standard by facilitating industry like training. To accomplish this, a team of 16 person were divided into six sub teams which were responsible for individual modules. It also facilitates the learning of GIT Lab repository for code version control and synchronization.

The technical objective was to learn and implement various hardware/software modules like CAN Bus, GPS module, Compass module, Display , Sensors, power unit and Bluetooth module. It also facilitates implementation of various communicating protocols like GPIO, UART, I2C, SPI , PWM , CAN. In nutshell the real objective was to prepare engineers for real life challenges.

Scope

The scope of this project is limited to developing self navigating car for education use only which should be tested under proper supervision.

Team Members & Responsibilities

 Sensor Controller-
   Amey Patil 
   Sujith Durgad 
   Arvind Allawadi 
 Motor Controller and Power- 
   Digvijay Patil (Master Documentation)
   Rohan Jani 
   Mahesh Chudasama 
 Display-  
   Mradula Nayak
   Karthik Govindaswamy
 Communication Bridge + Android-  
   Siddhata Patil 
   Mohammed Raashid Kheruwala 
   Huzefa Siyamwala
 Geographical Controller-
   Yash Parulekar 
   Ajinkya Khasnis 
   Harsh Lavingia
   Anand Dumbre
 Master Controller- 
   Pradyumna Upadhya

Introduction

System block diagram

System Block diagram

Overall Algorithm

  1. GPS co-ordinates is sent from Android app to Android controller through bluetooth interface.
  2. Android Controller sends these co-ordinates to GPS+Compass controller
  3. START  command is sent from Android app to Android controller, which in turn sends START can command to Master controller.
  4. Master controller sends START can command to Motor, Sensor, IO, GPS+Compass controllers.
  5. When controllers get START command they subscribe to other boards at either 1,5,10,20,50Hz. 
  6. All the boards start calculating required can message values and publish subscribed messages data at subscribed frequency.
  7. All the boards receive the new published data.
  8. Steps 6 to 8 continue until STOP command is sent from Master(which in turn receive it from Android app)or destination reached 
     message is got from GPS+Compass controller to master.
  9. Master subscribes to Sensor and GPS+Compass controllers to keep getting new data at any of above mentioned frequency.
 10. Motor subscribes to Master to get car movement direction,speed message at any of above mentioned frequency.
 11. IO subscribes to Sensor, GPS+Compass controllers to get display data.
 12. GPS+Compass controller calculates current direction and required direction for given moment and sends this data to Master. Master 
     checks sensor values and if there are no obstacle moves as per required direction given by GPS+Compass. If there are obstacles then
     it moves to avoid the given obstacle.
 13. Steps 12 keeps repeating until required co-ordinates are reached.

Schedule

Common Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	9/16/2014	10/7/2014	Finish Ordering project hardware parts	Completed.	11/10/2014
2	10/5/2014	10/21/2014	Fine tune subscriber code	Completed	10/28/2014
3	10/7/2014	10/21/2014	Finish Development of CAN Transceiver boards	Completed	10/25/2014
4	10/5/2014	11/4/2014	Sub teams finalize and implement dependency code(atleast single API per team)	Completed	10/28/2014
5	10/5/2014	10/28/2014	Finish hardware	Completed	10/27/2014
6	10/28/2014	12/2/2014	Start integration and testing.	Scheduled	12/19/2014

Master Team Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	9/30/2014	10/21/2014	Fine tune subscriber code and finalize CAN apis required from other boards	Completed	10/21/2014
2	10/5/2014	10/21/2014	Fine tune subscriber code	Completed	10/27/2014
3	10/5/2014	10/21/2014	Develop CAN Transceiver Board	Completed	10/19/2014
4	10/5/2014	11/4/2014	Implement API co-ordination logic and test with other boards APIs	Completed	11/20/2014
5	10/21/2014	10/28/2014	Test hardware with master code and motor code.	Completed	10/26/2014.
6	10/21/2014	11/4/2014	Integrate master with motor and sensor.	Completed	11/3/2014
7	10/28/2014	11/11/2014	Integrate master ,motor,sensor with andriod.	Completed	11/10/2014
8	10/28/2014	11/11/2014	Integrate master with display.	Completed	11/10/2014
9	10/4/2014	11/11/2014	Integrate master with compass and gps.	Completed	11/20/2014
10	11/4/2014	11/18/2014	Fix integration bugs and fine tune boards initialization and communication.	Completed	11/15/2014
11	11/11/2014	11/28/2014	Implement car movement logic as per GPS/COMPASS/Sensor data.	Ongoing	12/19/2014
12	11/28/2014	12/10/2014	Test hardware/software to remove bugs and fine tune algorithm.	Ongoing	12/19/2014

GEO Team Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	9/16/2014	9/23/2014	Decided and then ordered GPS modem Received Compass module	Completed	9/23/2014
2	9/23/2014	9/30/2014	Acquired GPS modem Interface Compass with SJOne Board via I2C	Completed	9/30/2014
3	9/30/2014	10/7/2014	Designing GPS driver Test code to get compass heading information	Completed	11/08/2014
4	10/7/2014	10/21/2014	Integration of GPS with the main board CAN RX task and subscription handling	Completed	11/23/2014
5	10/21/2014	11/04/2014	Test communication with the Master Determine final heading using GPS location and compass reading	Completed	11/25/2014
6	11/04/2014	11/18/2014	Test and debug, Make necessary changes in the driver Compass Calibration	In Progress	12/19/2014

Motor Team Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	9/30/2014	10/7/2014	Understand the SERVO and DC motor controller signals	Completed	10/4/2014
2	10/4/2014	10/11/2014	Interface SJSU one board to SERVO and DC motor controller	Completed	10/10/2014
3	10/7/2014	10/18/2014	Develop CAN transceiver boards	Completed	10/12/2014
4	10/12/2014	10/26/2014	Design and Develop unified power distribution circuit and hardware structure for RC car	Completed	10/25/2014
5	10/19/2014	11/03/2014	Interface motor SJSU board with master SJSU board for motion tuning	Completed	11/03/2014
6	10/26/2014	11/07/2014	Redesign mechanical structure and fix wiring issue	Completed	11/08/2014
7	10/19/2014	11/07/2014	Work on shaft encoder for motor speed feedback	Completed	11/14/2014
8	11/01/2014	11/11/2014	Work with other teams to establish reliable CAN communication.	Completed	11/11/2014
9	11/07/2014	11/30/2014	Fine tuning of turning curves, jerks, acceleration and deceleration algorithm.	Completed	12/12/2014

I/O Team Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	9/16/2014	9/23/2014	Decided and then ordered display module	Completed	9/23/2014
2	9/24/2014	10/7/2014	Setting up the GIT	Completed	10/14/2014
3	10/7/2014	10/14/2014	Basic display on LCD with UART interface	Completed	10/23/2014
4	10/14/2014	10/28/2014	CAN communication between Master and I/O	Completed	10/28/2014
5	10/28/2014	10/31/2014	CAN communication between I/O and sensor	Completed	11/02/2014
6	10/31/2014	11/4/2014	CAN communication between I/O and GPS	Completed	11/02/2014
7	11/5/2014	11/9/2014	Logic for No. of CAN messages/sec, LED's for Start, CAN Tx,CAN Rx	Completed	11/18/2014
8	11/9/2014	11/15/2014	Mount LCD on board on CAR and Final testing	Completed	11/30/2014

Sensor Controller

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	10/3/2014	10/10/2014	Developing a Test code for sensors	Completed	10/14/2014
2	10/10/2014	10/17/2014	Finalizing on the sensors	Completed	10/14/2014
3	10/17/2014	10/24/2014	Transfer of sensor data via can bus to master	Completed	10/21/2014
4	10/24/2014	10/30/2014	Implementation with multiple sensors	Completed	10/30/2014
5	10/30/2014	11/24/2014	Testing the implementation for multiple sensors and debugging the issues.	Completed	11/28/2014
6	10/24/2014	11/25/2014	Implementation of Light sensor and accelerometer sensor.	Completed	11/30/2014
7	12/01/2014	12/17/2014	Optimizing the code and testing for stability and report.	Completed	12/19/2014

Communication Bridge + Android Team Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	9/16/2014	9/23/2014	Design UI of the Android App	Completed	9/23/2014
2	9/23/2014	9/30/2014	Interface and pairing the Android App with Bluetooth module	Completed	9/30/2014
3	9/30/2014	10/7/2014	Implementation of first stage of Android App (Frame 1: Sending data via Bluetooth to give directions for the car)	Completed	10/4/2014
4	10/7/2014	10/14/2014	Implementation of Bridge between Android and UART	Completed	10/16/2014
5	10/14/2014	10/28/2014	Implementation of second stage of Android App (Frame 2: Create on click function to give Start and End coordinates for the car)	Completed	10/28/2014
6	10/28/2014	11/11/2014	Implementation of third stage of Android App (Frame 3: Navigation path using markers and CLL coordinate system, START button and STOP button)	Completed	11/15/2014
7	11/11/2014	11/25/2014	Testing and improving the UI of to the App	Completed	11/25/2014

Parts List & Cost

Qty	Description	Manufacturer	Part Number	Total Cost
6	Ultra Sonic Sensor	Arduino	HC-SR04	12.58
7	Ultra Sonic Sensor mounts	e-bay	N/A	32.52
1	Compass Module	Honeywell	HMC6352	Provided by Preet
1	GPS Receiver	MediaTek	LS20031 5Hz (66 Channel)	$59.95
1	GPS Antenna	V.Torch	VTGPSIA-3	$11.95
1	RC car	Traxxas	1/10	$272
1	Bluetooth module	SunFounder	HC-05	$7.99
1	LCD Display	Given by Preet	SJValley Engineering	Provided by Preet
6	CAN Tranceivers(Free Samples)	Microchip	MCP2551	Samples (no cost)
1	Xbee Module	Digi international	PRO 802.15.4	$19
1	IR Sensors	VISHAY	TSOP1238	$2
1	NIMH Battery for logic circuitry	Tenergy	7.4v,3000mAh	$27
1	Traxxas Fast charger	EZ-Peak PLUS	6Watts,6A	$98
1	Voltage Regulator, Capacitor(Miscellaneous)	7805	N/A	$1
1	Acrylic Sheet	Home Depot	N/A	$14.02
1	Hardware parts (studs, screws etc.)	HSC electronics	N/A	$32
1	Connectors(Female to Female)	Anchor electronics	N/A	$110

Backup Parts & cost

Qty	Description	Manufacturer	Part Number	Total Cost
1	LIPO motor battery	ONYX-Duratrax	7.4V-5000mAh-25C	$62

We didn't have any back up of Geo sensors, we will suggest to have one, as we faced this issue in our final demo.

Design & Implementation

Controller Communication Table

Controller ID Table

Controller ID	Controller
0x050	Master Controller
0x051	Geographical Controller
0x052	Motor Controller
0x053	Sensor Controller
0x054	IO Controller
0x055	App/Bridge Controller

Master Controller MessageID Table

SubscribeID	Description	PublishID	Description
0x42A	Subscribe to new motor data to be set	0x52A	Publish motor data (Response of 0x42A )
0x44A	Subscribe to new input/output data	0x54A	Publish data to be displayed (Response of 0x44A )
0x45C	Subscribe to reliable sensor value (sensor data from sensor through master)	0x55C	Publish reliable sensor value (Response of 0x45C)
0x45D	Subscribe to current location data (GPS data from Master through GPS)	0x55D	Publish current location data (Response of 0x55D)
0x44A	Subscribe to display data (api to be used by display to get new display data)	0x54A	Publish new display data (Response of 0x54A)
Master Specific MessageID	Description	ResponseID	Description
0x312	Start (master specific command)
0x313	Stop (master specific command)

Geographical Controller MessageID Table

SubscribeID	Description	PublishID	Description
0x40C	Subscribe to Heading Data and Compass Data from GPS+Compass controller	0x50C	Publish Heading Data and Compass Data Data (Response of 0x40C )
0x44A	Subscribe to heading and bearing Data(I/O unit subscribes	0x54A	Publish heading and bearing Data (Sends data to I/O unit)
Geo Specific MessageID	Description	ResponseID	Description
0x353	Waypoint Latitude Received (Geo specific command)
0x354	Waypoint Longitude Received (Geo specific command)
0x355	Waypoints Transmission complete (Geo specific command)

Motor Controller MessageID Table

SubscribeID	Description	PublishID	Description
0x40B	Subscribe to Motor Data	0x50B	Publish Motor data(Response of 0x40B)

Sensor Controller MessageID Table

SubscribeID	Description	PublishID	Description
0x40A	Subscribe to Sensor Data	0x50A	Publish Sensor Data (Response of 0x40A)

IO Controller

SubscribeID	Description	PublishID	Description
0x40A	Subscribe to IO Data	0x50A	Publish IO Data (Response of 0x40A)
0x44A	I/O unit subscribes to sensor data, compass data, android data	0x54A	The respective boards unit sends data to I/O unit

Android and Bridge

SubscribeID	Description	PublishID	Description
0x45A	Subscribe Start/Stop command(IO data to Master)	0x55A	Publish "start" message (response of 0x312)
0x45B	Subscribe GPS longitude and latitude (Android GPS data to Master)	0x55B	Publish current location (response of 0x45D)

Hardware Interface

The hardware communication-

SJOne to CAN-Tranceiver connections are made as follows-

CAN Transceiver Schematic-

Above circuit shows CAN Bus transceiver circuit schematic. The schematic is created using EAGLE PCB layout editor tool which is free and easily available online. It wan be downloaded from http://www.cadsoftusa.com/download-eagle/ website. The tool consist of Schematic editor and Layout editor. As shown in main block diagram, we are using six node system but for scalability purpose the CAN hardware is made for eight node system. Tx and RX pins of all the CAN transceiver ICs has to be connected to CAN bus. Dont forget to put 120 Ohm terminating resistor at the end of two nodes.

The can transceiver ICs are from microchips semiconductor MCP2551. The samples of these ICs can be obtained from microchip website where you can get 12 samples for free. These ICs operates at 5V and can be driven by external 5V power supply. These ICS are pretty stable and reliable but still we faced a problem with CAN hardware IC once. So make sure to implement CAN Bus off functionality in the software. You can also buy available CAN modules which operates at 3.3 V. The advantages of using these CAN modules are that, those are compatible with SJOne board which also operates at 3.3 V. These modules can cost up to $5 for one module but it can save a lot of time in designing hardware.

The schematic also shows the desing of 5V power supply for entire circuit. Schematic shows various components of power supply unit including filter capacitors. Power unit would be seperately described in below section.

Motor controller

Fig : Motor Controller and peripheral interface

Above circuit shows the connection diagram of motor controller with it's peripherals. SJOne motor controller is responsible for driving car forward and backward using back DC motor while it can drive the car right and left using servo motor. Both the motors are driven through onboard motor driver as shown in below diagram which can guide both the motors based on PWM signal received from Motor controller SJOne board. PWM signal of 100 Hz is generated with the duty cycle varis from 10% to 20% for various functions using pwm0 and pwm1. PWM0 is connected to Back motor while pwm1 is connected to front servo motor.

The motor speed and angle of direction can be changed by changing the duty cycle of this PWM cycle. The signnal range is shown in the diagram attached below. So car would run at max speed which is 30 mph with duty cycle of 20% and it would go in reverse direction when its signal duty cycle is between 11% to 15%. Car would be at rest when both front and back motor signal is at 15%. For front motor , car will turn right when duty cycle is greater than 15% and it would turn left when duty cycle is less than 15%. Note that none of the controller signal should exceed the given limit. Also note that, the voltage level requied for motor contrller is 3.3 V which is also compatible with SJOne board.

controller_waveform

Reveiver pin connections

As shown in above figure , the SJOne motor controller board can be connected to receiver pins as shown. pwm0 is connected to signal pin of receiver ch 3 which drives the main dc motor for forward and backward movement where as pwm1 is connected to signal pin of receiver ch 1 which drives the servo for turns.

CAR body and various parts

CAR Chassis and Mechanical assembly :

The car chassis and its various parts are shown in the diagram. It shows default components and parts on the car chassis. For our project we have to mount various additional components like Six different SJOne board, Power supply unit, CAN bus hardware, GPS module , compass moudle , ultrasonic sensors and LCD display module. Given chassis does not have enough space to accomodate and mount all of these hardwares and hence we decided to use another platform which is raised above chassis level by using studds and acrelic sheet. To mount all of these, we also had to struggle with drilling hole in chassis for mounting new assemble, space constraint and keeping assembly compact. We used stacked approach to fit the assembly within a available space. So we mounted power unit and CAN board on bottom side of acrelic sheet where as SJOne boards were mounted one on top of other on the top side of the sheet. Deciding on the mechanical design and mounting is one of the most crucial part of this project which decides the easiness or difficulty level going forward. Investing time in design and mounting would pay going forward. Making robust hardware can save lots of time going future which could be invested in debugging. To get the mechanical work done, you can make use of Techshop which is located on 2nd street and San salvador st. or you can go to mechanical department to get your work done.

Power Circuit Design

Designing a power unit require a thorough research and good understanding of electrical characteristics of the electrical network. To get the required specification, one can take a pen and paper to calculate the required power rating and same can be verified by connecting an Ammeter in series with external power supply while running the circuit on full load.

The power requirement has to be fulfilled from the on board circuit and hence using efficient power regulator is desirable. For embedded applications, LIDO ( Low Input Drop Out ) power regulators are more desirable which has less power dissipation compared to other linear regulators like 7805 which has power dissipation of up to 30 to 35%. One can use LITO ICs such as LT1085CT-5 power regulator which can withstand up to 3Amps. These ICs allows the power unit to operate up to the battery voltage as low as 6.5V and hence the circuit can function properly for long time.

One of the biggest drawback of using Linear power regulator like 7805 is that, it needs minimum input voltage of 8V to generate constant 5v output and hence as soon as battery voltage falls below 8 , regulator output starts fluctuating and it fails to provide sufficient current to drive the sensor an display. Unfortunately we had designed power supply with 7805 in the very beginning stage which cost us many difficulties while doing testing and debugging.

Regulator IC: LM7805

Electrical characteristics

Input voltage Vo = 7-25v
Output current Io= 500mA-1A

LM7805 is a standard linear voltage regulator that gives a steady output of 5 volts with operating conditions of

 Vin-Vout  ≥ 2V with Vin ≥ 2Volts 

The leakage/ ground current Ig≤ 10mA. When used in its load line mode, Lm7805 provides protection against internal surges The output capacitance Co is used to provide a steady transient response and protects against voltage/current peaks . Hence instead of 0.1uF, 10uf is used for C=i∂v/∂t ( Hence of the surge is lost is charging the cap )

Another alternate solution would be to use a Low Dropout regulators LDO's have a low voltage drop (i.e 0.3V ≤ Vin-Vout ≥ 1.2 V) but that comes on the cost higher ground current is 30mA ≤ Ig ≥ 60mA) Here as current is important for it gets distributed on the load lines we have used Standard Voltage regulator. Hence a quasi LDO or a standard voltage regulator is advised.

Battery and Charging Circuit

Battery comparison

Lithium Polymer battery ( LiPo )	Nickel Metal Hydride battery( NiMh )
7.4V 5000mAh 2s lipo pack	6 x 1.2v Tenergy sub C 3000 mAh
Costlier than Nimh	Cheaper than Lipo
Provides a steady output of 7.2 volt over a larger time span	Has a faster discharge rate
Discharges below 6Volts in approx 70mins	Discharges below 7Volt in 45-55mins
Special charger is required which has feedback control	Can be charged with a normal charger

Software Design and Implementation

Master controller

Subscription Publish Algorithm

Main Workflow

In our project controllers need data from other controllers at regular intervals of time. This requirement can be written in software through Subscription Publish Algorithm. The main idea of this algorithm is that Board A can get periodic messages from Board B by subscribing to Board B after startup only once and after that it keeps getting new data for the subscribed can message id at subscribed frequency. For our project subscription can be done at only 1,5,10,20,50Hz and if any other frequencies are tried it will mapped to of these frequencies depending of its nearest value i.e Board A can subscribe to Board B at any of above frequencies for given CAN ID. Once Board A sends subscription message for can id say A1_ID at say 5Hz board B adds a A1_ID entry and then starts sending can data of A1_ID at 5Hz. There is a separate TX task for these frequencies which sends new published data for all the entries of respective tasks.

SendTask Workflow

Rx and Tx Tasks

Master has one task to receive all the can messages and one task to send can messages. Page "http://www.socialledge.com/sjsu/index.php?title=Self-driving_Car" gives good explanation of canid and can message distribution.
Whenever Rx task receives 400 series messages i.e subscription messages it checks if entry for given can id has already been done in its respective subscription list. If it is a new message then new entry will be done otherwise it is ignored. When 500 or 300 series messages are received then data of can message is saved and used according to our alorithm. Tx task is used to send can message from one board to another board. Also, subscription tx tasks are used to publish data at any of above mentioned frequencies.

RxTask Workflow

Master decision making algorithm

  Declare default speed and turn
   If 
     there is any obstacle in front of any sensor move as per ultra-sonic sensor data
   else 
     move as per Geo-sensor data

Ultrasonic sensor movement logic

  If front sensor not blocked
     GO STRAIGHT
  else if left sensor blocked and right sensor unblocked
     GO RIGHT
  else if right sensor blocked and left sensor unblocked
     GO LEFT
  else if back sensor unblocked
     SEND change direction message to motor
     GO BACK
  else 
     STAND STILL

Geo sensor movement logic

  If required degree value has stop flag 
     STOP (destination reached)
  else if absolute of(Current compass degree - Required compass degree)> 40 degree and (current degree < required degree)
     GO RIGHT
  else if absolute of(Current compass degree - Required compass degree)> 40 degree and (current degree > required degree)
     GO LEFT
  else 
     GO STRAIGHT

Android and Bridge

System Diagram

Complete System Diagram for Android communication

The above System Diagram shows the overall connection of the SJOne board and the HC05 bluetooth module. The module has 4 pins labeled on the back, VCC, GND, TXD and RXD. You might buy a module with two more pins KEY and STATE but it won't matter if you leave them open. The communication for configuration of the module is based on AT commands. There is one command for every thing, to set the device name, set the pin, set the baud rate and much more. All you have to do is to save these AT commands in the form of string and send each byte serially to the module using a simple for loop. Initially the baud rate is set to 9600. Following table shows few of the AT commands which you may require.

Command	Response	Use
AT	OK	Used to verify communication
AT+NAMExyz	OKsetname	Sets the module name to “xyz”
AT+PIN1234	OKsetPIN	Sets the module PIN to 1234
AT+BAUD1	OK1200	Sets the baud rate to 1200
AT+BAUD2	OK2400	Sets the baud rate to 2400
AT+BAUD3	OK4800	Sets the baud rate to 4800
AT+BAUD4	OK9600	Sets the baud rate to 9600
AT+BAUD5	OK19200	Sets the baud rate to 19200
AT+BAUD6	OK38400	Sets the baud rate to 38400
AT+BAUD3	OK4800	Sets the baud rate to 4800
AT+BAUD4	OK9600	Sets the baud rate to 9600

This bluetooth module requires 5V. Its Rx is connected to Tx of SJOne board and its Tx is connected to Rx of SJOne board with a common ground. We need bluetooth module in order to establish communication between the SJOne board and the Android Phone. In order to do this, code for bluetooth pairing, connecting and transmitting was thus written on Android SDK. There are three main tasks on the Android side :

1. To send location coordinates (latitude and longitude) to GPS.
2. To transmit "START" signal to the master.
3. To transmit "STOP" signal to the master.

At the receiver, this data will be received by the Bluetooth Module and provided to SJOne(Android board) via UART. Then via CAN communication its passed on to the Master and GPS boards.

Software Developing Environment

Android SDK

The software developing Environment used for Android was Android SDK and for bridge we used Free RTOS. To develop an Android App for our self driving car, the first thing we needed was a proper connection between the Bluetooth module and our Android phone. For this we used the Bluetooth APIs available like Bluetooth Adapter, Bluetooth Device etc. Here the Bluetooth Adapter is used as the first step to setup the Bluetooth connection and to verify if the bluetooth is supported or not. The Bluetooth Adapter is returned when we call static BluetoothAdapter.getDefaultAdapter(). Secondly, it is very important that you enable the Bluetooth and this is done by calling startActivityForResult(). According to your requirement you can either use BluetoothAdapter.ACTION_REQUEST_ENABLE or BluetoothAdapter.ACTION_STATE_CHANGED. Third Task is the Discovery, for this we have to call startbtAdapter.startDiscovery(). Next Task is to scan the devices available for Pairing. This is done by BluetoothAdapter.ACTION_DISCOVERY_STARTED and BluetoothAdapter.ACTION_DISCOVERY_FINISHED. And if nothing is happening check if the Bluetooth is ON if not turnOnBT(). Next task is to pair the Devices. This is done by calling btAdapter.getBondedDevices(). This will return already paired devices with the Android Device you using. Next step is to connect the devices which are not already paired. These devices are paired by entering the password for the device. Next step is to initiate a Bluetooth Connection for sending the data. For this simply copy the code for "private class ConnectThread extends Thread" from the Bluetooth|Android Developer site. Final task is set the UUID to "00001101-0000-1000-8000-00805F9B34FB" and you are good to go. It is very important that you add Permissions in the Android Manifest.xml. The permissions that we used were:

   <uses-permission android:name="android.permission.INTERNET" />
   <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
   <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
   <uses-permission android:name="com.google.android.providers.gsf.permission.READ_GSERVICES" />
   <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
   <uses-permission android:name="android.permission.BLUETOOTH"/>

Developing an Android App

Android App : Stage 1

Android App : Stage 3

Android App : Stage 2

The very first stage was to create a Map fragment. For this we decided to go with the Google Map API V2. For this we need the "Google Play services" . To install this package go to Android SDK Manager, click on Google play services and click on install package. Once the package is installed, we have to import this library. After this we need to add the googleplay_services_lib to our project. To do this, goto Properties -> Android -> Click on the googleplay_services_lib -> Click on Add. In MainActivity.java import the following:

    import com.google.android.gms.maps.GoogleMap;
    import com.google.android.gms.maps.MapFragment;

Now add all the required permissions to your project

   <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
   <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
   <permission
       android:name="siddhata.patil.sdc243.permission.MAPS_RECEIVE"
       android:protectionLevel="signature" />

Next step is the SHA1 fingerprint key. Goto Mac / Windows -> Preferences -> Android -> Build -> Copy the given SHA1 fingerprint key. Now go on the Internet and search for API Console - Google code. This is Google Developers Console. On left hand side you will see Services -> turn the tab ON for Google Maps Android API v2. Now again go on the left hand side and you will find API Access. Click on that. Generate new key -> Paste the copied SHA1 key ; "your package name" -> Click on Create. Your API key will be generated. Now copy this API key and paste this in your AndroidManifest.xml.

         <meta-data
           android:name="com.google.android.gms.version"
           android:value="@integer/google_play_services_version" />
         <meta-data
           android:name="com.google.android.maps.v2.API_KEY"
           android:value="Paste you API key" />

Now for the UI, under Activity_main.xml, we need to create a map fragment in Relative layout.

  <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
   xmlns:tools="http://schemas.android.com/tools"
   xmlns:map="http://schemas.android.com/apk/res-auto"
   android:id="@+id/LinearLayout1"
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:orientation="vertical" >
   <fragment  
         android:id="@+id/map"
         android:layout_width="match_parent"
         android:layout_height="match_parent"
         android:name="com.google.android.gms.maps.MapFragment"
         />

Now, for the second stage of our Android App, we had to create an On click function to select the Start and End coordinates for our car.

   public void onMapLongClick(LatLng point) 
   {
    AlertDialog.Builder setPasswordDialog = new AlertDialog.Builder(this);
    setPasswordDialog.setTitle("243SDC_Team 2");
    setPasswordDialog.setMessage("Coordinates for the car:"+ String.valueOf(point.latitude) + " , "
    + String.valueOf(point.longitude));
    setPasswordDialog.show();
      if(isStartDone==0)
      {
      SANJOSE1 = new LatLng(point.latitude, point.longitude);
      Log.d("ADebugTag", "Setting Start Point");
      isStartDone=1;
      }
      else
      {
      Log.d("ADebugTag", "Setting End Point");
      SANJOSE2 = new LatLng(point.latitude, point.longitude); 
      }
    }

Now for the third and the last stage of our Android Application, we had to add three buttons for the UI.

1. Navigation Button - This button gives us a red color path between the selected Start and End coordinates.
2. Start Button - Once the Start button is pressed, all the coordinates of the desired path are sent to the GPS board a character "a" is sent to the Master board indicating a start signal.
3. Stop Button - Stop button sends character "z" to the Master board indicating a stop signal.

As you can see in the above picture, we have inserted extra waypoints for a better accuracy. The Google Api gives us only the start and end coordinates of the path, but we decided to calculate multiple waypoints and hence programmed our App accordingly.

Sensor Controller

HC-SR04 Ultrasonic Sensor Features

• It is a four pin ultrasonic sensor. Four pins being; supply, ground, trigger and echo.
• The module is composed of; ultrasonic transmitter, ultrasonic receiver, and control circuit.
• It is a non-contact obstacle detector.
• Range of obstacle detection is from 2cm to 400cm.
• Requires, 5V 15mA supply.
• 15 degrees of measuring angle.

HC-SR04 Working Principle

Timing Diagram

• When a short 10uS pulse is provided to the trigger input, the module will send out an 8 cycle burst of ultrasound at 40 kHz and make its echo pin a logic high.
• The Echo pin is lowered to logic low when the ultrasound burst is reflected off a distant object.
• Now, the width of this pulse on the echo pin is in direct proportion with the distance of the obstacle.
• Timing diagram for all these signals is shown in the above figure.

HC-SR04 Distance Calculation

Actual Distance

• We know, speed of sound is 340m/s.
• In our sensor, ultrasonic sound waves needs to travel twice the distance of the obstacle as shown in the above diagram.
• From the pulse width, we know the time required to get an echo.
• For example, let us assume the time required to get an echo is 10msec, the following image shows how the distance is calculated.

Distance calculation

Hardware Implementation

• As shown in the image below, we are connecting six such ultrasonic sensors.
• The front three and rear sensors are for obstacle detection, while the middle two sensors are for edge detection.
• All trigger and echo pins are directly connected to the hardware pins of SJ-One board.

Sensor Block Diagram

Software Implementation

• We are using hardware timer 0 for calculating time between trigger and echo of all six sensors.
• All the sensors are triggered in sequential order to avoid interference from one another.
• The flowchart of our implementation is as shown in the figure below.

Sensor Block Diagram

• As shown above each sensor will wait for the echo for 10msec. If it gets an echo within 10msec then it will calculate the distance proportional to that echo. If it doesn't get an echo within 10msec then it will assume the distance is greater than or equal to 170cms.
• Hardware timer is programmed to run continuously from the moment it is initialized.
• As shown below, we save the timer value in a variable when trigger is provided to a sensor.

   LPC_GPIO2->FIOPIN &= ~(1 << pin_number);
   LPC_GPIO2->FIOPIN |= (1 << pin_number);
   delay_us(10);
   LPC_GPIO2->FIOPIN &= ~(1 << pin_number);
   sensor0_trigger_time = lpc_timer_get_value(lpc_timer0);

• When echo is received, we subtract the saved timer value from the current timer value to calculate the time required for the ultrasonic wave to return. This distance calculation code is defined in ISR.
• As we have seen earlier, the echo pin makes a transition from high to low when echo is received. Hence, the ISR is called when there is a falling edge on the echo pin.
• The ISR code is as shown below.

   void sensor0_echo_function()
   {
       temp0 = lpc_timer_get_value(lpc_timer0) - sensor0_trigger_time;
       distance[0] = ((temp0) * 0.017) - 10;
   }

Algorithm

  1. Trigger sensor 0.
  2. If echo is not received within 10msec, register distance 0 = 170cm and skip next step.
  3. If echo is received within 10msec, calculate distance 0.
  4. Trigger sensor 1.
  5. If echo is not received within 10msec, register distance 1 = 170cm and  skip next step.
  6. If echo is received within 10msec, calculate distance 1.
  7. Trigger sensor 2
  8. If echo is not received within 10msec, register distance 2 = 170cm and  skip next step.
  9. If echo is received within 10msec, calculate distance 2.
 10. Trigger sensor 3.
 11. If echo is not received within 10msec, register distance 3 = 170cm and  skip next step.
 12. If echo is received within 10msec, calculate distance 3.
 13. Trigger sensor 4.
 14. If echo is not received within 10msec, register distance 4 = 170cm and  skip next step.
 15. If echo is received within 10msec, calculate distance 4.
 16. Trigger sensor 5.
 17. If echo is not received within 10msec, register distance 5 = 170cm and  skip next step.
 18. If echo is received within 10msec, calculate distance 5.
 19. Go to step 1.

I/O Unit

SJValley LCD display

The I/O Unit consists of an LCD display to report the status of the car such as sensor values, heading and the current degree for the compass, latitude and longitude sent by Android. It also displays the CAN messages received per second. The LCD display that is being used in the car is SJONE Serial LCD display which runs on UART.
It is a 20x4 LCD display with a LCD driver which converts the UART characters to data and command signals for the LCD display.

The LCD has two modes of operation:
1. User Control mode
In this mode, the user controls the placing of LCD characters according to row and column by using GOTO command and $ character.
2. Smart LCD mode
In this mode, the user has to maintain a buffer for each line and print it on the line directly with scrolling enabled.

Pin Configuration

LCD Pin	SJONE Pin
Rx	P0.10(TXD2)
Vcc	5 V
GND	Ground

LCD initialization

The LCD display has a driver programmed to detect the baud rate. When the board starts, the UART port is configured to get '0xF0' character.

LCD Initialization Flowchart

Implementation

1. LCD controller uses bypass mode of CAN and listens to all the messages. This is implemented to count the no. of messages per second on the CAN bus.
2. A separate task is called which runs every 500 ms to display the messages.
3. The controller receives the CAN messages in 8 bit and 16 bit unsigned integers and have to be converted to character to display on the LCD.
4. We first store the CAN messages from sensor controller, geographical controller and android controller in global buffers.
5. The value from the buffer is converted to character values and a string is constructed to print on the lines of LCD display.
6. By default, the values from sensor, compass and android are displayed on the screen of LCD by refreshing it every 500 ms.
7. For the purpose of debugging, the sensor values are displayed continuously when switch 1 is pressed, compass values are displayed when switch 2 is pressed, android values are displayed when switch 3 is pressed.

LCD Controller Flowchart

Geographical Controller

This controller is used to receive coordinates from Android App and navigate car from source to destination. Android board sent coordinates between source and destination which are fetched from Google API, calculate compass heading and bearing using different navigation points and send compass heading and bearing to a master controller for decision making.

GPS Module

SparkFun Venus GPS with SMA Connector with Antenna GPS Embedded SMA GPS Module Features:

• upto 20Hz update rate
• UART protocol

GPS Configuration

The SparkFun Venus GPS comes with a default baud rate of 9600 bps and update rate of 1 Hz. It does NOT have an antenna, so we had to use Antenna GPS Embedded SMA. For navigation, we required a GPS update rate of 10Hz. This also requires a baud rate upgrade to 115200 bps .

The GPS has a flash memory to store all its configuration settings including but not limited to baud rate and update rate. We chose to communicate to the GPS using a serial port application utility - Hercules.exe. The GPS was connected on UART 2 and the computer (Hercules.exe utility) is connected on the UART 0. Essentially we built a benedictional UART bridge between UART0 and UART2.

To communicate with the GPS we programmed two firmware which will connect the PC USB port (Hercules.exe) to the GPS, so that configuration commands can be sent to it. The SJ One Board should be connected to PC USB port (Hercules.exe) . The SJ One Board should be connected to the GPS over UART2. These firmware are loaded on the Gitlab repository. Following firmware were used to configure the VENUS GPS:

1. lpc1758_freertos_GPS_9600.hex We used this firmware for a new GPS which has factory setting. Since, the new GPS will communicate at 9600bps. Note, this firmware communicates with PC serial port (Hercules.exe) at 38400 bps. We entered the following commands in the Hercules.exe:

1. Configure NMEA messages to send GGA and RMC NMEA sentences:
A0 A1 00 09 08 01 00 00 00 01 00 00 01 09 0D 0A 
2. Configure UART port and change to a baud rate of 115200 bps:
A0 A1 00 04 05 00 05 01 01 0D 0A

Note, that the above commands update the internal flash of Venus, so we need not reconfigure the module.

2. lpc1758_freertos_GPS_BOTH_115200.hex We used this firmware, if the GPS is already configured at 115200 bps using the " lpc1758_freertos_GPS_9600.hex". Since the baud rate of the GPS has increased, we have increased the value of the UART0 baud rate to a baud rate greater than or equal to 115200 bps Note, this firmware communicates with PC USB port (Hercules.exe) at 115200 bps.

A few handy GPS commands for the Venus GPS. these commands were referred from Application Note AN0003.pdf i.e. "Binary Messages Of SkyTraq Venus 6 GPS Receiver Ver 1.4.19". Following command will update the data flash:

Configure the system position rate to 10Hz  :
A0 A1 00 03 0E 0A 01 05 0D 0A

Lessons learned: The baud rate of both should be the same. In our case we mainly receive a lot of data. We only send data while sending communication commands. Thus our communication is mainly one directional. If the GPS/UART2 baud is at 115200 and UART 0 is still at 38400. Then we do NOT see anything on the Hercules.exe utility. We got stuck here for some time. Later the problem was solved by upgrading the UART0 baud rate at 115200 bps.

- Parse NMEA message to get current longitude and latitude
- Distance calculation

HMC-6352 Digital Compass Features

• I2C 2-wire interface
• Full Integration of 2-Axis Magnetic Sensors and Electronics
• Low Voltage Operation (2.7 to 5.2V)
• 3-modes of operation
• Heading resolution 0.5 degree
• 0-360 degree reading

The compass module was used in data on demand mode. It gives reading 6ms after a reading is requested. The data is returned in the form of two separate bytes and has to be shifted and added to get the final compass degree reading. A very simplistic compass but one has to be careful about its positioning. To get stable readings we average the compass readings to reduce the fluctuations that arise due to vibrations and vehicle movements.

Hardware Pin Diagram

System Diagram for GEO Controller

Software Design

Geo controller Flowchart

Testing & Technical Challenges

Master Controller Testing

Master controller gets data from GPS+Compass and sensor controller and depending of these data sends movement data to motor controller. Serial interaface messages helped in resolving few logic errors of movement algorithm. Logging of data was also useful in testing the algorithm. Real time testing was the last testing option and way to resolve few integration issues.

Geo Controller Testing

Deciding decision making threshold for required direction value

Acting on the minutest variation between current heading and required direction of travel made the car take too many decisions to correct its course. The frequent commands to the motor made the navigation very jerky and slow. In order to make it smoother we decided that master should act on course correction only if the variation crossed a certain limit.

Making the car turn towards the intended direction using the shortest path

If the value for intended direction of navigation was too large (greater than 180), the car took a long circuitous route to align itself in the new direction. This slowed down the navigation and made it erratic. So we added logic to make the car turn in the direction where it would have to turn the least to align itself in the intended direction of navigation.

Increasing the resolution of waypoints received

Initial data received from navigation app provided waypoints (received from Google maps API) which were fewer and spaced apart over long distances. Over this range, minute differences in compass values affected navigation as car did not travel in a straight line. It was further affected by the tendency of the car to gradually move in rightwards direction. We solved this by calculating midpoints of received coordinates, so the waypoints were spaced closer together. This reduced the effect of compass value variation and rightwards bias of car on navigation.

Android Testing

Command Log.d("ADebugTag", "Debugging!!!!") was used a lot of times. There was lot of debugging carried out since, one change in Android SDK would make us do change in the CAN communication in Free RTOS. The very first test carried out was the transmission of the data via bluetooth from Android phone to SJOne board. This was done by sending dummy coordinates to the SJOne board. Second test was carried out for the START and STOP buttons. This was tested by receiving the respective characters on the console. Third and final test was carried out for navigation. This test was done using actual App with the car thus involving GPS as well as Master.

Sensor Testing

HCSR04 Sensor Testing

• As shown in the figure below, HC-SR04 ultrasonic sensor requires an external 5V DC supply.
• When in the initial testing stage we just connected one sensor for testing the accuracy and the range of the sensor.
• The values we received were very stable and neat.

HC-SR04 sensor circuit diagram

LV-MaxSonar Sensor

• The connection diagram for LV-MaxSonar sensor is as shown in the image below.
• This is another option we considered for the ultrasonic sensors for obstacle detection.
• This sensor does not need a trigger, it is internally designed to send a new trigger on reception of an echo.
• And as usual, the pulse recieved on the echo pin is directly proportional to the distance of the obstacle.

LV-MaxSonar sensor circuit Diagram

Finalizing an sensor

• Both sensors being pretty accurate, we were confused while finalizing one.
• HCSR04 sensor was better option because as it was much cost efficient than the LV-MaxSonar Sensor (Where one LV-MaxSonar costs $30, one HCSR04 costed us only $2)
• Its only drawback is, the transmitter is separate from the receiver which introduced a field angle.

Switching to Hardware Timer

• Previously, all sensor were triggered using software timers. We declared a soft timer for each sensor which kept track of the time between trigger and echo for that particular sensor.
• If we see the declaration of software timer as shown below, we come to know that the timer returns a value in milliseconds.

   inline uint64_t getTargetTimerValueMs(void) const { return mTargetMs; }

• If we apply the before mentioned distance formula to this timer value in milliseconds, we will always get the distance in multiples of 17.
• Let's work out an example for better understanding;

Software Timer Distance Calculation

• As the return return type of this function is an integer, we always get the distance in multiples of 17, which compromises the accuracy by a large factor.
• Because of this reason we switched to hardware timers.
• The declaration of hardware timer is as shown below, and this return value of time is in micro-seconds.

   uint32_t lpc_timer_get_value(const lpc_timer_t timer)
   {
       return (lpc_timer_get_struct(timer)->TC);
   }

• Let's work out the same example for the return value being 1usec.

Hardware Timer Distance Calculation

• Hence, even if the timer value is an integer, as it is in microseconds, we have improved the accuracy.
• As there are only three hardware timers in LPC 1768 we cannot allot individual timer for each sensor. Hence, we use just one hardware timer which runs regardless any individual sensor.
• All sensors get the current timer value during trigger and echo from this single timer, and do the further processing individually.

Sequentially Triggering of Sensors

• We used to trigger all the sensors at the same time, which caused interference between adjacent sensors, which in turn caused mis-firing of echo.
• This resulted in incorrect distance values from all the sensors.
• Thus to solve this issue, we implemented sequential triggering.
• Under this logic, each sensor will be triggered only when the previous sensor receives an echo or exceeds the maximum echo reception wait time which is 60msec.
• This implementation solved the issue at hand but gave rise to a new issue which is mentioned in the next section.

Limiting the Scope to Improve Frequency

• As discussed in the previous section, if we implement sequential triggering for each sensor, if there is no obstacle, then the worst case delay would be 360 msec(60msec*6sensors) to update all sensor values to the master.
• Means the frequency of communicating these values to the master will be, 2.8Hz.
• For proper obstacle avoidance, we need to provide the sensor data to the master atleast 10 times per second, i.e. at 10Hz.
• Which means data from all six sensors must be calculated within 100msec.
• Even if we consider limiting the time allotted to a sensor to time required for maximum distance (400cms), we will require 23.5msec each sensor i.e. 141msec to update the values of all six sensors. This increases the frequency to 7.1Hz.
• This led is to the solution to this problem, if we limit the scope of each sensor then we can update the sensor values more frequently to the master.
• To overcome this issue, we limited the maximum scope of the sensor to 170 cms, limiting the time required to get the echo to 10msec. Which makes the total time required to calculate all six sensors' data about 60msec.
• Hence, as shown in the flowchart, each sensor waits 10msec for an echo. If we get an echo within 10msec, we calculate the distance; if we don't, we assume the obstacle is at 170cms or further.

Misfiring of Sensor

• At times the sensor used to mis-fire. Which means; in a stable condition, if the obstacle is at a constant distance of 150cms, 1 out of 50 continuous values will be 60cms.
• This value being false, misguides the master.
• To overcome this issue, we introduced a threshold value called DELTA (say, 10cms). Which defines the acceptable range from the previous value.
• In this algorithm, an abrupt change in the distance value should be constant for at least two consecutive reads to be considered genuine.
• If the current value from the sensor is in the range of the previous value's +/- 10cms, then this value is considered to be correct, and is provided to the master. Then this current value will be copied in the previous value register.
• If the current value is not is the previous value's +/- DELTA range then it is considered as a misfire and hence is not provided to the master. But this sudden change might be because of a sudden obstacle; hence, the value is copied in the previous value register, and if the same value repeats, it will be considered genuine and provided to the master.
• The code for this algorithm is as shown below;

       if(temp-DELTA<current && current<temp+DELTA){
           distance = current;
       }
       temp = current;

• Hence, this algorithm will overcome the abrupt mis-firing of the sensor and make the data provided to the master more reliable.

I/O Testing

1. While testing the display board we gave a supply of 5V from voltmeter, as there was fluctuations in supply from the voltmeter we ended up burning the board.
2. We used character display module, the values received from sensor was of integer type. So, we wrote a function to convert integer type to character type and print values on to the display.
3. We received gps degree and compass degree of type integer, which was a 4 digit value. We wrote a function to divide the whole value by 10 which would be a perfect gps and compass degree and send it to display module for printing.
4. Similarly to print the latitude and longitude we wrote a function to convert float type to character type and print on to the display.

Challenges and Learning

Challenges in Master

Main activity of master is to get new data from GPS+Compass controller, sensor controller and send movement logic to motor controller depending on movement logic. Co-ordinating with these controllers and make car move as per our requirement required effort and testing during integration and testing phase of the project. Real time testing with log+serial interface messages helped in resolving the issues in hardware and logic errors.

Challenges in Android

There are two activities in Android. One is the bluetooth activity and other is the navigation activity. Switching from bluetooth activity to navigation activity would disconnect the bluetooth activity. This was one of the early challenges faced by us. We overcame this by changing the layout of our App. Then we combined the two activities in one activity itself by adjusting the dimensions. One more challenge faced by us was to differentiate latitude and longitude and give them separately to the GPS team. This was done by inserting one distinguishing character after each latitude and longitude so that the SJOne board could do the parsing and send it to the GPS board accordingly.

Challenges in Geo Controller

The biggest challenge for the Geo controller was to get stable readings from the compass and finding the right position to mount it. It was very hard to tell what the correct direction was by comparing the directions with the readings from the cellphone compass, since each one of them gave a different reading. There was no way to verify the right reading. There were some issues in version control. There was great difficulty in finding a spot without any interference with the compass. The GPS did not get a lock with the satellites initially, this was fixed by adding an antenna which improved the performance considerably.

Conclusion

This team project was a good learning experience for the team. This project not only helped us to learn and improve our technical skills but also improved our team/work management skills. From our experience we would suggest the teams working on this project in future to define the project goals, work distribution in a planned way as it will help in smooth execution of the project. Work role of the team members should be defined and this helps in increasing the efficiency of the team. Overall, we would like to call this project a success as it helped us improve our technical and non technical environment which would help us in real work environment.

Project Video

SJSU_Rover:Video1 CMPE243 Team2 (Project Demo Video)
SJSU_Rover:Video2 CMPE243 Team2 (Straight path)

Project Source Code

git@gitlab.com:ddpatil/cmpe243_fall14_team2_sdc.git

References

Acknowledgement

We would like to thank Preet for his guidance during CMPE243 class and are grateful for his help. We would also like to thank other class mates of CMPE243 for their help during this class.

References Used

1. Preetpal Kang, Lecture notes of CMPE 243, Computer Engineering, Charles W. Davidson College of Engineering, San Jose State University, Aug-Dec 2014.
2. en.wikipedia.org/
3. Fast Charger
4. Lipo Battery
5. GPS Module
6. Subscribe Publish Algorithm
7. Git Tutorial
8. Compass Module
9. Can Transciever Module
10. LM7805
11. Bluetooth Module
12. Ultrasonic Sensor Module
13. LV-MaxSonar
14. LPC1758 User Manual
15. C++ Tutorial
16. GoogleMapsAPI1
17. GoogleMapsAPI2
18. FreeRTOS Tutorial
19. Publish Subscribe design Pattern Code Example
20. LCD Display