Difference between revisions of "F15: TopGun"

Latest revision as of 04:57, 22 December 2016

1 TopGun Self Driving Car
2 Abstract
3 Objectives & Introduction
- 3.1 Team Members & Responsibilities
  - 3.1.1 Five Controllers Used
4 Schedule
5 Parts List & Cost
6 DBC File Implementation
- 6.1 CAN Message ID Table
7 Sensor Controller
8 Geographical Controller
9 Motor I/O Controller
10 Master Controller
11 Bluetooth/Bridge Controller
12 Overall System Optimizations and fail safe conditions
13 Testing & Technical Challenges
14 Conclusion
- 14.1 Project Video
- 14.2 Project Source Code
15 References
- 15.1 Acknowledgement
- 15.2 References Used

TopGun Self Driving Car

This is Top Gun - The super car that drives by itself!

Abstract

The GPS-controlled automated RC car will consists of 5 different LPC 1758 controllers. Each controller will have a specific major tasks required to drive the car. The naming convention goes as:- Motor & I/O controller - this will control the motors of the car and will also connected with a LCD display to show the car's status, Sensor controller - It will be connected to the obstacle detecting sensors on the car, Communication Bridge - It will be connected to an Android mobile phone so as to provide co-ordinates, GEO controller - This will give the exact orientation of the car e.g., heading & bearing, etc. and finally the Master controller - This will collect the data from other controllers and will guide the motor controller. These controllers are connected using CAN bus. After the final implementation, this car will be capable of driving by itself using the destination co-ordinates set by us avoiding every obstacles, overcoming slopes thereby reaching the destination safely!

Project Diagram

Objectives & Introduction

Team Members & Responsibilities

Members:

Divya Dodda
Dhruv Kakadiya
Chitrang Talaviya
Navjot Singh
Anuj Korat
Anush Shankar
Aditya Devaguptapu
Hemanth Konanur Nagendra
Akshay Vijaykumar

Treasurer:

Anuj Korat

Schedule

Team Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	09/15/2015	09/27/2015	Understanding the requirements and having initial team discussions on approach to be followed to carry out project Forming sub-teams and assigning individual modules to each sub-team	Completed	09/27/2015
2	09/27/2015	10/30/2015	Following up on RC car and other component procurement through team discussions	Completed	10/30/2015
3	10/30/2015	10/06/2015	Hardware design of the car including discussions on component placement, soldering and wiring.	Completed	10/06/2015
4	10/06/2015	10/17/2015	CAN message ID's, priorities, data size and format proposals for all the possible CAN messages on the bus	Completed	10/20/2015
5	10/20/2015	11/05/2015	Discussions and proposals on basic obstacle avoidance algorithm with sensor integration, hands on and testing	Completed	11/03/2015
6	11/05/2015	11/25/2015	Integrating other modules and components to the RC car, development of autonomous driving algorithm and finalize on hardware layout of the car	Completed	12/1/2015
7	11/25/2015	12/7/2015	Testing the RC car in real world environments	Completed	12/5/2015

Parts List & Cost

Item#	Part Desciption	Vendor	Qty	Cost
1	RC Car	From Preet	1	Free
2	RC Car Battery	Amazon	1	$24.72
3	Core CPU Supply	Amazon	1	$12.70
4	CAN Transceiver MCP2551	Microchip	15	$20.00
5	Printed Circuit Boards	Amazon	1	$12.25
6	M-F,F-F,M-M Jumper Wires	Amazon	120	$8.75
7	Ultrasonic Parallax Ping Sensor	Fry's Electronics	1	$63.99
8	Ultrasonic Sensors	Amazon	5	$10.45
9	9 DOF Razor IMU module	SparkFun	1	$74.95
10	FTDI Basic Breakout	SparkFun	1	$14.95
11	LCD Display uLCD-32PTU	4D systems	1	$111.00
12	Bluetooth Module	Amazon	1	$9.99
13	Wire Cutter	Amazon	1	$2.99
14	GPS Sensor	Adafruit	1	$39.95
15	Bosch 9 DOF sensor	Adafruit	0	$34.95
16	Black/White line detection sensor - RPM sensor	Amazon	1	$6.49
17	Hall effect sensor - RPM sensor	Amazon	1	$5.59
17	RGB Backlight Character LCD 20*4	Adafruit	0	$24.95
	Total Cost			$450

DBC File Implementation

This section explains DBC file implementation of the project. The DBC implementation contains the python based DBC file parser, a DBC file and auto generated C code for the five CAN nodes. These five nodes include driver(master), sensor, motor, geo and bluetooth node. The DBC file is a input to the python DBC parser script. The python script will generate a C file for the specific node given by the user at the command line argument. The python script goes through this DBC file and generates code to marshal (covert to raw CAN) and unmarshal (convert from raw CAN) using the provided API that you can enclose in a header file.

The following is the DBC file of the project.

VERSION ""
NS_:
 NS_DESC_
 CM_
 BA_DEF_
 BA_
 VAL_
 CAT_DEF_
 CAT_
 FILTER
 BA_DEF_DEF_
 EV_DATA_
 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 MOTORIO BLUETOOTH GEO
BO_ 0 DRIVER_KILL_SWITCH: 0 DRIVER
 SG_ DRIVER_KILL_SWITCH_cmd 		: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
BO_ 1 DRIVER_RESET: 0 DRIVER
 SG_ DRIVER_RESET_cmd 				: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
BO_ 2 DRIVER_SYNC_ACK: 0 DRIVER
 SG_ DRIVER_SYNC_ACK_cmd 			: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
BO_ 3 MOTORIO_SYNC: 0 MOTORIO
 SG_ MOTORIO_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 4 SENSOR_SYNC: 0 SENSOR
 SG_ SENSOR_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 5 BLUETOOTH_SYNC: 0 BLUETOOTH
 SG_ BLUETOOTH_SYNC_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 6 GEO_SYNC: 0 GEO
 SG_ GEO_SYNC_cmd 					: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 7 MOTORIO_HEARTBEAT: 0 MOTORIO
 SG_ MOTORIO_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 8 SENSOR_HEARTBEAT: 0 SENSOR
 SG_ SENSOR_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 9 BLUETOOTH_HEARTBEAT: 0 BLUETOOTH
 SG_ BLUETOOTH_HEARTBEAT_cmd 		: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 10 GEO_HEARTBEAT: 0 GEO
 SG_ GEO_HEARTBEAT_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
BO_ 11 MOTORIO_RUNMODE: 1 DRIVER
 SG_ MOTORIO_RUNMODE_cmd 			: 0|8@1+ (1,0) [0|3] "" MOTORIO
BO_ 12 SENSOR_SONARS: 6 SENSOR
 SG_ SENSOR_SONARS_front_left 		: 0|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
 SG_ SENSOR_SONARS_front_right 		: 8|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
 SG_ SENSOR_SONARS_front_center 	: 16|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
 SG_ SENSOR_SONARS_left 			: 24|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
 SG_ SENSOR_SONARS_right 			: 32|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
 SG_ SENSOR_SONARS_back 			: 40|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
BO_ 13 MOTORIO_DIRECTION: 2 DRIVER
 SG_ MOTORIO_DIRECTION_speed_cmd 	: 0|8@1+ (1,0) [0|4] "" MOTORIO
 SG_ MOTORIO_DIRECTION_turn_cmd 	: 8|8@1+ (1,0) [0|5] "" MOTORIO
BO_ 14 DRIVER_CHECKPOINT_REQ: 1 DRIVER
 SG_ DRIVER_CHECKPOINT_REQ_cmd 		: 0|8@1+ (1,0) [0|3] "" BLUETOOTH,MOTORIO
BO_ 15 BLUETOOTH_CHECKPOINT_SEND: 1 BLUETOOTH
 SG_ BLUETOOTH_CHECKPOINT_SEND_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO
BO_ 16 BLUETOOTH_CHECKPOINT_DATA: 1 BLUETOOTH
 SG_ BLUETOOTH_CHECKPOINT_DATA_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO
BO_ 17 DRIVER_LOC_UPDATE: 8 DRIVER
 SG_ DRIVER_LOC_UPDATE_LAT_cmd 		: 0|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
 SG_ DRIVER_LOC_UPDATE_LONG_cmd 	: 32|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
BO_ 18 GEO_SPEED_ANGLE: 5 GEO
 SG_ GEO_SPEED_cmd 					: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTORIO
 SG_ GEO_ANGLE_heading_cmd 			: 8|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
 SG_ GEO_ANGLE_bearing_cmd 			: 24|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
BO_ 19 GEO_LOC_DATA: 8 GEO
 SG_ GEO_LOC_LAT_cmd 				: 0|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
 SG_ GEO_LOC_LONG_cmd 				: 32|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
BO_ 20 SENSOR_LIGHT_BAT: 2 SENSOR
 SG_ SENSOR_LIGHT_cmd 				: 0|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO
 SG_ SENSOR_BAT_cmd 				: 8|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO

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_ MOTORIO "The motor_io controller of the car";
CM_ BU_ BLUETOOTH "The bluetooth controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BO_ 2 "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_ 7 	          1;
BA_ "GenMsgCycleTime" BO_ 8 	          1;
BA_ "GenMsgCycleTime" BO_ 9 	          1;
BA_ "GenMsgCycleTime" BO_ 10              1;
BA_ "GenMsgCycleTime" BO_ 11 	          1;
BA_ "GenMsgCycleTime" BO_ 12              10;        
BA_ "GenMsgCycleTime" BO_ 13              10;
BA_ "GenMsgCycleTime" BO_ 17              10;
BA_ "GenMsgCycleTime" BO_ 18              10;
BA_ "GenMsgCycleTime" BO_ 19              10;

Let's understand the above DBC file. The line which contains BU_:... tells the python parser that the user has five nodes in the CAN implementation. In the TopGun project, we have total five nodes -> SENSOR, DRIVER(master), MOTOR, BLUETOOTH, GEO.
The second important thing in the DBC file is the lines starting from BO_ message_id. These lines define the different message ids for the CAN implementation of the TopGun project. Here, the project includes total 20 message ids. So, The DBC file contains separate BO_ message_id line for each and every message id. Now, let's see what these lines are indicating to the python parser. What the BO_ line contains is given below:
- BO_ 4 SENSOR_SYNC: 0 SENSOR --> BO_ "message_id" "message_id_name" "number_of_bytes_transmitted_on_CANbus" "transmitter_node"
Now, there are lines which start from SG_. The format of the line contains SG_ is given below. It will contain the variable name that we want to marshal and unmarshal for the CAN bus message data. It also contains the size of that variable and from where it is placed in the 8 bytes of total data. This line will also decide the range of the value held by this variable. User needs to define this max and mim range according to the application. If it is [0|0], then the the parser will consider this as a default and will give the maximum and minimum value of that variable according to its size and the sign information of the variable. Information in the (1,0) will define the multiplier of the value of the variable which in this case is 1. The second value of this bracket is 0 which indicates the offset for the value of the variable.

Execute the following commands in the command line argument to generate the API for the motor controller node.
- $python dbc_parse.py -i TopGun_12_38am_11_16_2015.dbc -s MOTORIO > generated_code_MOTORIO.c
The above command will generate the code for the generated_code_MOTORIO.c file

Sample implementation of CAN dbc for sensor message.
Sensor message encode code:

    can_msg_t sensor_can_msg;
    SENSOR_TX_SENSOR_SONARS_t sensor_msg;
    sensor_msg.SENSOR_SONARS_front_center = sen_front_center.szone;
    sensor_msg.SENSOR_SONARS_front_left = sen_front_left.szone;
    sensor_msg.SENSOR_SONARS_front_right = sen_front_right.szone;
    msg_hdr_t sensor_msg_header = SENSOR_TX_SENSOR_SONARS_encode((uint64_t*)&sensor_can_msg.data, &sensor_msg);
    sensor_can_msg.msg_id = sensor_msg_header.mid;
    sensor_can_msg.frame_fields.data_len = sensor_msg_header.dlc;
    transmit_data(sensor_can_msg);

Sensor message decode code:

    SENSOR_TX_SENSOR_SONARS_t sensor_msg;
    can_msg_t received_msg;
    msg_hdr_t hdr;
    hdr = { received_msg.msg_id, (uint8_t)received_msg.frame_fields.data_len };
    SENSOR_TX_SENSOR_SONARS_decode(&sensor_msg,(uint64_t*)&received_msg.data,&hdr);

CAN Message ID Table

Message ID	Task associated with ID	Data bit-fields
0x00	Kill Switch	No Data
0x01	Reset	reset_motorio:8; // Acknowledge motorio controller reset_sensor:8; // Acknowledge sensor controller reset_geo:8; // Acknowledge geo controller reset_bluetooth:8; // Acknowledge bluetooth module
0x02	Master Sync Ack	ack_motorio:8; // Acknowledge motorio controller ack_sensor:8; // Acknowledge sensor controller ack_geo:8; // Acknowledge geo controller ack_bluetooth:8; // Acknowledge bluetooth module
0x03	MotorIO Controller Sync	No Data
0x04	Sensor Controller Sync	No Data
0x05	Bluetooth Controller Sync	No Data
0x06	Geo Controller Sync	No Data
0x07	MotorIO controller Heart-beat	No Data
0x08	Sensor controller Heart-beat	No Data
0x09	Bluetooth controller Heart-beat	No Data
0x0A	Geo controller Heart-beat	No Data
0x0B	Run mode	mode:8;
0x0C	Distance Sensor Data	front_left:8; // Front left sensor reading front_right:8; // Front right sensor reading front_center:8; // Front centre sensor reading left:8; // Left sensor reading right:8; // Right sensor reading back:8; // Back sensor reading
0x0D	MotorIO Direction Data	speed:8; // Indicate speed for DC motor turn:8; // Indicate turn angle for servo motor
0x0E	Check-point Request Message	No Data
0x0F	Check-point Start Message	num_of_points; // Number of check-points to be loaded
0x10	Check-point Data	float latitude; float longitude;
0x11	Geo-Controller New Destination Data	float latitude; float longitude;
0x12	Geo-Controller Speed and Angle message	speed:8; // Speed as measured by the GPS sensor heading:16; // Heading from the Geo controller bearing:16; // Bearing calculated by the Geo controller
0x13	Geo-Controller Location Data	float latitude; float longitude;
0x14	Light and Battery Sensor Data	light_sensor:8; // Light sensor reading batt_sensor:8; // Battery level sensor reading

Sensor Controller

Team Members:

Divya Dodda
Dhruv Kakadiya

Sensor Controller Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	09/20/2015	09/27/2015	Researching and ordering the sensors to be used in the project	Completed	9/27/2015
2	09/27/2015	10/03/2015	Studying sensor data sheets and preparing code sketch to be used after components are procured Interface ADC ultrasonic sensor to SJOne board(available spare sensors), reading sensor values and filtering the readings	Completed	10/03/2015
3	10/03/2015	10/10/2015	Interfacing ADC ultrasonic sensor to SJOne board, reading sensor values and filter the readings	Completed	10/10/2015
4	10/10/2015	10/20/2015	Understanding inertial measurement unit sensor, interfacing it to SJOne board to get filtered readings	Completed	10/20/2015
5	10/20/2015	11/05/2015	Integrating multiple sensors to the SJOne board, testing the sensors and debugging issues	Completed	11/02/2015
6	11/05/2015	11/15/2015	Preparing sensor values to be sent over CAN bus and testing out the correctness of sensor can messages	Completed	11/10/2015
7	11/25/2015	11/30/2015	Testing of code during final phases, modifying code in cooperation with other teams and optimization of code	Completed	12/1/2015

Sensor Testing

Front Sonar Visualization

Simple Sensor ping operation

Sensor Ping Operation

HCSR04 Sensor Testing

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

HC-SR04 sensor

Parallax Ping Sensor Testing

As shown in the figure below, Parallax ping ultrasonic sensor requires an external 5V DC supply.

Parallax ping sensor

Finalizing distance sensors

Both sensors being pretty accurate, we were confused while finalizing one. So we were using both sensors, for front we were using Parallax and for left,right and back sensors we were using HCSR04 sensor.
HCSR04 sensor was better option because as it was much cost efficient than the Parallax Ping Sensor (Where one Parallax Ping costs $30, one HCSR04 costed us only $2)
Its only drawback is, the cheaper one sensor needed good filter to remove some spikes and Parallax sensor was working pretty good without any filtering.

Software timer for repetitive pulse and Hardware timer for calculating pulse width

All sensor were triggered using software timers. We declared a soft timer for each sensor which kept track of the time between trigger and echo for that particular sensor.

   SoftTimer limit_time;    
   limit_time.reset(25);
   limit_time.restart();
   if(limit_time.expired()){
       break;
   }

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

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

   lpc_timer_enable(lpc_timer0,1);
   lpc_timer_set_value(lpc_timer0,0);

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

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

Sequentially Triggering of Sensors

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

Limiting the Scope to Improve Frequency

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

Misfiring of Sensor

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

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

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

Sensor Software Design

Sensor Controller Team Software Design

Sensor software design is composed of three crucial tasks, which are to read GPIO based sonar, read ADC based sonar, and CAN TX.

Operation Sequences

GPIO based read

ADC based read

CAN Frame write

Tasks

Sensor Controller Tasks
Task Name	Purpose
Period Init	Can bus initialization
Period Register telemetry	Register sensor_data can message
Periodic 1Hz Callback	Check can bus off
Periodic 10Hz Callback	Get and Send Sensor Data

Sensor Zones

Each sensor can detect obstacles at a maximum range of 400cm. We have divided this range into 3 zones as shown in the figure.

Sensor Zones

Sensor Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	Parallax Ultrasonic Sensor (Front Left)	Vcc	5V Power Supply	+5V	Front Left Sensor Power
8	Parallax Ultrasonic Sensor (Front Left)	GND	5V Power Supply	GND	Front Left Sensor GND
9	Parallax Ultrasonic Sensor (Front Left)	Echo/Trig	SJOne Board	P2.0	Front Left Sensor Echo
10	Parallax Ultrasonic Sensor (Front Right)	Vcc	5V Power Supply	+5V	Front Right Sensor Power
11	Parallax Ultrasonic Sensor (Front Right)	GND	5V Power Supply	GND	Front Right Sensor GND
12	Parallax Ultrasonic Sensor (Front Right)	Echo/Trig	SJOne Board	P2.2	Front Right Sensor Echo
13	Parallax Ultrasonic Range Sensor (Front Middle)	Vcc	5V Power Supply	+5V	Front Middle Sensor Power
14	Parallax Ultrasonic Range Sensor (Front Middle)	GND	5V Power Supply	GND	Front Middle Sensor GND
15	Parallax Ultrasonic Range Sensor (Front Middle)	Echo	SJOne Board	P2.4	Front Middle Sensor Echo
16	Parallax Ultrasonic Range Sensor (Front Middle)	Trig	SJOne Board	P2.5	Front Middle Sensor Trig
17	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
18	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Sensor Implementation Using Interrupts

We implemented interrupt based code for 3-pin and 4-pin ping sensors.

Implementation of 4-pin Sensors With Interrupt

Initially a class for the 4-pin sensor was developed. Three instances of this class were declared for front, right and left sensors with GPIO pin numbers for trigger, echo with trigger being the input to the sensor and echo being the output of the sensor to the board.In addition to the pin numbers an unique index for each sensor.
First task was to assign the pin numbers to set as input and output pins which were interrupt based GPIO pins.
From the file "eint.h", we inferred the ports 0 and 2 were interrupt based pins.

Interrupt On The Echo Pin

To set an interrupt on echo pin, we used the API "eint3_enable_port2(pin, edge_type, callback_function)". The respective echo pin number was provided as the first parameter for front, right and left sensors. The edge type was rising and falling edge on the echo pin of each sensor. Two callback functions were implemented for rising and falling edge. When the echo pin went high,we captured the time using the API "sys_get_uptime_us()" in the rising edge callback function. When the echo pin went low, we captured the time using the same API in the falling edge callback function. The difference between uptime and downtime obtained from these callbacks functions, was used to calculate the distance using the formula "distance(in cms) = (downtime-uptime) * (1.0 / 58.0)."

Design Flow

The function for pinging the sensors followed the order front,right and left with indexes 0,1, and 2 respectively. The function was called from 1000Hz periodic callback function. The design flow for the function was as follows:

1. Check the index of the pinged sensor.
2. Send the pulse to the trigger pin for the indexed sensor.
3. Calculate uptime, downtime, distance for the current instance sensor.
4. Add the latest calculated distance value to a dedicated filter for the respective sensor.
5. The filter would update and return the latest average distance.
6. Calculate the zone for the distance obtained.
7. The data to be sent onto the can bus involves the zone information for all the three sensors for every 1000Hz. This meant the zone information of the pinged and the un-pinged sensor values are needed out to be sent over the bus.
8. We concluded that at a given point of time, the can bus would receive the previously calculated values for all the sensors. What this meant is if we calculated the values for current instance of the front sensor, we would push the values of the previous instance of front,right and left sensors on the bus. This would keep the master updated with all the sensor data.

Sensor Implementation with Interrupts Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	4-pin Ultrasonic Sensor (Front)	Vcc	5V Power Supply	+5V	Front Sensor Power
8	4-pin Ultrasonic Sensor (Front)	GND	5V Power Supply	GND	Front Sensor GND
9	4-pin Ultrasonic Sensor (Front)	Trig	SJOne Board	P2.0	Front Sensor Trigger pin
10	4-pin Ultrasonic Sensor (Front)	Echo	SJOne Board	P2.1	Front Sensor Echo pin
11	4-pin Ultrasonic Sensor (Right)	Vcc	5V Power Supply	+5V	Right Sensor Power
12	4-pin Ultrasonic Sensor (Right)	GND	5V Power Supply	GND	Right Sensor GND
13	4-pin Ultrasonic Sensor (Right)	Trig	SJOne Board	P2.2	Right Sensor Trigger pin
14	4-pin Ultrasonic Sensor (Right)	Echo	SJOne Board	P2.3	Right Sensor Echo pin
15	4-pin Ultrasonic Sensor (Left)	Vcc	5V Power Supply	+5V	Left Sensor Power
16	4-pin Ultrasonic Sensor (Left)	GND	5V Power Supply	GND	Left Sensor GND
17	4-pin Ultrasonic Sensor (Left)	Trig	SJOne Board	P2.4	Left Sensor Trigger pin
18	4-pin Ultrasonic Sensor (Left)	Echo	SJOne Board	P2.5	Left Sensor Echo pin
19	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
20	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Implementation 3-pin Sensors With Interrupt

Design flow

The design flow for the 3-pin ping sensors with interrupts was same as the 4-pin ping sensors with interrupts.

3-pin sensor has a single pin for Echo and Trigger.

1. In the sensor function, first the Trigger pin is set as output. A high to low pulse is provided.
2. Once the low pulse is provided on the trigger pin, the same pin is configured as input pin to the board.
3. The echo pin is monitored for rising and falling edge. Once the falling edge is detected, the distance calculation, can data transfer takes place following the same logic as 4-pin sensor.

The pin connections for this implementation are same as Sensors pin connections mentioned in 7.2.3.

Geographical Controller

Team Members:

Chitrang Talaviya
Navjot Singh

Geographical Controller Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	09/20/2015	09/27/2015	Researching and ordering the parts	Completed	9/27/2015
2	09/27/2015	10/05/2015	Studying module data sheets and writing code sketches to be used when modules are procured(GPS and IMU)	Completed	10/05/2015
3	10/05/2015	10/15/2015	Interfacing GPS module and compass to SJOne board and get consistent filtered readings	Completed	10/17/2015
4	10/15/2015	10/30/2015	Proposals for heading and distance calculation, unit testing and integrating modules	Completed	10/30/2015
5	10/30/2015	11/10/2015	Calibration of compass and GPS readings, CAN bus communication from geo controller to other boards.	Completed	11/10/2015
6	11/10/2015	11/25/2015	Android application connection with data reception and transmit	Completed	11/25/2015
7	11/25/2015	12/15/2015	Final phase testing and optimization, collaborating with android team to get better reliable outcomes	Completed	12/12/2015

Geographical Controller H/W Design

Below figure represents the block diagram of Geo Controller. Geo-controller uses GPS and IMU module for its working. Uart3 and Uart2 are used for interfacing IMU and GPS with SJ One board at baud rate 9600bps.

H/W Interface of GeoController

Geographical Controller Hardware Design Components

Adafruit MTK3339 GPS:

This GPS unit is interfaced via UART with build in antenna. The GPS provides latitude and longitude accurately up to 5-10 meters with a strong satellite fix with update rate of 10Hz. By default, the baud rate is 9600bps. Power usage for this module is 20mA during navigation.

The GPS module comes with following capabilities:

-165 dBm sensitivity, 10 Hz updates, 66 channels
5V friendly design and only 20mA current draw
Breadboard friendly + two mounting holes
RTC battery-compatible
Built-in datalogging
PPS output on fix
Internal patch antenna + u.FL connector for external active antenna
Fix status LED

We chose this part because it provided the base functionality we needed along with many other functions that would be fun to play with and try to include in the project. The antennae options and voltage regulator were also very enticing. We get raw GPS "NMEA sentence" output from module. The most important NMEA sentences include the GGA which provides the current Fix data, the RMC which provides the minimum gps sentences information, and the GSA which provides the Satellite status data. We are filtering the data for RMC, Recommended Minimum, which will look similar to:

    $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
where:-RMC          Recommended Minimum sentence C
     123519       Fix taken at 12:35:19 UTC
     A            Status A=active or V=Void.
     4807.038,N   Latitude 48 deg 07.038' N
     01131.000,E  Longitude 11 deg 31.000' E
     022.4        Speed over the ground in knots
     084.4        Track angle in degrees True
     230394       Date - 23rd of March 1994
     003.1,W      Magnetic Variation
     *6A          The checksum data, always begins with *

GPS_Module

9 Degrees of Freedom- Razor IMU:

In our project, we used IMU module to get the heading of the device. The 9DOF Razor IMU provides nine degree of inertial measurement incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer). The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface. UART interface is used for interfacing with SJ One board and it is connected via UART3 with LPC board and is operated at 3.3V.

Features:

9 Degrees of Freedom on a single, flat board:
- ITG-3200 - triple-axis digital-output gyroscope
- ADXL345 - 13-bit resolution, ±16g, triple-axis accelerometer
- HMC5883L - triple-axis, digital magnetometer
Outputs of all sensors processed by on-board ATmega328 and sent out via a serial stream
Autorun feature and help menu integrated into the example firmware
Output pins match up with FTDI Basic Breakout, Bluetooth Mate, XBee Explorer
3.5-16VDC input
ON-OFF control switch and reset switch

9DOF-IMU

Geographical Controller H/W Interface

Below table shows the Pins connection of GPS and IMU module with SJ One Board. Both the h/w's are interfaced with Controller using UART interface. The operating volatge of GPS and IMU is 3.3V.

Geographical Controller Pin Connection Table
Description	Interface	Device Port	SJOne Board Port
Supply Voltage	N/A	Vcc	3.3 V
Ground	N/A	GND	GND
GPS Module	UART2	Channel 1 -> Rx Channel 2 -> Tx Channel 3 -> EN	Channel 1 -> Tx P2.8 Channel 2 -> Rx P2.9 Channel 3 -> Vcc
IMU Module	UART3	Channel 1 -> Rx Channel 2 -> Tx Channel 3 -> DTR	Channel 1 -> Tx P4.28 Channel 2 -> Rx P4.29 Channel 3 -> GPIO P2.2

Geographical Controller S/W Design

Geographical controller uses two modules to get GPS data and headings. These are:

GPS module
IMU module

Tasks

Geo Controller Tasks
Task Name	Purpose
IMU Task	To get IMU reading over UART3.
GPS Task	Read the GPS data string via UART2 Interrupt Handler.
Periodic 1Hz Callback	Receive Checkpoint from Master.
Periodic 10Hz Callback	Send GPS data over CAN BUS Send IMU heading,bearing,speed and distance data over CAN Bus

In the below sections, one will see the methods used to get the values from the modules. Both of the modules are interfaced using UART.

GPS

Initialization: GPS data is retrieved using Interrupts for UART2. Before using Interrupts for receiving GPS string that contains data,UART2 is initialized with Receiving Interrupts Enabled. The code for UART init is as below. The UART init is done once, so is called in main().

void uart2init()
{
   // In our inter-board communication we have used UART 2 for transmission and reception. So, We will unable UART 2.
   LPC_SC->PCONP |= (1<<24);  // We have to Power on the UART 2 peripheral. To do so we have to enable bit 24 of PCONP register.
   LPC_SC->PCLKSEL1 &= ~((1<<16)|(1<<17));    // Peripheral Clock = CPUClock/4. (48 Mhz/4= 12 Mhz)
   LPC_PINCON->PINSEL4 &= ~((1<<19)|(1<<18)|(1<<17)|(1<<16)); 
   LPC_PINCON->PINSEL4 |= ((1<<19) | (1<<17));  // We have to set this bits to meet the requirements of selection lines.
   LPC_UART2-> LCR  |= 0xFFFFFF83;    // To access DLL and DLM we have to set 7th bit of the LCR. We are enabling Dlatch by setting this bit.
   // 0 and 1 bits of LCR is 11. 8 bit data format. 1 stop bit. No parity.
   LPC_UART2 -> DLL = 71;         // To set the baud rate 9600 bps we have to set divisor latch least significant bits to 96.
   LPC_UART2 -> DLM = 0;// and most significant bits to 0.
   LPC_UART2-> FDR = 0xA1;
   LPC_UART2-> LCR &=~(1<<7) ;    // We have to reset the Dlatch bit before starting the communication.
   LPC_UART2->FCR = (1 << 0) | (1 << 6);
   LPC_UART2->FCR |= (1 << 1) | (1 << 2);
   LPC_UART2->IER = (1 << 0);
}

