Latest revision as of 12:24, 20 January 2016

1 ThunderBird : Self Driving Car
2 Abstract
3 Objectives & Introduction
4 Schedule
- 4.1 Team Schedule
5 Parts List & Cost
6 Design & Implementation
7 Sensor Controller
8 Motor and I/O Controllers
9 GPS Controller
- 9.1 SPARKFUN VENUS GPS with SMA CONNECTOR
- 9.2 Compass
10 Master Controller
11 Bluetooth Control and Android application
12 Testing & Technical Challenges
13 Conclusion
- 13.1 Project Video
- 13.2 Project Source Code
14 References
- 14.1 Acknowledgement
- 14.2 References Used

ThunderBird : Self Driving Car

Abstract

ThunderBird is a 1/10 2 WD electric short self-driving truck. The truck is equipped with sensors to detect obstacles, GPS for getting directions, Compass for the truck's orientation, Bluetooth for communicating with the android device and LCD for displaying the sensor values, velocity of the truck and current heading on screen. The modules are interfaced using 5 SJ One boards which features a Cortex-M3 LPC1758. CAN bus is used for communicating between the modules. Android device is used to send start message and enter the destination coordinates through Bluetooth. Based on the GPS co-ordinates master directs the motor in respective direction and if the sensors detect obstacles, it signals the motors to drive the car accordingly. Based on GPS co-ordinates and sensor values Master directs the truck until destination is reached.

Objectives & Introduction

Objective

Objective of this project is to be able to work as a team of ten members to develop an Autonomous self driving Car. which gives us the real time work experience as the team of ten members has to be divided into subteams and work on individual modules(Sensors controller, Motor and I/O controller, GPS controller, Android controller and Master controller ) by collaborating with other sub team members for communication between the modules.

Main goal of this project is to understand how CAN protocol works and its architecture in detail, as all controllers of the system communicate through CAN bus.

Team Members & Responsibilities

Master Controller and Android application
- Sravani Aitha
- Vishnu Vardhana Reddy Mandalapu
- James Sushanth Anandraj
- Athavan Kanagasabapathy
Motors and I/O
- Dheeraj Dake
- Akhil Bhargav Josyabhatla
Sensors
- Nitesh Jain
- Rajashree Kambli
GPS
- Rishit Borad
- Ravi Vanjara
Bridge/Android Controller
- James Sushanth Anandraj
- Athavan Kanagasabapathy

Introduction

Our Autonoumous self-driving car is designed in a way that it has five controllers to deal with different functions of the car and these controllers communicate through CAN bus, below is the description for various controllers.

Bridge Controller : Bridge controller receives the start, stop messages and check points from the android application and it sends the start and stop messages over CAN bus in order to start and stop the car.
Motors and I/O Controller : Motor controller receives the steer and direction information from the master controller and navigates the car in required direction.
Sensors Controller : There are four sensors mounted on the car, three in front and one on rear, sensor controller update the motor with obstacle information by sending the updates from the sensors.
GPS Controller : GPS controller sends the updated direction and the distance to the destination.
Master Controller : Master controller collaborate the messages from Brdidge, sensor and GPS controllers and directs the motor in required direction.

Overall Algorithm

1. Android/Bridge controller sends the start command to master controller as soon it receives start from android app.
2. GPS controller sends the current location to Bridge and Bridge relays the current co-ordinates to android app.
3. Android application sends the required destination to the Bridge controller and Bridge controller sends the information to GPS controller.
4. Based on the current location and destination, GPS+Compass controller decides the required direction for the car to navigate and sends it to Master
controller.
5. Master starts listening to sensor data from sensor controller, required direction from GPS+compass controller and it also keeps listening to android
controller for any stop message.
6. As soon as Master receives GPS start command, Master controller starts calculating the right direction for the car to navigate.
7. Sensor Controller keeps sending sensor values on the bus and Motor+IO controller, Bridge controller.
8. Bridge controller sends the sensor values to android app for the displays, android app keeps updating its sensor values as soon as receives an
update from bridge controller.
9. Motor+IO controller keeps listening to the data from GPS+Compass controller for the heading direction and updates the LCD display accordingly.
10. Motor+IO controller updates all the sensor values on the LCD display as soon as it receives the update from sensor controller.
11. Master decides the right direction for the car based on sensor values and GPS-co ordinates, sends the message to Motor to move the vehicle in decided
direction.
12. Motor listens to the direction from Master controller and directs the car accordingly. .
13. Step 4 to 12 continue until the Master receives stop command from Android controller or destination reached message from GPS Controller.
14. As soon as Master receives stop message or destination reached command, Master sends stop message to Motor Controller.
15. Motor controller stops the car as soon as it receives stop command from Master controller.

Controllers

Schedule

Team Schedule

Sl.No	Start Date	End Date	Task	Status	Actual Completion Date
1	09/22/2015	09/29/2015	Order RC Car	Completed	09/26/2015
2	09/30/2014	10/6/2015	Ordered components	Completed	10/04/2015
3	10/07/2015	10/13/2015	Study about the modules and the RC car	Completed	10/13/15
4	10/14/2015	10/20/2015	Test motors using PWM	Completed	10/16/15
5	10/21/2015	10/28/2015	Interface sensor modules	Completed	10/26/15
6	10/29/2015	11/05/2015	Interface GPS and compass	Completed	11/6/15
7	11/12/2015	11/19/2015	Interface LCD	Completed	11/28/15
8	11/20/2015	11/27/2015	Interface modules over CAN bus	Completed	11/26/15
9	11/28/2015	12/05/2015	Integrating modules	Completed	12/8/15
10	12/6/2015	12/13/2015	Testing	Completed	12/15/15
11	12/14/2015	12/19/2015	More Testing	Completed	12/18/15

Motor and I/O Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	10/6/2015	10/13/2015	Determining the ESC initialization sequence	Completed	10/11/15
2	10/13/2015	10/20/2015	Testing the Servo and DC motor using SJ One board PWM's	Completed	10/16/2015
3	10/20/2015	10/27/2015	Design motor control using messages from the CAN bus	Completed	10/27/15
4	10/27/2015	11/3/2015	Implement code to accept messages from other modules over CAN bus and display it on the LCD	Completed	11/28/15
5	11/3/2015	11/10/2015	Update motor speeds on the LCD in real time	Completed	11/28/15
6	11/10/2015	11/17/2015	Interface I/O and motor modules with master controller and establish communication	Completed	11/28/15
7	11/17/2015	11/24/2015	Fine turning motors for precise control	Completed	11/24/15
8	11/24/2015	12/01/2015	Fine tuning (buffer)	Completed	12/2/15
9	12/01/2015	12/08/2015	Testing and debugging	Completed	12/10/15

Geographical Position Controller Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	10/6/2015	10/13/2015	Research & order GPS module	Completed	10/8/2015
2	10/13/2015	10/20/2015	Interface GPS using I2C with SJOne board	Completed	10/20/15
3	10/20/2015	10/27/2015	Interface Compass with SJOne board	Completed	10/27/15
4	10/27/2015	11/3/2015	Calibrate Compass and GPS	Completed	11/2/15
5	11/3/2015	11/10/2015	Parse raw data and create meaningful data	Completed	11/21/15
6	11/10/2015	11/17/2015	Implement CAN communication with SJOne board	Completed	11/19/15
7	11/17/2015	11/24/2015	Test and debug GPS & Compass locally	Completed	11/24/15
8	11/24/2015	12/01/2015	Integrate GPS/Compass module with Master board	Completed	12/2/15
9	12/01/2015	12/08/2015	Implement routing algorithm for Car	Completed	12/10/15
10	12/08/2015	12/15/2015	Test and Debug GPS/Compass integration with master	Completed	12/17/15

Sensor Controller Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	10/5/2015	10/11/2015	Finalize and order the sensors	Completed	10/11/2015
2	10/12/2015	10/18/2015	Wire the sensors and write a sample test code to check the sensors.	Completed	10/18/2015
3	10/19/2015	11/01/2015	Transfer the sensor data to master controller via can bus.	Completed	10/31/2015
4	11/2/2015	11/9/2015	Implement and integrate the code for all the sensors.	Completed	11/15/2015
5	11/2/2015	11/15/2015	Test and Debug the integrated module.	Completed	10/15/2015
6	11/16/2015	11/29/2015	Collaborate with the other module teams to make sure that the sensors are in working condition.	Completed	11/30/2015
7	11/30/2015	12/06/2015	Test for stability of sensors and report.	Completed	11/31/15
8	12/07/2015	12/13/2015	Prepare for Demo.	Completed	12/13/15

Master controller and android controller Schedule

Sl. No	Start Date	End Date	Task	Status	Actual Completion Date
1	10/6/2015	10/13/2015	Car purchase ,dismantle and setup for project	Completed	10/8/2015
2	10/13/2015	10/20/2015	Can setup components purchase, Can bus design and soldering	Completed	10/20/15
3	10/20/2015	10/27/2015	Basic Can communication testing by sending and receiving data and can msg specification for all controllers and messages.	Completed	10/27/15
4	10/27/2015	11/3/2015	Development and implementation of Algorithm for driving car and obstacle avoidance.	Completed	11/2/15
5	11/3/2015	11/10/2015	Interface bt dongle with sjone board and android device and test with commands	Completed	11/11/15
6	11/10/2015	11/17/2015	Develop Android GUI and application to interact with car using bluetooth. Implement all necessary commands on sjone board for communication with android device. Interface with Motor and IO Controller.	Completed	11/18/15
7	11/17/2015	11/24/2015	Test and debug Master algorithm and Android interface locally and with Motor controller interfaced by providing predetermined directional commands.	Completed	11/23/15
8	11/24/2015	12/01/2015	Integrate Master Board with all boards and implement heartbeat protocol.	Completed	11/2/15
9	12/01/2015	12/08/2015	Test run 1 with all boards integrated and with all planned features developed.	Completed	12/8/15
10	12/08/2015	12/15/2015	Test run 2 after solving issues found in test run 1.	Completed	12/17/15

Parts List & Cost

S.R.	Description	Manufacturer	Part Number	Qty	Total Cost
1	SJOne Board	-	-	5	$400.00
2	RC Car	Furry Arrma - 2 Wheel Drive - 1/10	-	1	$185.00
3	Ultrasonic Sensor	LV-MaxSonar - EZ1	MB1010	5	$140.00
4	1.8 Color TFT LCD display with MicroSD Card Breakout	Adafruit	ST7735R	1	$19.95
5	SparkFun Venus GPS with SMA Connector	Sparkfun	GPS-11058	1	$49.95
6	Triple-axis Magnetometer (Compass) Board	Adafruit	HMC5883L	1	$9.95
7	CAN Transceiver	Microchip	MCP2551	6	$25.00
8	Bluetooth Module	Exbee	standalone	6	$20.00
	Total (Including Shipping and Taxes				$847.00

Design & Implementation

CAN 11-bit ID Format

MSG	DST	SRC
5 bits (11-6)	3 bits (5-3)	3 bits (2-0)

Controller ID Table

Controller ID	Controller Type
0xA0	Master Controller
NO TX	Motor Controller & I/O Controller
0xB0	GPS
0xC8	Sensor
0x00	Android Controller

This DBC File has used to communicate between all controllers in RC Car.

VERSION ""

NS_ : NS_DESC_
CM_
BA_DEF_
BA_
VAL_
CAT_DEF_
CAT_
FILTER
BA_DEF_DEF
EV_DATA_
ha ENVVAR_DATA_
SGTYPE_
SGTYPE_VAL_
BA_DEF_SGTYPE_
BA_SGTYPE_
SIG_TYPE_REF_
VAL_TABLE_
SIG_GROUP_
SIG_VALTYPE_
SIGTYPE_VALTYPE_
BO_TX_BU_
BA_DEF_REL_
BA_REL_
BA_DEF_DEF_
REL_ BU_SG_REL_
BU_EV_REL_
BU_BO_REL_
SG_MUL_VAL_

BS_:

BU_: NOONE SENSOR DRIVER MOTOR GPS IO

BO_ 0xA0 HEARTBEAT: 1 DRIVER

SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS

BO_ 0xA1 sensorback: 1 SENSOR

SG_ SENSOR_BACK_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GPS,IO

BO_ 0x02 IOSTART: 1 IO

SG_ IOSTART_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 0x01 IOSTOP: 1 IO

SG_ IOSTOP_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 0x03 IOCHECKPOINTCOUNT: 1 IO

SG_ IOCOUNT_cmd : 0|8@1+ (1,0) [0|0] "" GPS,DRIVER

BO_ 0x05 GPSCHECKPOINTCOUNT: 1 GPS

SG_ GPSCOUNT_cmd : 0|8@1+ (1,0) [0|0] "" IO,DRIVER

BO_ 0x04 IOGPSCHECKPOINT: 8 IO

SG_ IOLATITUDE : 0|32@1+ (0.1,0) [0|0] "DEGREE" DRIVER,GPS 
SG_ IOLONGTITUDE : 32|32@1+ (0.1,0) [0|0] "DEGREE" DRIVER,GPS

BO_ 0xB0 COMPASS: 4 GPS

SG_ COMPASS_direction : 0|8@1+ (1,0) [0|0] "DIRECTION" DRIVER,GPS,MOTOR 
SG_ COMPASS_angle : 8|16@1- (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB1 GPS_longitude: 8 GPS

SG_ GPS_longitude_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR 
SG_ GPS_longitude_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB2 GPS_latitude: 8 GPS

SG_ GPS_latitude_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR 
SG_ GPS_latitude_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB3 GPS_heading: 8 GPS

SG_ GPS_heading_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR 
SG_ GPS_heading_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB4 GPS_dest_reached: 4 GPS

SG_ GPS_dest_reached : 0|32@1+ (1,0) [0|0] "" DRIVER,GPS,MOTOR

BO_ 200 SONARS: 6 SENSOR

SG_ SENSOR_SONARS_mux M : 0|4@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR 
SG_ SENSOR_SONARS_s1_fault : 4|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_s2_fault : 5|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_s3_fault : 6|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_s4_fault : 7|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_left m0 : 8|12@1+ (0.1,0) [0|400] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_middle m0 : 20|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_right m0 : 32|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_rear m0 : 44|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_no_filt_left m1 : 8|12@1+ (0.1,0) [0|400] "" NOONE
SG_ SENSOR_SONARS_no_filt_middle m1 : 20|12@1+ (0.1,0) [0|400] "" NOONE
SG_ SENSOR_SONARS_no_filt_right m1 : 32|12@1+ (0.1,0) [0|400] "" NOONE
SG_ SENSOR_SONARS_no_filt_rear m1 : 44|12@1+ (0.1,0) [0|400] "" NOONE

BO_ 0X020 MOTOR_CMD: 3 DRIVER

SG_ MOTOR_CMD_steer : 0|8@1- (1,0) [0|0] "" MOTOR 
SG_ MOTOR_CMD_drive : 8|8@1+ (1,0) [0|0] "" MOTOR 
SG_ MOTOR_CMD_angle : 16|8@1+ (1,0) [0|0] "" MOTOR

CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one"; CM_ BU_ DRIVER "The DRIVER controller driving the car"; CM_ BU_ SENSOR "The sensor controller of the car"; CM_ BU_ MOTOR "The motor controller of the car"; CM_ BO_ 0xA0 "Sync message used to synchronize the controllers";

BA_DEF_ "BusType" STRING ; BA_DEF_ SG_ "FieldType" STRING ; BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;

BA_DEF_DEF_ "BusType" "CAN"; BA_DEF_DEF_ "FieldType" "";

BA_ "GenMsgCycleTime" BO_ 0xA0 1000; BA_ "GenMsgCycleTime" BO_ 0x01 100; BA_ "GenMsgCycleTime" BO_ 0X020 100; BA_ "FieldType" SG_ 0xA0 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

VAL_ 0xA0 DRIVER_HEARTBEAT_cmd 1 "DRIVER_HEARTBEAT_cmd_NOOP" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 2 "DRIVER_HEARTBEAT_cmd_REBOOT";

Hardware Design

The hardware was designed in a very clean and neat design with the help of 17 pin jumper cables matching the SJ-One board in order to save the space and avoid the multiple layers of wiring. Every hardware parts were built upon after careful consideration.

The CAN Controller used is MCP2551. It is a high speed transceiver which serves as boundary for all the SJ-One controllers which helps to communicate with each other. The operating speed of the bus is upto 1 megabits per second. The high and low signal acting as the output are protected internally against any short-circuits and sudden transitions in voltage level. The connection to SJ-One board is shown s per below diagram,

Pin Connections

SI No.	CAN Pin	SJ-One Pin	Main Board	Function
1	1	P0.1		TXD of SJ-One board connected to TX pin of transceiver
2	2	Vcc		Voltage supply to transceiver
3	3	GND		Common ground connection
4	4	P0.0		RXD of SJ-One board connected to RX pin of transceiver
5	6		Low Wire	Connected to a common wire carrying CANL signals
6	7		High Wire	Connected to a common wire carrying CANH signals

Software Design

Implementation

Working Mechanism

Fig 2.ThunderBird System Flow Diagram

Sensor Controller

Fig 1. LV-EZ Ultrasonic Range Finder

Fig 2. sonarback

We have used four Maxbotix LV-EZ Ultrasonic Range Finder sensors (MB1010), three for front (left, right, mid) and one for the rear. These ultrasonic sensors are used to detect the obstacle which our car can encounter on its route. These sensors are connected to the SJOne board and the CAN bus and can work on 3.3V-5.0V.

The pin configuration for the sensor is as follows:
1) Pin 2-PW: This pin outputs a pulse width representation of range. The distance can be calculated using the scale factor of 147uS per inch.
2) Pin 4-RX: This pin is internally pulled high. The LV-MaxSonar-EZ will continually measure range and output if RX data is left unconnected or held high. If held low the sensor will stop ranging. Bring high for 20uS or more to command a range reading.
3) Pin 6-+5V: Vcc – Operates on 2.5V - 5.5V. Recommended current capability of 3mA for 5V, and 2mA for 3V.
4) Pin 7-GND: Return for the DC power supply. GND (& Vcc) must be ripple and noise free for best operation.