Getting GPS data from Interrupt Handler: The reason we used Interrupt handler was to get the data from GPS without any delay. Interrupt handler on getting all the string, will send over 'Queue'. To get data from the GPS module, we need to send raw data over UART bus :

char dataTobeSenttoGPS[] = "$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n"; char dataTobeSenttoGPS_1[] = "$PMTK220,100*2F\r\n"; After sending this, we will be getting GPS string after every 100ms, which is read by interrupt handler as:

extern "C"
{
   void UART2_IRQHandle()
   {
       static  char GPS_buffer1[100];
       static int i_new=0;
       while(!(LPC_UART2-> LSR & 0x01));
       GPS_buffer1[i_new]= LPC_UART2 -> RBR;
       if(GPS_buffer1[i_new]=='\n') {
          GPS_buffer1[i_new]='\0';
          flag_received = true;
          if(xQueueSendFromISR(gps_queue1, &GPS_buffer1 , 0)) {
          }
          else{
          }
          i_new=0;
       }
       else{
       i_new++;
       }
   }
}

Sending data over CAN bus: In GeoController, we are using can1 for transmit and receive can messages. Latitude and longitude values are getting updated by GPS task using global structure. 'CAN send' function which is getting called every 100hz is using memcpy function to copy the structure data to CAN message and send over can bus.

       gps_msg.msg_id = GEO_LOC_DATA_ID;
       gps_msg.frame_fields.is_29bit = 0;
       gps_msg.frame_fields.data_len = sizeof(gps_data_dec);
       memcpy(&gps_msg.data.qword, &gps_data_dec, sizeof(gps_data_dec));
       CAN_tx(GEO_CNTL_CANBUS, &gps_msg, GEO_CNTL_CAN_TIMEOUT);

IMU