Sensor Hardware Design

Fig 3. Board-Block-Diagram

Fig 3. sensor mount

250mS after power-up, the LV-MaxSonar-EZ is ready to accept the RX command. If the RX pin is left open or held high, the sensor will first run a calibration cycle (49mS), and then it will take a range reading (49mS). After the power up delay, the first reading will take an additional ~100mS. Subsequent readings will take 49mS. The LV-MaxSonar-EZ checks the RX pin at the end of every cycle. Range data can be acquired once every 49mS.

Each 49mS period starts by the RX being high or open, after which the LV-MaxSonar-EZ sends the transmit burst, after which the pulse width pin (PW) is set high. When a target is detected the PW pin is pulled low. The PW pin is high for up to 37.5mS if no target is detected. The remainder of the 49mS time (less 4.7mS) is spent adjusting the analog voltage to the correct level. When a long distance is measured immediately after a short distance reading, the analog voltage may not reach the exact level within one read cycle. During the last 4.7mS, the serial data is sent.

Sensor Software Design and Algorithm

The following steps are for initializing, getting readings and calculating distance in inches for one sensor- Main init function: 1) Configure the PW pin of sensor as input.

2) Configure RX pin of the sensor as output and set it high.

3) Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.

4) Note down the sys_get_uptime_us() at the rising interrupt. Let this time be T1.

5) Note down the sys_get_uptime_us() again when the falling edge is encountered. Let this time be T2.

6) To calculate the distance in inches, do - (T2-T1)/147.

7) Send this value to the Master controller via the CAN bus.

Periodic Callback Functions:

We are using the periodic callback functions.Hence we implemented the algorithm around those tasks.We used static variables in order to preserve the values incase functions are completed and the desired tasks are not completed yet. We used only the 1000Hz and 100Hz tasks.

--1000Hz task:

Start 1st sensor.

Get fall edge and calculate value.

Stop sensor and start next.

--100Hz task:

Get all 4 sensor values and send to Master and Motor via Can.

This is the snippet of our Interrupt function callbacks.

eint3_enable_port2(RightSensorPW_Pin, eint_rising_edge, eintCallbackright_Rise);
eint3_enable_port2(RightSensorPW_Pin, eint_falling_edge, eintCallbackright_Fall);

void eintCallbackright_Rise()
{
  //Note down the system start time for right sensor ( start_right_time)
}

void eintCallbackright_Fall()
{
 //Note down the current system time 
 //Subtract the start_right_time from the current system time and divide the result by 147 to get the distance in inches.
}

Fig 4.Sensor workflow

Fig 5. Sensor Timing Diagram

Fig 6. Sensor State Diagram

Fig 7. Sensor Flow chart

Sensor: Technical Challenges

Issue #1 - Fluctuating sensor values: We observed random/fluctuation in the sensor values. Sometimes, the value was even zero.The primary reason was that we were using the ADC mode. ADC mode converts analog to digital values received from the sensors. The values were unstable and unreliable.We could have used an arbitration to get accurate values. But the SJSU one board has only 3 ADC pins and we have 4 sensors to mount. So,either way we could not use ADC mode.
Solution: Switched from ADC mode to PWM mode to get more reliable values,with minimum spikes.PWM mode is a more reliable mode. We got accurate spikes on an oscilloscope and hence we used the PWM mode on the sensors.

Issue #2 - The beams from two adjacent sensors collided with one another.The waves from the sensors travel in a V shape.This caused inter sensor value collision.
Solution: Increased the distance between the sensors and made sure sensors working serially and not in parallel.We increased the distance between the sensors to avoid inter sensor collisions.Also we turned one sensor on at a time. Hence we turned one sensor,got the values and then turned it off before moving on to the next one.The reliability increased considerably.

Issue #3 - The sensor when mounted on the car detected ground as obstacle.During the 1st demo, we mounted the sensors on the main board itself. This caused us getting values from the ground. This situation can be tricky when the car is on a slope.
Solution: Increased the height of sensors placed on the car.We mounted the sensors on custom PCB's and made sure no ground reflections were encountered.

Issue #4 - The sensors did not work on independent 5V supply.We provided a common 5V power to all the sensors. This caused fluctuations and hence unreliable values.
Solution: Switched the power supply to a more reliable and constant SJSU one board VCC.To reduce the spikes, we could have used a stable 5V power source. But we opted for stable power from the SJSU board. This reduced spikes.

Issue #5 - The sensors (Left and Right sensor) gave faulty values when placed at 45 degrees on the corner of the base board i.e. fall edge missed sometimes.The waves from the sensors got reflected from white or oil based painted objects if the sensors were placed at 45 degrees.
Solution: Increased the angle to cover wider area and avoid reflections.Finally we tested out many permutations and combinations to find the accurate angles at which the sensors reflected properly and waves didn't just pass on. Hence increasing the angles to more than 45 degrees helped get us accurate values.

Fig 5. Sensor before

Fig 6. Sensor after

HEAD/TAIL LIGHTS

Based on the Light Sensor mounted on the SJSU one board, we are turning on the LED placed on the Head Light position.The threshold taken for Light is 20.Also for Back lights,if the car halts or moves in the reverse direction, the tail lights will turn on. The encoder values from the motor are used to achieve this.

Sensor Test Video

Sensor Test Video

Motor and I/O Controllers

ThunderBird is a 2 WD truck. It is equipped with a ARRMA BLX brushless DC motor connected to an BLX80 ESC(Electronic Speed Control). The ESC drives the DC motor according to the PWM(Pulse Width Modulation) signal. The truck's front wheels are connected to a waterproof ADS-7M Metal Geared Steering Servo. The servo and the DC motor are controlled using the PWM pins of the SJOne board.

Motors

Pulse Width Modulation - Controlling DC motor

Fig 1. Initializing pwm signal

Fig 2. Initializing pwm signal

Fig 3. Forward pwm signal

Fig 4. Reverse pwm signal

Fig 5. Servo pwm signal

Fig 6. Optical Sensor for measuring RPM

Fig 7. Optical sensor secured on the car's back rim

Fig 8. Schematics of Optical sensor interface with SJOne board

Pulse width modulation is a technique which is used to encode the analog signal into a pulsating signal. The signal is represented as a series of pulses. This signal can be easily generated using the pwm pins of the SJOne board. The ESC is initialized upon passing a PWM signal which is sent by the RF module on the truck. The type of signal is observed by hooking the PWM pin to the digital oscilloscope. The initialization signal is shown in figure 1. A resolution of 1ms is set on the oscilloscope. The PWM signal has a width of 1.5 ms. This signal initializes the ESC. Once the ESC's are initialized, the motors require a signal to accelerate and decelerate. The type of signals for moving the motor forward and backward are realized by hooking the output pin of the RF module to the digital oscilloscope. The forward and backward pwm signals at full throttle are shown in figures 2 and 3 respectively. The respective pwm signal pulses for moving the motors forward and backward are shown below.

Acceleration PWM signal
- Forward full throttle - 2 ms
- Forward medium throttle - 1.8 ms
- Neutral - 1.5 ms

Reverse PWM signal
- Reverse full throttle - 1 ms
- Reverse medium throttle - 1.2 ms
- Neutral - 1.5 ms

PWM Calculations

The PWM value to be set is determined from these calculations:

PWM is a percentage of the signal frequency
The signal is of 50 Hz i.e. 20 ms duration
A 10% of the signal value gives a duration of 2 ms - 10/100 * 20 = 2 ms

The respective percentages for all the signal were calculated and the PWM signals were generated using the PWM.set function. The generated pulses from the SJOne PWM pin is passed to the ESC for initialization and controlling the DC motor. The ESC has 3 connections - Vcc, GND and PWM. SJOne board's GND and PWM are connected to the ESC. The Vcc is supplied from the battery pack.

A sample code demonstrating the PWM signals is written and the motors were controlled using the on-board SJOne switches.

DC motor demo

Controlling Servo motor

The servo motor channel in the RF module is hooked to the digital oscilloscope to determine the initial sequence. It is observed that when the RF transmitter is switched on, the RC remote sends a pwm signal which resets the servo to its starting position. This PWM signal re-centers the truck's wheels. The signal is realized by hooking the data pin from the first channel of the RF module to the digital oscilloscope. The PWM signal is shown in figure 4. The signal is having a pulse of 1.6 ms. The steering on the RC is moved left and right to determine the PWM signals. The signal values were noted from the oscilloscope. The values are tabulated below.

Steering PWM signal
- Steer full right - 2 ms
- Steer full left - 1 ms
- Steer center - 1.6 ms

A PWM signal having a pulse width between 1.6 ms to 2 ms is used to control the steering towards right precisely. Similarly, a PWM signal having a pulse width between 1 ms to 1.6 ms is used to control the steering towards left precisely. The servo has 3 connections - Vcc, GND and PWM. The servo motor is not connected to a ESC. It doesn't get any voltage if it is not connected to the RF module. The servo motor operates at 6V. For testing, the Vcc of the servo motor is connected to the RF module. The GND from the RF module is made common with the GND from SJOne board. The PWN signal is given as an input from the SJOne board. The PWM signal values were calculated using the procedure shown above. The respective PWM signals were then sent to the servo motor using the PWM pin on the SJOne board for steering the truck.

The on-board switches on the SJOne board are used to steer the truck left and right. A sample code demonstrating this functionality is written and tested.

Servo motor demo

Speed Feedback Encoder

The car should maintain it's speed at all times. The factors affecting the car's speed include incline surfaces, weight of the car and low battery. During these cases, the car should increase and decrease its speed accordingly. There should be some mechanism to know the speed of the car. If you get a Traxxas car, it has an inbuilt device built into the car for measuring the car's speed. We are using optical sensor to detect the car's revolutions.

Optical Sensor

The optical sensor is shown in the figure 5. The optical sensor has Vcc, GND and data pins. The Tx led lights bright red and the Rx receives the reflected light from the Tx when it encounters a white surface. The optical sensor is mounted on the back rim of the car. A white paper is patched on to the tyre to reflect the light from the Tx into the Rx. The mounted optical sensor is shown in figure 6. The schematics for the optical sensor is shown in figure 7. The sensor's data pin is hooked to the GPIO pin. An ISR is called on that pin which will increment a counter value each time the interrupt is called. The counts are averaged using period functions and is displayed on the LCD for every second. The RPM is controlled according to these revolutions per second value. When the car goes on a slope, the pwm is increased to maintain the RPM and once the car climbs the slope, PWM value is decreased. It adjusts accordingly to maintain the RPM!

Precise Steer

The car should steer precisely according to the compass value and GPS value. The GPS tells the car where to go and the compass will tell the car in which direction it should go. The compass gives the values in degrees which lie in the range 0 to 360. The car's servo motor has a PWM range of 4 to 10 with 4 being the extreme left, 7 being the center and 10 being the extreme right. The compass degrees are divided into 17 sectors. The sectors 0 to 9 have values ranging from 0 to 180 degrees and sectors 10 to 17 have values ranging from 180 to 360 degrees. The sectors 0 to 9 drive the car right and the sectors 10 to 17 drive the car left. Each sector accounts to 20 degrees on the compass value. The entire PWM range is divided into sector value. The respective PWM value is set for the car's servo motor for precise steering control.

When the car encounters an obstacle, the precise control is stopped and the car steers to avoid the obstacle. Once the obstacles are avoided, the precise control is activated back.

Periodic Callback Functions:

The periodic callback functions are called periodically. The initialization is done in periodic init which is done at the start. The periodic callback functions 1Hz, 10 Hz, 100 Hz and 1000 Hz are called every 1000 ms, 100ms, 10 ms and 1 ms respectively. The following tasks were performed in the periodic functions.

--1Hz task:

Reset the number of interrupts received from the optical sensor

--10Hz task:

Update the LCD

--100Hz task:

The motor code

--1000Hz task:

Not used

Common Problems and troubleshooting

Issue #1 - The PWM signal width i see on the Oscilloscope is not correct!
Solution: I observed this while using PWM.set() in periodic functions. I did observe a correct pulse width on the oscilloscope when i did pwm.set in main(). But when i did pwm.set() in the periodic functions, i observed that the PWM signal is giving an incorrect pulse width. The reason is the PWM object is getting destructed. PWM object doesn't get destructed when used in a while(1) loop. When used in the periodic functions, it gets destroyed as soon as the function exits. The solution for this is to make a PWM Singleton Class that doesn't destruct. You can use methods such as motorcontrol.drive() and motorcontrol.steer() to set the PWM's for driving and steering the car. This is a better approach than making the PWM class global.

Issue #2 - The car's ESC initializes but the motor doesn't move irrespective of the PWM value!
Solution: Make sure that the battery is charged. Simple as that.

Issue #3 - How do i find the car's ESC initialization sequence?
Solution: You can use an Oscilloscope for this. As soon as the car is switched on the car's RC module sends a PWM signal to the ESC. The signal's width can be observed by hooking that PWM pin to the oscilloscope. The PWM value can be calculated according to the procedure described above. Give the respective PWM values and the ESC will be initialized.

I/O

Liquid Crystal Display

Fig 9.LCD, Driver and SJOne interface

Fig 10.LCD displaying the values

A 20x4 LCD(CM 204-1) is used for displaying the speed, sensor values and the start and end coordinates. A LCD driver by SJValley Engineering is used for accessing the LCD through UART. The driver and LCD are soldered on to the prototype board. A USB jack is soldered on-board to power the LCD using the 5V supply from the external battery. The connections between the driver and SJOne board is shown in figure 5. As soon as the LCD is powered on, it displays to enter 0xF0 which is the command for detecting the baud rate. After 0xF0 is sent, the data can be transmitted using UART. A baud rate of 38400 is used for displaying information on the LCD. If you are getting some junk values, make sure that the baud rate is set correct and check the soldering.

The LCD with displaying the values is shown in figure 6. The following helps you to organize information on your LCD.

Commands for displaying information on LCD
- urt.put displays a character on the LCD
- urt.putlin displays a character on the LCD and moves the cursor to the next line
- $CLR_SCR is used to clear the screen

Fig 9.Flowchart for LCD

Common Problems and troubleshooting

Issue #1 - LCD is displaying only 2 lines, line 1 and line 3 when i power it on.

Solution: Check the connections. Make sure that the LCD is properly soldered to the driver.

Issue #2 - I am getting garbage values printed on the screen when i try to transfer information over UART

Solution: LCD is not initialized properly. Make sure you get the detecting baudrate information displayed on screen when the LCD is powered on.

Issue #3 - Is it okay to program the LCD while being connected to the SJOne board?

Solution: I didn't find any issues while programming the SJOne board with the LCD connected to it. However, some teams had issues with it.

Issue #4 - How do i update a single field on the LCD keeping the rest static?

Solution: I cleared the entire screen every 100 ms and it looked like only the values are being updated!

GPS Controller

Geographical controller module plays an important role in heading and positioning of autonomous car.It consists of 20GHZ GPS module and 9-DOF RAZOR IMU interfaced to SJ-one board.

The GPS module provides Latitude and Longitude co-ordinates for current position of car.The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to give you nine degrees of inertial measurement.

Hardware Interface

SPARKFUN VENUS GPS with SMA CONNECTOR

Sparkfun Venus GPS is interfaced to SJone Board using UART communication protocol. As shown in above figure ; we have used UART-2 on SJone board to interface with GPS module at 38400 bps. GPS module needs a 2-3 mins of startup time to lock satellites and receive gps co-ordinates.It is recommended to use a coin cell battery or a alternative power source to boot up and lock satellites.

Sparkfun Venus GPS provides GPS information basically the current latitude and longitude in different NMEA standard messages such as

 $GPBOD - Bearing, origin to destination
  $GPBWC - Bearing and distance to waypoint, great circle
  $GPGGA - Global Positioning System Fix Data
  $GPGLL - Geographic position, latitude / longitude
  $GPGSA - GPS DOP and active satellites 
  $GPGSV - GPS Satellites in view
  $GPHDT - Heading, True
  $GPR00 - List of waypoints in currently active route
  $GPRMA - Recommended minimum specific Loran-C data
  $GPRMB - Recommended minimum navigation info
  $GPRMC - Recommended minimum specific GPS/Transit data
  $GPRTE - Routes
  $GPTRF - Transit Fix Data
  $GPSTN - Multiple Data ID
  $GPVBW - Dual Ground / Water Speed
  $GPVTG - Track made good and ground speed
  $GPWPL - Waypoint location
  $GPXTE - Cross-track error, Measured
  $GPZDA - Date & Time

We use $GPGGA - Global Positioning System Fix Data

Time, position and fix related data for a GPS receiver.

Structure: $GPGGA,hhmmss.sss,ddmm.mmmm,a,dddmm.mmmm,a,x,xx,x.x,x.x,M,,,,xxxx*hh<CR><LF>

1 2 3 4 5 6 7 8 9 10 11

Example:

$GPGGA,111636.932,2447.0949,N,12100.5223,E,1,11,0.8,118.2,M,,,,0000*02<CR><LF>

Gpgca NEMA standard description table

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. From our and experience of our project advisors we would recommend a GPS with refresh/update rate of ATLEAST 10Hz.

These are few commands which have 90% usage for most GPS module setup and troubleshooting.

1. Factory Reset
A0 A1 00 02 04 00 04 0D 0A
2. Configure the position update rate of GPS system(10 Hz).
A0 A1 00 03 0E 0A 01 05 0D 0A
3. Configure serial port. this command will set baud rate to 38400.
A0 A1 00 04 05 00 03 01 07 0D 0A
4. Configure NMEA message interval (this command will block all strings except GPGGA).
A0 A1 00 09 08 01 00 00 00 00 00 00 01 08 0D 0A

9 Degree of Freedom RAZOR IMU The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to give you nine degrees of inertial measurement. The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface.

Compass

Hardware Interface

We are using sparkfun Razor IMU to give 9-degree of internal measurement. It has inbuilt triple axis gyroscope, accelerometer and magnetometer. The 8Mhz factory firmware gives compass heading using UART which is raw value of yaw, pitch and roll. The firmware for the Razor IMU is available on the GIT on various platforms such as Ardiuno, Android, Processing etc.

400

We are using Ardiuno platform to download the firmware on the compass using Aurdino software. The same platform and firmware offers functionality to calibrate the compass. Having compass values is not enough for the project as it may or may not work on in real-time, when it is embedded on the car. Magnetometer is sensitive to magnetic field around, hence, the compass needs to be calibrated in the environment where it has to perform i.e on the car. The firmware is written in a way that it shows the deviation from the original value during calibration and gives a final value after the calibration to put as an offset in respective meter. All the meters, gyroscope, accelerometer and magnetometer, needs to be calibrated individually as the final heading is being calculated using values from all the three meters. [1], calibration methods are given on the link mentioned earlier.

Compass firmware in aurdino

Roll

Accelerometer calibration

Accelerometer calibration is done by pointing every axis towards up and down directions and move slowly to get the min and max values respectively and the update the min/max into the firmware file Razor_AHRS.ino.

accel x,y,z (min/max) = X_MIN/X_MAX Y_MIN/Y_MAX Z_MIN/Z_MAX

Magnetometer calibration

Magnetometer extended calibration

Magnetometer calibration is done using processing software which gives the metrics for offset values, given below. It is also extended calibration which is done by the software. There are two type of calibration for magnetometer, one being the hard calibration and soft calibration being the other.
1. Hard calibration: Calibrating the compass with the earth's magnetic field.
2. Soft calibration: Calibration the compass with the surrounding magnetic fields.

  #define CALIBRATION__MAGN_USE_EXTENDED true
  const float magn_ellipsoid_center[3] = {0, 0, 0};
  const float magn_ellipsoid_transform[3][3] = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}};

Gyroscope calibration

Gyroscope calibration is done by keeping gyroscope still for 10 seconds and it gives the average gyroscope values in terms of yaw, pitch and roll.

gyro x,y,z (current/average) = -29.00/-27.98 102.00/100.51 -5.00/-5.85

Calibrating the compass

Heading before calibration

Heading after calibration

Flowchart

Challenges faced

1. Considering cost effectiveness and other projects, we odered HMC5881 compass. There are not so many resources on internet to calibrate the compass right and it gave the heading which differed from the actual north. We tried adding offset in the compass value to ake it work but the offset was fluctuating in all the coordinates also gave different headings after each power cycle.

2. After disappointing results from the HMC5881 compass, we ordered Razor IMU 9DOF compass and unfortunately the compass module turned out to be defective and we learned that after many calibration attampts. The compass was giving different north direction after every power cycle and the heading data was drifting back to same angle after moving the compass. We were able to resolve the drifting issue by removing the error correction code but even after resolving one issue the major issue remained same and not gave the right north direction.

3. For the same Razor IMU 9DOF, the heading was constantly decreasing even for the stagnant position of the compass. The headings were regular and smooth, ie. changed with the movement of the compass but after every power cycle the north pointer was different and in many cases not the right north direction. We were able to get the constant values for the heading by altering the Kp_yaw and Ki_yaw to 0.02f and 0.000045f respectively. to get the north direction, we had to change the Razor IMU module with the new one and it worked as expected after calibration.

4. While receiving GPS checkpoint from IO module, the decoding altered the float data and the data did not match with the data sent from the IO module. We copied the float value to a 4 byte char array to get the right data from IO module.

Master Controller

Master controller is responsible for communication between different controllers and sync each controller's data in directing the car in right direction. It receives ths start or stop command from Android application as soon it receives the command, Master sends motor with the respective message. Master controller listens to the data from sensors and GPS and compass, based on the obstacle avoidance algorithm and GPS co-ordinates, Master decides the right direction for the car and sends it to the Motor.

Software Implementation

Master controller initializes CAN and set the bypass filter on master to accept all incoming CAN messages and in software we process the required data based on the message IDs. as soon as the Controller is up, it initializes the CAN, periodicScehdular task starts executing, where we are using 100Hz function to process all incoming messages and transmitting the CAN messages on to the Bus. if CAN transmission fails, resetcan_bus function is being called to resent the CAN.

Below sections explains the flow in detail.

 main()
  { 
    CAN initialization
    periodicschedular task
  }

Heart Beat mechanism

Hearbeat message flow

The heart beat mechanism is included in order to check for aliveness of each of the controller. There are totally five controllers including the Master Controller. The heart beat algorithm has been included in every of the controllers,

      1) Every controller sends a CAN message with their own respective msessage ID's 

      2) During the reception of the CAN Messages, there is a difference between the tasks between Master and other controller's 

               Master Side:

                      1) Receive the CAN message

                      2) Decode the message id and Update the Counter value associated with that Message ID.

               Other Controllers Side:

                      1) If message is from Master, then toggle their LED

                      2) Ignoring the other messages

      3) The Controllers are checked for aliveness every 10 seconds by comparing the current and old counter values. 

                      1) If both old and current counter values matches, then corresponding controller is considered to be dead and LED is light up.

                      2) If they doesn't match then the status has been received and controller is alive.

Obstacle avoidance and car navigation Algorithm

Based on the data received from GPS Controller and sensor values, Master would decide the direction and steer values for the car and update the motor with the required direction and steer data. Direction and steer value computation is based on the below algorithm.

Obstacle avoidence and car navigation algorithm

PSEUDOCODE:

   if (Start command from android or Switch)
       if (GPS starts sending the valid data)
        {
           if Destination_Reached == TRUE
             return STOP command          
           else (Listen to the Sensor first and if no obstacle listen to GPS Direction)
              if NO OBSTACLE detected
                 return GPS DIRECTION
             
               if RIGHT OBSTACLE detected
                if GPS_DIRECTION == RIGHT
                  RETURN STRAIGHT
                 else
                  RETURN GPS_DIRECTION

               if STRAIGHT OBSTACLE detected
                  (Compare RIGHT and LEFT SENSOR)
                  if RIGHT OBSTACLE is NEAR than LEFT SENSOR:
 		      RETURN RIGHT
		    else
                     RETURN LEFT
      
               if STRAIGHT and RIGHT OBSTACLE detected
                  RETURN SLIGHT_LEFT
		
               if LEFT OBSTACLE detected:
                  if GPS_DIRECTION == LEFT
                    RETURN STRAIGHT
                  else
                    RETURN GPS_DIRECTION

               if LEFT and RIGHT OBSTACLE detected
                  RETURN STRAIGHT

               if STRAIGHT and LEFT OBSTACLE detected
                  RETURN SLIGHT_RIGHT
	
               if STRAIGHT, LEFT and RIGHT OBSTACLE detected 
                  if REAR SENSOR detected
                    RETURN STOP
                  else 
                    RETURN REVERSE

GPS Direction:

               if COMPASS_Angle == 0
                 return STRAIGHT Command                
               else if COMPASS_DIRECTION = 1
                 return RIGHT command              
               else
                 return LEFT command

Periodic Callback Functions :

We used periodic callback functions in implementing CAN communication between controllers to make the communication deterministic and real-time. We used 100Hz in implementing the CAN communication for transmitting and receiving CAN messages.

100Hz function is used to process CAN messages received by Master controller, compute the required direction and to transmit the CAN message to Motor controller, It processes up to five messages in one function call and it also completes executing obstacle avoidance algorithm and based on GPS data, required direction is computed and CAN message is transmitted with required direction details and steer data to Motor Controller.

Periodic Schedular task

100Hz Function:

{
     Receive and process sensor controller data
     Receive and process GPS+Compass controller data
     Receive and process Birdge controller data
     Compute the direction of the car based on Sensor and GPS data
     Transmit CAN message to Motor with required direction or stop condition. 
}

Bluetooth Control and Android application

Hardware Design

A BTBEE Pro Bluetooth XBee socket chip connected to the SJOne board is the main hardware component used in Bridge communication.It is interfaced to the SJONE board over UART2. The SJONE board is in turn interfaced with the CAN Bus using a MCP2551 CAN Transceiver.

Hardware Interface

The BTBEE Pro is placed on the XBee socket of the SJOne board. This design was chosen over using I2C/SPI interface as SJONE board has a XBEE socket which can be used directly.The BT module communicates with the SJOne board using a UART interface. Uart2 on the SJONE board is used for this purpose. In order to enable the communication over UART, the switch on the SJONE board needs to set to UART2 position.

Bluetooth Hardware Interface

Software Design

The Software design of the Bluetooth and android Bridge control system consists of two main parts
1) Bluetooth to CAN Bridge Software on SJONE board 2) Thunderbird Android Application