Initialization: IMU is initialized using Singleton Class pattern. UART3 is being used for IMU interface with board.

   readYawCommand{'#', 'f'} // string is used to get Yaw reading from IMU module.
   if(IMUInterface.sendYawReadCommand(IMUInterface.readYawCommand))
   {
       // Waits for a response from IMU
       if(IMUInterface.getYawReadingString())
       {
           CUSTOM_DEBUG("IMUTask : Read success");
       }
       else
       {
           CUSTOM_DEBUG("IMUTask : Read fail");
       }

The Yaw data we received from getYawReadingString() is used later to calculate heading value.

Sending data over CAN bus: CAN1 is used for sending can messages. Following code shows, how the structure for IMU is filled by calling respective functions such as : calculateBearing(), getHeading(), calculateDistance() and then send over CAN bus.

void geo_send_heading()
{
   can_msg_t geo_msg;
   geo_spd_angle geo_data;
   if(a == GEO_DATA_TO_SEND)
   {
       static imu& imu_handle = IMUInterface;  // Handle to singleton IMU object
       geo_data.bearing = calculateBearing(current_checkpoint_data);   // put bearing here
       geo_data.heading = imu_handle.getHeading();
       if(geo_data.heading < HEADING_OFFSET2 && geo_data.heading >= 0)
       {
           geo_data.heading = 360 - HEADING_OFFSET2 + (geo_data.heading);
       }
       else
       {
           geo_data.heading = geo_data.heading - HEADING_OFFSET2;
       }
       geo_data.speed = speed_gps;
       geo_data.distance = (uint16_t)calculateDistance(current_checkpoint_data);
   }
   if(a == GEO_DO_NOT_SEND)
   {
       geo_data.bearing = 0;   // put bearing here
       geo_data.heading = 0;
       geo_data.speed = 0;
       geo_data.distance = 0;
   }
   geo_msg.msg_id = GEO_SPEED_ANGLE_ID;
   geo_msg.frame_fields.is_29bit = 0;
   geo_msg.frame_fields.data_len = sizeof(geo_data);
   memcpy(&geo_msg.data.qword,&geo_data, sizeof(geo_data));
   CAN_tx(GEO_CNTL_CANBUS, &geo_msg, GEO_CNTL_CAN_TIMEOUT);
}

Updating Firmware on IMU:
- For updating the firmware on IMU, we used FTDI basic breakout which uses USB mini cable to connect to PC. The board comes programmed with the 8MHz Arduino bootloader (stk500v1) and some example firmware that demos the outputs of all the sensors. UART connection are made to interface IMU with breakout board at 57600bps. We have modified the firmware in a way that we receive only the required information via UART.
- Connections between IMU and FTDI breakout :-

FTDI BREAKOUT      RAZOR
GND           <--> GND
CTS           <--> CTS
3.3V          <--> 3.3V
TXO           <--> RXI
RXI           <--> TXO
DTR           <--> DTR

The details are given at: https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial. Firmware provides the readings Yaw, Pitch and Roll readings. As in the project we only need the Yaw data, so firmware is been updated to provide only the Yaw readings.

Sensor Calibration:
- Sensor calibration include calibrating the accelerometer, gyroscope and magnetometer. Sensor calibration in our project is done twice, once in the beginning and then at the end when all the boards are mounted on the car. As the magnetic field of motor can effect the gyroscope readings so we did the calibration again. The details can be found on the link given above.

Software Flow Diagram

S/W Interface Flow Diagram of Geo-Controller

Motor I/O Controller

Team Members:

Anuj Korat
Dhruv Kakadiya

Motor & I/O Controller Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	09/20/2015	09/27/2015	Researching and ordering the LCD module to be used in the project	Completed	9/27/2015
2	09/27/2015	10/05/2015	Studying data sheets(LCD and motor) to get understanding of basic concepts and working of components Understanding and proposing driving mechanisms for LCD and motors(DC and servo)	Completed	10/05/2015
3	10/05/2015	10/12/2015	Interfacing motors to SJOne board and developing drivers for the same Interfacing LCD module to SJOne board and developing drivers to display basic texts and symbols	Completed	10/12/2015
4	10/12/2015	10/30/2015	Implementation of basic power on RC car run with motors(DC and servo) interfaced to SJOne board Collaborating with other teams to develop basic obstacle avoidance and testing it	Completed	11/5/2015
5	10/30/2015	11/12/2015	Proposals related to speed controls and sensors for the same and integration of LCD module(with data display)	Completed	11/12/2015
6	11/12/2015	11/25/2015	CAN bus communication from motor and I/O controller to other boards	Completed	11/15/2015
7	11/25/2015	12/15/2015	Debugging issues during trial runs and testing out fault cases	Completed	12/8/2015

Motor/IO Controller Software Design

Tasks

Motor/IO Controller Tasks
Task Name	Purpose
Period Init	Can bus initialization, Motor and LCD initialization
Period Register telemetry	Register Motor_data can message and dc_speed counts for different speeds
Periodic 1Hz Callback	Check can bus off and Print data on LCD
Periodic 10Hz Callback	Drive car according to received data from Master controller
Periodic 100Hz Callback	Receive CAN bus data
Periodic 1000Hz Callback	Receive touch data from LCD and check RPM sensor

DC Motor

Our car came with the motor that needed 7.4V of power supply to work. This motor has the power to run the car at a maximum speed of the 35mph.

The table below contains information about PWM (duty cycle) given to the motor and the corresponding speed of the car on a flat surface.

S.R.	Duty Cycle	Speed(mph)
1	15.80	2
2	16.00	4
3	16.20	6
4	16.40	8
5	16.60	10
6	16.80	11

Table3: DC Motor Duty Cycle v/s Speed

DC Motor

DC motor is controlled with the help of three wires coming out of the ESC. These wires are VCC, GND and Speed control. The VCC line is not used as required voltage is directly given to the motor through a battery, via ESC. The GND line and Speed control lines are connected to the ground and PWM pin of SJOne board.

S.R.	ESC Wire Pins	SJOne Board Pins
1	Vcc	-
2	GND	GND
3	Speed Control	P2.1

DC Motor Pin Connections

To drive the DC motor, we are using pwm2 i.e. pin P2.1 of the SJOne board. We are using the in-build PWM generation function which requires two parameters, one is pin being used and the other being the frequency. To set the required duty cycle, the in-build set function is used.

DC Motor Connector

Servo Motor

Our car came with a waterproof digital servo motor. This motor works without ESC. We can directly control this motor by giving PWM signal from our SJOne board. The below table contains information about PWM (duty cycle) given to the motor and the corresponding turns taken by the car.

S.R.	Duty Cycle	Turn
1	10.41	Full Left
2	12.35	Half Left
3	13.53	Slight Left
4	15.39	Straight
5	16.00	Slight Right
6	17.37	Half Right
7	20.03	Full Right

Servo Motor Duty Cycle v/s Turn

Servo Motor

Servo motor is controlled with the help of three wires coming out of the servo motor. The wires are VCC, GND and Direction control. The VCC is connected to the 3.3v. GND and direction control are connected to the ground and pwm pins of SJOne board.

S.R.	Servo Motor Pins	SJOne Board Pins
1	Vcc	Vcc
2	GND	GND
3	Direction Control	P2.0

Servo Motor Pin Connections

We control the Servo motor using pwm1 i.e. pin P2.0 of the SJOne board. We configure the PWM pin using an in-build function which requires two parameters, one is the pin that we are using and the other is the frequency of the pwm. To set the duty cycle, in-build set function is used in which we are passing the duty cycle at which we want servo motor to work.

Servo Motor Connector

Motor PWM Singleton implementation

I/O Software Design

The I/O Software is based off of two tasks: The Event Handler Task and the RX Task.

Event Handler Task (High Priority):

This Task receives any immediate messages sent from the uLCD, processes the message, and sends the message to the CAN BUS.

This task enables the system to: Turn On/Off the Vehicle and Change Vehicle Modes.

RX Task (Low Priority):

This task receives all messages from the CAN BUS, and outputs message data onto the uLCD

High Level IO Software Logic -- Event Handler Task Logic -- RX Task Logic

HighLevel

EventHandlerTaskLogic

RXTaskLogic

Different screens on LCD

Locked Screen

Home Screen

Geo Screen

Sensor Screen

Motor Screen

The contents displayed on LCD were well thought of according to its application in our project. We wanted to test the sensor and the magnetometer readings while we were testing out car along with testing the algorithm of navigation. This would enable us to not connect the LPC controller with a Laptop to check and verify readings. The LCD we bought is from 4D systems and is very convenient and efficient to use. It has its own software which enables us to work in 4 different modes. We chose the mode which gave us different tools to build the compass, buttons and the angularometer. A bluetooth to serial converter is used to program the LCD with the software. We used the tools (that came with the LCD Module), to picturize our LCD screens. We loaded the program into LCD's memory card. The program that we burned on LCD will use the data bytes we send from our microcontroller and will print those bytes appropriately on different elements that we had created. For example, there are 360 degrees values to show on angularometer. The microcontroller will give a value from 0-360 based on the CAN frame which consists of car speed, heading and bearing values broadcasted by the Geo controller. In this way, almost every parameter being exchanged on the CAN bus of the car is displayed.

The LCD Software

The following is the link to the main page of the LCD. It contains everything you need to know to run this LCD and run it to the highest feature. It has the datasheet as well as the info regarding the software too. Go through the software datasheets as well as we will need that software to run the LCD initially. The LCD accepts any data from our microcontroller only if it is programmed that way by the software.

http://www.4dsystems.com.au/product/uLCD_32PTU/

Next link is to the to the collection of go through materials for each every object the LCD uses.

http://old.4dsystems.com.au/appnotes.php

So you know all the features of the LCD now and also have downloaded the Software, now what? The best and the easiest mode of working is the ViSi-Genie. Its fast, efficient and powerful. With Visi-Genie, you can just drag and drop tools you wanna use on your LCD. Lets take an example.

Now, if you have gone through the software datasheets, you will be already have accustomed with the software and its fun too. Select your tool accordingly your requirement. Be creative. We needed to show magnetometer values, from 0 to 360 in order to debug whether the compass is pointing towards north exactly or not. So we used an angularometer under the Gauges tab. It will have all the properties associated with the object. You can test each of them. Now, the data sent from the microcontroller will be directly printed on the LCD to its position on the angularometer. In this way, we can easily know the direction of True North with the help of LCD. Alon with this there are some strings used on LCD which shows longitude, lattitude, etc. This string is also sent from the microcontroller. When you are done with the tools, put a memory card with a maximum of 2 GB of memory into your LCD and connect it serially to your PC. USB to serial converter is to be used here. Burn the software image onto your LCD. At this point, your LCD is programmed to show all the images and the tools and is ready to accept all the data from the controller and print them on itself. So now we have got to do, is only connect the controller with LCD and send data bytes with help of UART.

The connection is done in following way:-

LPC -> LCD
TXD2 -> RX
RXD -> TX
VCC -> VCC
GND -> GND

The format overhead for sending data is of 4 bytes. If you want to set the angularometer, you have to give 6 bytes via UART,

Byte1 - Event byte
Byte2 - Object type 
Byte3 - Object number
Byte4 - Data byte 1
Byte5 - Data byte 2
Byte6 - Check sum

The following is a code snippet to print a string on LCD

Similarly, when you touch any of the input tool on LCD, it will send 6 bytes in the same format to your microcontroller(Yes! It is touch screen). So, in this way you will know, what object you have set and to what value. For example,

There are some input tools given h=here to change the factor for PWM operation. This really comes in handy when you are testing your car in the field and just to increase your motor's speed you have to change your code and flash your controller again and again. Instead have your LCD set the factor in as simply as this way. When you touch the the left or right arrow, the LCD will send the object's identity to the controller. The controller will check this and it will then set the globally declared PWM factor which changes it in real-time and then print that value on the string object between. See, told you to be creative!. This truly makes your LCD input and output together.

Master Controller

Team Members:

Hemanth Konanur Nagendra
Akshay Vijaykumar

Master Controller Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	10/10/2015	10/20/2015	Establishing powerup sync and acknowledgement between master controller, sensor controller and Bluetooth controller Implement heart beat monitoring on the master controller.	Completed	10/20/2015
2	10/21/2015	10/31/2015	Get sensor readings from the sensor controller and start/stop commands from Bluetooth controller to control the car Send driving commands to the motor controller over the CAN bus	Completed	10/25/2015
3	10/26/2015	11/01/2015	Decide the obstacle avoidance algorithm based on sensor readings from sensor controller. Implement and test the avoidance algorithm.	Completed	11/01/2015
4	11/10/2015	11/20/2015	Get route co-ordinates from Bluetooth controller and setup infrastructure to send checkpoint updates to Geo-controller. The master controller should be able to receive new routes in between navigation.	Completed	11/20/2015
5	10/21/2015	11/30/2015	Get heading, bearing and speed information from Geo-controller Decide on the navigation algorithm	Completed	11/24/2015
6	12/01/2015	12/07/2015	Test obstacle avoidance along with Navigation algorithm	Completed	12/12/2015
7	12/08/2015	12/15/2015	Extensive testing and smoothing out speed, turning, etc	Completed	12/16/2015

The Master Controller receives obstacle information from the Sensor Controller, navigation data from the Geo Controller and routing information from the Bluetooth Controller, collates all this information and provides driving directions to the Motor Controller.

Design

Hardware Design

The diagram shows the hardware connections for the Master Controller.

Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	CAN 3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	CAN Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
8	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Control Flow

On boot-up, Master Controller first attempts to sync with all the other controllers through a power-up sync and acknowledgement handshake mechanism. Once sync is established with all the controllers, it periodically monitors the heart-beat signals from all the controllers till the end of power cycle. If any controller goes out of sync, the master requests that controller to reset itself.

The Master Controller now enters the ‘stopped’ state where no driving takes place. It continuously monitors the CAN bus for any routes from the Bluetooth Controller. Once all the navigation check points have been received, the Master Controller starts driving the car by directing the Motor Controller based on the Geo controller data. While driving, the Master Controller continuously listens for the obstacle data from the Sensor Controller and avoids any obstacles, if necessary. Once obstacle avoidance has been completed, Master makes any necessary course corrections and proceeds towards the destination as per the route.

The flowchart depicts the entire sequence of events involved in driving the car from a source to destination point.

Communication between Controllers

Power-up Sync and Acknowledgement

Once master boots up, it continuously monitors the CAN bus for a “Power up Sync” message from each of the other controllers. Once it receives the Sync message from all the controllers it acknowledges all of them at once by sending the “Master Sync Ack” message. This should prompt the other controllers to spawn their periodic tasks and start their respective functionalities.

Heart Beat Implementation

After sending the ACK message the master proceeds to spawn its own periodic scheduler and starts monitoring the heartbeat signals from all the controllers at a rate of 1Hz.

Every 1Hz, all the controllers are expected to send their respective “Heart-beat” message over the CAN bus. If this message fails to arrive, the master controller will wait for a specific period of time for the other controller to sync again. The sensor controller and motorIO controllers are very critical components for driving the car. So, they are not allowed to skip any heart-beats. The other controllers have varying thresholds of wait time, allowing them to sync with the master again. Once the threshold time is crossed, the master controller issues a “Reset” message for the controller that went out of sync. The receiving controller is expected to reset and sync again at this point.

If the sensor controller or motor controller go out of sync, the master stops issuing driving directions to the motorIO controller, hence stopping the car.

Data Communication

The master controller performs the following data transactions over the CAN bus.

Bluetooth controller signals to the master controller that a new route has been requested from the Android application through “Check-Point Send” message. In this message, the Bluetooth controller also specifies the number of check-points that are present along the route. The master acknowledges this signal through “Check-point Request” message. The Bluetooth controller starts sending the check-points periodically, at 10Hz, after it receives the ack. The master stores all these check-points in an array and switches to navigation mode.

In navigation mode, master controller issues the next immediate check-point to the Geo controller through “Geo location update” message and expects the current heading, current bearing, current speed and current GPS location information from the Geo controller with respect to this new checkpoint. Master controller continuously calculates the distance between the current GPS location and the current checkpoint location to determine if the checkpoint has been reached. Once reached, the next checkpoint co-ordinates are issued to the Geo controller. This cycle is repeated till the destination has been reached.

All through the navigation mode, master controller directs the motor controller to drive (speed and direction to turn) based on heading and bearing information from the Geo controller. The obstacle information is also being continuously received from the sensor controller. If an obstacle is detected, the master controller stops navigating to the checkpoint and avoids the obstacle. Once obstacle has been avoided the master goes back to navigation.

Driving Algorithm

Overview

Driving algorithm has two parts to it. One is the obstacle avoidance algorithm and the other is the navigation algorithm. Obstacle avoidance has a higher priority. Navigation algorithm drives the car as long as no obstacles are present.

Obstacle Avoidance Algorithm

The primary obstacle avoidance algorithm is based on the front three sensors. The algorithm is based on the truth table below. The near obstacles have higher priority than obstacles in the mid range, which has a higher priority than the obstacles in the far range. The tables below depict the action taken by the master controller when obstacles are in the near and mid-range. A ‘1’ in the table represents that a particular sensor has an obstacle within the range being evaluated. A ‘0’ represents that a particular sensor has no obstacle within the range being evaluated. The last two columns show the command sent from the master controller to the motorIO controller.

Obstacle avoidance in the Near range

Front Left Sensor	Front Center Sensor	Front Right Sensor	Motor Speed	Motor turn
0	0	0	Normal	Straight
0	0	1	Slow	Hard Left
0	1	0	Stop	Straight
0	1	1	Slow	Hard Left
1	0	0	Slow	Hard Right
1	0	1	Stop	Straight
1	1	0	Slow	Hard Right
1	1	1	Stop	Straight

Obstacle avoidance in the Mid range

Front Left Sensor	Front Center Sensor	Front Right Sensor	Motor Speed	Motor turn
0	0	0	Normal	Straight
0	0	1	Slow	Slight Left
0	1	0	Normal	Straight
0	1	1	Slow	Slight Left
1	0	0	Slow	Slight Right
1	0	1	Stop	Straight
1	1	0	Slow	Hard Right
1	1	1	Stop	Straight

Navigation Algorithm

As stated before, the Master Controller receives all the necessary parameters for navigation viz, current GPS co-ordinates, heading and bearing from the Geo-Controller. The heading and bearing are angles that are measured from 0 degrees to 360 degrees from the true North. Heading specifies the direction in which the car is currently oriented in. Bearing specifies the direction in which the car has to be oriented so as to reach the next check point. The current navigation algorithm divides the entire 360 degree orientation space of the car into 30 zones of 12 degrees each. The difference between the bearing and heading values is used to correct the direction of the car. This correction value would lie between 0 degrees to 360 degrees, falling into one of the 30 zones. As seen in the diagram, If the correction lies between 0 degrees to 12 degrees, the car should travel straight at normal speed. If the correction lies between 97 degrees to 180 degrees, the car should take a U-turn from the right direction at a slow speed. Similar behaviors of the car in terms of the direction and speed of movement of the car are specified for each zone and are sent as commands to the Motor Controller.

A few examples to test the correctness of the algorithm are discussed. If the heading is 50 degrees and the bearing is 90 degrees, the correction is 40 degrees. The behavior specified for the zone in which this correction will fall into is for the car to perform a hard right turn at slow speed. Similarly, if the heading is 70 degrees and the bearing is 10 degrees, the correction is -60 degrees. Converting this to a value in between 0 degrees and 360 degrees, we have 300 degrees ( 360 degrees - 60 degrees ). The behavior specified for the zone in which this correction will fall into is for the car to perform a slight left turn at normal speed.

Distance Calculation

The distance is calculated as shown in the figure below.

The master controller continuously monitors the distance of the car from the next checkpoint. We issue the next checkpoint co-ordinate when the distance is less than or equal a threshold value. The current threshold has been set to 3m after performing tests with a range of threshold values.

LED and 7-Segment Display Status

LED 1 - ON or OFF when the START or STOP command is issued from the Bluetooth Controller/Mobile Application.

LED 2 - Toggles when in Obstacle Avoidance Mode. OFF when in Navigation Mode.

LED 3 - ON if controller heartbeats are missed. OFF when all controllers are in sync.

LED 4 - ON when an error in CAN communication occurs. Turns OFF when the Errors are handled.

7-Segment Display - Displays the current checkpoint that the car is navigating to. When the destination is reached, the number '99' is displayed.

Bluetooth/Bridge Controller

Team Members:

Anush Shankar
Aditya Devaguptapu

Bluetooth/Bridge Controller Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	09/20/2015	09/30/2015	Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API	Completed	09/30/2015
2	09/31/2015	10/10/2015	Placement of buttons on the app activity page to switch on and off bluetooth on the phone Marker placement on Google maps for source and destination	Completed	10/10/2015
3	10/10/2015	10/22/2015	Creating input and output streams for bluetooth for sending and receiving data Performing straight line routing between source and destination on google maps	Completed	10/22/2015
4	10/22/2015	10/30/2015	Interfacing bluetooth module to SJOne board through UART and receive data on SJOne board sent by the bluetooth application	Completed	11/05/2015
5	10/30/2015	11/10/2015	Relay commands and CAN messages from SJOne to android application and test correctness of data	Completed	11/15/2015
6	11/10/2015	11/22/2015	Performing correct routing between source and destination, have a complete working application, basic testing of application and bridge interface	Completed	11/22/2015
7	11/22/2015	12/15/2015	Extensive Testing of application during final phases, modifying code in cooperation with other teams and optimization of android application	Completed	12/13/2015

Bluetooth Controller

The Bluetooth Controller is responsible to help the RC car navigation by providing it with route information between source and destination as selected on the Android application. It communicates with the Android application over Bluetooth channel to obtain the route and way-point data between two points on the google map. The route and way-point information once received is parsed to get latitude and longitude for all way-points. This information is then communicated to the Master Controller via CAN bus.

HC-06 Bluetooth Module

The HC-06 is a bluetooth controller with slave only configuration used to communicate to and from a master Bluetooth module. The master Bluetooth module is capable to initiating a connection with other Bluetooth module, while slave is not able to do that. The slave can only communicate with the master module over a connection established by the master. The HC-06 by default is in slave configuration as per factory settings.

Some of the features of HC-06 which make it apt for the RC car are as follows:

Can work at the low voltage (3.1V~4.2V). The current in pairing is in the range of 30～40mA. The current in communication is 8mA.

Has a 2.4GHz digital wireless transceiver.

Small (27mm×13mm×2mm)

Peripherals circuit is simple.

Low power consumption

Has high-performance wireless transceiver system

Low Cost

Bluetooth Controller Hardware Design

Bluetooth Controller Interface Diagram

Bluetooth Controller Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	CAN 5V	Power Supply	5V	SJOne - CAN Power
6	CAN Transceiver	CAN Ground	Power Supply	GND	SJOne - CAN Ground
7	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
8	CAN Transceiver	CANH	CAN BUS	CANH	CANH to CAN BUS
9	Bluetooth Module	TXD	SJOne Board	RXD3	SJOne RX3- Bluetooth module TXD
10	Bluetooth Module	RXD	SJOne Board	TXD3	SJOne TX3- Bluetooth module RXD
11	Bluetooth Module	Bluetooth module VCC(3.3V)	Power Supply	3.3V	Bluetooth module - Power supply 3.3V
12	Bluetooth Module	Bluetooth module GND	Power Supply	GND	Bluetooth module - Power supply GND

Control Flow

On boot-up, Bluetooth Controller first attempts to sync with the Master controller through a power-up sync and acknowledgement handshake mechanism. Once sync is established with the Master Controller, the Bluetooth controller periodically sends heart-beat signals to master controller till the end of power cycle. If any Bluetooth controller goes out of sync, the master requests the controller to reset itself.

Once all initial handshaking procedures are completed and heart beat signal is established, the Bluetooth Controller waits for data from the On board HC-06 Bluetooth module on the UART port. When Bluetooth connection is established between the Android application and the On board HC-06 Bluetooth controller, routing data is sent from the Android app to the SJOne board. The SJOne board receives the data on UART port via interrupts and parses the data to extract 6 point precision floating point values for each way-points latitude and longitude. The way-point latitude and longitude is stored in a array to be sent out on CAN bus.

Once all way-point data is parsed and ready, the SJOne board first sends out the number of way-points to the master controller and waits for acknowledgement from the master controller. One reception of the acknowledgement from the master and intent to receive the way-point data, the data is sent on the CAN bus periodically till all the data is exhausted.

Communication between Bluetooth and Other Controllers

Power-up Sync and Acknowledgement

Once Bluetooth controller boots up, it continuously sends "Power up Sunc" on the CAN bus to the master using "BLUETOOTH_SYNC_ID" can message id. The controller then polls on the sync function to receive an acknowledgement from the master towards "Power on Sync". Once an acknowledgement is received from master with message id "MASTER_SYNC_ACK_ID", the Bluetooth controller starts the FreeRtos scheduler. Only after this will all tasks run on the controller.

Heart Beat Implementation

Once Bluetooth controller starts the scheduler, it starts sending out heart beat messages on can bus directed towards the master controller using message id "BLUETOOTH_HEARTBEAT_ID" every 1 Hz. If the master does not receive heart beat message it asks Bluetooth controller to reset.

Data Communication

The Bluetooth controller performs data transactions over the CAN bus with the master controller and Geographical controller. The Bluetooth controller receives the geo coordinates every 1 hz using "GEO_LOC_DATA_ID" to get current car location and send it to the android application for dynamic location update. Bluetooth controller signals to the master controller that a new route has been requested from the Android application through “CHECKPOINT_SEND_ID” message id. In this message, the Bluetooth controller also specifies the number of check-points that are present along the route. The Bluetooth Controller waits on master's acknowledgement through “CHECKPOINT_REQ_ID” message id. The Bluetooth controller starts sending the check-points periodically, at 10Hz, after it receives the ack. Once all the way-points are sent to the master, the Bluetooth Controller goes to listening to UART interrupts for any changes in the route.

Flow Chart

The flow chart for the Bluetooth Controller is as follows:

Bluetooth Controller Flow Chart

Android Application Design

Problem Definition

At the end of the day, an autonomous vehicle is built so as to usher in a new era of transport where the user need not be concerned with driving the vehicle. With this basic idea in mind, we can thus define our problem- how does one communicate with an autonomous vehicle to perform the tasks he/she desires? On further contemplation, it could even be argued that we are able to accomplish the task of navigating from source to destination in a normal vehicle because the user is able to manually control the vehicle. We will hence require an interface by means of which we can specify a source and a destination. With the ubiquity of smart phones, it makes perfect sense for us to leverage the availability of the Android platform to make an application that would augment the user’s ability of accomplishing objectives with the autonomous vehicle.

A Basic Mock Up of the App based on the Problem Definition

Design

The objective of the Android App is to be able to let the user control the car by issuing commands from a smartphone- the most fundamental commands being the ability to issue a source and a destination for the Car to traverse. Providing the car with autonomy ensures that we need to be able to specify location information to the car in a form that it can understand. We will thus use Google’s comprehensive mapping solution to look up places on the map. We shall also use their services to get the best route available between the source and the destination. Google’s Android OS is a very popular OS for smartphones. Its proliferation in the smartphone market, very comprehensive documentation and open-source nature make it a natural choice for the platform on top of which the application will be developed. Android Studio is Google’s IDE for developing applications on the Android platform. Their Maps API will be used to implement a Map fragment and to specify travel points while the Directions API works in the background to provide a route from source to direction. The user will be provided with buttons to connect with the car, to issue Start/Stop Commands, to send a route if a travel needs to be performed and to determine the location of the car.

Android application design and sequence of operations

Implementation

App Template and Using Google Maps within an App

Android Studio comes with some default templates which lets the user have a basic app up and running within no time. The project has a .java file to program the logic of the app while the user interface can be modified using the .xml(extended markup language) file. The user can test the app using the in-built emulator or by running it on an Android phone. To use Maps within your application, you will first have to get a API key on Google’s Developer Console online. This API key lets Google track statistics related to the app usage. If the Map loads when the App starts up, then its a sign that you’ve successfully implemented a Map fragment.

Using Maps and Implementing the Directions API

A Maps Fragment comes with several features that let the user specify input to the App. We use Markers (Pin shaped images) to denote locations on the map. Every Marker on the map has its own latitude and longitude which is a necessary value for calculating a route. We essentially want to calculate a route from a source, which in this case, is the location of our car. The CarLocation Button gets us the location of the Car and places a marker on the map at the location of the Car. The App has a OnClickListener function in the background, waiting for a tap input from the user. This tap places a marker that denotes the destination that the user, or in this case, the car will navigate to. On placing the destination marker, the Directions API calculates a route between the source and the destination based on how the parameters for the API are defined. The Directions API returns intermediate points (with latitudes and longitudes of their own) that form a route between the source and the destination. The Polylines function defined within the map can be used to plot a line that connects these points from the source to the destination.

Application Startup

Placing a Marker at the Car Location

Creating a Route from Car Location to the Destination Marker

Showing intermediate co-ordinates along the route

Using Bluetooth and Bluetooth API

Android provides a robust and well defined Bluetooth API as part of application development support. The API provides functions to query devices, pair with devices, connect to devices and send/receive data. In our application pairing, connection and send/receive API functions are used to talk to HC-06 Bluetooth module on the RC car. The application has a bunch of buttons at the bottom which are used to establish Bluetooth communication and used to control markers on the Google Map. The functionalities of the Buttons are as follows:

SI No.	Button	Functionality
1	ON	User is prompted to Turn on Bluetooth device on the phone. User can "allow" or "deny" the request. Application displays message if no bluetooth support on phone.
2	CONNECT	Establishes a communication channel with a slave Bluetooth. Connection is done to a Predefined Bluetooth MAC address.
3	DISCONNECT	Disconnects communication channel with an already connected Bluetooth module
4	START CAR	Sends string 0 over Bluetooth channel to indicate to the SJOne Board start of car.
5	STOP CAR	Sends string 0 over Bluetooth channel to indicate to the SJOne Board to kill the car(Wireless Kill switch).
6	CLEAR	Clears markers on the Google Map.
7	CAR LOC	Places a marker on Google Map based on cars coordinates received from the HC-06 Bluetooth module on-board the car.
8	SEND ROUTE	Send route from source to destination selected on map after filtering way-points.

Our Modifications

The number of points returned was filtered to obtain an accurate route with sufficient points, enough to not overwhelm the SJOne Board during processing.
The first point was ignored because it nearly coincides with the location of the car and it made sense for the car to ignore this first point in order to preserve time and power.
We also place a limit on the maximum number of points that can appear. For a real world scenario, this limit wouldn’t make sense. However for a tiny RC Car which runs on battery to possess so much information and not be able to navigate through vast paths, it wouldn’t make sense for so much information to be filtered.

Workflow

On starting the app, the user first uses the ON button to switch the phone’s bluetooth On. The next step is to Connect to the Bluetooth module that is present on the RC Car. This is accomplished using the Connect button, which toasts a “Connected” notification once this connection happens. The Start Car Button then polls for the location of the car and places a marker on the map. The User may then tap the map and place the destination marker. Placing the destination marker triggers the Directions API to create a route and plot it from the location of the Car till the Destination Marker. The Send Route button sends the route to the controller on the car which lets the car travel from source to destination.

Overall System Optimizations and fail safe conditions

We have taken all fail safe conditions into consideration, so suppose if any controller will not work as desire or will work in very bad way then how our car should respond to that condition?

If sensor controller is not working properly and sensor CAN messages are not on bus then master controller will detect that and suddenly after some number of missing counts it will issue stop motor command to motor controller.

At motor controller side as we have connected RPM sensor to increase/decrease speed according to actual real time feedback from rotations of wheel, is not working properly or we can consider that RPM sensor is being dead then in that case normal motor algorithm will detect that RPM sensor count is zero only if my motor actually rotates or not. So in that condition our optimized algorithm was detecting if RPM sensor count is zero for continuous 3 seconds then there is something wrong happening with RPM sensor so Motor controller will immediately send stop command to motors.

Suppose due to steep slope my motor speed gets increased too fast and then suddenly flat surface is coming then in that condition if we will not optimize our driving algorithm then motor will run away very fast then normal speed, so remove that type of condition we have taken difference of RPM sensor counts in interval of each second. So if that difference is too high then decrease speed at very high factor and speed is too slow then vice and versa. So it is basically like put RPM sensor count difference into PID(Proportional, Integral, Differentiation) algorithm to make out very smooth navigation.

If bluetooth controller will be out of range after established connection between bluetooth controller and mobile application then it results into some undesired condition like we will not have any control of car in our hand. So to resolve this problem we were continuously sending some heartbeat commands from bluetooth application to controller in each second of interval after establishing connection. So if bluetooth controller will not get heartbeat command from Android application then it will send motor stop command to master and master will forward that command to Motor controller so we can stop motors immediately.

At Geo controller side if GPS is not stabilized its values and still someone has issued navigation command from bluetooth application then Geo controller will give longitude and latitude as zero only so master will know that it's wrong values so master controller will not issue start command to motors.

In Geo controller we were not getting just simple reading of compass for heading calculation but we were taking reading of yaw angle from gyrometer in reference of magnetic axis of earth with subtracting necessary pitch of car with Kalman filter implementation. So we were getting very smooth and exact angle in any condition like if car navigates on any type of slope(up/down).

Testing & Technical Challenges

Issue #1 (Motor I/O)

The Motor I/O controller is the only controller which accepts all the CAN messages sent on the bus. This is because the LCD needs to print values from the different controllers like Sensor controller, Master controller and Geo controller. It was decided mutually to use the CAN transmit receive function on the bus at same speed, which was 100 Hz. As our controller had to receive more than one frame in one cycle of 10 ms, the hardware CAN receive queue kept on enlarging. We were dequeueing at a slower speed than what was required. So, the rate at which the data was read by the software was not fast enough when compared to the hardware buffering the data. This slowed down our operation. So, a tip for the future - always make sure that you receive the CAN data frame at the same speed as the transmitter's and dequeue your CAN receive queue completely so as to make sure you are getting all the latest data. Also, make sure to remove all the debug prints in the periodic scheduler running at 100 HZ frequency or more. We could put Telemetry to good use here.

Issue #2 (Project Hardware)

We decided to establish CAN communication across different controllers at an early stage in the project. In order to do so, we rushed into soldering the CAN bus on the PCB. At a later stage, we realized that we had done this in a compact manner. And now, arranging all the LPCs together with the jumper wires connecting to the CAN bus made it hard to debug issues. We had to re-arrange the whole hardware, strictly according to the soldered CAN bus which made the task a little inconvenient. Lesson learnt here was that, when it comes to hardware, always discuss with your teammates about all the aspects of arranging your car and keep some space for future use.

Issue #3 (Project Hardware)

Perhaps the most common problem for all the groups, the car crashed in almost every run during the initial testing phases. Even if you think your code is perfect and your car will do exactly what you think it should, it will crash for sure at start and may wreck something here or there (Trying to save your car and not disappoint you!). Install a kill switch at the earliest that will instantly stop the car whenever you want. At least implement a kill button in your Mobile App. Also, try to cover the front of your car with multiple layers of cardboard, thermocol or sponge material which will help the car to absorb the shock.

Issue #4 (Geo controller software)

Geo controller was crashing randomly. After careful observation, we figured that the problem was happening because of too many log messages written to SPI flash. The memory was full with log errors. Clearing flash and removing unnecessary logging from the code helped solve the problem.

While initially testing IMU in raw data mode, the module was providing improper data values. We had to calibrate the Gyrometer and Magnetometer to get exact angles with precision of +/- 2 degrees. Even after this, the magnetometer's readings were changing when any soft/hard iron object was taken near the sensor. In order to remove electromagnetic interference generated from DC motor, we had to place our IMU far from DC Motor.

To ensure that the data values provided by the IMU were accurate, we calibrated IMU sensors with the help of calibration Software provided by manufacturer.

Sometimes the string received from GPS module contains void data. To get rid of this invalid data, we started using UART interrupts and receiving all data at once. This is later sent to the GPS task via a Queue. Here, the GPS tasks validates the data and sets GPS structure to NULL in case data is invalid.

In the beginning, we were not using the volatile keyword due to which, there was no update in the string we read from Queue in the GPS task. By using volatile keyword on the variable used inside the Interrupt handler, we avoided the compiler optimization.

Issue #5 (Motor Controller software)

While initializing ESC(Electronic Speed Controller), we didn't know the exact sequence to be sent for initialization of DC motor. We tried to figure out the required sequences by using an Oscilloscope. We used this to hack the ESC for the pulse width and frequency, the DC motor parameters used to drive the car in Forward and Reverse direction. We figured out the initialization sequence by trial and error.

The main point was to give at least a 20ms(miliseconds) time delay to send each pulse. Otherwise, if we send pulses less than 20ms, the pwm pulse value will not be set properly as DC pwm's frequency itself was 20ms(Frequency - 50Hz).

We had issues driving the DC motor. The ESC would receive the PWM values that we were setting and drive for a short period of time. Then the motor would stall. We had individual PWM objects for DC and Servo motors. There was no way for us to initialize this object in one place and use it in other places. Declaring global or static object of this class did not help. It was being destroyed at some point. Making the PWM class instance as a singleton solved this issue. The lesson here is, PWM generator is a hardware resource available for us and should be initialized only once before being utilized. Singleton classes provide the necessary means to accomplish the same. Moreover, singleton also forces the existence of only one instance of the class just like how there is just one instance of the hardware resource on board.

Issue #6 (Sensors using Interrupt on the 4-pin sensor's Echo pin)

Sequential Pinging

Initially, we tested the code for front, right and left 4-pin ping sensors. We got satisfactory readings for all the 3 sensors. However, the distance value measured were unusually large at some angles. We concluded that at some point, the echo pin was not reaching the low edge while we were triggering the next sensor. This was affecting the distance value calculated. We solved this issue by checking for the logic level of the echo pin, and proceed with further triggering only when the echo pin was low.
Once this was resolved, the obtained output readings matched the expected output readings. All the zones and distance values were a match for the obstacle provided for the sensors.

Inline resistors

The testing was a success on the breadboard. When we loaded the code onto the sensor controller on the car, the readings were inaccurate. We realized, on the breadboard we tested using inline resistors between the echo pin of the sensor and the GPIO pin(set as input pin to the board) of the SJOne board. Once we introduced the inline resistors while testing on the sensor controller, we obtained accurate readings. Thus, we solved the issue of inaccurate readings and unresponsive input to the board by introducing the 1K inline resistors for each echo pin of the three sensors. If you plan to work with the ping sensors, do us the inline resistors as it was very obvious with the readings we experienced, inline resistors made a huge difference.

Issue #7 (Sensors using Interrupt on the 3-pin sensor's Echo pin)

Once the interrupt algorithm worked for 4-pin sensors, we implemented the same algorithm for 3-pin sensors with changes in the configuration of input and output pins. We tested for a single 3-pin sensor and obtained readings were accurate. Later we introduced the second sensor for testing the algorithm. This created an issue. The front sensor was being triggered and the same pin was configured as echo pin. Reading was obtained on the echo pin of the front sensor. In the next cycle, the index was incremented to the next sensor. The algorithm was stuck on the second sensor triggered. Each time the function was called from the periodic callback the index did not increment as required by the algorithm. We suspected the echo pin of second sensor was not going low at the required time, which would increment the index according to the algorithm. We could not debug this issue in time for demo. We hope to debug the issue and get the algorithm running for 3-pin sensors too.

Conclusion

Altogether, we really enjoyed this class and working on this project. We faced many difficulties throughout the semester including understanding the requirements for the project, planning and executing it. But each time we faced a problem, we got to learn something new. All of us were stuck at our individual tasks at some point or the other, but we helped each other and finally made our project up and running. Not to mention, Preet was always easily approachable.

The project functioned as intended by our design. -> Sending a source, a destination and checkpoints between them, from Android app to the Bluetooth controller -> Sending these co-ordinates to the Geo controller through CAN bus -> Calculating heading and bearing at Geo and sending those values back to Master Controller -> Sensor controller sending its readings from sensors to Master Controller -> Directing the Motor I/O Controller based on the Obstacle Avoidance and Navigation algorithms -> Motor I/O controller driving the car and displaying car parameters on LCD for debugging.

Don't spend too much time in heartbeat and power synchronization implementation as that is not actually required to run your car successfully, as in our project as well, we have implemented that thing but still there is no need to implement so better to start your project without heartbeat and power synchronization and spend more time on preciseness of obstacle avoidance and navigation algorithm. Choose Distance sensor, IMU and GPS sensor very wisely because a central point of this project is exactness of these 3 sensors and reliable CAN bus communication. If you want to really maintain real Automobile programming standards then try to follow MISRA-C/C++ standard. Some tasks were very tough to debug. But if you really put your mind into it, you will be able to see the solution right in front of you. One final tip - Do not get frustrated, There is not a single thing like "MAGIC"! Always have a bigger picture in mind! We have uploaded everything regarding this project on this page. We honestly appreciate your interest in reading it. Thank you and best of luck!

Project Video

CmpE 243 F15 The Titans - Self Driving RC Car Project

Project Source Code

Gitlab Source Code Link

References

Acknowledgement

We would like to thank Preet for teaching the concepts in a very practical sense in the class. It really helped us in the implementation and the testing of the project. We would also like to thank Rutwik who was always ready to help and who also gave us many ideas of what we can do in the project. All the team members worked really hard towards this project and this motivated us in accomplishing the team goals every week. All in all, a great course which required us not to memorize, but to think in a practical way. Thanks again Preet to introduce this course to the major. This will surely be a major benefit in building our career!

References Used

[1] Preetpal Kang's lecture notes of CMPE 243, Computer Engineering, San Jose State University, Aug-Dec 2015. 
[2] Fall 2014 Wiki Projects
[3] LPC1758 User Manual
[4] Parallax Ultrasonic Sensor
[5] CAN Transceiver
[6] Razor IMU
[7] Razor IMU Tutorial
[8] Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3
[9] GPS data calculation accuracy
[10] GPS Longitude Latitude distance calculator
[11] Calculate distance between two points

@@ Line 1: / Line 1: @@
-=== Grading Criteria ===
+== TopGun Self Driving Car ==
-<font color="green">
-*  How well is Software & Hardware Design described?
-*  How well can this report be used to reproduce this project?
-*  Code Quality
-*  Overall Report Quality:
-**  Software Block Diagrams
-**  Hardware Block Diagrams
-**:  Schematic Quality
-**  Quality of technical challenges and solutions adopted.
-</font>
-== Project Title ==
 This is Top Gun - The super car that drives by itself!
 == Abstract ==
-The GPS-controlled automated RC car will consistes of 5 different LPC 1758 controllers. Each controller will have a specific major tasks required to drive the car. The naming convention goes as:-
+The GPS-controlled automated RC car will consists of 5 different LPC 1758 controllers. Each controller will have a specific major tasks required to drive the car. The naming convention goes as:-
 Motor & I/O controller - this will control the motors of the car and will also connected with a LCD display to show the car's status, Sensor controller - It will be connected to the obstacle detecting sensors on the car, Communication Bridge - It will be connected to an Android mobile phone so as to provide co-ordinates, GEO controller - This will give the exact orientation of the car e.g., heading & bearing, etc. and finally the Master controller - This will collect the data from other controllers and will guide the motor controller. These controllers are connected using CAN bus. After the final implementation, this car will be capable of driving by itself using the destination co-ordinates set by us avoiding every obstacles, overcoming slopes thereby reaching the destination safely!
+[[File:F15_243_TG_ProjectDiagram.jpg|750px|thumb|centre|Project Diagram]]
 == Objectives & Introduction ==
-Show list of your objectives.  This section includes the high level details of your project.  You can write about the various sensors or peripherals you used to get your project completed.
 === Team Members & Responsibilities ===
+'''Members:'''
+*Divya Dodda
+*[https://www.linkedin.com/in/dhruvkakadiya Dhruv Kakadiya]
+*Chitrang Talaviya
+*Navjot Singh
+*Anuj Korat
+*[https://www.linkedin.com/in/anush-shankar-b9bb3376 Anush Shankar]
+*[https://www.linkedin.com/in/adityadeva Aditya Devaguptapu]
+*[https://www.linkedin.com/in/hemanthknagendra Hemanth Konanur Nagendra]
+*[https://www.linkedin.com/in/akshayvijaykumar Akshay Vijaykumar]
 '''Treasurer:'''
@@ Line 36: / Line 33: @@
 == Schedule ==
-Show a simple table or figures that show your scheduled as planned before you started working on the project.  Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals.  The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.
 '''Team Schedule'''
@@ Line 83: / Line 79: @@
 | Discussions and proposals on basic obstacle avoidance algorithm with sensor integration, hands on and testing
 | Completed
-|
+| 11/03/2015
 |-
 ! scope="row"| 6
@@ Line 89: / Line 85: @@
 | 11/25/2015
 | Integrating other modules and components to the RC car, development of autonomous driving algorithm and finalize on hardware layout of the car
-| Incomplete
+| Completed
-|
+| 12/1/2015
 |-
 ! scope="row"| 7
 | 11/25/2015
-| 12/15/2015
+| 12/7/2015
 | Testing the RC car in real world environments
-| Incomplete
+| Completed
-|
+| 12/5/2015
 |-
 |}
@@ Line 107: / Line 103: @@
 ! scope="col"| Part Desciption
 ! scope="col"| Vendor
-! scope="col"| Web link
 ! scope="col"| Qty
 ! scope="col"| Cost
@@ Line 113: / Line 108: @@
 ! scope="row"| 1
 | RC Car
-| From Preet
+| [http://www.rchobbyexplosion.com/DHK_Hunter_4WD_Short_Course_Truck_with_2_4Ghz_p/dhk8135.htm From Preet]
-| http://www.rchobbyexplosion.com/DHK_Hunter_4WD_Short_Course_Truck_with_2_4Ghz_p/dhk8135.htm
 | 1
 | Free
@@ Line 120: / Line 114: @@
 ! scope="row"| 2
 | RC Car Battery
-| Amazon
+| [https://www.amazon.com/dp/B000HKKZN0/ref=rr_xsim_1_1?ie=UTF8&qid=1443933750&sr=0 Amazon]
-| http://www.amazon.com/dp/B000HKKZN0/ref=rr_xsim_1_1?ie=UTF8&qid=1443933750&sr=0
 | 1
 | $24.72
@@ Line 127: / Line 120: @@
 ! scope="row"| 3
 | Core CPU Supply
-| Amazon
+| [https://www.amazon.com/gp/product/B002BHXYSK?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00 Amazon]
-| http://www.amazon.com/gp/product/B002BHXYSK?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00
 | 1
 | $12.70
@@ Line 134: / Line 126: @@
 ! scope="row"| 4
 | CAN Transceiver MCP2551
-| Microchip
+| [https://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405 Microchip]
-| http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405
 | 15
 | $20.00
@@ Line 141: / Line 132: @@
 ! scope="row"| 5
 | Printed Circuit Boards
-| Amazon
+| [https://www.amazon.com/Prototyping-Tinned-Universal-Printed-150x200mm/dp/B00N3WTROC/ Amazon]
-| http://www.amazon.com/Prototyping-Tinned-Universal-Printed-150x200mm/dp/B00N3WTROC/
+| 1
-http://www.amazon.com/Double-Protoboard-Prototype-Printed-Circuit/dp/B00NQ3A50S/
+| $12.25
-| 4
-| $20.13
 |-
 ! scope="row"| 6
 | M-F,F-F,M-M Jumper Wires
-| Amazon
+| [https://www.amazon.com/Kalevel%C2%AE-120pcs-Multicolored-Female-Breadboard/dp/B00M5WLZDW/ Amazon]
-| http://www.amazon.com/Kalevel%C2%AE-120pcs-Multicolored-Female-Breadboard/dp/B00M5WLZDW/
 | 120
 | $8.75
 |-
 ! scope="row"| 7
-| Servo Motors
+| Ultrasonic Parallax Ping Sensor
-| Amazon
+| [https://www.google.com/shopping/product/17772903592734483233?lsf=seller:6136318,store:2824197551625125398,lsfqd:0&prds=oid:18367026665601502597&q=Parallax,+Inc.+28015-RT+Ping+Ultrasonic+Distance+Sensor&hl=en&ei=f5R0VpeOL8a-jwO0zITwDw Fry's Electronics]
-| http://www.amazon.com/RioRand-TowerPro-micro-Helicopter-Arduino/dp/B00M8RGGFG/
+| 1
-| 5
+| $63.99
-| $12.89
 |-
 ! scope="row"| 8
 | Ultrasonic Sensors
-| Amazon
+| [https://www.amazon.com/gp/product/B00NG8TJ6E?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s02 Amazon]
-| http://www.amazon.com/gp/product/B00NG8TJ6E?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s02
 | 5
 | $10.45
@@ Line 170: / Line 156: @@
 ! scope="row"| 9
 | 9 DOF Razor IMU module
-| SparkFun
+| [https://www.sparkfun.com/products/10736 SparkFun]
-| https://www.sparkfun.com/products/10736
 | 1
 | $74.95
 |-
 ! scope="row"| 10
 | FTDI Basic Breakout
-| SparkFun
+| [https://www.sparkfun.com/products/9873 SparkFun]
-| https://www.sparkfun.com/products/9873
 | 1
 | $14.95
@@ Line 184: / Line 168: @@
 ! scope="row"| 11
 | LCD Display uLCD-32PTU
-| 4D systems
+| [https://www.4dsystems.com.au/product/uLCD_32PTU/ 4D systems]
-| http://www.4dsystems.com.au/product/uLCD_32PTU/
 | 1
 | $111.00
@@ Line 191: / Line 174: @@
 ! scope="row"| 12
 | Bluetooth Module
-| Amazon.com
+| [https://www.amazon.com/KEDSUM%C2%AE-Arduino-Wireless-Bluetooth-Transceiver/dp/B0093XAV4U/ Amazon]
-| http://www.amazon.com/KEDSUM%C2%AE-Arduino-Wireless-Bluetooth-Transceiver/dp/B0093XAV4U/
 | 1
 | $9.99
@@ Line 198: / Line 180: @@
 ! scope="row"| 13
 | Wire Cutter
-| Amazon
+| [https://www.amazon.com/Hakko-CHP-170-Stand-off-Construction-21-Degree/dp/B00FZPDG1K Amazon]
-| http://www.amazon.com/Hakko-CHP-170-Stand-off-Construction-21-Degree/dp/B00FZPDG1K
 | 1
 | $2.99
@@ Line 205: / Line 186: @@
 ! scope="row"| 14
 | GPS Sensor
-| Adafruit
+| [http://www.adafruit.com/products/746 Adafruit]
-| http://www.adafruit.com/products/746
 | 1
 | $39.95
 |-
 ! scope="row"| 15
-| 7-Segment Display
+| Bosch 9 DOF sensor
-| From Preet
+| [https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/ Adafruit]
-| https://www.sparkfun.com/products/retired/9765
+| 0
+| $34.95
+|-
+! scope="row"| 16
+| Black/White line detection sensor - RPM sensor
+| [http://www.amazon.com/Channel-Tracing-Sensor-Module-Detection/dp/B00LZV1V10/ref=sr_1_5?ie=UTF8&qid=1451253609&sr=8-5&keywords=white+line+detection+sensor Amazon]
+| 1
+| $6.49
+|-
+! scope="row"| 17
+| Hall effect sensor - RPM sensor
+| [http://www.amazon.com/Arduino-compatible-Velocity-Measurement-Sensor/dp/B00AFOZ6SW/ref=pd_sim_328_3?ie=UTF8&dpID=41niZqNYJBL&dpSrc=sims&preST=_AC_UL160_SR160%2C160_&refRID=1K0ABKZCYZSVCKF0Q293 Amazon]
 | 1
-| Free
+| $5.59
+|-
+! scope="row"| 17
+| RGB Backlight Character LCD 20*4
+| [https://www.adafruit.com/product/499 Adafruit]
+| 0
+| $24.95
 |-
 ! scope="row"|
 | Total Cost
 |
-|
 |
 | $450
@@ Line 226: / Line 222: @@
 |}
-== Design & Implementation ==
+== DBC File Implementation ==
-The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
-=== CAN Message ID Table ===
+* This section explains DBC file implementation of the project. The DBC implementation contains the python based DBC file parser, a DBC file and auto generated C code for the five CAN nodes. These five nodes include driver(master), sensor, motor, geo and bluetooth node. The DBC file is a input to the python DBC parser script. The python script will generate a C file for the specific node given by the user at the command line argument. The python script goes through this DBC file and generates code to marshal (covert to raw CAN) and unmarshal (convert from raw CAN) using the provided API that you can enclose in a header file.
-{| class="wikitable"
+* The following is the DBC file of the project.
-|-
-! scope="col"| Message ID
+ VERSION ""
-! scope="col"| Task associated with ID
+ NS_:
-! scope="col"| Data bit-fields
+  NS_DESC_
-|-
+  CM_
-| 0x00
+  BA_DEF_
-| Kill Switch
+  BA_
-| No Data
+  VAL_
-|-
+  CAT_DEF_
-| 0x01
+  CAT_
-| Reset
+  FILTER
-|
+  BA_DEF_DEF_
-   reset_motorio:8;   // Acknowledge motorio controller
+  EV_DATA_
-   reset_sensor:8;    // Acknowledge sensor controller
+  ENVVAR_DATA_
-   reset_geo:8;       // Acknowledge geo controller
+  SGTYPE_
-   reset_bluetooth:8; // Acknowledge bluetooth module
+  SGTYPE_VAL_
-|-
+  BA_DEF_SGTYPE_
-| 0x02
+  BA_SGTYPE_
-| Master Sync Ack
+  SIG_TYPE_REF_
-|
+  VAL_TABLE_
-   ack_motorio:8;		// Acknowledge motorio controller
+  SIG_GROUP_
-   ack_sensor:8;		// Acknowledge sensor controller
+  SIG_VALTYPE_
-   ack_geo:8;			// Acknowledge geo controller
+  SIGTYPE_VALTYPE_
-  ack_bluetooth:8;		// Acknowledge bluetooth module
+  BO_TX_BU_
-|-
+  BA_DEF_REL_
-| 0x03
+  BA_REL_
-| MotorIO Controller Sync
+  BA_DEF_DEF_REL_
-| No Data
+  BU_SG_REL_
-|-
+  BU_EV_REL_
-| 0x04
+  BU_BO_REL_
-| Sensor Controller Sync
+  SG_MUL_VAL_
-| No Data
+ BS_:
-|-
-| 0x05
+ BU_: NOONE SENSOR DRIVER MOTORIO BLUETOOTH GEO
-| Bluetooth Controller Sync
+ BO_ 0 DRIVER_KILL_SWITCH: 0 DRIVER
-| No Data
+  SG_ DRIVER_KILL_SWITCH_cmd 		: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
-|-
+ BO_ 1 DRIVER_RESET: 0 DRIVER
-| 0x06
+  SG_ DRIVER_RESET_cmd 				: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
-| Geo Controller Sync
+ BO_ 2 DRIVER_SYNC_ACK: 0 DRIVER
-| No Data
+  SG_ DRIVER_SYNC_ACK_cmd 			: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
-|-
+ BO_ 3 MOTORIO_SYNC: 0 MOTORIO
-| 0x07
+  SG_ MOTORIO_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
-| MotorIO controller Heart-beat
+ BO_ 4 SENSOR_SYNC: 0 SENSOR
-| No Data
+  SG_ SENSOR_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
-|-
+ BO_ 5 BLUETOOTH_SYNC: 0 BLUETOOTH
-| 0x08
+  SG_ BLUETOOTH_SYNC_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
-| Sensor controller Heart-beat
+ BO_ 6 GEO_SYNC: 0 GEO
-| No Data
+  SG_ GEO_SYNC_cmd 					: 0|0@1+ (1,0) [0|0] "" DRIVER
-|-
+ BO_ 7 MOTORIO_HEARTBEAT: 0 MOTORIO
-| 0x09
+  SG_ MOTORIO_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
-| Bluetooth controller Heart-beat
+ BO_ 8 SENSOR_HEARTBEAT: 0 SENSOR
-| No Data
+  SG_ SENSOR_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
-|-
+ BO_ 9 BLUETOOTH_HEARTBEAT: 0 BLUETOOTH
-| 0x0A
+  SG_ BLUETOOTH_HEARTBEAT_cmd 		: 0|0@1+ (1,0) [0|0] "" DRIVER
-| Geo controller Heart-beat
+ BO_ 10 GEO_HEARTBEAT: 0 GEO
-| No Data
+  SG_ GEO_HEARTBEAT_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
-|-
+ BO_ 11 MOTORIO_RUNMODE: 1 DRIVER
-| 0x0B
+  SG_ MOTORIO_RUNMODE_cmd 			: 0|8@1+ (1,0) [0|3] "" MOTORIO
-| Run mode
+ BO_ 12 SENSOR_SONARS: 6 SENSOR
-| mode:8;
+  SG_ SENSOR_SONARS_front_left 		: 0|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-|-
+  SG_ SENSOR_SONARS_front_right 		: 8|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-| 0x0C
+  SG_ SENSOR_SONARS_front_center 	: 16|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-| Distance Sensor Data
+   SG_ SENSOR_SONARS_left 			: 24|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-|
+  SG_ SENSOR_SONARS_right 			: 32|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  front_left:8;		// Front left sensor reading
+  SG_ SENSOR_SONARS_back 			: 40|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  front_right:8;		// Front right sensor reading
+  BO_ 13 MOTORIO_DIRECTION: 2 DRIVER
-  front_center:8;	        // Front centre sensor reading
+  SG_ MOTORIO_DIRECTION_speed_cmd 	: 0|8@1+ (1,0) [0|4] "" MOTORIO
-  left:8;			// Left sensor reading
+  SG_ MOTORIO_DIRECTION_turn_cmd 	: 8|8@1+ (1,0) [0|5] "" MOTORIO
-  right:8;			// Right sensor reading
+ BO_ 14 DRIVER_CHECKPOINT_REQ: 1 DRIVER
-  back:8;			// Back sensor reading
+   SG_ DRIVER_CHECKPOINT_REQ_cmd 		: 0|8@1+ (1,0) [0|3] "" BLUETOOTH,MOTORIO
-|-
+ BO_ 15 BLUETOOTH_CHECKPOINT_SEND: 1 BLUETOOTH
-| 0x0D
+   SG_ BLUETOOTH_CHECKPOINT_SEND_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO
-| MotorIO Direction Data
+ BO_ 16 BLUETOOTH_CHECKPOINT_DATA: 1 BLUETOOTH
-|
+   SG_ BLUETOOTH_CHECKPOINT_DATA_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO
-  speed:8;			// Indicate speed for DC motor
+ BO_ 17 DRIVER_LOC_UPDATE: 8 DRIVER
-  turn:8;			// Indicate turn angle for servo motor
+  SG_ DRIVER_LOC_UPDATE_LAT_cmd 		: 0|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
-|-
+  SG_ DRIVER_LOC_UPDATE_LONG_cmd 	: 32|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
-| 0x0E
+ BO_ 18 GEO_SPEED_ANGLE: 5 GEO
-| Check-point Request Message
+  SG_ GEO_SPEED_cmd 					: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTORIO
+  SG_ GEO_ANGLE_heading_cmd 			: 8|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
+  SG_ GEO_ANGLE_bearing_cmd 			: 24|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
+ BO_ 19 GEO_LOC_DATA: 8 GEO
+  SG_ GEO_LOC_LAT_cmd 				: 0|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
+  SG_ GEO_LOC_LONG_cmd 				: 32|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
+ BO_ 20 SENSOR_LIGHT_BAT: 2 SENSOR
+  SG_ SENSOR_LIGHT_cmd 				: 0|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO
+  SG_ SENSOR_BAT_cmd 				: 8|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO
+ 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_ MOTORIO "The motor_io controller of the car";
+ CM_ BU_ BLUETOOTH "The bluetooth controller of the car";
+ CM_ BU_ GEO "The geo controller of the car";
+ CM_ BO_ 2 "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_ 7 	          1;
+ BA_ "GenMsgCycleTime" BO_ 8 	          1;
+ BA_ "GenMsgCycleTime" BO_ 9 	          1;
+ BA_ "GenMsgCycleTime" BO_ 10              1;
+ BA_ "GenMsgCycleTime" BO_ 11 	          1;
+ BA_ "GenMsgCycleTime" BO_ 12              10;
+ BA_ "GenMsgCycleTime" BO_ 13              10;
+ BA_ "GenMsgCycleTime" BO_ 17              10;
+ BA_ "GenMsgCycleTime" BO_ 18              10;
+ BA_ "GenMsgCycleTime" BO_ 19              10;
+*Let's understand the above DBC file. The line which contains BU_:... tells the python parser that the user has five nodes in the CAN implementation. In the TopGun project, we have total five nodes -> SENSOR, DRIVER(master), MOTOR, BLUETOOTH, GEO.
+*The second important thing in the DBC file is the lines starting from BO_ message_id. These lines define the different message ids for the CAN implementation of the TopGun project. Here, the project includes total 20 message ids. So, The DBC file contains separate BO_ message_id line for each and every message id. Now, let's see what these lines are indicating to the python parser. What the BO_ line contains is given below:
+** BO_ 4 SENSOR_SYNC: 0 SENSOR --> BO_ "message_id" "message_id_name" "number_of_bytes_transmitted_on_CANbus" "transmitter_node"
+*Now, there are lines which start from SG_. The format of the line contains SG_ is given below. It will contain the variable name that we want to marshal and unmarshal for the CAN bus message data. It also contains the size of that variable and from where it is placed in the 8 bytes of total data. This line will also decide the range of the value held by this variable. User needs to define this max and mim range according to the application. If it is [0|0], then the the parser will consider this as a default and will give the maximum and minimum value of that variable according to its size and the sign information of the variable.  Information in the (1,0) will define the multiplier of the value of the variable which in this case is 1. The second value of this bracket is 0 which indicates the offset for the value of the variable.
+* Execute the following commands in the command line argument to generate the API for the motor controller node.
+** $python dbc_parse.py -i TopGun_12_38am_11_16_2015.dbc -s MOTORIO > generated_code_MOTORIO.c
+*The above command will generate the code for the generated_code_MOTORIO.c file
+* Sample implementation of CAN dbc for sensor message.
+* Sensor message encode code:
+     can_msg_t sensor_can_msg;
+     SENSOR_TX_SENSOR_SONARS_t sensor_msg;
+     sensor_msg.SENSOR_SONARS_front_center = sen_front_center.szone;
+     sensor_msg.SENSOR_SONARS_front_left = sen_front_left.szone;
+     sensor_msg.SENSOR_SONARS_front_right = sen_front_right.szone;
+     msg_hdr_t sensor_msg_header = SENSOR_TX_SENSOR_SONARS_encode((uint64_t*)&sensor_can_msg.data, &sensor_msg);
+     sensor_can_msg.msg_id = sensor_msg_header.mid;
+     sensor_can_msg.frame_fields.data_len = sensor_msg_header.dlc;
+     transmit_data(sensor_can_msg);
+* Sensor message decode code:
+     SENSOR_TX_SENSOR_SONARS_t sensor_msg;
+     can_msg_t received_msg;
+     msg_hdr_t hdr;
+     hdr = { received_msg.msg_id, (uint8_t)received_msg.frame_fields.data_len };
+     SENSOR_TX_SENSOR_SONARS_decode(&sensor_msg,(uint64_t*)&received_msg.data,&hdr);
+=== CAN Message ID Table ===
+{| class="wikitable"
+|-
+! scope="col"| Message ID
+! scope="col"| Task associated with ID
+! scope="col"| Data bit-fields
+|-
+| 0x00
+| Kill Switch
 | No Data
 |-
-| 0x0F
+| 0x01
-| Check-point Start Message
+| Reset
-|
-  num_of_points;	// Number of check-points to be loaded
-|-
-| 0x10
-| Check-point Data
 |
-   float latitude;
+   reset_motorio:8;   // Acknowledge motorio controller
-  float longitude;
+   reset_sensor:8;    // Acknowledge sensor controller
+   reset_geo:8;       // Acknowledge geo controller
+   reset_bluetooth:8; // Acknowledge bluetooth module
 |-
-| 0x11
+| 0x02
-| Geo-Controller New Destination Data
+| Master Sync Ack
-|
-  float latitude;
-  float longitude;
-|-
-| 0x12
-| Geo-Controller Speed and Angle message
 |
-   speed:8;		// Speed as measured by the GPS sensor
+   ack_motorio:8;		// Acknowledge motorio controller
-   heading:16;		// Heading from the Geo controller
+  ack_sensor:8;		// Acknowledge sensor controller
-   bearing:16;		// Bearing calculated by the Geo controller
+   ack_geo:8;			// Acknowledge geo controller
+   ack_bluetooth:8;		// Acknowledge bluetooth module
+|-
+| 0x03
+| MotorIO Controller Sync
+| No Data
+|-
+| 0x04
+| Sensor Controller Sync
+| No Data
 |-
-| 0x13
+| 0x05
-| Geo-Controller Location Data
+| Bluetooth Controller Sync
-|
+| No Data
-  float latitude;
-  float longitude;
 |-
-| 0x14
+| 0x06
-| Light and Battery Sensor Data
+| Geo Controller Sync
-|
+| No Data
-  light_sensor:8;	// Light sensor reading
-  batt_sensor:8;	// Battery level sensor reading
-|}
-=== 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.
-== '''Sensor Controller''' ==
-'''Team Members:'''
- Divya Dodda
- Dhruv Kakadiya
-'''Sensor Controller Schedule'''
-{| class="wikitable"
 |-
-! scope="col"| SI No.
+| 0x07
-! scope="col"| Start Date
+| MotorIO controller Heart-beat
-! scope="col"| End Date
+| No Data
-! scope="col"| Task
-! scope="col"| Status
-! scope="col"| Actual Completion Date
 |-
-! scope="row"| 1
+| 0x08
-| 09/20/2015
+| Sensor controller Heart-beat
-| 09/27/2015
+| No Data
-| Researching and ordering the sensors to be used in the project
-| Completed
-| 9/27/2015
 |-
-! scope="row"| 2
+| 0x09
-| 09/27/2015
+| Bluetooth controller Heart-beat
-| 10/03/2015
+| No Data
-|
+|-
-*Studying sensor data sheets and preparing code sketch to be used after components are procured
+| 0x0A
-*Interface ADC ultrasonic sensor to SJOne board(available spare sensors), reading sensor values and filtering the readings
+| Geo controller Heart-beat
-| Completed
+| No Data
-| 10/03/2015
 |-
-! scope="row"| 3
+| 0x0B
-| 10/03/2015
+| Run mode
-| 10/10/2015
+| mode:8;
-| Interfacing ADC ultrasonic sensor to SJOne board, reading sensor values and filter the readings
-| Completed
-| 10/10/2015
 |-
-! scope="row"| 4
+| 0x0C
-| 10/10/2015
+| Distance Sensor Data
-| 10/20/2015
-| Understanding inertial measurement unit sensor, interfacing it to SJOne board to get filtered readings
-| Completed
-| 10/20/2015
-|-
-! scope="row"| 5
-| 10/20/2015
-| 11/05/2015
-| Integrating multiple sensors to the SJOne board, testing the sensors and debugging issues
-| Incomplete
 |
+  front_left:8;		// Front left sensor reading
+  front_right:8;		// Front right sensor reading
+  front_center:8;	        // Front centre sensor reading
+  left:8;			// Left sensor reading
+  right:8;			// Right sensor reading
+  back:8;			// Back sensor reading
 |-
-! scope="row"| 6
+| 0x0D
-| 11/05/2015
+| MotorIO Direction Data
-| 11/25/2015
-| Preparing sensor values to be sent over CAN bus and testing out the correctness of sensor can messages
-| Incomplete
 |
+  speed:8;			// Indicate speed for DC motor
+  turn:8;			// Indicate turn angle for servo motor
 |-
-! scope="row"| 7
+| 0x0E
-| 11/25/2015
+| Check-point Request Message
-| 12/15/2015
+| No Data
-| Testing of code during final phases, modifying code in cooperation with other teams and optimization of code
+|-
-| Incomplete
+| 0x0F
+| Check-point Start Message
+|
+  num_of_points;	// Number of check-points to be loaded
+|-
+| 0x10
+| Check-point Data
 |
+  float latitude;
+  float longitude;
 |-
-|}
+| 0x11
+| Geo-Controller New Destination Data
-=== Sensor Testing ===
+|
-==== HCSR04 Sensor Testing ====
+  float latitude;
+  float longitude;
-* As shown in the figure below, HC-SR04 ultrasonic sensor requires an external 5V DC supply.
+|-
-* When in the initial testing stage we just connected one sensor for testing the accuracy and the range of the sensor.
+| 0x12
-* The values we received were very stable and neat.
+| Geo-Controller Speed and Angle message
-[[File:Cmpe243 t2 self driving car Hcsr04 circuit diagram.png|600px|centre|thumb|HC-SR04 sensor]]
+|
+  speed:8;		// Speed as measured by the GPS sensor
-==== Parallax Ping Sensor Testing ====
+  heading:16;		// Heading from the Geo controller
+  bearing:16;		// Bearing calculated by the Geo controller
+|-
+| 0x13
+| Geo-Controller Location Data
+|
+  float latitude;
+  float longitude;
+|-
+| 0x14
+| Light and Battery Sensor Data
+|
+  light_sensor:8;	// Light sensor reading
+  batt_sensor:8;	// Battery level sensor reading
+|}
-* As shown in the figure below, Parallax ping ultrasonic sensor requires an external 5V DC supply.
+== '''Sensor Controller''' ==
-[[File:Ping.png|600px|centre|thumb|Parallax ping sensor]]
+'''Team Members:'''
+ Divya Dodda
+ Dhruv Kakadiya
-==== Finalizing distance sensors ====
+'''Sensor Controller Schedule'''
-* Both sensors being pretty accurate, we were confused while finalizing one. So we were using both sensors, for front we were using Parallax and for left,right and back sensors we were using HCSR04 sensor.
+{| class="wikitable"
-* HCSR04 sensor was better option because as it was much cost efficient than the Parallax Ping Sensor (Where one Parallax Ping costs $30, one HCSR04 costed us only $2)
+|-
-* Its only drawback is, the cheaper one sensor needed good filter to remove some spikes and Parallax sensor was working pretty good without any filtering.
+! scope="col"| SI No.
+! scope="col"| Start Date
-==== Switching to Hardware Timer ====
+! scope="col"| End Date
-* Previously, all sensor were triggered using software timers. We declared a soft timer for each sensor which kept track of the time between trigger and echo for that particular sensor.
+! scope="col"| Task
-* If we see the declaration of software timer as shown below, we come to know that the timer returns a value in milliseconds.
+! scope="col"| Status
-    inline uint64_t getTargetTimerValueMs(void) const { return mTargetMs; }
+! scope="col"| Actual Completion Date
-* If we apply the before mentioned distance formula to this timer value in milliseconds, we will always get the distance in multiples of 17.
+|-
-* Let's work out an example for better understanding;
+! scope="row"| 1
-[[File:Cmpe243 t2 self driving car Soft timer calculation.png|600px|centre|thumb|Software Timer Distance Calculation]]
+| 09/20/2015
-* As the return return type of this function is an integer, we always get the distance in multiples of 17, which compromises the accuracy by a large factor.
+| 09/27/2015
-* Because of this reason we switched to hardware timers.
+| Researching and ordering the sensors to be used in the project
-* The declaration of hardware timer is as shown below, and this return value of time is in micro-seconds.
+| Completed
-    uint32_t lpc_timer_get_value(const lpc_timer_t timer)
+| 9/27/2015
-    {
+|-
-        return (lpc_timer_get_struct(timer)->TC);
+! scope="row"| 2
-    }
+| 09/27/2015
-* Let's work out the same example for the return value being 1usec.
+| 10/03/2015
-[[File:Cmpe243 t2 self driving car Hardware timer calculation.png|600px|centre|thumb|Hardware Timer Distance Calculation]]
+|
-* Hence, even if the timer value is an integer, as it is in microseconds, we have improved the accuracy.
+*Studying sensor data sheets and preparing code sketch to be used after components are procured
-* As there are only three hardware timers in LPC 1768 we cannot allot individual timer for each sensor. Hence, we use just one hardware timer which runs regardless any individual sensor.
+*Interface ADC ultrasonic sensor to SJOne board(available spare sensors), reading sensor values and filtering the readings
-* All sensors get the current timer value during trigger and echo  from this single timer, and do the further processing individually.
+| Completed
+| 10/03/2015
-==== Sequentially Triggering of Sensors ====
+|-
-* We used to trigger all the sensors at the same time, which caused interference between adjacent sensors, which in turn caused mis-firing of echo.
+! scope="row"| 3
-* This resulted in incorrect distance values from all the sensors.
+| 10/03/2015
-* Thus to solve this issue, we implemented sequential triggering.
+| 10/10/2015
-* Under this logic, each sensor will be triggered only when the previous sensor receives an echo or exceeds the maximum echo reception wait time which is 60msec.
+| Interfacing ADC ultrasonic sensor to SJOne board, reading sensor values and filter the readings
-* This implementation solved the issue at hand but gave rise to a new issue which is mentioned in the next section.
+| Completed
+| 10/10/2015
-==== Limiting the Scope to Improve Frequency ====
+|-
+! scope="row"| 4
-* As discussed in the previous section, if we implement sequential triggering for each sensor, if there is no obstacle, then the worst case delay would be 360 msec(60msec*6sensors) to update all sensor values to the master.
+| 10/10/2015
-* Means the frequency of communicating these values to the master will be, 2.8Hz.
+| 10/20/2015
-* For proper obstacle avoidance, we need to provide the sensor data to the master atleast 10 times per second, i.e. at 10Hz.
+| Understanding inertial measurement unit sensor, interfacing it to SJOne board to get filtered readings
-* Which means data from all six sensors must be calculated within 100msec.
+| Completed
-* Even if we consider limiting the time allotted to a sensor to time required for maximum distance (400cms), we will require 23.5msec each sensor i.e. 141msec to update the values of all six sensors. This increases the frequency to 7.1Hz.
+| 10/20/2015
-* This led is to the solution to this problem, if we limit the scope of each sensor then we can update the sensor values more frequently to the master.
+|-
-* To overcome this issue, we limited the maximum scope of the sensor to 170 cms, limiting the time required to get the echo to 10msec. Which makes the total time required to calculate all six sensors' data about 60msec.
+! scope="row"| 5
-* Hence, as shown in the flowchart, each sensor waits 10msec for an echo. If we get an echo within 10msec, we calculate the distance; if we don't, we assume the obstacle is at 170cms or further.
+| 10/20/2015
+| 11/05/2015
-==== Misfiring of Sensor ====
+| Integrating multiple sensors to the SJOne board, testing the sensors and debugging issues
+| Completed
-* At times the sensor used to mis-fire. Which means; in a stable condition, if the obstacle is at a constant distance of 150cms, 1 out of 50 continuous values will be 60cms.
+| 11/02/2015
-* This value being false, misguides the master.
-* To overcome this issue, we introduced a threshold value called DELTA (say, 10cms). Which defines the acceptable range from the previous value.
-* In this algorithm, an abrupt change in the distance value should be constant for at least two consecutive reads to be considered genuine.
-* If the current value from the sensor is in the range of the previous value's +/- 10cms, then this value is considered to be correct, and is provided to the master. Then this current value will be copied in the previous value register.
-* If the current value is not is the previous value's +/- DELTA range then it is considered as a misfire and hence is not provided to the master. But this sudden change might be because of a sudden obstacle; hence, the value is copied in the previous value register, and if the same value repeats, it will be considered genuine and provided to the master.
-* The code for this algorithm is as shown below;
-        if(temp-DELTA<current && current<temp+DELTA){
-            distance = current;
-        }
-        temp = current;
-* Hence, this algorithm will overcome the abrupt mis-firing of the sensor and make the data provided to the master more reliable.
-=== Sensor Software Design ===
-====Sensor Controller Team Software Design====
- Sensor software design is composed of three crucial tasks, which are to read GPIO based sonar, read ADC based sonar, and CAN TX.
-<br>
-<b>GPIO based read:</b>
- [[File:CMPE243_F14_sensorFlow1j.jpg‎]]
-<br>
-<b>ADC based read:</b>
-<br>
-[[File:CMPE243_F14_sonarFlow2.png]]
-<br>
-<b>CAN Frame write:</b>
-<br>
-[[File:CMPE243_F14_sonarFlow3.png]]
-==== Sensor Pin Connections ====
-{| class="wikitable"
 |-
+! scope="row"| 6
+| 11/05/2015
+| 11/15/2015
+| Preparing sensor values to be sent over CAN bus and testing out the correctness of sensor can messages
+| Completed
+| 11/10/2015
 |-
-! scope="col"| Line Item#
+! scope="row"| 7
-! scope="col"| Node A Source
+| 11/25/2015
-! scope="col"| Node A Pin
+| 11/30/2015
-! scope="col"| Node B Source
+| Testing of code during final phases, modifying code in cooperation with other teams and optimization of code
-! scope="col"| Node B Pin
+| Completed
-! scope="col"| Description
+| 12/1/2015
-|-
-|-
-! scope="row"| 1
-| 3.3V Power Supply
-| 3.3V
-| SJOne Board
-| 3V3
-| SJOne Power
-|-
-|-
-! scope="row"| 2
-| 3.3V Power Supply
-| GND
-| SJOne Board
-| GND
-| SJOne Ground
-|-
-|-
-! scope="row"| 3
-| CAN Transceiver
-| Tx
-| SJOne Board
-| P0.1 (Tx)
-| SJOne - CAN Tx
-|-
-|-
-! scope="row"| 4
-| CAN Transceiver
-| Rx
-| SJOne Board
-| P0.0 (Rx)
-| SJOne - CAN Rx
-|-
-|-
-! scope="row"| 5
-| CAN Transceiver
-| 3.3V
-| 3.3V Power Supply
-| 3.3V
-| SJOne - CAN Power
-|-
-|-
-! scope="row"| 6
-| CAN Transceiver
-| Ground
-| 3.3V Power Supply
-| GND
-| SJOne - CAN Ground
 |-
+|}
+=== Sensor Testing ===
+[[File:F15_243_TG_Front_Radar_Operation.gif|600px|centre|thumb|Front Sonar Visualization]]
+==== Simple Sensor ping operation ====
+[[File:F15_243_TG_Sensor_Ping_Operation.png|600px|centre|thumb|Sensor Ping Operation]]
+==== HCSR04 Sensor Testing ====
+* As shown in the figure below, HC-SR04 ultrasonic sensor requires an external 5V DC supply.
+* When in the initial testing stage we just connected one sensor for testing the accuracy and the range of the sensor.
+* The values we received were very stable and neat.
+[[File:F15_243_TG_IMG_1.jpg|600px|centre|thumb|HC-SR04 sensor]]
+==== Parallax Ping Sensor Testing ====
+* As shown in the figure below, Parallax ping ultrasonic sensor requires an external 5V DC supply.
+[[File:F15_243_TG_IMG_2.jpg|600px|centre|thumb|Parallax ping sensor]]
+==== Finalizing distance sensors ====
+* Both sensors being pretty accurate, we were confused while finalizing one. So we were using both sensors, for front we were using Parallax and for left,right and back sensors we were using HCSR04 sensor.
+* HCSR04 sensor was better option because as it was much cost efficient than the Parallax Ping Sensor (Where one Parallax Ping costs $30, one HCSR04 costed us only $2)
+* Its only drawback is, the cheaper one sensor needed good filter to remove some spikes and Parallax sensor was working pretty good without any filtering.
+==== Software timer for repetitive pulse and Hardware timer for calculating pulse width ====
+* All sensor were triggered using software timers. We declared a soft timer for each sensor which kept track of the time between trigger and echo for that particular sensor.
+    SoftTimer limit_time;
+    limit_time.reset(25);
+    limit_time.restart();
+    if(limit_time.expired()){
+        break;
+    }
+* If we apply the before mentioned distance formula to this timer value in milliseconds, we will always get the distance in multiples of 17.
+* Let's work out an example for better understanding;
+[[File: F15_243_TG_IMG_SoftTimerCalculation.jpg]]
+* As the return return type of this function is an integer, we always get the distance in multiples of 17, which compromises the accuracy by a large factor.
+* Because of this reason we switched to hardware timers.
+* The declaration of hardware timer is as shown below, and this return value of time is in micro-seconds.
+    lpc_timer_enable(lpc_timer0,1);
+    lpc_timer_set_value(lpc_timer0,0);
+* Let's work out the same example for the return value being 1usec.
+[[File: F15_243_TG_IMG_HardTimerCalculation.jpg]]
+* Hence, even if the timer value is an integer, as it is in microseconds, we have improved the accuracy.
+* As there are only three hardware timers in LPC 1768 we cannot allot individual timer for each sensor. Hence, we use just one hardware timer which runs regardless any individual sensor.
+* All sensors get the current timer value during trigger and echo  from this single timer, and do the further processing individually.
+==== Sequentially Triggering of Sensors ====
+* We used to trigger all the sensors at the same time, which caused interference between adjacent sensors, which in turn caused mis-firing of echo.
+* This resulted in incorrect distance values from all the sensors.
+* Thus to solve this issue, we implemented sequential triggering.
+* Under this logic, each sensor will be triggered only when the previous sensor receives an echo or exceeds the maximum echo reception wait time which is 60msec.
+* This implementation solved the issue at hand but gave rise to a new issue which is mentioned in the next section.
+==== Limiting the Scope to Improve Frequency ====
+* As discussed in the previous section, if we implement sequential triggering for each sensor, if there is no obstacle, then the worst case delay would be 360 msec(60msec*6sensors) to update all sensor values to the master.
+* Means the frequency of communicating these values to the master will be, 2.8Hz.
+* For proper obstacle avoidance, we need to provide the sensor data to the master atleast 10 times per second, i.e. at 10Hz.
+* Which means data from all six sensors must be calculated within 100msec.
+* Even if we consider limiting the time allotted to a sensor to time required for maximum distance (400cms), we will require 23.5msec each sensor i.e. 141msec to update the values of all six sensors. This increases the frequency to 7.1Hz.
+* This led is to the solution to this problem, if we limit the scope of each sensor then we can update the sensor values more frequently to the master.
+* To overcome this issue, we limited the maximum scope of the sensor to 170 cms, limiting the time required to get the echo to 10msec. Which makes the total time required to calculate all six sensors' data about 60msec.
+* Hence, as shown in the flowchart, each sensor waits 10msec for an echo. If we get an echo within 10msec, we calculate the distance; if we don't, we assume the obstacle is at 170cms or further.
+==== Misfiring of Sensor ====
+* At times the sensor used to mis-fire. Which means; in a stable condition, if the obstacle is at a constant distance of 150cms, 1 out of 50 continuous values will be 60cms.
+* This value being false, misguides the master.
+* To overcome this issue, we introduced a threshold value called DELTA (say, 10cms). Which defines the acceptable range from the previous value.
+* In this algorithm, an abrupt change in the distance value should be constant for at least two consecutive reads to be considered genuine.
+* If the current value from the sensor is in the range of the previous value's +/- 10cms, then this value is considered to be correct, and is provided to the master. Then this current value will be copied in the previous value register.
+* If the current value is not is the previous value's +/- DELTA range then it is considered as a misfire and hence is not provided to the master. But this sudden change might be because of a sudden obstacle; hence, the value is copied in the previous value register, and if the same value repeats, it will be considered genuine and provided to the master.
+* The code for this algorithm is as shown below;
+        if(temp-DELTA<current && current<temp+DELTA){
+            distance = current;
+        }
+        temp = current;
+* Hence, this algorithm will overcome the abrupt mis-firing of the sensor and make the data provided to the master more reliable.
+=== Sensor Software Design ===
+====Sensor Controller Team Software Design====
+* Sensor software design is composed of three crucial tasks, which are to read GPIO based sonar, read ADC based sonar, and CAN TX.
+'''Operation Sequences'''
+{|
+|[[File: F15_243_TG_IMG_8.jpg|340px|thumb|left|GPIO based read]]
+|[[File: F15_243_TG_IMG_9.jpg|400px|thumb|right|ADC based read]]
+|[[File: F15_243_TG_IMG_17.jpg|400px|thumb|right|CAN Frame write]]
+|}
+==== Tasks ====
+{| class="wikitable"
+|+ Sensor Controller Tasks
 |-
-! scope="row"| 7
+! align="center"|Task Name
-| Parallax Ultrasonic Sensor (Front Left)
+! align="center"|Purpose
-| Vcc
+|-
-| 5V Power Supply
+| Period Init
-| +5V
+| Can bus initialization
-| Front Left Sensor Power
-|-
 |-
-! scope="row"| 8
+| Period Register telemetry
-| Parallax Ultrasonic Sensor (Front Left)
+| Register sensor_data can message
-| GND
-| 5V Power Supply
-| GND
-| Front Left Sensor GND
-|-
 |-
-! scope="row"| 9
+| Periodic 1Hz Callback
-| Parallax Ultrasonic Sensor (Front Left)
+| Check can bus off
-| Echo/Trig
-| SJOne Board
-| P2.0
-| Front Left Sensor Echo
-|-
 |-
-! scope="row"| 10
+| Periodic 10Hz Callback
-| Parallax Ultrasonic Sensor (Front Right)
+| Get and Send Sensor Data
-| Vcc
+|-
-| 5V Power Supply
+|}
-| +5V
+==== Sensor Zones ====
-| Front Right Sensor Power
+Each sensor can detect obstacles at a maximum range of 400cm. We have divided this range into 3 zones as shown in the figure.
-|-
+{|
+|[[File: F15_243_TG_SensorZones.jpg|700px|thumb|left|Sensor Zones]]
+|}
+==== Sensor Pin Connections ====
+{| class="wikitable"
 |-
-! scope="row"| 11
-| Parallax Ultrasonic Sensor (Front Right)
-| GND
-| 5V Power Supply
-| GND
-| Front Right Sensor GND
-|-
 |-
-! scope="row"| 12
+! scope="col"| Line Item#
-| Parallax Ultrasonic Sensor (Front Right)
+! scope="col"| Node A Source
-| Echo/Trig
+! scope="col"| Node A Pin
-| SJOne Board
+! scope="col"| Node B Source
-| P2.2
+! scope="col"| Node B Pin
-| Front Right Sensor Echo
+! scope="col"| Description
-|-
 |-
-! scope="row"| 13
-| Parallax Ultrasonic Range Sensor (Front Middle)
-| Vcc
-| 5V Power Supply
-| +5V
-| Front Middle Sensor Power
-|-
 |-
-! scope="row"| 14
+! scope="row"| 1
-| Parallax Ultrasonic Range Sensor (Front Middle)
+| 3.3V Power Supply
+| 3.3V
+| SJOne Board
+| 3V3
+| SJOne Power
+|-
+|-
+! scope="row"| 2
+| 3.3V Power Supply
+| GND
+| SJOne Board
 | GND
-| 5V Power Supply
+| SJOne Ground
-| GND
+|-
-| Front Middle Sensor GND
-|-
 |-
-! scope="row"| 15
+! scope="row"| 3
-| Parallax Ultrasonic Range Sensor (Front Middle)
+| CAN Transceiver
-| Echo
+| Tx
 | SJOne Board
-| P2.4
+| P0.1 (Tx)
-| Front Middle Sensor Echo
+| SJOne - CAN Tx
-|-
 |-
-! scope="row"| 16
-| Parallax Ultrasonic Range Sensor (Front Middle)
-| Trig
-| SJOne Board
-| P2.5
-| Front Middle Sensor Trig
-|-
 |-
-! scope="row"| 17
+! scope="row"| 4
-| HC-SR04 Ultrasonic Sensor (Left)
+| CAN Transceiver
-| Vcc
+| Rx
-| 5V Power Supply
+| SJOne Board
-| +5V
+| P0.0 (Rx)
-| Left Sensor Power
+| SJOne - CAN Rx
 |-
 |-
-! scope="row"| 18
+! scope="row"| 5
-| HC-SR04 Ultrasonic Sensor (Left)
+| CAN Transceiver
-| GND
+| 3.3V
-| 5V Power Supply
+| 3.3V Power Supply
-| GND
+| 3.3V
-| Left Sensor GND
+| SJOne - CAN Power
 |-
 |-
-! scope="row"| 19
+! scope="row"| 6
-| HC-SR04 Ultrasonic Sensor (Left)
+| CAN Transceiver
-| Echo
+| Ground
-| SJOne Board
+| 3.3V Power Supply
-| P2.6
+| GND
-| Left Sensor Echo
+| SJOne - CAN Ground
-|-
 |-
-! scope="row"| 20
-| HC-SR04 Ultrasonic Sensor (Left)
-| Trig
-| SJOne Board
-| P2.7
-| Left Sensor Trig
-|-
 |-
-! scope="row"| 21
+! scope="row"| 7
-| HC-SR04 Ultrasonic Sensor (Right)
+| Parallax Ultrasonic Sensor (Front Left)
 | Vcc
 | 5V Power Supply
 | +5V
-| Right Sensor Power
+| Front Left Sensor Power
 |-
 |-
-! scope="row"| 22
+! scope="row"| 8
-| HC-SR04 Ultrasonic Sensor (Right)
+| Parallax Ultrasonic Sensor (Front Left)
 | GND
 | 5V Power Supply
 | GND
-| Right Sensor GND
+| Front Left Sensor GND
 |-
 |-
-! scope="row"| 23
+! scope="row"| 9
-| HC-SR04 Ultrasonic Sensor (Right)
+| Parallax Ultrasonic Sensor (Front Left)
-| Echo
+| Echo/Trig
 | SJOne Board
-| P2.8
+| P2.0
-| Right Sensor Echo
+| Front Left Sensor Echo
 |-
 |-
-! scope="row"| 24
+! scope="row"| 10
-| HC-SR04 Ultrasonic Sensor (Right)
+| Parallax Ultrasonic Sensor (Front Right)
-| Trig
+| Vcc
-| SJOne Board
+| 5V Power Supply
-| P2.9
+| +5V
-| Right Sensor Trig
+| Front Right Sensor Power
 |-
 |-
-! scope="row"| 25
+! scope="row"| 11
-| CAN Transceiver
+| Parallax Ultrasonic Sensor (Front Right)
-| CANL
+| GND
-| CAN BUS
+| 5V Power Supply
-| CANL
+| GND
-| CANL to CAN BUS
+| Front Right Sensor GND
+|-
 |-
+! scope="row"| 12
+| Parallax Ultrasonic Sensor (Front Right)
+| Echo/Trig
+| SJOne Board
+| P2.2
+| Front Right Sensor Echo
+|-
 |-
-! scope="row"| 26
+! scope="row"| 13
-| CAN Transceiver
+| Parallax Ultrasonic Range Sensor (Front Middle)
-| CANR
+| Vcc
-| CAN BUS
+| 5V Power Supply
-| CANR
+| +5V
-| CANR to CAN BUS
+| Front Middle Sensor Power
+|-
 |-
-|}
+! scope="row"| 14
+| Parallax Ultrasonic Range Sensor (Front Middle)
-== '''Geographical Controller''' ==
+| GND
-'''Team Members:'''
+| 5V Power Supply
- Chitrang Talaviya
+| GND
- Navjot Singh
+| Front Middle Sensor GND
+|-
-'''Geographical Controller Schedule'''
-{| class="wikitable"
 |-
-! scope="col"| SI No.
+! scope="row"| 15
-! scope="col"| Start Date
+| Parallax Ultrasonic Range Sensor (Front Middle)
-! scope="col"| End Date
+| Echo
-! scope="col"| Task
+| SJOne Board
-! scope="col"| Status
+| P2.4
-! scope="col"| Actual Completion Date
+| Front Middle Sensor Echo
+|-
 |-
-! scope="row"| 1
+! scope="row"| 16
-| 09/20/2015
+| Parallax Ultrasonic Range Sensor (Front Middle)
-| 09/27/2015
+| Trig
-| Researching and ordering the parts
+| SJOne Board
-| Completed
+| P2.5
-| 9/27/2015
+| Front Middle Sensor Trig
+|-
 |-
-! scope="row"| 2
+! scope="row"| 17
-| 09/27/2015
+| CAN Transceiver
-| 10/05/2015
+| CANL
-| Studying module data sheets and writing code sketches to be used when modules are procured(GPS and IMU)
+| CAN BUS
-| Completed
+| CANL
-| 10/05/2015
+| CANL to CAN BUS
 |-
-! scope="row"| 3
-| 10/05/2015
-| 10/15/2015
-| Interfacing GPS module and compass to SJOne board and get consistent filtered readings
-| Completed
-| 10/17/2015
 |-
-! scope="row"| 4
+! scope="row"| 18
-| 10/15/2015
+| CAN Transceiver
-| 10/30/2015
+| CANR
-| Proposals for heading and distance calculation, unit testing and integrating modules
+| CAN BUS
-| Completed
+| CANR
-| 10/30/2015
+| CANR to CAN BUS
 |-
-! scope="row"| 5
+|}
-| 10/30/2015
-| 11/10/2015
+=== Sensor Implementation Using Interrupts ===
-| Calibration of compass and GPS readings, CAN bus communication from geo controller to other boards.
-| Completed
-| 11/10/2015
+*We implemented interrupt based code for 3-pin and 4-pin ping sensors.
-|-
+==== Implementation of 4-pin Sensors With Interrupt ====
-! scope="row"| 6
-| 11/10/2015
+*Initially a class for the 4-pin sensor was developed. Three instances of this class were declared for front, right and left sensors with GPIO pin numbers for trigger, echo with trigger being the input to the sensor and echo being the output of the sensor to the board.In addition to the pin numbers an unique index for each sensor.
-| 11/25/2015
+*First task was to assign the pin numbers to set as input and output pins which were interrupt based GPIO pins.
-| Android application connection with data reception and transmit
+*From the file "eint.h", we inferred the ports 0 and 2 were interrupt based pins.
-| Completed
-| 11/25/2015
+===== Interrupt On The Echo Pin =====
-|-
-! scope="row"| 7
+*To set an interrupt on echo pin, we used the API "eint3_enable_port2(pin, edge_type, callback_function)". The respective echo pin number was provided as the first parameter for front, right and left sensors. The edge type was rising and falling edge on the echo pin of each sensor. Two callback functions were implemented for rising and falling edge. When the echo pin went high,we captured the time using the API "sys_get_uptime_us()" in the rising edge callback function. When the echo pin went low, we captured the time using the same API in the falling edge callback function. The difference between uptime and downtime obtained from these callbacks functions, was used to calculate the distance using the formula "distance(in cms) = (downtime-uptime) * (1.0 / 58.0)."
-| 11/25/2015
-| 12/15/2015
+===== Design Flow =====
-| Final phase testing and optimization, collaborating with android team to get better reliable outcomes
-| Incomplete
+* The function for pinging the sensors followed the order front,right and left with indexes 0,1, and 2 respectively. The function was called from 1000Hz periodic callback function. The design flow for the function was as follows:
-|
-|-
-|}
-=== Geographical Controller H/W Design ===
-* Below figure represents the block diagram of Geo Controller. Geo-controller uses GPS and IMU module for its working. Uart3 and Uart2 are used for interfacing IMU and GPS with SJ One board at baud rate 9600bps.
+*1. Check the index of the pinged sensor.
+*2. Send the pulse to the trigger pin for the indexed sensor.
-[[File:CmpE243_F15_TopGun_GeoController_HWInterface.jpg|500px|thumb|centre|Fig _ :H/W Interface of GeoController]]
+*3. Calculate uptime, downtime, distance for the current instance sensor.
+*4. Add the latest calculated distance value to a dedicated filter for the respective sensor.
-=== Geographical Controller H/W Interface ===
+*5. The filter would update and return the latest average distance.
+*6. Calculate the zone for the distance obtained.
-* Below table shows the Pins connection of GPS and IMU module with SJ One Board. Both the h/w's are interfaced with Controller using UART interface. The operating volatge of GPS and IMU is 3.3V.
+*7. The data to be sent onto the can bus involves the zone information for all the three sensors for every 1000Hz. This meant the zone information of the pinged and the un-pinged sensor values are needed out to be sent over the bus.
+*8. We concluded that at a given point of time, the can bus would receive the previously calculated values for all the sensors. What this meant is if we calculated the values for current instance of the front sensor, we would push the values of the previous instance of front,right and left sensors on the bus. This would keep the master updated with all the sensor data.
+===== Sensor Implementation with Interrupts Pin Connections =====
 {| class="wikitable"
-|+ Geographical Controller Pin Connection Table
 |-
-! scope="col"| '''Description'''
-! scope="col"| '''Interface'''
-! scope="col"| '''Device Port'''
-! scope="col"| '''SJOne Board Port'''
 |-
-| Supply Voltage
+! scope="col"| Line Item#
-| N/A
+! scope="col"| Node A Source
-| Vcc
+! scope="col"| Node A Pin
-| 3.3 V
+! scope="col"| Node B Source
+! scope="col"| Node B Pin
+! scope="col"| Description
+|-
+|-
+! scope="row"| 1
+| 3.3V Power Supply
+| 3.3V
+| SJOne Board
+| 3V3
+| SJOne Power
+|-
 |-
-| Ground
+! scope="row"| 2
-| N/A
+| 3.3V Power Supply
 | GND
+| SJOne Board
 | GND
+| SJOne Ground
+|-
 |-
-| GPS Module
+! scope="row"| 3
-| UART2
+| CAN Transceiver
-|
+| Tx
- Channel 1 -> Rx
+| SJOne Board
- Channel 2 -> Tx
+| P0.1 (Tx)
- Channel 3 -> EN
+| SJOne - CAN Tx
-|
- Channel 1 -> Tx P2.8
- Channel 2 -> Rx P2.9
- Channel 3 -> Vcc
 |-
-| IMU Module
-| UART3
-|
- Channel 1 -> Rx
- Channel 2 -> Tx
-|
- Channel 1 -> Tx P2.8
- Channel 2 -> Rx P2.9
 |-
-|}
+! scope="row"| 4
+| CAN Transceiver
-=== Geographical Controller S/W Design ===
+| Rx
-*Updating Firmware on IMU:
+| SJOne Board
- For updating the firmware on IMU, we used FTDI basic breakout which uses USB mini cable to connect to PC. The board comes programmed with the 8MHz     Arduino bootloader (stk500v1) and some example firmware that demos the outputs of all the sensors. UART connection are made to interface IMu with breakout board at 57600bps.
+| P0.0 (Rx)
- Connections between IMU and FTDI breakout.
+| SJOne - CAN Rx
- FTDI BREAKOUT      RAZOR
+|-
- GND           <--> GND
+|-
- CTS           <--> CTS
+! scope="row"| 5
-.3V          <--> 3.3V
+| CAN Transceiver
- TXO           <--> RXI
+| 3.3V
- RXI           <--> TXO
+| 3.3V Power Supply
- DTR           <--> DTR
+| 3.3V
- The details are given at: https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial
+| SJOne - CAN Power
- Firmware provides the readings Yaw, Pitch and Roll readings. As in the project we only need the Yaw data, so firmware is been updated to provide only the Yaw readings.
+|-
+|-
-*Sensor Calibration:
+! scope="row"| 6
-  Sensor calibration include calibrating the accelerometer, gyroscope and magnetometer. Sensor calibration in our project is done twice, once in the beginning and then at the end when all the boards are mounted on the car. As the magnetic field of motor can effect the gyroscope readings so we did the calibration again. The details can be found on the link given above.
+| CAN Transceiver
+| Ground
-=== Geographical Controller Hardware Design Components ===
+| 3.3V Power Supply
-<table>
+| GND
-<tr>
+| SJOne - CAN Ground
-<td valign="top" align="justify" width=550px>
+|-
-<b>Adafruit MTK3339 GPS:</b>
+|-
+! scope="row"| 7
-This GPS unit is interfaced via UART with build in antenna. The GPS provides latitude and longitude accurately up to 5-10 meters with a strong satellite fix with update rate of 10Hz. By default, the baud rate is 9600bps. Power usage for this module is 20mA during navigation.
+| 4-pin Ultrasonic Sensor (Front)
+| Vcc
-The GPS module comes with following capabilities:
+| 5V Power Supply
+| +5V
-*-165 dBm sensitivity, 10 Hz updates, 66 channels
+| Front Sensor Power
-* 5V friendly design and only 20mA current draw
+|-
-* Breadboard friendly + two mounting holes
+|-
-* RTC battery-compatible
+! scope="row"| 8
-* Built-in datalogging
+| 4-pin Ultrasonic Sensor (Front)
-* PPS output on fix
+| GND
-* Internal patch antenna + u.FL connector for external active antenna
+| 5V Power Supply
-* Fix status LED
+| GND
+| Front Sensor GND
-We chose this part because it provided the base functionality we needed along with many other functions that would be fun to play with and try to include in the project. The antennae options and voltage regulator were also very enticing.
+|-
-</td>
+|-
-<td>
+! scope="row"| 9
-</td>
+| 4-pin Ultrasonic Sensor (Front)
-<td>
+| Trig
-[[File:CmpE243_F15_TopGun_GPS_module.jpg|200px|thumb|right|Fig _ :GPS_Module]]
+| SJOne Board
-</td>
+| P2.0
-</tr>
+| Front Sensor Trigger pin
-<tr>
+|-
-<td valign="top" align="justify" width=550px>
+|-
-<b>9 Degrees of Freedom- Razor IMU:</b>
+! scope="row"| 10
+| 4-pin Ultrasonic Sensor (Front)
-In our project, we used IMU module to get the heading of the device.
+| Echo
-The 9DOF Razor IMU provides nine degree of inertial measurement by incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer).The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface. UART interface is used for interfacing with SJ One board and it is connected via UART3 with LPC board and is operated at 3.3V.
+| SJOne Board
+| P2.1
-Features:
+| Front Sensor Echo pin
+|-
-*9 Degrees of Freedom on a single, flat board:
+|-
-**ITG-3200 - triple-axis digital-output gyroscope
+! scope="row"| 11
-**ADXL345 - 13-bit resolution, ±16g, triple-axis accelerometer
+| 4-pin Ultrasonic Sensor (Right)
-**HMC5883L - triple-axis, digital magnetometer
+| Vcc
-*Outputs of all sensors processed by on-board ATmega328 and sent out via a serial stream
+| 5V Power Supply
-*Autorun feature and help menu integrated into the example firmware
+| +5V
-*Output pins match up with FTDI Basic Breakout, Bluetooth Mate, XBee Explorer
+| Right Sensor Power
-*3.5-16VDC input
+|-
-*ON-OFF control switch and reset switch
+|-
-</td>
+! scope="row"| 12
-<td>
+| 4-pin Ultrasonic Sensor (Right)
-</td>
+| GND
-<td>
+| 5V Power Supply
-[[File:CmpE243_F15_TopGun_IMU.jpg|300px|thumb|right|Fig _ :9DOF_IMU]]
+| GND
-</td>
+| Right Sensor GND
-</tr>
+|-
-</table>
-== '''Motor I/O Controller''' ==
-''' Team Members: '''
- Anuj Korat
- Dhruv Kakadiya
-'''Motor & I/O Controller Schedule'''
-{| class="wikitable"
 |-
-! scope="col"| SI No.
+! scope="row"| 13
-! scope="col"| Start Date
+| 4-pin Ultrasonic Sensor (Right)
-! scope="col"| End Date
+| Trig
-! scope="col"| Task
+| SJOne Board
-! scope="col"| Status
+| P2.2
-! scope="col"| Actual Completion Date
+| Right Sensor Trigger pin
+|-
 |-
-! scope="row"| 1
+! scope="row"| 14
-| 09/20/2015
+| 4-pin Ultrasonic Sensor (Right)
-| 09/27/2015
+| Echo
-| Researching and ordering the LCD module to be used in the project
+| SJOne Board
-| Completed
+| P2.3
-| 9/27/2015
+| Right Sensor Echo pin
+|-
 |-
-! scope="row"| 2
+! scope="row"| 15
-| 09/27/2015
+| 4-pin Ultrasonic Sensor (Left)
-| 10/05/2015
+| Vcc
-|
+| 5V Power Supply
-*Studying data sheets(LCD and motor) to get understanding of basic concepts and working of components
+| +5V
-*Understanding and proposing driving mechanisms for LCD and motors(DC and servo)
+| Left Sensor Power
-| Completed
+|-
-| 10/05/2015
 |-
-! scope="row"| 3
+! scope="row"| 16
-| 10/05/2015
+| 4-pin Ultrasonic Sensor (Left)
-| 10/12/2015
+| GND
-|
+| 5V Power Supply
-*Interfacing motors to SJOne board and developing drivers for the same
+| GND
-*Interfacing LCD module to SJOne board and developing drivers to display basic texts and symbols
+| Left Sensor GND
-| Completed
+|-
-| 10/12/2015
 |-
-! scope="row"| 4
+! scope="row"| 17
-| 10/12/2015
+| 4-pin Ultrasonic Sensor (Left)
-| 10/30/2015
+| Trig
-|
+| SJOne Board
-*Implementation of basic power on RC car run with motors(DC and servo) interfaced to SJOne board
+| P2.4
-*Collaborating with other teams to develop basic obstacle avoidance and testing it
+| Left Sensor Trigger pin
-| Completed
+|-
-| 11/5/2015
 |-
-! scope="row"| 5
+! scope="row"| 18
-| 10/30/2015
+| 4-pin Ultrasonic Sensor (Left)
-| 11/12/2015
+| Echo
-| Proposals related to speed controls and sensors for the same and integration of LCD module(with data display)
+| SJOne Board
-| Completed
+| P2.5
-| 11/12/2015
+| Left Sensor Echo pin
 |-
-! scope="row"| 6
-| 11/12/2015
-| 11/25/2015
-| CAN bus communication from motor and I/O controller to other boards
-| Completed
-| 11/15/2015
 |-
-! scope="row"| 7
+! scope="row"| 19
-| 11/25/2015
+| CAN Transceiver
-| 12/15/2015
+| CANL
-| Debugging issues during trial runs and testing out fault cases
+| CAN BUS
-| Incomplete
+| CANL
-|
+| CANL to CAN BUS
+|-
+|-
+! scope="row"| 20
+| CAN Transceiver
+| CANR
+| CAN BUS
+| CANR
+| CANR to CAN BUS
 |-
 |}
+==== Implementation 3-pin Sensors With Interrupt ====
-==== I/O Software Design====
+===== Design flow =====
-The I/O Software is based off of two tasks: The Event Handler Task and the RX Task.
+*The design flow for the 3-pin ping sensors with interrupts was same as the 4-pin ping sensors with interrupts.
-'''Event Handler Task (High Priority):'''
+*3-pin sensor has a single pin for Echo and Trigger.
-This Task receives any immediate messages sent from the uLCD, processes the message, and sends the message to the CAN BUS.
+*1. In the sensor function, first the Trigger pin is set as output. A high to low pulse is provided.
+*2. Once the low pulse is provided on the trigger pin, the same pin is configured as input pin to the board.
+*3. The echo pin is monitored for rising and falling edge. Once the falling edge is detected, the distance calculation, can data transfer takes place following the same logic as 4-pin sensor.
-This task enables the system to: Turn On/Off the Vehicle and Change Vehicle Modes.
+* The pin connections for this implementation are same as Sensors pin connections mentioned in 7.2.3.
-'''RX Task (Low Priority):'''
+== '''Geographical Controller''' ==
+'''Team Members:'''
+ Chitrang Talaviya
+ Navjot Singh
-This task receives all messages from the CAN BUS, and outputs message data onto the uLCD
+'''Geographical Controller Schedule'''
+{| class="wikitable"
-'''High Level IO Software Logic'''
+|-
+! scope="col"| SI No.
-[[File:CmpE243 F14 TUndergrad IOHighLevel.jpg]]
+! scope="col"| Start Date
-'''Event Handler Task Logic'''
-[[File:CmpE243 F14 TUndergrad IOEventHandlerTaskLogic.jpg]]
-'''RX Task Logic'''
-[[File:CmpE243 F14 TUndergrad IORXTaskLogic.jpg]]
-== '''Master Controller''' ==
-'''Team Members:'''
- Hemanth Konanur Nagendra
- Akshay Vijaykumar
-'''Master Controller Schedule'''
-{| class="wikitable"
-|-
-! scope="col"| SI No.
-! scope="col"| Start Date
 ! scope="col"| End Date
 ! scope="col"| Task
@@ Line 1,033: / Line 1,064: @@
 |-
 ! scope="row"| 1
-| 10/10/2015
+| 09/20/2015
-| 10/20/2015
+| 09/27/2015
-|
+| Researching and ordering the parts
-*Establishing powerup sync and acknowledgement between master controller, sensor controller and Bluetooth controller
-*Implement heart beat monitoring on the master controller.
 | Completed
-| 10/20/2015
+| 9/27/2015
 |-
 ! scope="row"| 2
-| 10/21/2015
+| 09/27/2015
-| 10/31/2015
+| 10/05/2015
-|
+| Studying module data sheets and writing code sketches to be used when modules are procured(GPS and IMU)
-*Get sensor readings from the sensor controller and start/stop commands from Bluetooth controller to control the car
-*Send driving commands to the motor controller over the CAN bus
 | Completed
-| 10/25/2015
+| 10/05/2015
 |-
 ! scope="row"| 3
-| 10/26/2015
+| 10/05/2015
-| 11/01/2015
+| 10/15/2015
-|
+| Interfacing GPS module and compass to SJOne board and get consistent filtered readings
-*Decide the obstacle avoidance algorithm based on sensor readings from sensor controller.
-*Implement and test the avoidance algorithm.
 | Completed
-| 11/01/2015
+| 10/17/2015
 |-
 ! scope="row"| 4
+| 10/15/2015
+| 10/30/2015
+| Proposals for heading and distance calculation, unit testing and integrating modules
+| Completed
+| 10/30/2015
+|-
+! scope="row"| 5
+| 10/30/2015
 | 11/10/2015
-| 11/20/2015
+| Calibration of compass and GPS readings, CAN bus communication from geo controller to other boards.
-|
-*Get route co-ordinates from Bluetooth controller and setup infrastructure to send checkpoint updates to Geo-controller.
-*The master controller should be able to receive new routes in between navigation.
 | Completed
-| 11/20/2015
+| 11/10/2015
-|-
-! scope="row"| 5
-| 10/21/2015
-| 11/30/2015
-|
-*Get heading, bearing and speed information from Geo-controller
-*Decide on the navigation algorithm
-| Incomplete
-|
 |-
 ! scope="row"| 6
-| 12/01/2015
+| 11/10/2015
-| 12/07/2015
+| 11/25/2015
-|
+| Android application connection with data reception and transmit
-*Incorporate reverse driving algorithm in case of obstacle avoidance along with extra sensor readings
+| Completed
-*Test obstacle avoidance
+| 11/25/2015
-| Incomplete
-|
 |-
 ! scope="row"| 7
-| 12/08/2015
+| 11/25/2015
 | 12/15/2015
-| Extensive testing and smoothing out speed, turning, etc
+| Final phase testing and optimization, collaborating with android team to get better reliable outcomes
-| Incomplete
+| Completed
-|
+| 12/12/2015
 |-
 |}
+=== Geographical Controller H/W Design ===
+* Below figure represents the block diagram of Geo Controller. Geo-controller uses GPS and IMU module for its working. Uart3 and Uart2 are used for interfacing IMU and GPS with SJ One board at baud rate 9600bps.
+[[File:CmpE243_F15_TopGun_GeoController_HWInterface.jpg|500px|thumb|centre|H/W Interface of GeoController]]
+=== Geographical Controller Hardware Design Components ===
+<table>
+<tr>
+<td valign="top" align="justify" width=550px>
+<b>Adafruit MTK3339 GPS:</b>
-The Master Controller receives obstacle information from the Sensor Controller, navigation data from the Geo Controller and routing information from the Bluetooth Controller, collates all this information and provides driving directions to the Motor Controller.
+This GPS unit is interfaced via UART with build in antenna. The GPS provides latitude and longitude accurately up to 5-10 meters with a strong satellite fix with update rate of 10Hz. By default, the baud rate is 9600bps. Power usage for this module is 20mA during navigation.
-=== Design ===
-=== Master Controller Team Hardware Design ===
-[[File:CmpE243_F14_TeamUndergrad_MasterHWSchematic.png|650px]]
+The GPS module comes with following capabilities:
-==== Master Pin Connections ====
+*-165 dBm sensitivity, 10 Hz updates, 66 channels
-{| class="wikitable"
+* 5V friendly design and only 20mA current draw
-|-
+* Breadboard friendly + two mounting holes
-! scope="col"| Line Item#
+* RTC battery-compatible
-! scope="col"| Node A Source
+* Built-in datalogging
-! scope="col"| Node A Pin
+* PPS output on fix
-! scope="col"| Node B Source
+* Internal patch antenna + u.FL connector for external active antenna
-! scope="col"| Node B Pin
+* Fix status LED
-! scope="col"| Description
-|-
+We chose this part because it provided the base functionality we needed along with many other functions that would be fun to play with and try to include in the project. The antennae options and voltage regulator were also very enticing.
-! scope="row"| 1
+We get raw GPS "NMEA sentence" output from module. The most important NMEA sentences include the GGA which provides the current Fix data, the RMC which provides the minimum gps sentences information, and the GSA which provides the Satellite status data. We are filtering the data for RMC, Recommended Minimum, which will look similar to:
-| 3.3V Power Supply
-| 3.3V
+     $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
-| SJOne Board
+ where:-RMC          Recommended Minimum sentence C
-| 3V3
+       Fix taken at 12:35:19 UTC
-| SJOne Power
+      A            Status A=active or V=Void.
-|-
+.038,N   Latitude 48 deg 07.038' N
-|-
+.000,E  Longitude 11 deg 31.000' E
-! scope="row"| 2
+.4        Speed over the ground in knots
-| 3.3V Power Supply
+.4        Track angle in degrees True
-| GND
+       Date - 23rd of March 1994
-| SJOne Board
+.1,W      Magnetic Variation
-| GND
+      *6A          The checksum data, always begins with *
-| SJOne Ground
-|-
-|-
+</td>
-! scope="row"| 3
+<td>
-| CAN Transceiver
+</td>
-| CAN Tx
+<td>
-| SJOne Board
+[[File:F15_243_TG_gpsModule.jpg|250px|thumb|right|GPS_Module]]
-| P0.1 (Tx)
+</td>
-| SJOne - CAN Tx
+</tr>
-|-
+<tr>
-|-
+<td valign="top" align="justify" width=550px>
-! scope="row"| 4
+<b>9 Degrees of Freedom- Razor IMU:</b>
-| CAN Transceiver
-| CAN Rx
+In our project, we used IMU module to get the heading of the device.
-| SJOne Board
+The 9DOF Razor IMU provides nine degree of inertial measurement incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer). The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface. UART interface is used for interfacing with SJ One board and it is connected via UART3 with LPC board and is operated at 3.3V.
-| P0.0 (Rx)
-| SJOne - CAN Rx
+Features:
-|-
+*9 Degrees of Freedom on a single, flat board:
+**ITG-3200 - triple-axis digital-output gyroscope
+**ADXL345 - 13-bit resolution, ±16g, triple-axis accelerometer
+**HMC5883L - triple-axis, digital magnetometer
+*Outputs of all sensors processed by on-board ATmega328 and sent out via a serial stream
+*Autorun feature and help menu integrated into the example firmware
+*Output pins match up with FTDI Basic Breakout, Bluetooth Mate, XBee Explorer
+*3.5-16VDC input
+*ON-OFF control switch and reset switch
+</td>
+<td>
+</td>
+<td>
+[[File:F15_243_TG_imuModule.jpg|300px|thumb|right|9DOF-IMU]]
+</td>
+</tr>
+</table>
+=== Geographical Controller H/W Interface ===
+* Below table shows the Pins connection of GPS and IMU module with SJ One Board. Both the h/w's are interfaced with Controller using UART interface. The operating volatge of GPS and IMU is 3.3V.
+{| class="wikitable"
+|+ Geographical Controller Pin Connection Table
 |-
-! scope="row"| 5
+! scope="col"| '''Description'''
-| CAN Transceiver
+! scope="col"| '''Interface'''
-| CAN 3.3V
+! scope="col"| '''Device Port'''
-| 3.3V Power Supply
+! scope="col"| '''SJOne Board Port'''
-| 3.3V
-| SJOne - CAN Power
 |-
+| Supply Voltage
+| N/A
+| Vcc
+| 3.3 V
 |-
-! scope="row"| 6
+| Ground
-| CAN Transceiver
+| N/A
-| CAN Ground
+| GND
-| 3.3V Power Supply
 | GND
-| SJOne - CAN Ground
 |-
+| GPS Module
+| UART2
+|
+ Channel 1 -> Rx
+ Channel 2 -> Tx
+ Channel 3 -> EN
+|
+ Channel 1 -> Tx P2.8
+ Channel 2 -> Rx P2.9
+ Channel 3 -> Vcc
 |-
-! scope="row"| 7
+| IMU Module
-| CAN Transceiver
+| UART3
-| CANL
+|
-| CAN BUS
+ Channel 1 -> Rx
-| CANL
+ Channel 2 -> Tx
-| CANL to CAN BUS
+ Channel 3 -> DTR
-|-
+|
-|-
+ Channel 1 -> Tx P4.28
-! scope="row"| 8
+ Channel 2 -> Rx P4.29
-| CAN Transceiver
+ Channel 3 -> GPIO P2.2
-| CANR
-| CAN BUS
-| CANR
-| CANR to CAN BUS
 |-
 |}
-==== Control Flow ====
+=== Geographical Controller S/W Design ===
-On boot-up, Master Controller first attempts to sync with all the other controllers through a power-up sync and acknowledgement handshake mechanism. Once sync is established with all the controllers, it periodically monitors the heart-beat signals from all the controllers till the end of power cycle. If any controller goes out of sync, the master requests that controller to reset itself.
+Geographical controller uses two modules to get GPS data and headings. These are:
+*GPS module
+*IMU module
-The Master Controller now enters the ‘stopped’ state where no driving takes place. It continuously monitors the CAN bus for any routes from the Bluetooth Controller. Once all the navigation check points have been received, the Master Controller starts driving the car by directing the Motor Controller based on the Geo controller data. While driving, the Master Controller continuously listens for the obstacle data from the Sensor Controller and avoids any obstacles, if necessary. Once obstacle avoidance has been completed, Master makes any necessary course corrections and proceeds towards the destination as per the route.
+''' Tasks '''
+{| class="wikitable"
+|+ Geo Controller Tasks
+|-
+! align="center"|Task Name
+! align="center"|Purpose
+|-
+| IMU Task
+| To get IMU reading over UART3.
+|-
+| GPS Task
+| Read the GPS data string via UART2 Interrupt Handler.
+|-
+| Periodic 1Hz Callback
+| Receive Checkpoint from Master.
+|-
+| Periodic 10Hz Callback
+| Send GPS data over CAN BUS
+Send IMU heading,bearing,speed and distance data over CAN Bus
+|-
+|}
-==== Communication between Controllers ====
-===== Power-up Sync and Acknowledgement =====
-Once master boots up, it continuously monitors the CAN bus for a “Power up Sync” message from each of the other controllers. Once it receives the Sync message from all the controllers it acknowledges all of them at once by sending the “Master Sync Ack” message. This should prompt the other controllers to spawn their periodic tasks and start their respective functionalities.
-===== Heart Beat Implementation =====
+In the below sections, one will see the methods used to get the values from the modules. Both of the modules are interfaced using UART.
-After sending the ACK message the master proceeds to spawn its own periodic scheduler and starts monitoring the heartbeat signals from all the controllers at a rate of 1Hz.
-Every 1Hz, all the controllers are expected to send their respective “Heart-beat” message over the CAN bus. If this message fails to arrive, the master controller will wait for a specific period of time for the other controller to sync again. The sensor controller and motorIO controllers are very critical components for driving the car. So, they are not allowed to skip any heart-beats. The other controllers have varying thresholds of wait time, allowing them to sync with the master again. Once the threshold time is crossed, the master controller issues a “Reset” message for the controller that went out of sync. The receiving controller is expected to reset and sync again at this point.
+''' GPS '''
+*Initialization: GPS data is retrieved using Interrupts for UART2. Before using Interrupts for receiving GPS string that contains data,UART2 is initialized with Receiving Interrupts Enabled. The code for UART init is as below. The UART init is done once, so is called in main().
-If the sensor controller or motor controller go out of sync, the master stops issuing driving directions to the motorIO controller, hence stopping the car.
+ void uart2init()
+ {
+    // In our inter-board communication we have used UART 2 for transmission and reception. So, We will unable UART 2.
+    LPC_SC->PCONP |= (1<<24);  // We have to Power on the UART 2 peripheral. To do so we have to enable bit 24 of PCONP register.
+    LPC_SC->PCLKSEL1 &= ~((1<<16)|(1<<17));    // Peripheral Clock = CPUClock/4. (48 Mhz/4= 12 Mhz)
+    LPC_PINCON->PINSEL4 &= ~((1<<19)|(1<<18)|(1<<17)|(1<<16));
+    LPC_PINCON->PINSEL4 |= ((1<<19) | (1<<17));  // We have to set this bits to meet the requirements of selection lines.
+    LPC_UART2-> LCR  |= 0xFFFFFF83;    // To access DLL and DLM we have to set 7th bit of the LCR. We are enabling Dlatch by setting this bit.
+    // 0 and 1 bits of LCR is 11. 8 bit data format. 1 stop bit. No parity.
+    LPC_UART2 -> DLL = 71;         // To set the baud rate 9600 bps we have to set divisor latch least significant bits to 96.
+    LPC_UART2 -> DLM = 0;// and most significant bits to 0.
+    LPC_UART2-> FDR = 0xA1;
+    LPC_UART2-> LCR &=~(1<<7) ;    // We have to reset the Dlatch bit before starting the communication.
+    LPC_UART2->FCR = (1 << 0) | (1 << 6);
+    LPC_UART2->FCR |= (1 << 1) | (1 << 2);
+    LPC_UART2->IER = (1 << 0);
+ }
-===== Data Communication =====
+*Getting GPS data from Interrupt Handler: The reason we used Interrupt handler was to get the data from GPS without any delay. Interrupt handler on getting all the string, will send over 'Queue'. To get data from the GPS module, we need to send raw data over UART bus :
-The master controller performs the following data transactions over the CAN bus.
+char dataTobeSenttoGPS[] = "$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n";
+char dataTobeSenttoGPS_1[] =  "$PMTK220,100*2F\r\n";
+After sending this, we will be getting GPS string after every 100ms, which is read by interrupt handler as:
+ extern "C"
+ {
+    void UART2_IRQHandle()
+    {
+        static  char GPS_buffer1[100];
+        static int i_new=0;
+        while(!(LPC_UART2-> LSR & 0x01));
+        GPS_buffer1[i_new]= LPC_UART2 -> RBR;
+        if(GPS_buffer1[i_new]=='\n') {
+           GPS_buffer1[i_new]='\0';
+           flag_received = true;
+           if(xQueueSendFromISR(gps_queue1, &GPS_buffer1 , 0)) {
+           }
+           else{
+           }
+           i_new=0;
+        }
+        else{
+        i_new++;
+        }
+    }
+ }
+*Sending data over CAN bus: In GeoController, we are using can1 for transmit and receive can messages. Latitude and longitude values are getting updated by GPS task using global structure. 'CAN send' function which is getting called every 100hz is using memcpy function to copy the structure data to CAN message and send over can bus.
+        gps_msg.msg_id = GEO_LOC_DATA_ID;
+        gps_msg.frame_fields.is_29bit = 0;
+        gps_msg.frame_fields.data_len = sizeof(gps_data_dec);
+        memcpy(&gps_msg.data.qword, &gps_data_dec, sizeof(gps_data_dec));
+        CAN_tx(GEO_CNTL_CANBUS, &gps_msg, GEO_CNTL_CAN_TIMEOUT);
-Bluetooth controller signals to the master controller that a new route has been requested from the Android application through “Check-Point Send” message. In this message, the Bluetooth controller also specifies the number of check-points that are present along the route. The master acknowledges this signal through “Check-point Request” message. The Bluetooth controller starts sending the check-points periodically, at 10Hz, after it receives the ack. The master stores all these check-points in an array and switches to navigation mode.
+''' IMU '''
+*Initialization: IMU is initialized using Singleton Class pattern. UART3 is being used for IMU interface with board.
-In navigation mode, master controller issues the next immediate check-point to the Geo controller through “Geo location update” message and expects the current heading, current bearing, current speed and current GPS location information from the Geo controller with respect to this new checkpoint. Master controller continuously calculates the distance between the current GPS location and the current checkpoint location to determine if the checkpoint has been reached. Once reached, the next checkpoint co-ordinates are issued to the Geo controller. This cycle is repeated till the destination has been reached.
+    readYawCommand{'#', 'f'} // string is used to get Yaw reading from IMU module.
+    if(IMUInterface.sendYawReadCommand(IMUInterface.readYawCommand))
+    {
+        // Waits for a response from IMU
+        if(IMUInterface.getYawReadingString())
+        {
+            CUSTOM_DEBUG("IMUTask : Read success");
+        }
+        else
+        {
+            CUSTOM_DEBUG("IMUTask : Read fail");
+        }
+The Yaw data we received from getYawReadingString() is used later to calculate heading value.
+*Sending data over CAN bus: CAN1 is used for sending can messages. Following code shows, how the structure for IMU is filled by calling respective functions such as : calculateBearing(), getHeading(), calculateDistance() and then send over CAN bus.
+ void geo_send_heading()
+ {
+    can_msg_t geo_msg;
+    geo_spd_angle geo_data;
+    if(a == GEO_DATA_TO_SEND)
+    {
+        static imu& imu_handle = IMUInterface;  // Handle to singleton IMU object
+        geo_data.bearing = calculateBearing(current_checkpoint_data);   // put bearing here
+        geo_data.heading = imu_handle.getHeading();
+        if(geo_data.heading < HEADING_OFFSET2 && geo_data.heading >= 0)
+        {
+            geo_data.heading = 360 - HEADING_OFFSET2 + (geo_data.heading);
+        }
+        else
+        {
+            geo_data.heading = geo_data.heading - HEADING_OFFSET2;
+        }
+        geo_data.speed = speed_gps;
+        geo_data.distance = (uint16_t)calculateDistance(current_checkpoint_data);
+    }
+    if(a == GEO_DO_NOT_SEND)
+    {
+        geo_data.bearing = 0;   // put bearing here
+        geo_data.heading = 0;
+        geo_data.speed = 0;
+        geo_data.distance = 0;
+    }
+    geo_msg.msg_id = GEO_SPEED_ANGLE_ID;
+    geo_msg.frame_fields.is_29bit = 0;
+    geo_msg.frame_fields.data_len = sizeof(geo_data);
+    memcpy(&geo_msg.data.qword,&geo_data, sizeof(geo_data));
+    CAN_tx(GEO_CNTL_CANBUS, &geo_msg, GEO_CNTL_CAN_TIMEOUT);
+ }
+*Updating Firmware on IMU:
+** For updating the firmware on IMU, we used FTDI basic breakout which uses USB mini cable to connect to PC. The board comes programmed with the 8MHz     Arduino bootloader (stk500v1) and some example firmware that demos the outputs of all the sensors. UART connection are made to interface IMU with breakout board at 57600bps. We have modified the firmware in a way that we receive only the required information via UART.
+**Connections between IMU and FTDI breakout :-
+ FTDI BREAKOUT      RAZOR
+ GND           <--> GND
+ CTS           <--> CTS
+.3V          <--> 3.3V
+ TXO           <--> RXI
+ RXI           <--> TXO
+ DTR           <--> DTR
+The details are given at: https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial. Firmware provides the readings Yaw, Pitch and Roll readings. As in the project we only need the Yaw data, so firmware is been updated to provide only the Yaw readings.
-All through the navigation mode, master controller directs the motor controller to drive (speed and direction to turn) based on heading and bearing information from the Geo controller. The obstacle information is also being continuously received from the sensor controller. If an obstacle is detected, the master controller stops navigating to the checkpoint and avoids the obstacle. Once obstacle has been avoided the master goes back to navigation.
+*Sensor Calibration:
+**  Sensor calibration include calibrating the accelerometer, gyroscope and magnetometer. Sensor calibration in our project is done twice, once in the beginning and then at the end when all the boards are mounted on the car. As the magnetic field of motor can effect the gyroscope readings so we did the calibration again. The details can be found on the link given above.
-=== Driving Algorithm ===
-==== Overview ====
-==== Obstacle Avoidance Algorithm ====
+''' Software Flow Diagram '''
-==== Navigation Algorithm ====
-== '''Bluetooth/Bridge Controller''' ==
-'''Team Members:'''
+[[File:CmpE243_F15_TopGun_GeoController_SWInterfaceFlowgraph.jpg|700px|thumb|centre|S/W Interface Flow Diagram of Geo-Controller]]
- Anush Shankar
- Aditya Devaguptapu
-'''Bluetooth/Bridge Controller Schedule'''
+== '''Motor I/O Controller''' ==
+''' Team Members: '''
+ Anuj Korat
+ Dhruv Kakadiya
+'''Motor & I/O Controller Schedule'''
 {| class="wikitable"
 |-
@@ Line 1,229: / Line 1,410: @@
 ! scope="row"| 1
 | 09/20/2015
-| 09/30/2015
+| 09/27/2015
-| Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API
+| Researching and ordering the LCD module to be used in the project
 | Completed
-| 09/30/2015
+| 9/27/2015
 |-
 ! scope="row"| 2
-| 09/31/2015
+| 09/27/2015
-| 10/10/2015
+| 10/05/2015
 |
-*Placement of buttons on the app activity page to switch on and off bluetooth on the phone
+*Studying data sheets(LCD and motor) to get understanding of basic concepts and working of components
-*Marker placement on Google maps for source and destination
+*Understanding and proposing driving mechanisms for LCD and motors(DC and servo)
 | Completed
-| 10/10/2015
+| 10/05/2015
 |-
 ! scope="row"| 3
-| 10/10/2015
+| 10/05/2015
-| 10/22/2015
+| 10/12/2015
 |
-*Creating input and output streams for bluetooth for sending and receiving data
+*Interfacing motors to SJOne board and developing drivers for the same
-*Performing straight line routing between source and destination on google maps
+*Interfacing LCD module to SJOne board and developing drivers to display basic texts and symbols
 | Completed
-| 10/22/2015
+| 10/12/2015
 |-
 ! scope="row"| 4
-| 10/22/2015
+| 10/12/2015
 | 10/30/2015
-| Interfacing bluetooth module to SJOne board through UART and receive data on SJOne board sent by the bluetooth application
+|
+*Implementation of basic power on RC car run with motors(DC and servo) interfaced to SJOne board
+*Collaborating with other teams to develop basic obstacle avoidance and testing it
 | Completed
-| 11/05/2015
+| 11/5/2015
 |-
 ! scope="row"| 5
 | 10/30/2015
-| 11/10/2015
+| 11/12/2015
-| Relay commands and CAN messages from SJOne to android application and test correctness of data
+| Proposals related to speed controls and sensors for the same and integration of LCD module(with data display)
 | Completed
-| 11/15/2015
+| 11/12/2015
 |-
 ! scope="row"| 6
-| 11/10/2015
+| 11/12/2015
-| 11/22/2015
+| 11/25/2015
-| Performing correct routing between source and destination, have a complete working application, basic testing of application and bridge interface
+| CAN bus communication from motor and I/O controller to other boards
 | Completed
-| 11/22/2015
+| 11/15/2015
 |-
 ! scope="row"| 7
-| 11/22/2015
+| 11/25/2015
 | 12/15/2015
-| Extensive Testing of application during final phases, modifying code in cooperation with other teams and optimization of android application
+| Debugging issues during trial runs and testing out fault cases
-| In progress
+| Completed
-|
+| 12/8/2015
 |-
 |}
-=== Bluetooth Controller ===
+=== Motor/IO Controller Software Design===
-The Bluetooth Controller is responsible to help the RC car navigation by providing it with route information between source and destination as selected on the Android application. It communicates with the Android application over Bluetooth channel to obtain the route and way-point data between two points on the google map. The route and way-point information once received is parsed to get latitude and longitude for all way-points. This information is then communicated to the Master Controller via CAN bus.
-=== HC-06 Bluetooth Module===
+==== Tasks ====
+{| class="wikitable"
+|+ Motor/IO Controller Tasks
+|-
+! align="center"|Task Name
+! align="center"|Purpose
+|-
+| Period Init
+| Can bus initialization, Motor and LCD initialization
+|-
+| Period Register telemetry
+| Register Motor_data can message and dc_speed counts for different speeds
+|-
+| Periodic 1Hz Callback
+| Check can bus off and Print data on LCD
+|-
+| Periodic 10Hz Callback
+| Drive car according to received data from Master controller
+|-
+| Periodic 100Hz Callback
+| Receive CAN bus data
+|-
+| Periodic 1000Hz Callback
+| Receive touch data from LCD and check RPM sensor
+|-
+|}
-[[File:Cmpe243_F15_HC-06_module.png|200px|right|thumb|HC-06 Bluetooth Module]]
+=== DC Motor ===
-The HC-06 is a bluetooth controller with slave only configuration used to communicate to and from a master Bluetooth module. The master Bluetooth module is capable to initiating a connection with other Bluetooth module, while slave is not able to do that. The slave can only communicate with the master module over a connection established by the master. The HC-06 by default is in slave configuration as per factory settings.
+<table>
+<tr>
+<td valign="top" align="justify" width=600px>
+Our car came with the motor that needed 7.4V of power supply to work. This motor has the power to run the car at a maximum speed of the 35mph.<br><br>
+The table below contains information about PWM (duty cycle) given to the motor and the corresponding speed of the car on a flat surface.<br><br>
+{| class="wikitable"
+|-
+! align="center"|S.R.
+! align="center"|Duty Cycle
+! align="center"|Speed(mph)
+|-
+! scope="row" align="center"|1
+| scope="row" align="center"|15.80
+| scope="row" align="center"|2
+|-
+! scope="row" align="center"|2
+| scope="row" align="center"|16.00
+| scope="row" align="center"|4
+|-
+! scope="row" align="center"|3
+| scope="row" align="center"|16.20
+| scope="row" align="center"|6
+|-
+! scope="row" align="center"|4
+| scope="row" align="center"|16.40
+| scope="row" align="center"|8
+|-
+! scope="row" align="center"|5
+| scope="row" align="center"|16.60
+| scope="row" align="center"|10
+|-
+! scope="row" align="center"|6
+| scope="row" align="center"|16.80
+| scope="row" align="center"|11
+|-
+|}
+Table3: DC Motor Duty Cycle v/s Speed
-Some of the features of HC-06 which make it apt for the RC car are as follows:
+</td>
+<td align="center">
+[[File:F15_243_TG_DC_Motor.gif|300px]]<br>
+DC Motor
+</td>
+</tr>
+</table>
-*Can work at the low voltage (3.1V~4.2V). The current in pairing is in the range of 30～40mA. The current in communication is 8mA.
+<table>
+<tr>
+<td valign="top" align="justify" width=600px>
+DC motor is controlled with the help of three wires coming out of the ESC. These wires are VCC, GND and Speed control. The VCC line is not used as required voltage is directly given to the motor through a battery, via ESC. The GND line and Speed control lines are connected to the ground and PWM pin of SJOne board.
-*Has a 2.4GHz digital wireless transceiver.
+{| class="wikitable"
+|-
+! align="center"|S.R.
+! align="center"|ESC Wire Pins
+! align="center"|SJOne Board Pins
+|-
+! scope="row" align="center"|1
+| scope="row" align="center"|Vcc
+| scope="row" align="center"|-
+|-
+! scope="row" align="center"|2
+| scope="row" align="center"|GND
+| scope="row" align="center"|GND
+|-
+! scope="row" align="center"|3
+| scope="row" align="center"|Speed Control
+| scope="row" align="center"|P2.1
+|-
+|}
+DC Motor Pin Connections
-*Small (27mm×13mm×2mm)
+To drive the DC motor, we are using pwm2 i.e. pin P2.1 of the SJOne board. We are using the in-build PWM generation function which requires two parameters, one is pin being used and the other being the frequency. To set the required duty cycle, the in-build set function is used.
+</td>
-*Peripherals circuit is simple.
+<td align="center">
+[[File:F15_243_TG_motor_cnt.png|300px]]<br>
+DC Motor Connector
+</td>
+</tr>
+</table>
-*Low power consumption
+[[File:F15_243_TG_Motor_init.png]]
-*Has high-performance wireless transceiver system
+=== Servo Motor ===
+<table>
-*Low Cost
+<tr>
+<td valign="top" align="justify" width=600px>
-=== Bluetooth Controller Hardware Design ===
+Our car came with a waterproof digital servo motor. This motor works without ESC. We can directly control this motor by giving PWM signal from our SJOne board. The below table contains information about PWM (duty cycle) given to the motor and the corresponding turns taken by the car.
-[[File:Cmpe243_F15_Bluetooth_interfacedia.png|620px|centre|thumb|Bluetooth Controller Interface Diagram]]
-==== Master Pin Connections ====
 {| class="wikitable"
 |-
-! scope="col"| Line Item#
+! align="center"|S.R.
-! scope="col"| Node A Source
+! align="center"|Duty Cycle
-! scope="col"| Node A Pin
+! align="center"|Turn
-! scope="col"| Node B Source
+|-
-! scope="col"| Node B Pin
+! scope="row" align="center"|1
-! scope="col"| Description
+| scope="row" align="center"|10.41
+| scope="row" align="center"|Full Left
+|-
+! scope="row" align="center"|2
+| scope="row" align="center"|12.35
+| scope="row" align="center"|Half Left
 |-
-! scope="row"| 1
+! scope="row" align="center"|3
-| Power Supply
+| scope="row" align="center"|13.53
-| 3.3V
+| scope="row" align="center"|Slight Left
-| SJOne Board
-| 3V3
-| SJOne Power
 |-
+! scope="row" align="center"|4
+| scope="row" align="center"|15.39
+| scope="row" align="center"|Straight
 |-
-! scope="row"| 2
+! scope="row" align="center"|5
-| Power Supply
+| scope="row" align="center"|16.00
-| GND
+| scope="row" align="center"|Slight Right
-| SJOne Board
+|-
-| GND
+! scope="row" align="center"|6
-| SJOne Ground
+| scope="row" align="center"|17.37
+| scope="row" align="center"|Half Right
+|-
+! scope="row" align="center"|7
+| scope="row" align="center"|20.03
+| scope="row" align="center"|Full Right
+|-
+|}
+Servo Motor Duty Cycle v/s Turn
+</td>
+<td align="center">
+[[File:F15_243_TG_Servo_motor.gif|250px]]<br>
+Servo Motor
+</td>
+</tr>
+</table>
+<table>
+<tr>
+<td valign="top" align="justify" width=600px>
+Servo motor is controlled with the help of three wires coming out of the servo motor. The wires are VCC, GND and Direction control. The VCC is connected to the 3.3v. GND and direction control are connected to the ground and pwm pins of SJOne board.
+{| class="wikitable"
 |-
+! align="center"|S.R.
+! align="center"|Servo Motor Pins
+! align="center"|SJOne Board Pins
 |-
-! scope="row"| 3
+! scope="row" align="center"|1
-| CAN Transceiver
+| scope="row" align="center"|Vcc
-| CAN Tx
+| scope="row" align="center"|Vcc
-| SJOne Board
-| P0.1 (Tx)
-| SJOne - CAN Tx
 |-
+! scope="row" align="center"|2
+| scope="row" align="center"|GND
+| scope="row" align="center"|GND
 |-
-! scope="row"| 4
+! scope="row" align="center"|3
-| CAN Transceiver
+| scope="row" align="center"|Direction Control
-| CAN Rx
+| scope="row" align="center"|P2.0
-| SJOne Board
-| P0.0 (Rx)
-| SJOne - CAN Rx
-|-
 |-
-! scope="row"| 5
+|}
-| CAN Transceiver
+Servo Motor Pin Connections
-| CAN 5V
-| Power Supply
+We control the Servo motor using pwm1 i.e. pin P2.0 of the SJOne board. We configure the PWM pin using an in-build function which requires two parameters, one is the pin that we are using and the other is the frequency of the pwm. To set the duty cycle, in-build set function is used in which we are passing the duty cycle at which we want servo motor to work.
-| 5V
+</td>
-| SJOne - CAN Power
+<td align="center">
-|-
+[[File:Motor_cnt1.png|300px]]<br>
-|-
+Servo Motor Connector
-! scope="row"| 6
+</td>
-| CAN Transceiver
+</tr>
-| CAN Ground
+</table>
-| Power Supply
-| GND
+[[File:F15_243_TG_MotorControl_Singletone.png]]<br>
-| SJOne - CAN Ground
+Motor PWM Singleton implementation
-|-
-|-
+==== I/O Software Design====
-! scope="row"| 7
-| CAN Transceiver
+The I/O Software is based off of two tasks: The Event Handler Task and the RX Task.
-| CANL
-| CAN BUS
+'''Event Handler Task (High Priority):'''
-| CANL
-| CANL to CAN BUS
+This Task receives any immediate messages sent from the uLCD, processes the message, and sends the message to the CAN BUS.
-|-
-|-
+This task enables the system to: Turn On/Off the Vehicle and Change Vehicle Modes.
-! scope="row"| 8
-| CAN Transceiver
+'''RX Task (Low Priority):'''
-| CANH
-| CAN BUS
+This task receives all messages from the CAN BUS, and outputs message data onto the uLCD
-| CANH
-| CANH to CAN BUS
+'''High Level IO Software Logic -- Event Handler Task Logic -- RX Task Logic'''
+{|
+|[[File: F15_243_TG_IMG_HighLevel.jpg|500px|thumb|left|HighLevel]]
+|[[File: F15_243_TG_IMG_EventHandlerTaskLogic.jpg|550px|thumb|right| EventHandlerTaskLogic]]
+|[[File: F15_243_TG_IMG_RXTaskLogic.jpg|550px|thumb|right| RXTaskLogic]]
+|}
+===='''Different screens on LCD'''====
+{|
+|[[File: F15_243_TG_IMG_locked.jpg|200px|thumb|left|Locked Screen]]
+|[[File: F15_243_TG_IMG_10.jpg|200px|thumb|right|Home Screen]]
+|[[File: F15_243_TG_IMG_12.jpg|200px|thumb|right|Geo Screen]]
+|[[File: F15_243_TG_IMG_13.jpg|200px|thumb|right|Sensor Screen]]
+|[[File: F15_243_TG_IMG_motor.jpg|200px|thumb|right|Motor Screen]]
+|}
+The contents displayed on LCD were well thought of according to its application in our project. We wanted to test the sensor and the magnetometer readings while we were testing out car along with testing the algorithm of navigation. This would enable us to not connect the LPC controller with a Laptop to check and verify readings. The LCD we bought is from 4D systems and is very convenient and efficient to use. It has its own software which enables us to work in 4 different modes. We chose the mode which gave us different tools to build the compass, buttons and the angularometer. A bluetooth to serial converter is used to program the LCD with the software. We used the tools (that came with the LCD Module), to picturize our LCD screens. We loaded the program into LCD's memory card.
+The program that we burned on LCD will use the data bytes we send from our microcontroller and will print those bytes appropriately on different elements that we had created. For example, there are 360 degrees values to show on angularometer. The microcontroller will give a value from 0-360 based on the CAN frame which consists of car speed, heading and bearing values broadcasted by the Geo controller. In this way, almost every parameter being exchanged on the CAN bus of the car is displayed.
+===='''The LCD Software'''====
+[[File:F15_243_TG_LCD.png|center|750px]]
+The following is the link to the main page of the LCD. It contains everything you need to know to run this LCD and run it to the highest feature. It has the datasheet as well as the info regarding the software too. Go through the software datasheets as well as we will need that software to run the LCD initially. The LCD accepts any data from our microcontroller only if it is programmed that way by the software.
+*http://www.4dsystems.com.au/product/uLCD_32PTU/
+Next link is to the to the collection of go through materials for each every object the LCD uses.
+*http://old.4dsystems.com.au/appnotes.php
+So you know all the features of the LCD now and also have downloaded the Software, now what? The best and the easiest mode of working is the ViSi-Genie. Its fast, efficient and powerful. With Visi-Genie, you can just drag and drop tools you wanna use on your LCD. Lets take an example.
+[[File:F15_243_TG_lcdsoftware1.png|center|650px]]
+Now, if you have gone through the software datasheets, you will be already have accustomed with the software and its fun too. Select your tool accordingly your requirement. Be creative. We needed to show magnetometer values, from 0 to 360 in order to debug whether the compass is pointing towards north exactly or not. So we used an angularometer under the Gauges tab. It will have all the properties associated with the object. You can test each of them. Now, the data sent from the microcontroller will be directly printed on the LCD to its position on the angularometer. In this way, we can easily know the direction of True North with the help of LCD. Alon with this there are some strings used on LCD which shows longitude, lattitude, etc. This string is also sent from the microcontroller. When you are done with the tools, put a memory card with a maximum of 2 GB of memory into your LCD and connect it serially to your PC. USB to serial converter is to be used here. Burn the software image onto your LCD. At this point, your LCD is programmed to show all the images and the tools and is ready to accept all the data from the controller and print them on itself. So now we have got to do, is only connect the controller with LCD and send data bytes with help of UART.
+The connection is done in following way:-
+ LPC -> LCD
+ TXD2 -> RX
+ RXD -> TX
+ VCC -> VCC
+ GND -> GND
+The format overhead for sending data is of 4 bytes. If you want to set the angularometer, you have to give 6 bytes via UART,
+ Byte1 - Event byte
+ Byte2 - Object type
+ Byte3 - Object number
+ Byte4 - Data byte 1
+ Byte5 - Data byte 2
+ Byte6 - Check sum
+The following is a code snippet to print a string on LCD
+[[File:F15_243_TG_lcd_code.png|center|650px]]
+Similarly, when you touch any of the input tool on LCD, it will send 6 bytes in the same format to your microcontroller(Yes! It is touch screen). So, in this way you will know, what object you have set and to what value. For example,
+[[File:F15_243_TG_motor_soft.png|center|650px]]
+There are some input tools given h=here to change the factor for PWM operation. This really comes in handy when you are testing your car in the field and just to increase your motor's speed you have to change your code and flash your controller again and again. Instead have your LCD set the factor in as simply as this way. When you touch the the left or right arrow, the LCD will send the object's identity to the controller. The controller will check this and it will then set the globally declared PWM factor which changes it in real-time and then print that value on the string object between. See, told you to be creative!. This truly makes your LCD input and output together.
+== '''Master Controller''' ==
+'''Team Members:'''
+ Hemanth Konanur Nagendra
+ Akshay Vijaykumar
+'''Master Controller Schedule'''
+{| class="wikitable"
 |-
+! scope="col"| SI No.
+! scope="col"| Start Date
+! scope="col"| End Date
+! scope="col"| Task
+! scope="col"| Status
+! scope="col"| Actual Completion Date
 |-
-! scope="row"| 9
+! scope="row"| 1
-| Bluetooth Module
+| 10/10/2015
-| TXD
+| 10/20/2015
-| SJOne Board
+|
-| RXD3
+*Establishing powerup sync and acknowledgement between master controller, sensor controller and Bluetooth controller
-| SJOne RX3-  Bluetooth module TXD
+*Implement heart beat monitoring on the master controller.
-|-
+| Completed
+| 10/20/2015
 |-
-! scope="row"| 10
+! scope="row"| 2
-| Bluetooth Module
+| 10/21/2015
-| RXD
+| 10/31/2015
-| SJOne Board
+|
-| TXD3
+*Get sensor readings from the sensor controller and start/stop commands from Bluetooth controller to control the car
-| SJOne TX3-  Bluetooth module RXD
+*Send driving commands to the motor controller over the CAN bus
+| Completed
+| 10/25/2015
 |-
+! scope="row"| 3
+| 10/26/2015
+| 11/01/2015
+|
+*Decide the obstacle avoidance algorithm based on sensor readings from sensor controller.
+*Implement and test the avoidance algorithm.
+| Completed
+| 11/01/2015
 |-
-! scope="row"| 11
+! scope="row"| 4
-| Bluetooth Module
+| 11/10/2015
-| Bluetooth module VCC(3.3V)
+| 11/20/2015
-| Power Supply
+|
-| 3.3V
+*Get route co-ordinates from Bluetooth controller and setup infrastructure to send checkpoint updates to Geo-controller.
-| Bluetooth module - Power supply 3.3V
+*The master controller should be able to receive new routes in between navigation.
+| Completed
+| 11/20/2015
+|-
+! scope="row"| 5
+| 10/21/2015
+| 11/30/2015
+|
+*Get heading, bearing and speed information from Geo-controller
+*Decide on the navigation algorithm
+| Completed
+| 11/24/2015
 |-
+! scope="row"| 6
+| 12/01/2015
+| 12/07/2015
+|
+*Test obstacle avoidance along with Navigation algorithm
+| Completed
+| 12/12/2015
 |-
-! scope="row"| 12
+! scope="row"| 7
-| Bluetooth Module
+| 12/08/2015
-| Bluetooth module GND
+| 12/15/2015
-| Power Supply
+| Extensive testing and smoothing out speed, turning, etc
-| GND
+| Completed
-| Bluetooth module - Power supply GND
+| 12/16/2015
 |-
 |}
-==== Control Flow ====
-On boot-up, Bluetooth Controller first attempts to sync with the Master controller through a power-up sync and acknowledgement handshake mechanism. Once sync is established with the Master Controller, the Bluetooth controller periodically sends heart-beat signals to master controller till the end of power cycle. If any Bluetooth controller goes out of sync, the master requests the controller to reset itself.
-Once all initial handshaking procedures are completed and heart beat signal is established, the Bluetooth Controller waits for data from the On board HC-06 Bluetooth module on the UART port. When Bluetooth connection is established between the Android application and the On board HC-06 Bluetooth controller, routing data is sent from the Android app to the SJOne board. The SJOne board receives the data on UART port via interrupts and parses the data to extract 6 point precision floating point values for each way-points latitude and longitude. The way-point latitude and longitude is stored in a array to be sent out on CAN bus.
+The Master Controller receives obstacle information from the Sensor Controller, navigation data from the Geo Controller and routing information from the Bluetooth Controller, collates all this information and provides driving directions to the Motor Controller.
+=== Design ===
+====  Hardware Design ====
+The diagram shows the hardware connections for the Master Controller.
-Once all way-point data is parsed and ready, the SJOne board first sends out the number of way-points to the master controller and waits for acknowledgement from the master controller. One reception of the acknowledgement from the master and intent to receive the way-point data, the data is sent on the CAN bus periodically till all the data is exhausted.
+[[File:F15_243_TG_masterCANconnections.png|center|650px]]
-==== Communication between Bluetooth and Other Controllers ====
+==== Pin Connections ====
-===== Power-up Sync and Acknowledgement =====
+{| class="wikitable"
-Once Bluetooth controller boots up, it continuously sends "Power up Sunc" on the CAN bus to the master using "BLUETOOTH_SYNC_ID" can message id. The controller then polls on the sync function to receive an acknowledgement from the master towards "Power on Sync". Once an acknowledgement is received from master with message id "MASTER_SYNC_ACK_ID", the Bluetooth controller starts the FreeRtos scheduler. Only after this will all tasks run on the controller.
+|-
+! scope="col"| Line Item#
-===== Heart Beat Implementation =====
+! scope="col"| Node A Source
-Once Bluetooth controller starts the scheduler, it starts sending out heart beat messages on can bus directed towards the master controller using message id "BLUETOOTH_HEARTBEAT_ID" every 1 Hz. If the master does not receive heart beat message it asks Bluetooth controller to reset.
+! scope="col"| Node A Pin
+! scope="col"| Node B Source
-===== Data Communication =====
+! scope="col"| Node B Pin
-The Bluetooth controller performs data transactions over the CAN bus only with the master controller.
+! scope="col"| Description
+|-
-Bluetooth controller signals to the master controller that a new route has been requested from the Android application through “CHECKPOINT_SEND_ID” message id. In this message, the Bluetooth controller also specifies the number of check-points that are present along the route. The Bluetooth Controller waits on master's acknowledgement through “CHECKPOINT_REQ_ID” message id. The Bluetooth controller starts sending the check-points periodically, at 10Hz, after it receives the ack. Once all the way-points are sent to the master, the Bluetooth Controller goes to listening to UART interrupts for any changes in the route.
+! scope="row"| 1
+| 3.3V Power Supply
-===== Flow Chart=====
+| 3.3V
+| SJOne Board
-The flow chart for the Bluetooth Controller is as follows:
+| 3V3
+| SJOne Power
-[[File:Cmpe243_F15_flow_chart_bt.png|620px|centre|thumb|Bluetooth Controller Flow Chart]]
+|-
+|-
-==== Android App Design====
+! scope="row"| 2
+| 3.3V Power Supply
-=====Introduction=====
+| GND
-The objective of the Android App is to provide the User with an interface that is capable of providing commands to a car. The ubiquity of Android devices, availability of documentation for the Android APIs and Google's comprehensive mapping solution were reasons enough for us to implement this app on the Android platform. With these motivations in mind, the Android app was built with the Google Maps API and the Bluetooth API at its heart.
+| SJOne Board
+| GND
-=====Design=====
+| SJOne Ground
+|-
-The design of the app is straightforward- On start up, the user is presented with a Map fragment and buttons that control the behavior of the car. the User has to set his source point and destination point by tapping on two locations on a map. On selecting a destination, the Google Maps Directions API returns a route which is displayed on the Map. The User can then connect to the car and send the route via the buttons in the app.
+|-
+! scope="row"| 3
-=====Implementation=====
+| CAN Transceiver
+| CAN Tx
-== DBC File Implementation ==
+| SJOne Board
+| P0.1 (Tx)
-* This section explains DBC file implementation of the project. The DBC implementation contains the python based DBC file parser, a DBC file and auto generated C code for the five CAN nodes. These five nodes include driver(master), sensor, motor, geo and bluetooth node. The DBC file is a input to the python DBC parser script. The python script will generate a C file for the specific node given by the user at the command line argument. The python script goes through this DBC file and generates code to marshal (covert to raw CAN) and unmarshal (convert from raw CAN) using the provided API that you can enclose in a header file.
+| SJOne - CAN Tx
+|-
-* The following is the DBC file of the project.
+|-
+! scope="row"| 4
-      VERSION ""
+| CAN Transceiver
-       NS_ :
+| CAN Rx
-            NS_DESC_
+| SJOne Board
-            CM_
+| P0.0 (Rx)
-            BA_DEF_
+| SJOne - CAN Rx
-            BA_
+|-
-            VAL_
+|-
-            CAT_DEF_
+! scope="row"| 5
-            CAT_
+| CAN Transceiver
-            FILTER
+| CAN 3.3V
-            BA_DEF_DEF_
+| 3.3V Power Supply
-            EV_DATA_
+| 3.3V
-            ENVVAR_DATA_
+| SJOne - CAN Power
-            SGTYPE_
+|-
-            SGTYPE_VAL_
+|-
-            BA_DEF_SGTYPE_
+! scope="row"| 6
-            BA_SGTYPE_
+| CAN Transceiver
-            SIG_TYPE_REF_
+| CAN Ground
-            VAL_TABLE_
+| 3.3V Power Supply
-            SIG_GROUP_
+| GND
-            SIG_VALTYPE_
+| SJOne - CAN Ground
-            SIGTYPE_VALTYPE_
+|-
-            BO_TX_BU_
+|-
-            BA_DEF_REL_
+! scope="row"| 7
-            BA_REL_
+| CAN Transceiver
-            BA_DEF_DEF_REL_
+| CANL
-            BU_SG_REL_
+| CAN BUS
-            BU_EV_REL_
+| CANL
-            BU_BO_REL_
+| CANL to CAN BUS
-            SG_MUL_VAL_
+|-
- BS_:
+|-
- BU_: NOONE SENSOR DRIVER MOTORIO BLUETOOTH GEO
+! scope="row"| 8
- BO_ 0 DRIVER_KILL_SWITCH: 0 DRIVER
+| CAN Transceiver
-  SG_ DRIVER_KILL_SWITCH_cmd 		: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
+| CANR
- BO_ 1 DRIVER_RESET: 0 DRIVER
+| CAN BUS
-  SG_ DRIVER_RESET_cmd 				: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
+| CANR
- BO_ 2 DRIVER_SYNC_ACK: 0 DRIVER
+| CANR to CAN BUS
-  SG_ DRIVER_SYNC_ACK_cmd 			: 0|0@1+ (1,0) [0|0] "" SENSOR,MOTORIO,BLUETOOTH,GEO
+|-
- BO_ 3 MOTORIO_SYNC: 0 MOTORIO
+|}
-  SG_ MOTORIO_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 4 SENSOR_SYNC: 0 SENSOR
-  SG_ SENSOR_SYNC_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 5 BLUETOOTH_SYNC: 0 BLUETOOTH
-  SG_ BLUETOOTH_SYNC_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 6 GEO_SYNC: 0 GEO
-  SG_ GEO_SYNC_cmd 					: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 7 MOTORIO_HEARTBEAT: 0 MOTORIO
-  SG_ MOTORIO_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 8 SENSOR_HEARTBEAT: 0 SENSOR
-  SG_ SENSOR_HEARTBEAT_cmd 			: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 9 BLUETOOTH_HEARTBEAT: 0 BLUETOOTH
-  SG_ BLUETOOTH_HEARTBEAT_cmd 		: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 10 GEO_HEARTBEAT: 0 GEO
-  SG_ GEO_HEARTBEAT_cmd 				: 0|0@1+ (1,0) [0|0] "" DRIVER
- BO_ 11 MOTORIO_RUNMODE: 1 DRIVER
-  SG_ MOTORIO_RUNMODE_cmd 			: 0|8@1+ (1,0) [0|3] "" MOTORIO
- BO_ 12 SENSOR_SONARS: 6 SENSOR
-  SG_ SENSOR_SONARS_front_left 		: 0|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  SG_ SENSOR_SONARS_front_right 		: 8|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  SG_ SENSOR_SONARS_front_center 	: 16|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  SG_ SENSOR_SONARS_left 			: 24|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  SG_ SENSOR_SONARS_right 			: 32|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
-  SG_ SENSOR_SONARS_back 			: 40|8@1+ (1,0) [0|4] "" DRIVER,MOTORIO
- BO_ 13 MOTORIO_DIRECTION: 2 DRIVER
-  SG_ MOTORIO_DIRECTION_speed_cmd 	: 0|8@1+ (1,0) [0|4] "" MOTORIO
-  SG_ MOTORIO_DIRECTION_turn_cmd 	: 8|8@1+ (1,0) [0|5] "" MOTORIO
- BO_ 14 DRIVER_CHECKPOINT_REQ: 1 DRIVER
-  SG_ DRIVER_CHECKPOINT_REQ_cmd 		: 0|8@1+ (1,0) [0|3] "" BLUETOOTH,MOTORIO
- BO_ 15 BLUETOOTH_CHECKPOINT_SEND: 1 BLUETOOTH
-  SG_ BLUETOOTH_CHECKPOINT_SEND_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO
- BO_ 16 BLUETOOTH_CHECKPOINT_DATA: 1 BLUETOOTH
-  SG_ BLUETOOTH_CHECKPOINT_DATA_cmd 	: 0|8@1+ (1,0) [0|3] "" DRIVER,MOTORIO
- BO_ 17 DRIVER_LOC_UPDATE: 8 DRIVER
-  SG_ DRIVER_LOC_UPDATE_LAT_cmd 		: 0|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
-  SG_ DRIVER_LOC_UPDATE_LONG_cmd 	: 32|32@1+ (0.0001,0) [0|0] "" GEO,MOTORIO
- BO_ 18 GEO_SPEED_ANGLE: 5 GEO
-  SG_ GEO_SPEED_cmd 					: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTORIO
-  SG_ GEO_ANGLE_heading_cmd 			: 8|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
-  SG_ GEO_ANGLE_bearing_cmd 			: 24|16@1+ (1,0) [0|0] "" DRIVER,MOTORIO
- BO_ 19 GEO_LOC_DATA: 8 GEO
-  SG_ GEO_LOC_LAT_cmd 				: 0|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
-  SG_ GEO_LOC_LONG_cmd 				: 32|32@1+ (0.0001,0) [0|0] "" DRIVER,MOTORIO
- BO_ 20 SENSOR_LIGHT_BAT: 2 SENSOR
-  SG_ SENSOR_LIGHT_cmd 				: 0|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO
-  SG_ SENSOR_BAT_cmd 				: 8|8@1+ (1,0) [0|1] "" DRIVER,MOTORIO
- CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one";
+==== Control Flow ====
- CM_ BU_ DRIVER "The driver controller driving the car";
+On boot-up, Master Controller first attempts to sync with all the other controllers through a power-up sync and acknowledgement handshake mechanism. Once sync is established with all the controllers, it periodically monitors the heart-beat signals from all the controllers till the end of power cycle. If any controller goes out of sync, the master requests that controller to reset itself.
- CM_ BU_ SENSOR "The sensor controller of the car";
- CM_ BU_ MOTORIO "The motor_io controller of the car";
+The Master Controller now enters the ‘stopped’ state where no driving takes place. It continuously monitors the CAN bus for any routes from the Bluetooth Controller. Once all the navigation check points have been received, the Master Controller starts driving the car by directing the Motor Controller based on the Geo controller data. While driving, the Master Controller continuously listens for the obstacle data from the Sensor Controller and avoids any obstacles, if necessary. Once obstacle avoidance has been completed, Master makes any necessary course corrections and proceeds towards the destination as per the route.
- CM_ BU_ BLUETOOTH "The bluetooth controller of the car";
- CM_ BU_ GEO "The geo controller of the car";
+The flowchart depicts the entire sequence of events involved in driving the car from a source to destination point.
- CM_ BO_ 2 "Sync message used to synchronize the controllers";
+[[File:F15_243_TG_MasterControlFlow.jpg|center|900px|Control Flow of Master Controller]]
+==== Communication between Controllers ====
+===== Power-up Sync and Acknowledgement =====
+Once master boots up, it continuously monitors the CAN bus for a “Power up Sync” message from each of the other controllers. Once it receives the Sync message from all the controllers it acknowledges all of them at once by sending the “Master Sync Ack” message. This should prompt the other controllers to spawn their periodic tasks and start their respective functionalities.
+===== Heart Beat Implementation =====
+After sending the ACK message the master proceeds to spawn its own periodic scheduler and starts monitoring the heartbeat signals from all the controllers at a rate of 1Hz.
+Every 1Hz, all the controllers are expected to send their respective “Heart-beat” message over the CAN bus. If this message fails to arrive, the master controller will wait for a specific period of time for the other controller to sync again. The sensor controller and motorIO controllers are very critical components for driving the car. So, they are not allowed to skip any heart-beats. The other controllers have varying thresholds of wait time, allowing them to sync with the master again. Once the threshold time is crossed, the master controller issues a “Reset” message for the controller that went out of sync. The receiving controller is expected to reset and sync again at this point.
- BA_DEF_  "BusType" STRING ;
+If the sensor controller or motor controller go out of sync, the master stops issuing driving directions to the motorIO controller, hence stopping the car.
- BA_DEF_ SG_ "FieldType" STRING ;
- BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
-  BA_DEF_DEF_ "BusType" "CAN";
+===== Data Communication =====
-  BA_DEF_DEF_ "FieldType" "";
+The master controller performs the following data transactions over the CAN bus.
+Bluetooth controller signals to the master controller that a new route has been requested from the Android application through “Check-Point Send” message. In this message, the Bluetooth controller also specifies the number of check-points that are present along the route. The master acknowledges this signal through “Check-point Request” message. The Bluetooth controller starts sending the check-points periodically, at 10Hz, after it receives the ack. The master stores all these check-points in an array and switches to navigation mode.
+In navigation mode, master controller issues the next immediate check-point to the Geo controller through “Geo location update” message and expects the current heading, current bearing, current speed and current GPS location information from the Geo controller with respect to this new checkpoint. Master controller continuously calculates the distance between the current GPS location and the current checkpoint location to determine if the checkpoint has been reached. Once reached, the next checkpoint co-ordinates are issued to the Geo controller. This cycle is repeated till the destination has been reached.
+All through the navigation mode, master controller directs the motor controller to drive (speed and direction to turn) based on heading and bearing information from the Geo controller. The obstacle information is also being continuously received from the sensor controller. If an obstacle is detected, the master controller stops navigating to the checkpoint and avoids the obstacle. Once obstacle has been avoided the master goes back to navigation.
+=== Driving Algorithm ===
+==== Overview ====
+Driving algorithm has two parts to it. One is the obstacle avoidance algorithm and the other is the navigation algorithm. Obstacle avoidance has a higher priority. Navigation algorithm drives the car as long as no obstacles are present.
+==== Obstacle Avoidance Algorithm ====
+The primary obstacle avoidance algorithm is based on the front three sensors. The algorithm is based on the truth table below. The near obstacles have higher priority than obstacles in the mid range, which has a higher priority than the obstacles in the far range. The tables below depict the action taken by the master controller when obstacles are in the near and mid-range. A ‘1’ in the table represents that a particular sensor has an obstacle within the range being evaluated. A ‘0’ represents that a particular sensor has no obstacle within the range being evaluated. The last two columns show the command sent from the master controller to the motorIO controller.
+'''Obstacle avoidance in the Near range'''
+{| class="wikitable"
+|-
+! scope="col"| Front Left Sensor
+! scope="col"| Front Center Sensor
+! scope="col"| Front Right Sensor
+! scope="col"| Motor Speed
+! scope="col"| Motor turn
+|-
+| 0
+| 0
+| 0
+| Normal
+| Straight
+|-
+| 0
+| 0
+| 1
+| Slow
+| Hard Left
+|-
+| 0
+| 1
+| 0
+| Stop
+| Straight
+|-
+| 0
+| 1
+| 1
+| Slow
+| Hard Left
+|-
+| 1
+| 0
+| 0
+| Slow
+| Hard Right
+|-
+| 1
+| 0
+| 1
+| Stop
+| Straight
+|-
+| 1
+| 1
+| 0
+| Slow
+| Hard Right
+|-
+| 1
+| 1
+| 1
+| Stop
+| Straight
+|-
+|}
+'''Obstacle avoidance in the Mid range'''
+{| class="wikitable"
+|-
+! scope="col"| Front Left Sensor
+! scope="col"| Front Center Sensor
+! scope="col"| Front Right Sensor
+! scope="col"| Motor Speed
+! scope="col"| Motor turn
+|-
+| 0
+| 0
+| 0
+| Normal
+| Straight
+|-
+| 0
+| 0
+| 1
+| Slow
+| Slight Left
+|-
+| 0
+| 1
+| 0
+| Normal
+| Straight
+|-
+| 0
+| 1
+| 1
+| Slow
+| Slight Left
+|-
+| 1
+| 0
+| 0
+| Slow
+| Slight Right
+|-
+| 1
+| 0
+| 1
+| Stop
+| Straight
+|-
+| 1
+| 1
+| 0
+| Slow
+| Hard Right
+|-
+| 1
+| 1
+| 1
+| Stop
+| Straight
+|-
+|}
+==== Navigation Algorithm ====
+As stated before, the Master Controller receives all the necessary parameters for navigation viz, current GPS co-ordinates, heading and bearing from the Geo-Controller. The heading and bearing are angles that are measured from 0 degrees to 360 degrees from the true North. Heading specifies the direction in which the car is currently oriented in. Bearing specifies the direction in which the car has to be oriented so as to reach the next check point. The current navigation algorithm divides the entire 360 degree orientation space of the car into 30 zones of 12 degrees each. The difference between the bearing and heading values is used to correct the direction of the car. This correction value would lie between 0 degrees to 360 degrees, falling into one of the 30 zones. As seen in the diagram, If the correction lies between 0 degrees to 12 degrees, the car should travel straight at normal speed. If the correction lies between 97 degrees to 180 degrees, the car should take a U-turn from the right direction at a slow speed. Similar behaviors of the car in terms of the direction and speed of movement of the car are specified for each zone and are sent as commands to the Motor Controller.
+A few examples to test the correctness of the algorithm are discussed. If the heading is 50 degrees and the bearing is 90 degrees, the correction is 40 degrees. The behavior specified for the zone in which this correction will fall into is for the car to perform a hard right turn at slow speed. Similarly, if the heading is 70 degrees and the bearing is 10 degrees, the correction is -60 degrees. Converting this to a value in between 0 degrees and 360 degrees, we have 300 degrees ( 360 degrees - 60 degrees ). The behavior specified for the zone in which this correction will fall into is for the car to perform a slight left turn at normal speed.
+{|
+|[[File: F15_243_TG_NavigationAlgorithm.jpg|center|700px|Zones used in the Navigation Algorithm]]
+|}
+==== Distance Calculation ====
+The distance is calculated as shown in the figure below.
+{|
+|[[File: F15_243_TG_CalculateDistance.png|center|700px|Code snippet of Distance Calculation]]
+|}
+The master controller continuously monitors the distance of the car from the next checkpoint. We issue the next checkpoint co-ordinate when the distance is less than or equal a threshold value. The current threshold has been set to 3m after performing tests with a range of threshold values.
+=== LED and 7-Segment Display Status ===
+LED 1 - ON or OFF when the START or STOP command is issued from the Bluetooth Controller/Mobile Application.
+LED 2 - Toggles when in Obstacle Avoidance Mode. OFF when in Navigation Mode.
+LED 3 - ON if controller heartbeats are missed. OFF when all controllers are in sync.
+LED 4 - ON when an error in CAN communication occurs. Turns OFF when the Errors are handled.
+-Segment Display - Displays the current checkpoint that the car is navigating to. When the destination is reached, the number '99' is displayed.
+== '''Bluetooth/Bridge Controller''' ==
+'''Team Members:'''
+  Anush Shankar
+ Aditya Devaguptapu
+'''Bluetooth/Bridge Controller Schedule'''
+{| class="wikitable"
+|-
+! scope="col"| SI No.
+! scope="col"| Start Date
+! scope="col"| End Date
+! scope="col"| Task
+! scope="col"| Status
+! scope="col"| Actual Completion Date
+|-
+! scope="row"| 1
+| 09/20/2015
+| 09/30/2015
+| Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API
+| Completed
+| 09/30/2015
+|-
+! scope="row"| 2
+| 09/31/2015
+| 10/10/2015
+|
+*Placement of buttons on the app activity page to switch on and off bluetooth on the phone
+*Marker placement on Google maps for source and destination
+| Completed
+| 10/10/2015
+|-
+! scope="row"| 3
+| 10/10/2015
+| 10/22/2015
+|
+*Creating input and output streams for bluetooth for sending and receiving data
+*Performing straight line routing between source and destination on google maps
+| Completed
+| 10/22/2015
+|-
+! scope="row"| 4
+| 10/22/2015
+| 10/30/2015
+| Interfacing bluetooth module to SJOne board through UART and receive data on SJOne board sent by the bluetooth application
+| Completed
+| 11/05/2015
+|-
+! scope="row"| 5
+| 10/30/2015
+| 11/10/2015
+| Relay commands and CAN messages from SJOne to android application and test correctness of data
+| Completed
+| 11/15/2015
+|-
+! scope="row"| 6
+| 11/10/2015
+| 11/22/2015
+| Performing correct routing between source and destination, have a complete working application, basic testing of application and bridge interface
+| Completed
+| 11/22/2015
+|-
+! scope="row"| 7
+| 11/22/2015
+| 12/15/2015
+| Extensive Testing of application during final phases, modifying code in cooperation with other teams and optimization of android application
+| Completed
+| 12/13/2015
+|-
+|}
+=== Bluetooth Controller ===
+The Bluetooth Controller is responsible to help the RC car navigation by providing it with route information between source and destination as selected on the Android application. It communicates with the Android application over Bluetooth channel to obtain the route and way-point data between two points on the google map. The route and way-point information once received is parsed to get latitude and longitude for all way-points. This information is then communicated to the Master Controller via CAN bus.
+=== HC-06 Bluetooth Module===
+[[File:F15_243_TG_HC-06_module.png|200px|right|thumb|HC-06 Bluetooth Module]]
+The HC-06 is a bluetooth controller with slave only configuration used to communicate to and from a master Bluetooth module. The master Bluetooth module is capable to initiating a connection with other Bluetooth module, while slave is not able to do that. The slave can only communicate with the master module over a connection established by the master. The HC-06 by default is in slave configuration as per factory settings.
+Some of the features of HC-06 which make it apt for the RC car are as follows:
+*Can work at the low voltage (3.1V~4.2V). The current in pairing is in the range of 30～40mA. The current in communication is 8mA.
+*Has a 2.4GHz digital wireless transceiver.
+*Small (27mm×13mm×2mm)
+*Peripherals circuit is simple.
+*Low power consumption
+*Has high-performance wireless transceiver system
+*Low Cost
+=== Bluetooth Controller Hardware Design ===
+[[File:F15_243_Bluetooth_interfacedia.png|620px|centre|thumb|Bluetooth Controller Interface Diagram]]
+==== Bluetooth Controller Pin Connections ====
+{| class="wikitable"
+|-
+! scope="col"| Line Item#
+! scope="col"| Node A Source
+! scope="col"| Node A Pin
+! scope="col"| Node B Source
+! scope="col"| Node B Pin
+! scope="col"| Description
+|-
+! scope="row"| 1
+| Power Supply
+| 3.3V
+| SJOne Board
+| 3V3
+| SJOne Power
+|-
+|-
+! scope="row"| 2
+| Power Supply
+| GND
+| SJOne Board
+| GND
+| SJOne Ground
+|-
+|-
+! scope="row"| 3
+| CAN Transceiver
+| CAN Tx
+| SJOne Board
+| P0.1 (Tx)
+| SJOne - CAN Tx
+|-
+|-
+! scope="row"| 4
+| CAN Transceiver
+| CAN Rx
+| SJOne Board
+| P0.0 (Rx)
+| SJOne - CAN Rx
+|-
+|-
+! scope="row"| 5
+| CAN Transceiver
+| CAN 5V
+| Power Supply
+| 5V
+| SJOne - CAN Power
+|-
+|-
+! scope="row"| 6
+| CAN Transceiver
+| CAN Ground
+| Power Supply
+| GND
+| SJOne - CAN Ground
+|-
+|-
+! scope="row"| 7
+| CAN Transceiver
+| CANL
+| CAN BUS
+| CANL
+| CANL to CAN BUS
+|-
+|-
+! scope="row"| 8
+| CAN Transceiver
+| CANH
+| CAN BUS
+| CANH
+| CANH to CAN BUS
+|-
+|-
+! scope="row"| 9
+| Bluetooth Module
+| TXD
+| SJOne Board
+| RXD3
+| SJOne RX3-  Bluetooth module TXD
+|-
+|-
+! scope="row"| 10
+| Bluetooth Module
+| RXD
+| SJOne Board
+| TXD3
+| SJOne TX3-  Bluetooth module RXD
+|-
+|-
+! scope="row"| 11
+| Bluetooth Module
+| Bluetooth module VCC(3.3V)
+| Power Supply
+| 3.3V
+| Bluetooth module - Power supply 3.3V
+|-
+|-
+! scope="row"| 12
+| Bluetooth Module
+| Bluetooth module GND
+| Power Supply
+| GND
+| Bluetooth module - Power supply GND
+|-
+|}
+==== Control Flow ====
+On boot-up, Bluetooth Controller first attempts to sync with the Master controller through a power-up sync and acknowledgement handshake mechanism. Once sync is established with the Master Controller, the Bluetooth controller periodically sends heart-beat signals to master controller till the end of power cycle. If any Bluetooth controller goes out of sync, the master requests the controller to reset itself.
+Once all initial handshaking procedures are completed and heart beat signal is established, the Bluetooth Controller waits for data from the On board HC-06 Bluetooth module on the UART port. When Bluetooth connection is established between the Android application and the On board HC-06 Bluetooth controller, routing data is sent from the Android app to the SJOne board. The SJOne board receives the data on UART port via interrupts and parses the data to extract 6 point precision floating point values for each way-points latitude and longitude. The way-point latitude and longitude is stored in a array to be sent out on CAN bus.
+Once all way-point data is parsed and ready, the SJOne board first sends out the number of way-points to the master controller and waits for acknowledgement from the master controller. One reception of the acknowledgement from the master and intent to receive the way-point data, the data is sent on the CAN bus periodically till all the data is exhausted.
+==== Communication between Bluetooth and Other Controllers ====
+===== Power-up Sync and Acknowledgement =====
+Once Bluetooth controller boots up, it continuously sends "Power up Sunc" on the CAN bus to the master using "BLUETOOTH_SYNC_ID" can message id. The controller then polls on the sync function to receive an acknowledgement from the master towards "Power on Sync". Once an acknowledgement is received from master with message id "MASTER_SYNC_ACK_ID", the Bluetooth controller starts the FreeRtos scheduler. Only after this will all tasks run on the controller.
+===== Heart Beat Implementation =====
+Once Bluetooth controller starts the scheduler, it starts sending out heart beat messages on can bus directed towards the master controller using message id "BLUETOOTH_HEARTBEAT_ID" every 1 Hz. If the master does not receive heart beat message it asks Bluetooth controller to reset.
+===== Data Communication =====
+The Bluetooth controller performs data transactions over the CAN bus with the master controller and Geographical controller. The Bluetooth controller receives the geo coordinates every 1 hz using "GEO_LOC_DATA_ID" to get current car location and send it to the android application for dynamic location update.
+Bluetooth controller signals to the master controller that a new route has been requested from the Android application through “CHECKPOINT_SEND_ID” message id. In this message, the Bluetooth controller also specifies the number of check-points that are present along the route. The Bluetooth Controller waits on master's acknowledgement through “CHECKPOINT_REQ_ID” message id. The Bluetooth controller starts sending the check-points periodically, at 10Hz, after it receives the ack. Once all the way-points are sent to the master, the Bluetooth Controller goes to listening to UART interrupts for any changes in the route.
+===== Flow Chart=====
+The flow chart for the Bluetooth Controller is as follows:
+[[File:F15_243_TG_flow_chart_bt.png|620px|centre|thumb|Bluetooth Controller Flow Chart]]
+=== Android Application Design ===
+==== Problem Definition ====
+At the end of the day, an autonomous vehicle is built so as to usher in a new era of transport where the user need not be concerned with driving the vehicle. With this basic idea in mind, we can thus define our problem- how does one communicate with an autonomous vehicle to perform the tasks he/she desires? On further contemplation, it could even be argued that we are able to accomplish the task of navigating from source to destination in a normal vehicle because the user is able to manually control the vehicle. We will hence require an interface by means of which we can specify a source and a destination. With the ubiquity of smart phones, it makes perfect sense for us to leverage the availability of the Android platform to make an application that would augment the user’s ability of accomplishing objectives with the autonomous vehicle.
+[[File:CmpE243_F15_AppMockUp.png|250px|thumb|center|upright| A Basic Mock Up of the App based on the Problem Definition]]
+==== Design ====
+The objective of the Android App is to be able to let the user control the car by issuing commands from a smartphone- the most fundamental commands being the ability to issue a source and a destination for the Car to traverse. Providing the car with autonomy ensures that we need to be able to specify location information to the car in a form that it can understand. We will thus use Google’s comprehensive mapping solution to look up places on the map. We shall also use their services to get the best route available between the source and the destination.
+Google’s Android OS is a very popular OS for smartphones. Its proliferation in the smartphone market, very comprehensive documentation and open-source nature make it a natural choice for the platform on top of which the application will be developed. Android Studio is Google’s IDE for developing applications on the Android platform. Their Maps API will be used to implement a Map fragment and to specify travel points while the Directions API works in the background to provide a route from source to direction. The user will be provided with buttons to connect with the car, to issue Start/Stop Commands, to send a route if a travel needs to be performed and to determine the location of the car.
+[[File:Cmpe243_F15_Android_app_design.png|400px|thumb|center|upright| Android application design and sequence of operations]]
+==== Implementation ====
+===== App Template and Using Google Maps within an App =====
+Android Studio comes with some default templates which lets the user have a basic app up and running within no time. The project has  a .java file to program the logic of the app while the user interface can be modified using the .xml(extended markup language) file. The user can test the app using the in-built emulator or by running it on an Android phone.
+To use Maps within your application, you will first have to get a API key on Google’s Developer Console online. This API key lets Google track statistics related to the app usage. If the Map loads when the App starts up, then its a sign that you’ve successfully implemented a Map fragment.
+===== Using Maps and Implementing the Directions API =====
+A Maps Fragment comes with several features that let the user specify input to the App. We use Markers (Pin shaped images) to denote locations on the map. Every Marker on the map has its own latitude and longitude which is a necessary value for calculating a route. We essentially want to calculate a route from a source, which in this case, is the location of our car. The CarLocation Button gets us the location of the Car and places a marker on the map at the location of the Car. The App has a OnClickListener function in the background, waiting for a tap input from the user. This tap places a marker that denotes the destination that the user, or in this case, the car will navigate to. On placing the destination marker, the Directions API calculates a route between the source and the destination based on how the parameters for the API are defined. The Directions API returns intermediate points (with latitudes and longitudes of their own) that form a route between the source and the destination. The Polylines function defined within the map can be used to plot a line that connects these points from the source to the destination.
+{|
+|[[File:CMPE243_F15_AppStep1.png|200px|thumb|left| Application Startup]]
+|[[File:CMPE243_F15_AppStep2.png|200px|thumb|right| Placing a Marker at the Car Location]]
+|[[File:CMPE243_F15_AppStep3.png|200px|thumb|right| Creating a Route from Car Location to the Destination Marker]]
+|[[File:CMPE243_F15_AppStep4.png|200px|thumb|right| Showing intermediate co-ordinates along the route]]
+|}
+===== Using Bluetooth and Bluetooth API =====
+Android provides a robust and well defined Bluetooth API as part of application development support. The API provides functions to query devices, pair with devices, connect to devices and send/receive data. In our application pairing, connection and send/receive API functions are used to talk to HC-06 Bluetooth module on the RC car. The application has a bunch of buttons at the bottom which are used to establish Bluetooth communication and used to control markers on the Google Map. The functionalities of the Buttons are as follows:
+{| class="wikitable"
+|-
+! align="center"|SI No.
+! align="center"|Button
+! align="center"|Functionality
+|-
+| 1
+| ON
+| User is prompted to Turn on Bluetooth device on the phone. User can "allow" or "deny" the request. Application displays message if no bluetooth support on phone.
+|-
+| 2
+| CONNECT
+| Establishes a communication channel with a slave Bluetooth. Connection is done to a Predefined Bluetooth MAC address.
+|-
+| 3
+| DISCONNECT
+| Disconnects communication channel with an already connected Bluetooth module
+|-
+| 4
+| START CAR
+| Sends string 0 over Bluetooth channel to indicate to the SJOne Board start of car.
+|-
+| 5
+| STOP CAR
+| Sends string 0 over Bluetooth channel to indicate to the SJOne Board to kill the car(Wireless Kill switch).
+|-
+| 6
+| CLEAR
+| Clears markers on the Google Map.
+|-
+| 7
+| CAR LOC
+| Places a marker on Google Map based on cars coordinates received from the HC-06 Bluetooth module on-board the car.
+|-
+| 8
+| SEND ROUTE
+| Send route from source to destination selected on map after filtering way-points.
+|-
+|}
+==== Our Modifications ====
+* The number of points returned was filtered to obtain an accurate route with sufficient points, enough to not  overwhelm the SJOne Board during processing.
+* The first point was ignored because it nearly coincides with the location of the car and it made sense for the car to ignore this first point in order to preserve time and power.
+* We also place a limit on the maximum number of points that can appear. For a real world scenario, this limit wouldn’t make sense. However for a tiny RC Car which runs on battery to possess so much information and not be able to navigate through vast paths, it wouldn’t make sense for so much information to be filtered.
+===== Workflow =====
+On starting the app, the user first uses the ON button to switch the phone’s bluetooth On. The next step is to Connect to the Bluetooth module that is present on the RC Car. This is accomplished using the Connect button, which toasts a “Connected” notification once this connection happens. The Start Car Button then polls for the location of the car and places a marker on the map. The User may then tap the map and place the destination marker. Placing the destination marker triggers the Directions API to create a route and plot it from the location of the Car till the Destination Marker. The Send Route button sends the route to the controller on the car which lets the car travel from source to destination.
+== Overall System Optimizations and fail safe conditions ==
+We have taken all fail safe conditions into consideration, so suppose if any controller will not work as desire or will work in very bad way then how our car should respond to that condition?
+* If sensor controller is not working properly and sensor CAN messages are not on bus then master controller will detect that and suddenly after some number of missing counts it will issue stop motor command to motor controller.
+* At motor controller side as we have connected RPM sensor to increase/decrease speed according to actual real time feedback from rotations of wheel, is not working properly or we can consider that RPM sensor is being dead then in that case normal motor algorithm will detect that RPM sensor count is zero only if my motor actually rotates or not. So in that condition our optimized algorithm was detecting if RPM sensor count is zero for continuous 3 seconds then there is something wrong happening with RPM sensor so Motor controller will immediately send stop command to motors.
+* Suppose due to steep slope my motor speed gets increased too fast and then suddenly flat surface is coming then in that condition if we will not optimize our driving algorithm then motor will run away very fast then normal speed, so remove that type of condition we have taken difference of RPM sensor counts in interval of each second. So if that difference is too high then decrease speed at very high factor and speed is too slow then vice and versa. So it is basically like put RPM sensor count difference into PID(Proportional, Integral, Differentiation) algorithm to make out very smooth navigation.
+* If bluetooth controller will be out of range after established connection between bluetooth controller and mobile application then it results into some undesired condition like we will not have any control of car in our hand. So to resolve this problem we were continuously sending some heartbeat commands from bluetooth application to controller in each second of interval after establishing connection. So if bluetooth controller will not get heartbeat command from Android application then it will send motor stop command to master and master will forward that command to Motor controller so we can stop motors immediately.
+* At Geo controller side if GPS is not stabilized its values and still someone has issued navigation command from bluetooth application then Geo controller will give longitude and latitude as zero only so master will know that it's wrong values so master controller will not issue start command to motors.
+* In Geo controller we were not getting just simple reading of compass for heading calculation but we were taking reading of yaw angle from gyrometer in reference of magnetic axis of earth with subtracting necessary pitch of car with Kalman filter implementation. So we were getting very smooth and exact angle in any condition like if car navigates on any type of slope(up/down).
+== Testing & Technical Challenges ==
+=== Issue #1 (Motor I/O) ===
+The Motor I/O controller is the only controller which accepts all the CAN messages sent on the bus. This is because the LCD needs to print values from the different controllers like Sensor controller, Master controller and Geo controller. It was decided mutually to use the CAN transmit receive function on the bus at same speed, which was 100 Hz. As our controller had to receive more than one frame in one cycle of 10 ms, the hardware CAN receive queue kept on enlarging. We were dequeueing at a slower speed than what was required. So, the rate at which the data was read by the software was not fast enough when compared to the hardware buffering the data. This slowed down our operation. So, a tip for the future - always make sure that you receive the CAN data frame at the same speed as the transmitter's and dequeue your CAN receive queue completely so as to make sure you are getting all the latest data. Also, make sure to remove all the debug prints in the periodic scheduler running at 100 HZ frequency or more. We could put Telemetry to good use here.
+=== Issue #2 (Project Hardware) ===
+We decided to establish CAN communication across different controllers at an early stage in the project. In order to do so, we rushed into soldering the CAN bus on the PCB. At a later stage, we realized that we had done this in a compact manner. And now, arranging all the LPCs together with the jumper wires connecting to the CAN bus made it hard to debug issues. We had to re-arrange the whole hardware, strictly according to the soldered CAN bus which made the task a little inconvenient. Lesson learnt here was that, when it comes to hardware, always discuss with your teammates about all the aspects of arranging your car and keep some space for future use.
+=== Issue #3 (Project Hardware) ===
+Perhaps the most common problem for all the groups, the car crashed in almost every run during the initial testing phases. Even if you think your code is perfect and your car will do exactly what you think it should, it will crash for sure at start and may wreck something here or there (Trying to save your car and not disappoint you!). Install a kill switch at the earliest that will instantly stop the car whenever you want. At least implement a kill button in your Mobile App. Also, try to cover the front of your car with multiple layers of cardboard, thermocol or sponge material which will help the car to absorb the shock.
+=== Issue #4 (Geo controller software) ===
+* Geo controller was crashing randomly. After careful observation, we figured that the problem was happening because of too many log messages written to SPI flash. The memory was full with log errors. Clearing flash and removing unnecessary logging from the code helped solve the problem.
+* While initially testing IMU in raw data mode, the module was providing improper data values. We had to calibrate the Gyrometer and Magnetometer to get exact angles with precision of +/- 2 degrees. Even after this, the magnetometer's readings were changing when any soft/hard iron object was taken near the sensor. In order to remove electromagnetic interference generated from DC motor, we had to place our IMU far from DC Motor.
+* To ensure that the data values provided by the IMU were accurate, we calibrated IMU sensors with the help of calibration Software provided by manufacturer.
+* Sometimes the string received from GPS module contains void data. To get rid of this invalid data, we started using UART interrupts and receiving all data at once. This is later sent to the GPS task via a Queue. Here, the GPS tasks validates the data and sets GPS structure to NULL in case data is invalid.
+* In the beginning, we were not using the volatile keyword due to which, there was no update in the string we read from Queue in the GPS task. By using volatile keyword on the variable used inside the Interrupt handler, we avoided the compiler optimization.
+=== Issue #5 (Motor Controller software) ===
+* While initializing ESC(Electronic Speed Controller), we didn't know the exact sequence to be sent for initialization of DC motor. We tried to figure out the required sequences by using an Oscilloscope. We used this to hack the ESC for the pulse width and frequency, the DC motor parameters used to drive the car in Forward and Reverse direction. We figured out the initialization sequence by trial and error.
+* The main point was to give at least a 20ms(miliseconds) time delay to send each pulse. Otherwise, if we send pulses less than 20ms, the pwm pulse value will not be set properly as DC pwm's frequency itself was 20ms(Frequency - 50Hz).
+* We had issues driving the DC motor. The ESC would receive the PWM values that we were setting and drive for a short period of time. Then the motor would stall. We had individual PWM objects for DC and Servo motors. There was no way for us to initialize this object in one place and use it in other places. Declaring global or static object of this class did not help. It was being destroyed at some point. Making the PWM class instance as a singleton solved this issue. The lesson here is, PWM generator is a hardware resource available for us and should be initialized only once before being utilized. Singleton classes provide the necessary means to accomplish the same. Moreover, singleton also forces the existence of only one instance of the class just like how there is just one instance of the hardware resource on board.
+=== Issue #6 (Sensors using Interrupt on the 4-pin sensor's Echo pin) ===
+==== Sequential Pinging ====
+*Initially, we tested the code for front, right and left 4-pin ping sensors. We got satisfactory readings for all the 3 sensors. However, the distance value measured were unusually large at some angles. We concluded that at some point, the echo pin was not reaching the low edge while we were triggering the next sensor. This was affecting the distance value calculated. We solved this issue by checking for the logic level of the echo pin, and proceed with further triggering only when the echo pin was low.
+*Once this was resolved, the obtained output readings matched the expected output readings. All the zones and distance values were a match for the obstacle provided for the sensors.
+==== Inline resistors ====
+*The testing was a success on the breadboard. When we loaded the code onto the sensor controller on the car, the readings were inaccurate. We realized, on the breadboard we tested using inline resistors between the echo pin of the sensor and the GPIO pin(set as input pin to the board) of the SJOne board. Once we introduced the inline resistors while testing on the sensor controller, we obtained accurate readings. Thus, we solved the issue of inaccurate readings and unresponsive input to the board by introducing the 1K inline resistors for each echo pin of the three sensors. If you plan to work with the ping sensors, do us the inline resistors as it was very obvious with the readings we experienced, inline resistors made a huge difference.
+=== Issue #7 (Sensors using Interrupt on the 3-pin sensor's Echo pin) ===
+* Once the interrupt algorithm worked for 4-pin sensors, we implemented the same algorithm for 3-pin sensors with changes in the configuration of input and output pins. We tested for a single 3-pin sensor and obtained readings were accurate. Later we introduced the second sensor for testing the algorithm. This created an issue. The front sensor was being triggered and the same pin was configured as echo pin. Reading was obtained on the echo pin of the front sensor. In the next cycle, the index was incremented to the next sensor. The algorithm was stuck on the second sensor triggered. Each time the function was called from the periodic callback the index did not increment as required by the algorithm. We suspected the echo pin of second sensor was not going low at the required time, which would increment the index according to the algorithm. We could not debug this issue in time for demo. We hope to debug the issue and get the algorithm running for 3-pin sensors too.
+== Conclusion ==
+Altogether, we really enjoyed this class and working on this project. We faced many difficulties throughout the semester including understanding the requirements for the project, planning and executing it. But each time we faced a problem, we got to learn something new. All of us were stuck at our individual tasks at some point or the other, but we helped each other and finally made our project up and running. Not to mention, Preet was always easily approachable.
-  BA_ "GenMsgCycleTime" BO_ 7 	          1;
+The project functioned as intended by our design.
- BA_ "GenMsgCycleTime" BO_ 8 	          1;
+-> Sending a source, a destination and checkpoints between them, from Android app to the Bluetooth controller
- BA_ "GenMsgCycleTime" BO_ 9 	          1;
+-> Sending these co-ordinates to the Geo controller through CAN bus
- BA_ "GenMsgCycleTime" BO_ 10              1;
+-> Calculating heading and bearing at Geo and sending those values back to Master Controller
- BA_ "GenMsgCycleTime" BO_ 11 	          1;
+-> Sensor controller sending its readings from sensors to Master Controller
- BA_ "GenMsgCycleTime" BO_ 12              10;
+-> Directing the Motor I/O Controller based on the Obstacle Avoidance and Navigation algorithms
- BA_ "GenMsgCycleTime" BO_ 13              10;
+-> Motor I/O controller driving the car and displaying car parameters on LCD for debugging.
- BA_ "GenMsgCycleTime" BO_ 17              10;
- BA_ "GenMsgCycleTime" BO_ 18              10;
- BA_ "GenMsgCycleTime" BO_ 19              10;
-*Let's understand the above DBC file. The line which contains BU_:... tells the python parser that the user has five nodes in the CAN implementation. In the TopGun project, we have total five nodes -> SENSOR, DRIVER(master), MOTOR, BLUETOOTH, GEO.
+Don't spend too much time in heartbeat and power synchronization implementation as that is not actually required to run your car successfully, as in our project as well, we have implemented that thing but still there is no need to implement so better to start your project without heartbeat and power synchronization and spend more time on preciseness of obstacle avoidance and navigation algorithm.    Choose Distance sensor, IMU and GPS sensor very wisely because a central point of this project is exactness of these 3 sensors and reliable CAN bus communication. If you want to really maintain real Automobile programming standards then try to follow MISRA-C/C++ standard. Some tasks were very tough to debug. But if you really put your mind into it, you will be able to see the solution right in front of you. One final tip - Do not get frustrated, There is not a single thing like "MAGIC"! Always have a bigger picture in mind! We have uploaded everything regarding this project on this page. We honestly appreciate your interest in reading it. Thank you and best of luck!
-*The second important thing in the DBC file is the lines starting from BO_ message_id. These lines define the different message ids for the CAN implementation of the TopGun project. Here, the project includes total 20 message ids. So, The DBC file contains separate BO_ message_id line for each and every message id. Now, let's see what these lines are indicating to the python parser. What the BO_ line contains is given below:
-** BO_ 4 SENSOR_SYNC: 0 SENSOR --> BO_ "message_id" "message_id_name" "number_of_bytes_transmitted_on_CANbus" "transmitter_node"
-*Now, there are lines which start from SG_. The format of the line contains SG_ is given below. It will contain the variable name that we want to marshal and unmarshal for the CAN bus message data. It also contains the size of that variable and from where it is placed in the 8 bytes of total data. This line will also decide the range of the value held by this variable. User needs to define this max and mim range according to the application. If it is [0|0], then the the parser will consider this as a default and will give the maximum and minimum value of that variable according to its size and the sign information of the variable.  Information in the (1,0) will define the multiplier of the value of the variable which in this case is 1. The second value of this bracket is 0 which indicates the offset for the value of the variable.
-* Execute the following commands in the command line argument to generate the API for the motor controller node.
-** $python dbc_parse.py -i TopGun_12_38am_11_16_2015.dbc -s MOTORIO > generated_code_MOTORIO.c
-*The above command will generate the code for the generated_code_MOTORIO.c file
-Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
-Make a smooth transition to testing section and described what it took to test your project.
-== Testing & Technical Challenges ==
-Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
-Make a smooth transition to testing section and described what it took to test your project.
-Include sub-sections that list out a problem and solution, such as:
-=== My Issue #1 ===
-Discuss the issue and resolution.
-== Conclusion ==
-Conclude your project here.  You can recap your testing and problems.  You should address the "so what" part here to indicate what you ultimately learnt from this project.  How has this project increased your knowledge?
 === Project Video ===
-Upload a video of your project and post the link here.
+*[https://www.youtube.com/watch?v=vd2cP3UfQ88 CmpE 243 F15 The Titans - Self Driving RC Car Project]
 === Project Source Code ===
-*  [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]
 *  [https://gitlab.com/hemanthkn/Cmpe240_autonomous_car_Fall15/ Gitlab Source Code Link]
 == References ==
 === Acknowledgement ===
-Any acknowledgement that you may wish to provide can be included here.
+We would like to thank Preet for teaching the concepts in a very practical sense in the class. It really helped us in the implementation and the testing of the project. We would also like to thank Rutwik who was always ready to help and who also gave us many ideas of what we can do in the project. All the team members worked really hard towards this project and this motivated us in accomplishing the team goals every week. All in all, a great course which required us not to memorize, but to think in a practical way. Thanks again Preet to introduce this course to the major. This will surely be a major benefit in building our career!
 === References Used ===
-List any references used in project.
-=== Appendix ===
+ [1] Preetpal Kang's lecture notes of CMPE 243, Computer Engineering, San Jose State University, Aug-Dec 2015.
-You can list the references you used.
+ [2] [http://www.socialledge.com/sjsu/index.php?title=Realtime_OS_on_Embedded_Systems#Fall_2014 Fall 2014 Wiki Projects]
+ [3] [https://www.keil.com/dd/chip/4871.htm LPC1758 User Manual]
+ [4] [https://www.parallax.com/product/28015 Parallax Ultrasonic Sensor]
+ [5] [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405 CAN Transceiver]
+ [6] [https://www.sparkfun.com/products/10736 Razor IMU]
+ [7] [https://github.com/ptrbrtz/razor-9dof-ahrs/wiki/Tutorial Razor IMU Tutorial]
+ [8] [https://www.adafruit.com/products/746 Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3]
+ [9] [http://gis.stackexchange.com/questions/29605/distance-calculation-integrating-incremental-gps-data GPS data calculation accuracy]
+ [10] [http://www.csgnetwork.com/gpsdistcalc.html GPS Longitude Latitude distance calculator]
+ [11] [http://stackoverflow.com/questions/365826/calculate-distance-between-2-gps-coordinates Calculate distance between two points]

Difference between revisions of "F15: TopGun"

Latest revision as of 04:57, 22 December 2016

Contents

TopGun Self Driving Car

Abstract

Objectives & Introduction

Team Members & Responsibilities

Five Controllers Used

Schedule

Parts List & Cost

DBC File Implementation

CAN Message ID Table

Sensor Controller

Sensor Testing

Simple Sensor ping operation

HCSR04 Sensor Testing

Parallax Ping Sensor Testing

Finalizing distance sensors

Software timer for repetitive pulse and Hardware timer for calculating pulse width

Sequentially Triggering of Sensors

Limiting the Scope to Improve Frequency

Misfiring of Sensor

Sensor Software Design

Sensor Controller Team Software Design

Tasks

Sensor Zones

Sensor Pin Connections

Sensor Implementation Using Interrupts

Implementation of 4-pin Sensors With Interrupt

Interrupt On The Echo Pin

Design Flow

Sensor Implementation with Interrupts Pin Connections

Implementation 3-pin Sensors With Interrupt

Design flow

Geographical Controller

Geographical Controller H/W Design

Geographical Controller Hardware Design Components

Geographical Controller H/W Interface

Geographical Controller S/W Design

Motor I/O Controller

Motor/IO Controller Software Design

Tasks

DC Motor

Servo Motor

I/O Software Design

Different screens on LCD

The LCD Software

Master Controller

Design

Hardware Design

Pin Connections

Control Flow

Communication between Controllers

Power-up Sync and Acknowledgement

Heart Beat Implementation

Data Communication

Driving Algorithm

Overview

Obstacle Avoidance Algorithm

Navigation Algorithm

Distance Calculation

LED and 7-Segment Display Status

Bluetooth/Bridge Controller

Bluetooth Controller

HC-06 Bluetooth Module

Bluetooth Controller Hardware Design

Bluetooth Controller Pin Connections

Control Flow

Communication between Bluetooth and Other Controllers

Power-up Sync and Acknowledgement

Heart Beat Implementation

Data Communication

Flow Chart

Android Application Design

Problem Definition

Design

Implementation

App Template and Using Google Maps within an App

Using Maps and Implementing the Directions API

Using Bluetooth and Bluetooth API