Bluetooth to CAN Bridge

The Bluetooth chip is initialized by passing the following commands over bluetooth.

Bluetooth initialization commands

Once the chip the initialized data is sent and received from the android app to the SJONE board by treating the Bluetooth connection as a UART bus using uart api's like uart2.getChar and uart2.printf.

In our bridge controller we have written the algorithm to parse input characters from uart and take action based on the sequence of characters that make up a command. The bridge controller responds to the following commands.
a) Hello - Hello message from android. The SJONE board responds with the current GPS coordinates.
b) Start - Start message from android. The SJONE board responds with HI to begin exchange of one GPS checkpoint value.
c) Stop - Stop message from android. The SJONE board responds with the number of GPS coordinates it received from Android.
d) Good - Car start message from android. The SJONE board transmits a start message to Master controller to start transmitting commands on can bus to control the car.
e) Bad - Emergency start message from android. The SJONE board transmits a stop message to the Master controller to send stop command on the can bus to all controllers.

Bluetooth Commands Parsing

Parsing float information from android

We have used a state machine approach to receive latitude and longitude float values from android app. The state machine is explained as a flowchart below.

Bluetooth Float Parsing

Updating analytics values to android

Updating analytics value to the android app is an important functionality of bluetooth controller. We read all messages on the can bus and store the values in dbc defined global variables. At 1 hz we send this out to the Android app. The analytics values that are sent to android are as follows
a) Induvidual sensor readings
b) Last command issued by Master
c) Speed of the car from Motor
d) Latitude, Longitude and Heading values from GPS.

Android Application Software Design

In our project android application is used to perform the following tasks around which we have designed the application. a) Connect to the truck over bluetooth
b) Get its current location
c) Set the destination for the truck to reach
d) View analytics information broadcasted over bluetooth

The above structure is clearly reflected in the activites used in the android application. We have 4 activities that makes up our android application. Intents and Bundled data is used to transmit information from one activity to another.

a) Welcome activity
The welcome activity is the first activity that is shown to the user. In this activity the user is presented with options to connect to the device. When the user clicks on the connect button a list of bluetooth devices are shown to the user and the user selects the truck and connects to it. Once connected we show the options activity.

b) Options activity
The options activity is the second activity shown to the user after he connects to the truck. In this activity we show options to obtain the current gps location from the device. This activity also serves as the analytics page where the different values obtained from bridge. The values are obtained from the bluetooth activity using intents.

c) Map activity
The Map activity is the activity where the user can select a destination. We have used Android-GoogleDirectionLibrary by akexorcist to show the map interface and set destination. We also used the library to get checkpoint data from Google directions API. A server key is used for authentication by the Google server before obtaining checkpoints .The checkpoints data is transmitted to bridge controller using the bluetooth activity.

d) Bluetooth Activity
The bluetooth activity forms the crux of the application. It receives intents with data to be transmitted to the SJONE board from all other activities. We have used Android-BluetoothSPPLibrary by akexorcist to establish and negotiate bluetooth connection and send and receive data. This activity also periodically receives analytics data and sends it to the options activity where it is displayed

Use Case Flow Chart

We expect the user to follow this flow chart to use the app to interact with the truck.

User Interaction Flow Chart

Android UI design

The UI was designed with simplicity and quick development time in mind. It was designed in the UI editor of Android Studio. The following are screenshots from application.

Periodic Scheduler Design

One Hertz Task

In One hertz task. We send analytics values to android app by UART over bluetooth. The analytics values sent are sensor values,motor directions sent by master, speed of car from motor, heading and location of the truck.

Ten Hertz Task

In 10 hertz task we read and write to the CAN bus to update DBC generated structures which represent the latest values received on the BUS.

Hundred Hertz Task

In 100 hertz task we read characters from the Bluetooth Uart connection and parse and execute appropriate commands.

Challenges Faced

a) Could not interface the UART connection with Terminal code of SJONE board to use existing command handler code
Solution: Develop custom code to parse data to and from the uart connection treating it as a char driver.

b) Bridge controller crashes when both CAN and Bluetooth communication are done in 100 hz task
Solution: Move Can communication to 10 hertz task

c) Bridge and Android app developed before other subsystems were fully functional
Solution: Create a Test section in Android app that uses hard coded values from sjsu board and goes through the user process.

d) GPS values sent and received are -1 times the ones used by GPS system
Solution: Multiply by -1 in all places when reading and writing values to the SJONE board.

Testing & Technical Challenges

CAN_DBC

Problem : The introduction of CAN DBC in the middle of the project was not well orchestrated and derailed the project from the schedule
Solution : If a major change such as CAN DBC needs to be made special efforts need to be taken to ensure proper coordination between the sender and receiver for every message added on the bus. Do not use experimental features like message multiplexer as it added to 2 extra days of debugging to figure out a software issue that mux is poorly implemented.

Project Manangement

Problem : Lack of proper time and project management led to schedules being missed.
Solution : At the begining of the project nominate a person as Project manager. This person should ensure proper communication between team members and review individual team status and high level algorithms for induvidual components frequently and look for quick methods to solve high level problems. Do not depend on team members physical presence. Use skype calls and other team collab tools to ensure weekly meeting and team progress.

Code Review

Problem : Lack of proper code review led to small software bugs which cause major delay due to debug time and effort
Solution : Assign a person for every person to review the other person's contribution from another team. This could help reduce small small bugs which have big time and effort impact.

Figuring out team strengths

Problem : People chose new domains different from their comfort zone to contribute to the project
Solution : People should choose subsystems based on their strengths. Even if you want to learn something new, you can learn after project, not during project. The project should proceed according to schedule which is already very difficult to follow. There should be no delay due to experimental work. All experiments can be done after the project is done. In all actions and decisions taken during project ask only one question. Will this help the project to work in the demo? do not worry about individual learning goals.

Conclusion

This was a very interesting and challenging team project. We gained good technical embedded application knowledge and it also helped us gaining team organization and management skills. This project gave us good exposure to different modules such as sensors, MOTOR, GPS, Android application and CAN bus, which made us comfortable to work on any new module by exploring its features. We would suggest the future teams working on this project to set individual goals and divide the major tasks into several small tasks and work towards them to be more productive. Overall experience of this project was very good, and we call it one of the best projects we worked on.

Project Video

Here is our demo.

THUNDERBIRD

Project Source Code

GitLab Source Code Link

References

Acknowledgement

We would like to thank Preet for guiding us throughout the semester and for giving us such the wonderful opportunity to work on this project. We would also like to thank Mr.Mitesh Sanghvi and the entire ISA team for their constant support and encouragement. Finally, it would not have been possible to work on the project without the entire team's support for each other. The team worked really hard to achieve the final goal of making the Self Driving RC Car work!

References Used

[1]Kang, P.(2015).CMPE243: Embedded system Application, notes [Power point slides and lecture notes]
[2]LPC1758 User Manual
[3]Real time OS on embedded system
[4]Razor IMU
[5]Razor IMU tutorial 1
[6]Razor IMU tutorial 2 
[7]Sparkfun GPS info
[8]Maxbotix Sonar Sensor
[9]LCD
[10]Android Google Direction Library
[11]Bluetooth SPP Library

@@ Line 1: / Line 1: @@
 == ThunderBird : Self Driving Car ==
+[[File:F15_ThunderBird_System_Diagram1.jpg|300px|Fig 1.ThunderBird Diagram]]
+[[File:F15_ThunderBird_System_Diagram2.jpg|200px|Fig 2.ThunderBird Diagram]]
+[[File:F15_ThunderBird_System_Diagram3.jpg|300px|Fig 3.ThunderBird Diagram]]
+[[File:F15_ThunderBird_System_Diagram4.jpg|300px|Fig 4.ThunderBird Diagram]]
+[[File:F15_ThunderBird_System_Diagram5.jpg|300px|center|Fig 5.ThunderBird Diagram]]
 == Abstract ==
-ThunderBird is a 1/10 2 WD electric short self-driving truck. The truck is equipped with sensors to detect obstacles, GPS for getting directions, Compass for the truck's orientation, Bluetooth for communicating with the android device and LCD for displaying the sensor values on screen. The modules are interfaced using 5 SJ One boards which features a Cortex-M3 LPC1758. CAN bus is used for communicating between the modules. Android device is used to send start message and enter the destination coordinates through Bluetooth. Based on the GPS co-ordinates master directs the motor in respective direction and if the sensors detect obstacles, it signals the motors to drive the car accordingly. based on GPS co-ordinates and sensor values Master directs the motor until destination is reached
+ThunderBird is a 1/10 2 WD electric short self-driving truck. The truck is equipped with sensors to detect obstacles, GPS for getting directions, Compass for the truck's orientation, Bluetooth for communicating with the android device and LCD for displaying the sensor values, velocity of the truck and current heading on screen. The modules are interfaced using 5 SJ One boards which features a Cortex-M3 LPC1758. CAN bus is used for communicating between the modules. Android device is used to send start message and enter the destination coordinates through Bluetooth. Based on the GPS co-ordinates master directs the motor in respective direction and if the sensors detect obstacles, it signals the motors to drive the car accordingly. Based on GPS co-ordinates and sensor values Master directs the truck until destination is reached.
 == Objectives & Introduction ==
@@ Line 9: / Line 14: @@
 === Objective ===
 Objective of this project is to be able to work as a team of ten members to develop an Autonomous self driving Car. which gives us the real time work experience as the team of ten members has to be divided into subteams and work on individual modules(Sensors controller, Motor and I/O controller, GPS controller, Android controller and Master controller ) by collaborating with other sub team members for communication between the modules.
+Main goal of this project is to understand how CAN protocol works and its architecture in detail, as all controllers of the system communicate through CAN bus.
 === Team Members & Responsibilities ===
@@ Line 21: / Line 28: @@
 ** Akhil Bhargav Josyabhatla
 * Sensors
-** Nitesh Jain
+** [https://www.linkedin.com/in/nitesh-jain-82452719/ Nitesh Jain]<br>
 ** [https://www.linkedin.com/in/rajashreekambli/ Rajashree Kambli]<br>
 * GPS
-** Rishit Borad
+** Rishit Borad<br>
-** Ravi Vanjara
+** [https://www.linkedin.com/in/ravivanjara/ Ravi Vanjara]<br>
+*Bridge/Android Controller
+** James Sushanth Anandraj<br>
+** Athavan Kanagasabapathy<br>
+=== Introduction ===
+[[File:F15_ThunderBird_System_Block_Diagram.jpg|1000px|Fig 1.ThunderBird System Block Diagram]]
+Our Autonoumous self-driving car is designed in a way that it has five controllers to deal with different functions of the car and these controllers communicate through CAN bus, below is the description for various controllers.
+* '''Bridge Controller''' : Bridge controller receives the start, stop messages and check points from the android application and it sends the start and stop messages over CAN bus in order to start and stop the car.
+* '''Motors and I/O Controller''' : Motor controller receives the steer and direction information from the master controller and navigates the car in required direction.
+* '''Sensors Controller''' : There are four sensors mounted on the car, three in front and one on rear, sensor controller update the motor with obstacle information by sending the updates from the sensors.
+* '''GPS Controller''' : GPS controller sends the updated direction and the distance to the destination.
+* '''Master Controller''' : Master controller collaborate the messages from Brdidge, sensor and GPS controllers and directs the motor in required direction.
+=== Overall Algorithm ===
+. Android/Bridge controller sends the start command to master controller as soon it receives start from android app.
+. GPS controller sends the current location to Bridge and Bridge relays the current co-ordinates to android app.
+. Android application sends the required destination to the Bridge controller and Bridge controller sends the information to GPS controller.
+. Based on the current location and destination, GPS+Compass controller decides the required direction for the car to navigate and sends it to Master
+        controller.
+. Master starts listening to sensor data from sensor controller, required direction from GPS+compass controller and it also keeps listening to android
+       controller for any stop message.
+. As soon as Master receives GPS start command, Master controller starts calculating the right direction for the car to navigate.
+. Sensor Controller keeps sending sensor values on the bus and  Motor+IO controller, Bridge controller.
+. Bridge controller sends the sensor values to android app for the displays, android app keeps updating its sensor values as soon as receives an
+       update from bridge controller.
+. Motor+IO controller keeps listening to the data from GPS+Compass controller for the heading direction and updates the LCD display accordingly.
+. Motor+IO controller updates all the sensor values on the LCD display as soon as it receives the update from sensor controller.
+. Master decides the right direction for the car based on sensor values and GPS-co ordinates, sends the message to Motor to move the vehicle in decided
+        direction.
+. Motor listens to the direction from Master controller and directs the car accordingly. .
+. Step 4 to 12 continue until the Master receives stop command from Android controller or destination reached message from GPS Controller.
+. As soon as Master receives stop message or destination reached command, Master sends stop message to Motor Controller.
+. Motor controller stops the car as soon as it receives stop command from Master controller.
+=== Controllers ===
 == Schedule ==
@@ Line 78: / Line 122: @@
 | 11/05/2015
 | Interface GPS and compass
-|
+| Completed
-|
+| 11/6/15
 |-
 ! scope="row"| 7
@@ Line 92: / Line 136: @@
 | 11/27/2015
 | Interface modules over CAN bus
-|
+| Completed
-|
+| 11/26/15
 |-
 ! scope="row"| 9
@@ Line 99: / Line 143: @@
 | 12/05/2015
 | Integrating modules
-|
+| Completed
-|
+| 12/8/15
 |-
 ! scope="row"| 10
@@ Line 106: / Line 150: @@
 | 12/13/2015
 | Testing
-|
+| Completed
-|
+| 12/15/15
 |-
 ! scope="row"| 11
@@ Line 113: / Line 157: @@
 | 12/19/2015
 | More Testing
-|
+| Completed
-|
+| 12/18/15
 |}
@@ Line 181: / Line 225: @@
 |11/24/2015
 |Fine turning motors for precise control
-|
+|Completed
-|
+|11/24/15
 |-
 |-
@@ Line 189: / Line 233: @@
 |12/01/2015
 |Fine tuning (buffer)
-|
+|Completed
-|
+|12/2/15
 |-
 |-
@@ Line 197: / Line 241: @@
 |12/08/2015
 |Testing and debugging
-|
+|Completed
-|
+|12/10/15
 |-
 |}
@@ Line 226: / Line 270: @@
 |10/20/2015
 |Interface GPS using I2C with SJOne board
-|Ongoing
+|Completed
-|
+|10/20/15
 |-
 |-
@@ Line 234: / Line 278: @@
 |10/27/2015
 |Interface Compass with SJOne board
-|
+|Completed
-|
+|10/27/15
 |-
 |-
@@ Line 242: / Line 286: @@
 |11/3/2015
 |Calibrate Compass and GPS
-|
+|Completed
-|
+|11/2/15
 |-
 |-
@@ Line 250: / Line 294: @@
 |11/10/2015
 |Parse raw data and create meaningful data
-|
+|Completed
-|
+|11/21/15
 |-
 |-
@@ Line 258: / Line 302: @@
 |11/17/2015
 |Implement CAN communication with SJOne board
-|
+|Completed
-|
+|11/19/15
 |-
 |-
@@ Line 266: / Line 310: @@
 |11/24/2015
 |Test and debug GPS & Compass locally
-|
+|Completed
-|
+|11/24/15
 |-
 |-
@@ Line 274: / Line 318: @@
 |12/01/2015
 |Integrate GPS/Compass module with Master board
-|
+|Completed
-|
+|12/2/15
 |-
 |-
@@ Line 282: / Line 326: @@
 |12/08/2015
 |Implement routing algorithm for Car
-|
+|Completed
-|
+|12/10/15
 |-
 |-
@@ Line 290: / Line 334: @@
 |12/15/2015
 |Test and Debug GPS/Compass integration with master
-|
+|Completed
-|
+|12/17/15
 |-
 |-
@@ Line 360: / Line 404: @@
 |12/06/2015
 |Test for stability of sensors and report.
-|Ongoing
+|Completed
-|
+|11/31/15
 |-
 |-
@@ Line 368: / Line 412: @@
 |12/13/2015
 |Prepare for Demo.
-|
+|Completed
-|
+|12/13/15
 |-
 |-
@@ Line 398: / Line 442: @@
 |10/20/2015
 |Can setup components purchase, Can bus design and soldering
-|Ongoing
+|Completed
-|
+|10/20/15
 |-
 |-
@@ Line 406: / Line 450: @@
 |10/27/2015
 |Basic Can communication testing by sending and receiving data and can msg specification for all controllers and messages.
-|
+|Completed
-|
+|10/27/15
 |-
 |-
@@ Line 414: / Line 458: @@
 |11/3/2015
 |Development and implementation of Algorithm for driving car and obstacle avoidance.
-|
+|Completed
-|
+|11/2/15
 |-
 |-
@@ Line 422: / Line 466: @@
 |11/10/2015
 |Interface bt dongle with sjone board and android device and test with commands
-|
+|Completed
-|
+|11/11/15
 |-
 |-
@@ Line 430: / Line 474: @@
 |11/17/2015
 |Develop Android GUI and application to interact with car using bluetooth. Implement all necessary commands on sjone board for communication with android device. Interface with Motor and IO Controller.
-|
+|Completed
-|
+|11/18/15
 |-
 |-
@@ Line 438: / Line 482: @@
 |11/24/2015
 |Test and debug Master algorithm and Android interface locally and with Motor controller interfaced by providing predetermined directional commands.
-|
+|Completed
-|
+|11/23/15
 |-
 |-
@@ Line 446: / Line 490: @@
 |12/01/2015
 |Integrate Master Board with all boards and implement heartbeat protocol.
-|
+|Completed
-|
+|11/2/15
 |-
 |-
@@ Line 454: / Line 498: @@
 |12/08/2015
 |Test run 1 with all boards integrated and with all planned features developed.
-|
+|Completed
-|
+|12/8/15
 |-
 |-
@@ Line 462: / Line 506: @@
 |12/15/2015
 |Test run 2 after solving issues found in test run 1.
-|
+|Completed
-|
+|12/17/15
 |-
 |-
@@ Line 521: / Line 565: @@
 |-
 ! scope="row" align="center"|7
-| CAN Transceiver (Free Samples)
+| CAN Transceiver
 | align="center"| Microchip
 | align="center"| MCP2551
 | align="center"| 6
-| align="right"| $0.00
+| align="right"| $25.00
+|-
+! scope="row" align="center"|8
+| Bluetooth Module
+| align="center"| Exbee
+| align="center"| standalone
+| align="center"| 6
+| align="right"| $20.00
 |-
 ! scope="row" align="center"|
@@ Line 532: / Line 583: @@
 |
 |
-| align="right"| <b>----</b>
+| align="right"| $847.00
 |-
 |}
@@ Line 556: / Line 607: @@
 ! scope="col"| Controller Type
 |-
-| 0x000
+| 0xA0
-| All Controller
-|-
-| 0x001
 | Master Controller
 |-
-| 0x010
+| NO TX
-| Motor Controller
+| Motor Controller & I/O Controller
 |-
-| 0x011
+| 0xB0
 | GPS
 |-
-| 0x100
+| 0xC8
 | Sensor
 |-
-| 0x101
+| 0x00
-| I/O Controller
-|-
-| 0x110
 | Android Controller
 |}
-==== Controller Communication Table ====
+This DBC File has used to communicate between all controllers in RC Car.
+VERSION ""
+NS_ :
+	NS_DESC_<br>
+	CM_<br>
+	BA_DEF_<br>
+	BA_<br>
+	VAL_<br>
+	CAT_DEF_<br>
+	CAT_<br>
+	FILTER<br>
+	BA_DEF_DEF<br>
+	EV_DATA_<br>ha
+	ENVVAR_DATA_<br>
+	SGTYPE_<br>
+	SGTYPE_VAL_<br>
+	BA_DEF_SGTYPE_<br>
+	BA_SGTYPE_<br>
+	SIG_TYPE_REF_<br>
+	VAL_TABLE_<br>
+	SIG_GROUP_<br>
+	SIG_VALTYPE_<br>
+	SIGTYPE_VALTYPE_<br>
+	BO_TX_BU_<br>
+	BA_DEF_REL_<br>
+	BA_REL_<br>
+	BA_DEF_DEF_<br>REL_
+	BU_SG_REL_<br>
+	BU_EV_REL_<br>
+	BU_BO_REL_<br>
+	SG_MUL_VAL_<br>
+BS_:
+BU_: NOONE SENSOR DRIVER MOTOR GPS IO
+BO_ 0xA0 HEARTBEAT: 1 DRIVER
+ SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS
+BO_ 0xA1 sensorback: 1 SENSOR
+ SG_ SENSOR_BACK_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GPS,IO
+BO_ 0x02 IOSTART: 1 IO
+ SG_ IOSTART_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER
+BO_ 0x01 IOSTOP: 1 IO
+ SG_ IOSTOP_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER
+BO_ 0x03 IOCHECKPOINTCOUNT: 1 IO
+ SG_ IOCOUNT_cmd : 0|8@1+ (1,0) [0|0] "" GPS,DRIVER
+BO_ 0x05 GPSCHECKPOINTCOUNT: 1 GPS
+ SG_ GPSCOUNT_cmd : 0|8@1+ (1,0) [0|0] "" IO,DRIVER
+BO_ 0x04 IOGPSCHECKPOINT: 8 IO
+ SG_ IOLATITUDE : 0|32@1+ (0.1,0) [0|0] "DEGREE" DRIVER,GPS
+ SG_ IOLONGTITUDE : 32|32@1+ (0.1,0) [0|0] "DEGREE" DRIVER,GPS
+BO_ 0xB0 COMPASS: 4 GPS
+ SG_ COMPASS_direction : 0|8@1+ (1,0) [0|0] "DIRECTION" DRIVER,GPS,MOTOR
+ SG_ COMPASS_angle : 8|16@1- (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+BO_ 0xB1 GPS_longitude: 8 GPS
+ SG_ GPS_longitude_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+ SG_ GPS_longitude_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+BO_ 0xB2 GPS_latitude: 8 GPS
+ SG_ GPS_latitude_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+ SG_ GPS_latitude_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+BO_ 0xB3 GPS_heading: 8 GPS
+ SG_ GPS_heading_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+ SG_ GPS_heading_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR
+BO_ 0xB4 GPS_dest_reached: 4 GPS
+ SG_ GPS_dest_reached : 0|32@1+ (1,0) [0|0] "" DRIVER,GPS,MOTOR
+BO_ 200 SONARS: 6 SENSOR
+ SG_ SENSOR_SONARS_mux M : 0|4@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_s1_fault : 4|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_s2_fault : 5|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_s3_fault : 6|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_s4_fault : 7|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_left m0 : 8|12@1+ (0.1,0) [0|400] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_middle m0 : 20|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_right m0 : 32|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_rear m0 : 44|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
+ SG_ SENSOR_SONARS_no_filt_left m1 : 8|12@1+ (0.1,0) [0|400] "" NOONE
+ SG_ SENSOR_SONARS_no_filt_middle m1 : 20|12@1+ (0.1,0) [0|400] "" NOONE
+ SG_ SENSOR_SONARS_no_filt_right m1 : 32|12@1+ (0.1,0) [0|400] "" NOONE
+ SG_ SENSOR_SONARS_no_filt_rear m1 : 44|12@1+ (0.1,0) [0|400] "" NOONE
+BO_ 0X020 MOTOR_CMD: 3 DRIVER
+ SG_ MOTOR_CMD_steer : 0|8@1- (1,0) [0|0] "" MOTOR
+ SG_ MOTOR_CMD_drive : 8|8@1+ (1,0) [0|0] "" MOTOR
+ SG_ MOTOR_CMD_angle : 16|8@1+ (1,0) [0|0] "" MOTOR
+CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one";
+CM_ BU_ DRIVER "The DRIVER controller driving the car";
+CM_ BU_ SENSOR "The sensor controller of the car";
+CM_ BU_ MOTOR "The motor controller of the car";
+CM_ BO_ 0xA0 "Sync message used to synchronize the controllers";
+BA_DEF_  "BusType" STRING ;
+BA_DEF_ SG_ "FieldType" STRING ;
+BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
+BA_DEF_DEF_ "BusType" "CAN";
+BA_DEF_DEF_ "FieldType" "";
+BA_ "GenMsgCycleTime" BO_ 0xA0 1000;
+BA_ "GenMsgCycleTime" BO_ 0x01 100;
+BA_ "GenMsgCycleTime" BO_ 0X020 100;
+BA_ "FieldType" SG_ 0xA0 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
+VAL_ 0xA0 DRIVER_HEARTBEAT_cmd 1 "DRIVER_HEARTBEAT_cmd_NOOP" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 2 "DRIVER_HEARTBEAT_cmd_REBOOT";
+=== Hardware Design ===
+[[File:F15_ThunderBird__CAN_Diagram.jpg|900px|center|Fig 1.ThunderBird Hardware Diagram]]
+The hardware was designed in a very clean and neat design with the help of 17 pin jumper cables matching the SJ-One board in order to save the space and avoid the multiple layers of wiring. Every hardware parts were built upon after careful consideration.
+The CAN Controller used is MCP2551. It is a high speed transceiver which serves as boundary for all the SJ-One controllers which helps to communicate with each other. The operating speed of the bus is upto 1 megabits per second. The high and low signal acting as the output are protected internally against any short-circuits and sudden transitions in voltage level. The connection to SJ-One board is shown s per below diagram,
+[[File:F15_ThunderBird_HW_CANBLOCK.jpg|center|500px|Fig 1.SJ-One Board - CAN Interface]]
+'''Pin Connections'''
 {| class="wikitable"
 |-
-! scope="col"|Message ID
+! scope="col"| SI No.
-! scope="col"|Destination ID
+! scope="col"| CAN Pin
-! scope="col"|Source ID
+! scope="col"| SJ-One Pin
-! scope="col"|CAN ID
+! scope="col"| Main Board
-! scope="col"|Message function
+! scope="col"| Function
-! scope="col"|Message Data
-! scope="col"|From
-! scope="col"|Receieved By
 |-
-| 0x00000
+! scope="row"| 1
-| 0x000
+| 1
-| 0x000
+| P0.1
-| 0x000
+|
-| Kill
+| TXD of SJ-One board connected to TX pin of transceiver
-| NoData
-| Master
-| All
 |-
-| 0x00001
+! scope="row"| 2
-| 0x001
+| 2
-| 0x110
+| Vcc
-| 0x04E
+|
-| Android stop
+| Voltage supply to transceiver
-| NoData
-| Android Bridge
-| Master
 |-
-| 0x00010
+! scope="row"| 3
-| 0x001
+| 3
-| 0x110
+| GND
-| 0x08E
+|
-| Android start
+| Common ground connection
-| NoData
-| Android Bridge
-| Master
 |-
-| 0x00011
+! scope="row"| 4
-| 0x001
+| 4
-| 0x100
+| P0.0
-| 0x0CC
+|
-| Sensor data
+| RXD of SJ-One board connected to RX pin of transceiver
-| Byte[0]: Left sensor <br> Byte[1]: Front sensor <br> Byte[2]: Right sensor <br> Byte[3]: Rear sensor <br> Byte[4]: Speed
-| Sensors
-| Master
 |-
-| 0x00100
-| 0x011
-| 0x001
-| 0x119
-| Current position request
-| NoData
-| Master
-| GPS
 |-
-| 0x00101
+! scope="row"| 5
-| 0x001
+| 6
-| 0x011
+|
-| 0x14B
+| Low Wire
-| Geo direction
+| Connected to a common wire carrying CANL signals
-| Byte[0]: Current Angle <br> Byte[1]: Desired Angle
-| GPS
-| Master
 |-
-| 0x00110
-| 0x001
-| 0x011
-| 0x18B
-| Geo data
-| Byte[0]: Latitude1 <br> Byte[1]: Latitude2 <br> Byte[2]: Longitude1 <br> Byte[3]: Longitude2 <br> Byte[4]: Distance to next checkpoint <br> Byte[5]: Checkpoint reached?
-| GPS
-| Master
 |-
-| 0x00111
+! scope="row"| 6
-| 0x010
+| 7
-| 0x001
+|
-| 0x1D1
+| High Wire
-| Motor Command
+| Connected to a common wire carrying CANH signals
-|Byte[0] Forward : 0 <br> Byte[0] Left : 1 <br> Byte[0] Right : 2 <br> Byte[0] Reverse : 3 <br> Byte[0] Stop : 4
-| Master
-| I/O & Motor
-|-
-| 0x01000
-| 0x101
-| 0x001
-| 0x229
-| Display Start
-| NoData
-| Master
-| I/O & Motor
-|-
-| 0x01001
-| 0x101
-| 0x001
-| 0x269
-| Display data
-| Byte[0]: Speed <br> Byte[1]: Distance to next checkpoint
-| Master
-| I/O & Motor
 |-
 |}
-=== 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 ===
-Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
 === Implementation ===
-This section includes implementation, but again, not the details, just the high level.  For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
+=== Working Mechanism ===
+[[File:F15_ThunderBird_System_WorkingMechanismFlowDiagram.jpg|1020px|center|Fig 1.ThunderBird System ImplementationFlow__Diagram]]
+<br>
+<br>
+[[File:F15_ThunderBird_System_WorkingMechanismFlowGIF.gif|500px|thumb|center|text-top|Fig 2.ThunderBird System Flow Diagram]]
 == Sensor Controller ==
@@ Line 712: / Line 834: @@
 <br>
 [[File:F15_ThunderBird_sensor_hardwarelayout.jpg|700px|thumb|center|text-top|Fig 3. Board-Block-Diagram]]
+[[File:F15_ThunderBird_sensor_mount.jpg|700px|thumb|right|text-top|Fig 3. sensor mount]]
 <br>
 mS after power-up, the LV-MaxSonar-EZ is ready to accept the RX command. If the RX pin is left open or held high, the sensor will first run a calibration cycle (49mS), and then it will take a range reading (49mS). After the power up delay, the first reading will take an additional ~100mS. Subsequent readings will take 49mS. The LV-MaxSonar-EZ checks the RX pin at the end of every cycle. Range data can be acquired once every 49mS.
@@ Line 718: / Line 841: @@
 Each 49mS period starts by the RX being high or open, after which the LV-MaxSonar-EZ sends the transmit burst, after which the pulse width pin (PW) is set high. When a target is detected the PW pin is pulled low. The PW pin is high for up to 37.5mS if no target is detected. The remainder of the 49mS time (less 4.7mS) is spent adjusting the analog voltage to the correct level. When a long distance is measured immediately after a short distance reading, the analog voltage may not reach the exact level within one read cycle. During the last 4.7mS, the serial data is sent.
 <br>
 ==== Sensor Software Design and Algorithm ====
-[[File:F15_ThunderBird_sensor_StateDiagram.jpg|500px|thumb|center|text-top|Fig 4. Sensor State Diagram]]
 The following steps are for initializing, getting readings and calculating distance in inches for one sensor-
+Main init function:
+) Configure the PW pin of sensor as input.
-) Configure the PW pin of sensor as input.
 ) Configure RX pin of the sensor as output and set it high.
-) Enable the Rising and the Falling edge interrupt on the PW pin of the sensor
+) Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.
 ) Note down the sys_get_uptime_us() at the rising interrupt. Let this time be T1.
@@ Line 736: / Line 859: @@
 ) Send this value to the Master controller via the CAN bus.
+====Periodic Callback Functions:====
+We are using the periodic callback functions.Hence we implemented the algorithm around those tasks.We used static variables in order to preserve the values incase functions are completed and the desired tasks are not completed yet. We used only the 1000Hz and 100Hz tasks.
+=====--1000Hz task:=====
+Start 1st sensor.
+Get fall edge and calculate value.
+Stop sensor and start next.
+=====--100Hz task:=====
+Get all 4 sensor values and send to Master and Motor via Can.
+This is the snippet of our Interrupt function callbacks.
+ eint3_enable_port2(RightSensorPW_Pin, eint_rising_edge, eintCallbackright_Rise);
+ eint3_enable_port2(RightSensorPW_Pin, eint_falling_edge, eintCallbackright_Fall);
+ void eintCallbackright_Rise()
+ {
+   //Note down the system start time for right sensor ( start_right_time)
+ }
+ void eintCallbackright_Fall()
+ {
+  //Note down the current system time
+  //Subtract the start_right_time from the current system time and divide the result by 147 to get the distance in inches.
+ }
+[[File:F15_ThunderBird_sensor_OverallSensorfinal.gif|thumb|center|450px|text-top|Fig 4.Sensor workflow]]
 <br>
-[[File:F15_ThunderBird_sensor_SOFTWARE_FLOWCHARTEDITED.png|700px|thumb|center|text-top|Fig 5. Sensor Flow chart ]]
+[[File:F15_ThunderBird_sensor_TimingDiagram.png|700px|thumb|right|text-top|Fig 5. Sensor Timing Diagram]]
+[[File:F15_ThunderBird_sensor_StateDiagram.jpg|600px|thumb|right|text-top|Fig 6. Sensor State Diagram]]
+[[File:F15_ThunderBird_sensor_SOFTWARE_FLOWCHARTEDITED.png|700px|thumb|center|text-top|Fig 7. Sensor Flow chart ]]
 <br>
 ==== Sensor: Technical Challenges ====
 <br>
-) Fluctuating sensor values: We observed random shoots in the sensor values. Sometimes, the value was even zero.
+'''Issue #1''' - Fluctuating sensor values: We observed random/fluctuation in the sensor values. Sometimes, the value was even zero.The primary reason was that we were using the ADC mode. ADC mode converts analog to digital values received from the sensors. The values were unstable and unreliable.We could have used an arbitration to get accurate values. But the SJSU one board has only 3 ADC pins and we have 4 sensors to mount. So,either way we could not use ADC mode.
+<br>
+Solution: Switched from ADC mode to PWM mode to get more reliable values,with minimum spikes.PWM mode is a more reliable mode. We got accurate spikes on an oscilloscope and hence we used the PWM mode on the sensors.
+<br>
+'''Issue #2''' - The beams from two adjacent sensors collided with one another.The waves from the sensors travel in a V shape.This caused inter sensor value collision.
+<br>
+Solution: Increased the distance between the sensors and made sure sensors working serially and not in parallel.We increased the distance between the sensors to avoid inter sensor collisions.Also we turned one sensor on at a time. Hence we turned one sensor,got the values and then turned it off before moving on to the next one.The reliability increased considerably.
+<br>
+'''Issue #3''' - The sensor when mounted on the car detected ground as obstacle.During the 1st demo, we mounted the sensors on the main board itself. This caused us getting values from the ground. This situation can be tricky when the car is on a slope.
+<br>
+Solution: Increased the height of sensors placed on the car.We mounted the sensors on custom PCB's and made sure no ground reflections were encountered.
+<br>
-) The beams from two adjacent sensors collided with one another.
+'''Issue #4''' - The sensors did not work on independent 5V supply.We provided a common 5V power to all the sensors. This caused fluctuations and hence unreliable values.
+<br>
+Solution: Switched the power supply to a more reliable and constant SJSU one board VCC.To reduce the spikes, we could have used a stable 5V power source. But we opted for stable power from the SJSU board. This reduced spikes.
+<br>
-) The sensor when mounted on the car detected ground as obstacle
+'''Issue #5''' - The sensors (Left and Right sensor) gave faulty values when placed at 45 degrees on the corner of the base board i.e. fall edge missed sometimes.The waves from the sensors got reflected from white or oil based painted objects if the sensors were placed at 45 degrees.
+<br>
+Solution: Increased the angle to cover wider area and avoid reflections.Finally we tested out many permutations and combinations to find the accurate angles at which the sensors reflected properly and waves didn't just pass on. Hence increasing the angles to more than 45 degrees helped get us accurate values.
-) The sensors did not work on independent 5V supply.
+[[File:F15_ThunderBird_sensor_graphbefore.jpg|700px|thumb|left|text-top|Fig 5. Sensor before]]
+[[File:F15_ThunderBird_sensor_graphafter.jpg|700px|thumb|right|text-top|Fig 6. Sensor after]]
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+=== HEAD/TAIL LIGHTS ===
+Based on the Light Sensor mounted on the SJSU one board, we are turning on the LED placed on the Head Light position.The threshold taken for Light is 20.Also for Back lights,if the car halts or moves in the reverse direction, the tail lights will turn on. The encoder values from the motor are used to achieve this.
-) The sensors (Left and Right sensor) gave faulty values when placed at 45 degrees on the corner of the base board.
+=== Sensor Test Video ===
+*[https://youtu.be/NOeDWrW0Gs4 Sensor Test Video]
 == Motor and I/O Controllers ==
@@ Line 756: / Line 958: @@
 ===Motors===
 ===Pulse Width Modulation - Controlling DC motor ===
-[[File:F15_ThunderBird_pwm1_5.png|300px|thumb|right|text-top|Fig 1. Initializing pwm signal]]
+[[File:F15_ThunderBird_Motor_interface.png|300px|thumb|right|text-top|Fig 1. Initializing pwm signal]]
-[[File:F15_ThunderBird_pwm2_0.jpg|300px|thumb|right|text-top|Fig 2. Forward pwm signal]]
+[[File:F15_ThunderBird_pwm1_5.png|300px|thumb|right|text-top|Fig 2. Initializing pwm signal]]
-[[File:F15_ThunderBird_pwm1_0.jpg|300px|thumb|right|text-top|Fig 3. Reverse pwm signal]]
+[[File:F15_ThunderBird_pwm2_0.jpg|300px|thumb|right|text-top|Fig 3. Forward pwm signal]]
-[[File:F15_ThunderBird_pwm1_servo.bmp|300px|thumb|right|text-top|Fig 4. Servo pwm signal]]
+[[File:F15_ThunderBird_pwm1_0.jpg|300px|thumb|right|text-top|Fig 4. Reverse pwm signal]]
+[[File:F15_ThunderBird_pwm1_servo.bmp|300px|thumb|right|text-top|Fig 5. Servo pwm signal]]
+[[File:F15_ThunderBird_Optical_sensor_RPM.jpg|300px|thumb|right|text-top|Fig 6. Optical Sensor for measuring RPM]]
+[[File:F15_ThunderBird_Mounted_Optical_sensor_RPM.jpg|300px|thumb|right|text-top|Fig 7. Optical sensor secured on the car's back rim]]
+[[File:F15_ThunderBird_Optical_Sensor_schematics.png|300px|thumb|right|text-top|Fig 8. Schematics of Optical sensor interface with SJOne board]]
 Pulse width modulation is a technique which is used to encode the analog signal into a pulsating signal. The signal is represented as a series of pulses. This signal can be easily generated using the pwm pins of the SJOne board. The ESC is initialized upon passing a PWM signal which is sent by the RF module on the truck. The type of signal is observed by hooking the PWM pin to the digital oscilloscope. The initialization signal is shown in figure 1. A resolution of 1ms is set on the oscilloscope. The PWM signal has a width of 1.5 ms. This signal initializes the ESC. Once the ESC's are initialized, the motors require a signal to accelerate and decelerate. The type of signals for moving the motor forward and backward are realized by hooking the output pin of the RF module to the digital oscilloscope. The forward and backward pwm signals at full throttle are shown in figures 2 and 3 respectively. The respective pwm signal pulses for moving the motors forward and backward are shown below.
@@ Line 800: / Line 1,007: @@
 [https://www.youtube.com/watch?v=WmiXziWJSJI&feature=youtu.be Servo motor demo]
+=== Speed Feedback Encoder ===
+The car should maintain it's speed at all times. The factors affecting the car's speed include incline surfaces, weight of the car and low battery. During these cases, the car should increase and decrease its speed accordingly. There should be some mechanism to know the speed of the car. If you get a Traxxas car, it has an inbuilt device built into the car for measuring the car's speed. We are using optical sensor to detect the car's revolutions.
+==== Optical Sensor ====
+The optical sensor is shown in the figure 5. The optical sensor has Vcc, GND and data pins. The Tx led lights bright red and the Rx receives the reflected light from the Tx when it encounters a white surface. The optical sensor is mounted on the back rim of the car. A white paper is patched on to the tyre to reflect the light from the Tx into the Rx. The mounted optical sensor is shown in figure 6. The schematics for the optical sensor is shown in figure 7. The sensor's data pin is hooked to the GPIO pin. An ISR is called on that pin which will increment a counter value each time the interrupt is called. The counts are averaged using period functions and is displayed on the LCD for every second. The RPM is controlled according to these revolutions per second value. When the car goes on a slope, the pwm is increased to maintain the RPM and once the car climbs the slope, PWM value is decreased. It adjusts accordingly to maintain the RPM!
+=== Precise Steer ===
+The car should steer precisely according to the compass value and GPS value. The GPS tells the car where to go and the compass will tell the car in which direction it should go. The compass gives the values in degrees which lie in the range 0 to 360. The car's servo motor has a PWM range of 4 to 10 with 4 being the extreme left, 7 being the center and 10 being the extreme right. The compass degrees are divided into 17 sectors. The sectors 0 to 9 have values ranging from 0 to 180 degrees and sectors 10 to 17 have values ranging from 180 to 360 degrees. The sectors 0 to 9 drive the car right and the sectors 10 to 17 drive the car left. Each sector accounts to 20 degrees on the compass value. The entire PWM range is divided into sector value. The respective PWM value is set for the car's servo motor for precise steering control.
+When the car encounters an obstacle, the precise control is stopped and the car steers to avoid the obstacle. Once the obstacles are avoided, the precise control is activated back.
+====Periodic Callback Functions:====
+The periodic callback functions are called periodically. The initialization is done in periodic init which is done at the start. The periodic callback functions 1Hz, 10 Hz, 100 Hz and 1000 Hz are called every 1000 ms, 100ms, 10 ms and 1 ms respectively. The following tasks were performed in the periodic functions.
+=====--1Hz task:=====
+Reset the number of interrupts received from the optical sensor
+=====--10Hz task:=====
+Update the LCD
+=====--100Hz task:=====
+The motor code
+=====--1000Hz task:=====
+Not used
+===Common Problems and troubleshooting===
+'''Issue #1''' - The PWM signal width i see on the Oscilloscope is not correct! <br>
+Solution: I observed this while using PWM.set() in periodic functions. I did observe a correct pulse width on the oscilloscope when i did pwm.set in main(). But when i did pwm.set() in the periodic functions, i observed that the PWM signal is giving an incorrect pulse width. The reason is the PWM object is getting destructed. PWM object doesn't get destructed when used in a while(1) loop. When used in the periodic functions, it gets destroyed as soon as the function exits. The solution for this is to make a PWM Singleton Class that doesn't destruct. You can use methods such as motorcontrol.drive() and motorcontrol.steer() to set the PWM's for driving and steering the car. This is a better approach than making the PWM class global.
+'''Issue #2''' - The car's ESC initializes but the motor doesn't move irrespective of the PWM value! <br>
+Solution: Make sure that the battery is charged. Simple as that.
+'''Issue #3''' - How do i find the car's ESC initialization sequence? <br>
+Solution: You can use an Oscilloscope for this. As soon as the car is switched on the car's RC module sends a PWM signal to the ESC. The signal's width can be observed by hooking that PWM pin to the oscilloscope. The PWM value can be calculated according to the procedure described above. Give the respective PWM values and the ESC will be initialized.
 ===I/O===
 ===Liquid Crystal Display===
-[[File:F15_ThunderBird_SJone_LCD_interface.png|400px|thumb|right|text-top|Fig 5.LCD, Driver and SJOne interface]]
+[[File:F15_ThunderBird_SJone_LCD_interface.png|400px|thumb|right|text-top|Fig 9.LCD, Driver and SJOne interface]]
-[[File:F15_ThunderBird_Real_LCD.jpg|400px|thumb|right|text-top|Fig 6.LCD displaying the values]]
+[[File:F15_ThunderBird_Real_LCD.jpg|400px|thumb|right|text-top|Fig 10.LCD displaying the values]]
 A 20x4 LCD(CM 204-1) is used for displaying the speed, sensor values and the start and end coordinates. A LCD driver by SJValley Engineering is used for accessing the LCD through UART. The driver and LCD are soldered on to the prototype board. A USB jack is soldered on-board to power the LCD using the 5V supply from the external battery. The connections between the driver and SJOne board is shown in figure 5. As soon as the LCD is powered on, it displays to enter 0xF0 which is the command for detecting the baud rate. After 0xF0 is sent, the data can be transmitted using UART. A baud rate of 38400 is used for displaying information on the LCD. If you are getting some junk values, make sure that the baud rate is set correct and check the soldering.
@@ Line 813: / Line 1,067: @@
 **$CLR_SCR is used to clear the screen
+[[File:F15_ThunderBird_SJone_LCD_interface_flowchart.png|400px|thumb|center|text-top|Fig 9.Flowchart for LCD]]
 ===Common Problems and troubleshooting===
-. LCD is displaying only 2 lines, line 1 and line 3 when i power it on.
+'''Issue #1''' - LCD is displaying only 2 lines, line 1 and line 3 when i power it on.
-A. Check the connections. Make sure that the LCD is properly soldered to the driver.
+Solution: Check the connections. Make sure that the LCD is properly soldered to the driver.
-. I am getting garbage values printed on the screen when i try to transfer information over UART
+'''Issue #2''' - I am getting garbage values printed on the screen when i try to transfer information over UART
-A. LCD is not initialized properly. Make sure you get the detecting baudrate information displayed on screen when the LCD is powered on.
+Solution: LCD is not initialized properly. Make sure you get the detecting baudrate information displayed on screen when the LCD is powered on.
-. Is it okay to program the LCD while being connected to the SJOne board?
+'''Issue #3''' - Is it okay to program the LCD while being connected to the SJOne board?
-A. I didn't find any issues while programming the SJOne board with the LCD connected to it. However, some teams had issues with it.
+Solution: I didn't find any issues while programming the SJOne board with the LCD connected to it. However, some teams had issues with it.
-. How do i update a single field on the LCD keeping the rest static?
+'''Issue #4''' - How do i update a single field on the LCD keeping the rest static?
-A. I cleared the entire screen every 100 ms and it looked like only the values are being updated!
+Solution: I cleared the entire screen every 100 ms and it looked like only the values are being updated!
 == GPS Controller ==
@@ Line 840: / Line 1,094: @@
 The GPS module provides Latitude and Longitude co-ordinates for current position of car.The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to give you nine degrees of inertial measurement.
-'''SPARKFUN VENUS GPS with SMA CONNECTOR'''
+'''Hardware Interface'''
+[[File:cmpe243_hardware_conn.jpg]]
+=== SPARKFUN VENUS GPS with SMA CONNECTOR ===
+Sparkfun Venus GPS is interfaced to SJone Board using UART communication protocol. As shown in above figure ; we have used UART-2 on SJone board to interface with GPS module at 38400 bps. GPS module needs a 2-3 mins of startup time to lock satellites and receive gps co-ordinates.It is recommended to use a coin cell battery or a alternative power source to boot up and lock satellites.
+Sparkfun Venus GPS provides GPS information basically the current latitude and  longitude in different NMEA standard messages such as
+  $GPBOD - Bearing, origin to destination
+   $GPBWC - Bearing and distance to waypoint, great circle
+   $GPGGA - Global Positioning System Fix Data
+   $GPGLL - Geographic position, latitude / longitude
+   $GPGSA - GPS DOP and active satellites
+   $GPGSV - GPS Satellites in view
+   $GPHDT - Heading, True
+   $GPR00 - List of waypoints in currently active route
+   $GPRMA - Recommended minimum specific Loran-C data
+   $GPRMB - Recommended minimum navigation info
+   $GPRMC - Recommended minimum specific GPS/Transit data
+   $GPRTE - Routes
+   $GPTRF - Transit Fix Data
+   $GPSTN - Multiple Data ID
+   $GPVBW - Dual Ground / Water Speed
+   $GPVTG - Track made good and ground speed
+   $GPWPL - Waypoint location
+   $GPXTE - Cross-track error, Measured
+   $GPZDA - Date & Time
+We use $GPGGA - Global Positioning System Fix Data
+Time, position and fix related data for a GPS receiver.
+Structure: $GPGGA,hhmmss.sss,ddmm.mmmm,a,dddmm.mmmm,a,x,xx,x.x,x.x,M,,,,xxxx*hh<CR><LF>
+	2	3    4	5 6 7 8 9   10 11
+Example:
+$GPGGA,111636.932,2447.0949,N,12100.5223,E,1,11,0.8,118.2,M,,,,0000*02<CR><LF>
+[[File:CMPE243_THunderbird_gpgca.png]]
+'''Gpgca NEMA standard  description table'''
+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. From our and experience of  our project advisors we would recommend a GPS with refresh/update  rate of ATLEAST 10Hz.
+These are few commands which have 90% usage for most GPS module setup and troubleshooting.
+. <b>Factory Reset </b><br>
+A0 A1 00 02 04 00 04 0D 0A <br>
+. <b>Configure the position update rate of GPS system(10 Hz).</b><br>
+A0 A1 00 03 0E 0A 01 05 0D 0A <br>
+. <b>Configure serial port. this command will set baud rate to 38400.</b><br>
+A0 A1 00 04 05 00 03 01 07 0D 0A <br>
+. <b>Configure NMEA message interval  (this command will block all strings except GPGGA).</b><br>
+A0 A1 00 09 08 01 00 00 00 00 00 00 01 08 0D 0A <br>
+Degree of Freedom RAZOR IMU
+The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to give you nine degrees of inertial measurement. The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface.
+=== Compass ===
+Hardware Interface
+[[File:cmpe243_thunderbird_comp_interface.jpg]]
+We are using sparkfun Razor IMU to give 9-degree of internal measurement. It has inbuilt triple axis gyroscope, accelerometer and magnetometer. The 8Mhz factory firmware gives compass heading using UART which is raw value of yaw, pitch and roll. The firmware for the Razor IMU is available on the GIT on various platforms such as Ardiuno, Android, Processing  etc.
+[[File:sector.png|400]]
+We are using Ardiuno platform to download the firmware on the compass using Aurdino software. The same platform and firmware offers functionality to calibrate the compass. Having compass values is not enough for the project as it may or may not work on in real-time, when it is embedded on the car. Magnetometer is sensitive to magnetic field around, hence, the compass needs to be calibrated in the environment where it has to perform i.e on the car. The firmware is written in a way that it shows the deviation from the original value during calibration and gives a final value after the calibration to put as an offset in respective meter. All the meters, gyroscope, accelerometer and magnetometer, needs to be calibrated individually as the final heading is being calculated using values from all the three meters. [https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial#sensor-calibration], calibration methods are given on the link mentioned earlier.
+[[File:F15_Thunderbird_aurdino.png|400px|right|thumb|Compass firmware in aurdino]]
+[[File:F15_Thunderbird_ypr.png|600px|left|thumb|Heading string,Yaw | Pitch | Roll]]
+==== Accelerometer calibration ====
+Accelerometer calibration is done by pointing every axis towards up and down directions and move slowly to get the min and max values respectively and the update the min/max into the firmware file Razor_AHRS.ino.
+accel x,y,z (min/max) = X_MIN/X_MAX  Y_MIN/Y_MAX  Z_MIN/Z_MAX
+==== Magnetometer calibration ====
+[[File:F15_Thunderbird_Magnetometer.png|400px|right|thumb|Magnetometer extended calibration]]
+Magnetometer calibration is done using processing software which gives the metrics for offset values, given below. It is also extended calibration which is done by the software. There are two type of calibration for magnetometer, one being the hard calibration and soft calibration being the other. <br>
+. Hard calibration: Calibrating the compass with the earth's magnetic field.<br>
+. Soft calibration: Calibration the compass with the surrounding magnetic fields.
+   #define CALIBRATION__MAGN_USE_EXTENDED true
+   const float magn_ellipsoid_center[3] = {0, 0, 0};
+   const float magn_ellipsoid_transform[3][3] = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}};
+<br><br><br><br><br><br><br><br><br><br>
+==== Gyroscope calibration ====
+Gyroscope calibration is done by keeping gyroscope still for 10 seconds and it gives the average gyroscope values in terms of yaw, pitch and roll.
+gyro x,y,z (current/average) = -29.00/-27.98  102.00/100.51  -5.00/-5.85
+[[File:F15_Thunderbird_processing_cal.png|300px|right|thumb|Calibrating the compass]]
+<br><br><br><br><br><br><br><br><br><br><br><br><br>
+[[File:F15_Thunderbird_before_cal.png|500px|left|thumb|Heading before calibration]]
+[[File:F15_Thunderbird_after_cal.png|500px|right|thumb|Heading after calibration]]
+<br>
+====Flowchart====
+[[File:Cmpe243_thunderbird_gps_flowchart.jpg]]
+==== Challenges faced ====
+. Considering cost effectiveness and other projects, we odered HMC5881 compass. There are not so many resources on internet to calibrate the compass right and it gave the heading which differed from the actual north. We tried adding offset in the compass value to ake it work but the offset was fluctuating in all the coordinates also gave different headings after each power cycle.<br>
+. After disappointing results from the HMC5881 compass, we ordered Razor IMU 9DOF compass and unfortunately the compass module turned out to be defective and we learned that after many calibration attampts. The compass was giving different north direction after every power cycle and the heading data was drifting back to same angle after moving the compass. We were able to resolve the drifting issue by removing the error correction code but even after resolving one issue the major issue remained same and not gave the right north direction.<br>
+. For the same Razor IMU 9DOF, the heading was constantly decreasing even for the stagnant position of the compass. The headings were regular and smooth, ie. changed with the movement of the compass but after every power cycle the north pointer was different and in many cases not the right north direction. We were able to get the constant values for the heading by altering the Kp_yaw and Ki_yaw to 0.02f and 0.000045f respectively. to get the north direction, we had to change the Razor IMU module with the new one and it worked as expected after calibration.<br>
+. While receiving GPS checkpoint from IO module, the decoding altered the float data and the data did not match with the data sent from the IO module. We copied the float value to a 4 byte char array to get the right data from IO module.<br>
+= Master Controller =
+Master controller is responsible for communication between different controllers and sync each controller's data in directing the car in right direction. It receives ths start or stop command from Android application as soon it receives the command, Master sends motor with the respective message. Master controller listens to the data from sensors and GPS and compass, based on the obstacle avoidance algorithm and GPS co-ordinates, Master decides the right direction for the car and sends it to the Motor.
+=== Software Implementation ===
+Master controller initializes CAN and set the bypass filter on master to accept all incoming CAN messages and in software we process the required data based on the message IDs. as soon as the Controller is up, it initializes the CAN, periodicScehdular task starts executing, where we are using 100Hz function to process all incoming messages and transmitting the CAN messages on to the Bus. if CAN transmission fails, resetcan_bus function is being called to resent the CAN.
+Below sections explains the flow in detail.
+  main()
+   {
+     CAN initialization
+     periodicschedular task
+   }
+===Heart Beat mechanism===
+[[File:F15_ThunderBird_MASTER_Heartbeat.gif|thumb|center|500px|text-top|Hearbeat message flow]]
+The heart beat mechanism is included in order to check for aliveness of each of the controller. There are totally five controllers including the Master Controller. The heart beat algorithm has been included in every of the controllers, <br>
+) Every controller sends a CAN message with their own respective msessage ID's <br>
+) During the reception of the CAN Messages, there is a difference between the tasks between Master and other controller's <br>
+                Master Side:<br>
+) Receive the CAN message<br>
+) Decode the message id and Update the Counter value associated with that Message ID.<br>
+                Other Controllers Side:<br>
+) If message is from Master, then toggle their LED<br>
+) Ignoring the other messages<br>
+) The Controllers are checked for aliveness every 10 seconds by comparing the current and old counter values. <br>
+) If both old and current counter values matches, then corresponding controller is considered to be dead and LED is light up.<br>
+) If they doesn't match then the status has been received and controller is alive.<br>
+===Obstacle avoidance and car navigation Algorithm===
+Based on the data received from GPS Controller and sensor values, Master would decide the direction and steer values for the car and update the motor with the required direction and steer data. Direction and steer value computation is based on the below algorithm.
+====Obstacle avoidence and car navigation algorithm====
+PSEUDOCODE:
+    if (Start command from android or Switch)
+        if (GPS starts sending the valid data)
+         {
+            if Destination_Reached == TRUE
+              return STOP command
+            else (Listen to the Sensor first and if no obstacle listen to GPS Direction)
+               if NO OBSTACLE detected
+                  return GPS DIRECTION<br>
+                if RIGHT OBSTACLE detected
+                 if GPS_DIRECTION == RIGHT
+                   RETURN STRAIGHT
+                  else
+                   RETURN GPS_DIRECTION<br>
+                if STRAIGHT OBSTACLE detected
+                   (Compare RIGHT and LEFT SENSOR)
+                   if RIGHT OBSTACLE is NEAR than LEFT SENSOR:
+  		      RETURN RIGHT
+ 		    else
+                      RETURN LEFT<br>
+                if STRAIGHT and RIGHT OBSTACLE detected
+                   RETURN SLIGHT_LEFT<br>
+                if LEFT OBSTACLE detected:
+                   if GPS_DIRECTION == LEFT
+                     RETURN STRAIGHT
+                   else
+                     RETURN GPS_DIRECTION<br>
+                if LEFT and RIGHT OBSTACLE detected
+                   RETURN STRAIGHT<br>
+                if STRAIGHT and LEFT OBSTACLE detected
+                   RETURN SLIGHT_RIGHT<br>
+                if STRAIGHT, LEFT and RIGHT OBSTACLE detected
+                   if REAR SENSOR detected
+                     RETURN STOP
+                   else
+                     RETURN REVERSE<br>
+GPS Direction:
+                if COMPASS_Angle == 0
+                  return STRAIGHT Command
+                else if COMPASS_DIRECTION = 1
+                  return RIGHT command
+                else
+                  return LEFT command
+=== Periodic Callback Functions : ===
+We used periodic callback functions in implementing CAN communication between controllers to make the communication deterministic and real-time. We used 100Hz in implementing the CAN communication for transmitting and receiving CAN messages.
+Hz function is used to process CAN messages received by Master controller, compute the required direction and to transmit the CAN message to Motor controller, It processes up to five messages in one function call and it also completes executing obstacle avoidance algorithm and based on GPS data, required direction is computed and CAN message is transmitted with required direction details and steer data to Motor Controller.
+====Periodic Schedular task====
+Hz Function:
+ {
+      Receive and process sensor controller data
+      Receive and process GPS+Compass controller data
+      Receive and process Birdge controller data
+      Compute the direction of the car based on Sensor and GPS data
+      Transmit CAN message to Motor with required direction or stop condition.
+ }
+= Bluetooth Control and Android application =
+=== Hardware Design ===
+A BTBEE Pro Bluetooth XBee socket chip connected to the SJOne board is the main hardware component used in Bridge communication.It is interfaced to the SJONE board over UART2. The SJONE board is in turn interfaced with the CAN Bus using a MCP2551 CAN Transceiver.
+=== Hardware Interface ===
+The BTBEE Pro is placed on the XBee socket of the SJOne board. This design was chosen over using I2C/SPI interface as SJONE board has a XBEE socket which can be used directly.The BT module communicates with the SJOne board using a UART interface. Uart2 on the SJONE board is used for this purpose. In order to enable the communication over UART, the switch on the SJONE board needs to set to UART2 position.
+[[File:F15_Thunderbird_Bluetooth_HardwareInterface.png|600px|centre|thumb|Bluetooth Hardware Interface]]
+=== Software Design ===
+The Software design of the Bluetooth and android Bridge control system consists of two main parts<br>
+) Bluetooth to CAN Bridge Software on SJONE board
+) Thunderbird Android Application
+==== Bluetooth to CAN Bridge ====
+The Bluetooth chip is initialized by passing the following commands over bluetooth.
+[[File:F15_Thunderbird_BluetoothInit.png|600px|centre|thumb|Bluetooth initialization commands]]
+Once the chip the initialized data is sent and received from the android app to the SJONE board by treating the Bluetooth connection as a UART bus using uart api's like
+uart2.getChar and uart2.printf.
+In our bridge controller we have written the algorithm to parse input characters from uart and take action based on the sequence of characters that make up a command. The bridge controller responds to the following commands.<br>
+a) Hello - Hello message from android. The SJONE board responds with the current GPS coordinates.<br>
+b) Start - Start message from android. The SJONE board responds with HI to begin exchange of one GPS checkpoint value.<br>
+c) Stop  - Stop message from android. The SJONE board responds with the number of GPS coordinates it received from Android.<br>
+d) Good  - Car start message from android. The SJONE board transmits a start message to Master controller to start transmitting commands on can bus to control the car.<br>
+e) Bad   - Emergency start message from android. The SJONE board transmits a stop message to the Master controller to send stop command on the can bus to all controllers.<br>
+[[File:F15_Thunderbird_BluetoothCommands.png|600px|centre|thumb|Bluetooth Commands Parsing]]
+===== Parsing float information from android =====
+We have used a state machine approach to receive latitude and longitude float values from android app. The state machine is explained as a flowchart below.
+[[File:F15_Thunderbird_BluetoothFloatParser.png|600px|centre|thumb|Bluetooth Float Parsing]]
+===== Updating analytics values to android =====
+Updating analytics value to the android app is an important functionality of bluetooth controller. We read all messages on the can bus and store the values in dbc defined global variables. At 1 hz we send this out to the Android app. The analytics values that are sent to android are as follows <br>
+a) Induvidual sensor readings <br>
+b) Last command issued by Master <br>
+c) Speed of the car from Motor <br>
+d) Latitude, Longitude and Heading values from GPS. <br>
+=== Android Application Software Design ===
+In our project android application is used to perform the following tasks around which we have designed the application.
+a) Connect to the truck over bluetooth<br>
+b) Get its current location<br>
+c) Set the destination for the truck to reach<br>
+d) View analytics information broadcasted over bluetooth<br>
+The above structure is clearly reflected in the activites used in the android application. We have 4 activities that makes up our android application. Intents and Bundled data is used to transmit information from one activity to another. <br>
+a) Welcome activity <br>
+The welcome activity is the first activity that is shown to the user. In this activity the user is presented with options to connect to the device. When the user clicks on the connect button a list of bluetooth devices are shown to the user and the user selects the truck and connects to it. Once connected we show the options activity. <br>
+b) Options activity <br>
+The options activity is the second activity shown to the user after he connects to the truck. In this activity we show options to obtain the current gps location from the device. This activity also serves as the analytics page where the different values obtained from bridge. The values are obtained from the bluetooth activity using intents. <br>
+c) Map activity <br>
+The Map activity is the activity where the user can select a destination. We have used Android-GoogleDirectionLibrary by akexorcist to show the map interface and set destination. We also used the library to get checkpoint data from Google directions API. A server key is used for authentication by the Google server before obtaining checkpoints .The checkpoints data is transmitted to bridge controller using the bluetooth activity.<br>
+d) Bluetooth Activity <br>
+The bluetooth activity forms the crux of the application. It receives intents with data to be transmitted to the SJONE board from all other activities. We have used Android-BluetoothSPPLibrary by akexorcist to establish and negotiate bluetooth connection and send and receive data. This activity also periodically receives analytics data and sends it to the options activity where it is displayed <br>
+==== Use Case Flow Chart ====
+We expect the user to follow this flow chart to use the app to interact with the truck.
+[[File:F15_Thunderbird_Bluetoothandroidflow.png|600px|centre|thumb|User Interaction Flow Chart]]
+=== Android UI design ===
+The UI was designed with simplicity and quick development time in mind. It was designed in the UI editor of Android Studio. The following are screenshots from application.
+[[File:F15_Thunderbird_Androidwelcome.png|left|200px|Android Welcome screen]]     [[File:F15_Thunderbird_Androiddevices.png|200px|Android Bluetooth Devices]]     [[File:F15_Thunderbird_Androidoptions.png|200px|Android Options screen]]         [[File:F15_Thunderbird_Androidmapui.png|200px|Android Map UI with Checkpoints]]
+=== Periodic Scheduler Design ===
+==== One Hertz Task ====
+In One hertz task. We send analytics values to android app by UART over bluetooth. The analytics values sent are sensor values,motor directions sent by master, speed of car from motor, heading and location of the truck.
+==== Ten Hertz Task ====
+In 10 hertz task we read and write to the CAN bus to update DBC generated structures which represent the latest values received on the BUS.
+==== Hundred Hertz Task ====
+In 100 hertz task we read characters from the Bluetooth Uart connection and parse and execute appropriate commands.
+=== Challenges Faced ===
+a) Could not interface the UART connection with Terminal code of SJONE board to use existing command handler code <br>
+Solution: Develop custom code to parse data to and from the uart connection treating it as a char driver.<br><br>
+b) Bridge controller crashes when both CAN and Bluetooth communication are done in 100 hz task <br>
+Solution: Move Can communication to 10 hertz task<br><br>
+c) Bridge and Android app developed before other subsystems were fully functional <br>
+Solution: Create a Test section in Android app that uses hard coded values from sjsu board and goes through the user process.<br><br>
-== Master Controller ==
+d) GPS values sent and received are -1 times the ones used by GPS system <br>
-== Bluetooth Control and Android application ==
+Solution: Multiply by -1 in all places when reading and writing values to the SJONE board.<br><br>
+= Testing & Technical Challenges =
-== Testing & Technical Challenges ==
+=== CAN_DBC ===
-Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
+Problem : The introduction of CAN DBC in the middle of the project was not well orchestrated and derailed the project from the schedule<br>
-Make a smooth transition to testing section and described what it took to test your project.
+Solution : If a major change such as CAN DBC needs to be made special efforts need to be taken to ensure proper coordination between the sender and receiver for every message added on the bus. Do not use experimental features like message multiplexer as it added to 2 extra days of debugging to figure out a software issue that mux is poorly implemented.<br><br>
-Include sub-sections that list out a problem and solution, such as:
+=== Project Manangement ===
+Problem : Lack of proper time and project management led to schedules being missed.<br>
+Solution : At the begining of the project nominate a person as Project manager. This person should ensure proper communication between team members and review individual team status and high level algorithms for induvidual components frequently and look for quick methods to solve high level problems. Do not depend on team members physical presence. Use skype calls and other team collab tools to ensure weekly meeting and team progress.<br><br>
-=== My Issue #1 ===
+=== Code Review ===
-Discuss the issue and resolution.
+Problem : Lack of proper code review led to small software bugs which cause major delay due to debug time and effort<br>
+Solution : Assign a person for every person to review the other person's contribution from another team. This could help reduce small small bugs which have big time and effort impact.<br><br>
-== Conclusion ==
+=== Figuring out team strengths ===
-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?
+Problem : People chose new domains different from their comfort zone to contribute to the project<br>
+Solution : People should choose subsystems based on their strengths. Even if you want to learn something new, you can learn after project, not during project. The project should proceed according to schedule which is already very difficult to follow. There should be no delay due to experimental work. All experiments can be done after the project is done. In all actions and decisions taken during project ask only one question. Will this help the project to work in the demo? do not worry about individual learning goals.<br><br>
+= Conclusion =
+This was a very interesting and challenging team project. We gained good technical embedded application knowledge and it also helped us gaining team organization and management skills.
+This project gave us good exposure to different modules such as sensors, MOTOR, GPS, Android application and CAN bus, which made us comfortable to work on any new module by exploring its features.
+We would suggest the future teams working on this project to set individual goals and divide the major tasks into several small tasks and work towards them to be more productive.
+Overall experience of this project was very good, and we call it one of the best projects we worked on.
 === Project Video ===
-Upload a video of your project and post the link here.
+Here is our demo.
+[https://www.youtube.com/watch?v=fyOan7worio&feature=youtu.be THUNDERBIRD]
 === Project Source Code ===
-*  [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]
+*  [https://gitlab.com/JamesSushanthAnandraj/lpc1758_freertos GitLab Source Code Link]
-== References ==
+= References =
 === Acknowledgement ===
-Any acknowledgement that you may wish to provide can be included here.
+We would like to thank Preet for guiding us throughout the semester and for giving us such the wonderful opportunity to work on this project. We would also like to thank Mr.Mitesh Sanghvi and the entire ISA team for their constant support and encouragement. Finally, it would not have been possible to work on the project without the entire team's support for each other. The team worked really hard to achieve the final goal of making the Self Driving RC Car work!
 === References Used ===
-List any references used in project.
+ [1]Kang, P.(2015).CMPE243: Embedded system Application, notes [Power point slides and lecture notes]
+ [2][http://www.nxp.com/documents/user_manual/UM10360.pdf LPC1758 User Manual]
-=== Appendix ===
+ [3][http://www.socialledge.com/sjsu/index.php?title=Realtime_OS_on_Embedded_Systems Real time OS on embedded system]
-You can list the references you used.
+ [4][https://www.sparkfun.com/products/10736 Razor IMU]
+ [5][https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial#sensor-calibration Razor IMU tutorial 1]
+ [6][https://github.com/sparkfun/9DOF_Razor_IMU Razor IMU tutorial 2 ]
+ [7][https://www.sparkfun.com/products/11058 Sparkfun GPS info]
+ [8][http://maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf Maxbotix Sonar Sensor]
+ [9][http://www.alldatasheet.com/datasheet-pdf/pdf/562454/UNIOHM/CM-204.html LCD]
+ [10][https://github.com/akexorcist/Android-GoogleDirectionLibrary Android Google Direction Library]
+ [11][https://github.com/akexorcist/Android-BluetoothSPPLibrary Bluetooth SPP Library]

Difference between revisions of "F15: ThunderBird"

Latest revision as of 12:24, 20 January 2016

Contents

ThunderBird : Self Driving Car

Abstract

Objectives & Introduction

Objective

Team Members & Responsibilities

Introduction

Overall Algorithm

Controllers

Schedule

Team Schedule

Parts List & Cost

Design & Implementation

CAN 11-bit ID Format

Controller ID Table

Hardware Design

Software Design

Implementation

Working Mechanism

Sensor Controller

Sensor Hardware Design

Sensor Software Design and Algorithm

Periodic Callback Functions:

--1000Hz task:

--100Hz task:

Sensor: Technical Challenges

HEAD/TAIL LIGHTS

Sensor Test Video

Motor and I/O Controllers

Motors

Pulse Width Modulation - Controlling DC motor

PWM Calculations

Controlling Servo motor

Speed Feedback Encoder

Optical Sensor

Precise Steer

Periodic Callback Functions:

--1Hz task:

--10Hz task:

--100Hz task:

--1000Hz task:

Common Problems and troubleshooting

I/O

Liquid Crystal Display

Common Problems and troubleshooting

GPS Controller

SPARKFUN VENUS GPS with SMA CONNECTOR

Compass

Accelerometer calibration

Magnetometer calibration

Gyroscope calibration

Flowchart

Challenges faced

Master Controller

Software Implementation

Heart Beat mechanism

Obstacle avoidance and car navigation Algorithm

Obstacle avoidence and car navigation algorithm

Periodic Callback Functions :

Periodic Schedular task

Bluetooth Control and Android application

Hardware Design

Hardware Interface

Software Design

Bluetooth to CAN Bridge

Parsing float information from android

Updating analytics values to android

Android Application Software Design

Use Case Flow Chart

Android UI design

Periodic Scheduler Design

One Hertz Task

Ten Hertz Task

Hundred Hertz Task

Challenges Faced

Testing & Technical Challenges

CAN_DBC

Project Manangement