Difference between revisions of "F16: AutoNav"

Latest revision as of 19:18, 22 December 2016

1 Project Title
- 1.1 AutoNav - The Autonomous RC Car
2 Abstract
3 Objectives & Introduction
4 Team Members & Responsibilities
5 Schedule
6 Parts List & Cost
7 DBC File Implementation
8 Design & Implementation
- 8.1 Description
- 8.2 CAN BUS
9 Sensor Controller
10 Motor & I/O Controller
11 Bluetooth and Bridge(Android) Connections
12 Geographical Controller
13 Master Controller
14 Testing & Technical Challenges
15 Conclusion
- 15.1 Project Video
- 15.2 GitLab Source Code
16 References
- 16.1 Acknowledgement
- 16.2 References Used

Project Title

AutoNav - The Autonomous RC Car

AutoNav RC Car(Controller View)

AutoNav RC Car(Sensor View)

Abstract

This project report describes an attempt to develop an autonomous RC car which navigates from a source point to destination avoiding any obstacles in between. The project was divided into five modules namely Motor & Input/output Controller, Sensor Controller, Geo Controller, Communication Bridge & Android Controller and Master Controller, each performing specific set of tasks. Each of the five modules were established using SJOne Boards. Communication between all the five modules was established using CAN Bus.

Motor & I/O Controller - This controller was responsible for driving Brushless DC Motor interfaced through ESC, driving the stepper motor for steering and displaying the status of the RC car (speed, obstacle distance etc.) on the LCD.
Sensor Controller - This controller was responsible for obstacle detection and avoidance, interfacing done with Ultrasonic Ping Sensors.
Geo Controller - This controller focused on providing orientation (heading and bearing) and navigation route to the car.
Communication Bridge & Android Controller - Co-ordinates for navigation were provided by this controller using an android application. Communication was established via Bluetooth.
Master Controller - This controller was responsible for collecting the data from all the controllers, develop and implement obstacle avoidance algorithm to guide the car towards the final destination.

Objectives & Introduction

The main objectives of this project include:

To develop an autonomous RC Car.
To navigate from a set source to destination.
To avoid any obstacles in between.
To establish all communication between controllers via CAN bus.

The following peripherals of LPC 1758 were used to establish communications:

CAN Peripheral: Communicate between all the controllers on a common CAN bus.
UART Peripheral: Communicate between GEO Controller and GPS module, Bluetooth controller and Bluetooth module.
GPIO: Communicate between sensors and sensor controller.
PWM: Vary the speed of Brushless DC motor and Stepper motor via ESC interfaced through Motor Controller.

The block diagram below gives an overview of the various peripherals used:

Peripheral block diagram

Team Members & Responsibilities

Sensor Controller:

Vishwanath Balakuntla Ramesh

Motor & I/O Controller:

Sameer Saran
Jaswanth Bhimanapalli

Bluetooth (Communication Bridge) & Android Controller:

Sucharitha
Karthikeya Rao G V

Geographical Controller:

Arpita Ramanath
Veena Manasa Kanakamalla

Master Controller:

Ajai Krishna Velayutham
Goutam Madhukeshwar Hegde

Schedule

Consolidated Team Schedule

SI No.	Start Date	End Date	Task	Status	Actual Completion Date
1	09/13/2016	09/27/2016	Motor - Research and order RC car and additional batteries Sensor - Researching and understanding various sensor requirements for a self driving vehicle. Shortlisting the sensors suitable for our application. GPS - Research and order GPS and Compass module. Bluetooth - Learning and Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API. *Master - Understanding the working of CAN Communication and research on obstacle avoidance and navigational algorithm.	Completed	09/26/2016
2	09/27/2016	10/11/2016	Motor - Understand and implement PWM concepts to drive brushless DC motor and servo motor of the RC car. Set PWM frequency range for varying duty cycle. Sensor - Reading datasheets of shortlisted sensors, Understand pros and cons of each sensor. Make an Order. GPS - Get familiar with data sheets of both modules. Identify relevant pins and understand the module schematics (GPS and IMU). Bluetooth - Buttons and text insertion on the app. Ex: switch on and off Bluetooth, getting longitude latitude values on the phone Placement of route markers on Google maps between source and destination. *Master - Developing the required control messages to be used in CAN Bus for communication between different controllers.	Completed	10/11/2016
3	10/12/2016	10/18/2016	Motor - Interfacing Brushless DC Motor & Servo Motors to SJ one board - implement duty cycles using provided PWM library. Use terminal commands to test basic functionality like drive straight, turn left or right. Sensor - Write sample code for sensors and experiment with sensor output(filtering). GPS - Interface GPS and Compass modules to SJOne board using UART. Test functionality of each module. Bluetooth - Establishment of communication between Bluetooth and the phone application by sending and receiving the values Routing markers display on google maps for a straight line between source and destination. *Master - Establishing CAN communication between master controller, sensor controller and Bluetooth controller with addition of handling MIA in all the controllers.	Completed	10/20/2016
4	10/19/2016	10/30/2016	Motor - Implement CAN bus communication - setup CAN Msg ID acceptance filters, integration with sensor data and Master Controller.Develop basic obstacle avoidance algorithm. Testing of obstacle avoidance algorithm in real time. Sensor - DBC file implementation to establish CAN communication with Master controller. Collaborate with Motor I/O team to achieve basic obstacle avoidance. GPS - Calibrate GPS and Compass modules. Write code to parse raw Compass and GPS readings. Test calibration of the modules. Bluetooth - Interfacing Bluetooth module to SJ One board through UART and sending and receiving data between them. *Master - Master Controller should acquire obstacle range sensor data from sensor controller, control commands from Bluetooth controller.	Completed	11/01/2016
5	10/31/2016	11/08/2016	Motor - LCD interfacing to display messages from required controllers. DBC File Implementation and integrating data structures generated from auto gen code. Sensor - Identify and implement a mechanism to avoid sensors from interfering with each other. Add multiple sensors to the car and work on synchronization between them to achieve more precise obstacle avoidance. GPS - Establish CAN communication from Geo controller to Master controller. Send CAN messages of latitude, longitude, heading and bearing from Geo controller to master to set destination. Bluetooth - Receive commands from SJ One to android application and test if right data is being sent. *Master - Master controller should send directional control messages to motor controller to control the car to its desired path. Implement and test a simple obstacle avoidance algorithm on to the Master controller.	Completed	11/12/2016
6	11/09/2016	11/27/2016	Motor - RPM sensor interfacing to develop Motor Feedback Control loop. Up/down hill driving testing in real world. Sensor- Design and implement the circuit and software for Car's battery voltage monitoring and determining the State of charge(SOC). Design and implement the software to read light sensor values and Tilt (angle of the car) sensor values. GPS - Test destination setting, navigation and synchronization with Master controller and Android app. Bluetooth - Testing the routing path and the basic testing of the application. *Master - Master controller has to acquire coordinates from Geo controller to be used for navigational algorithm. Also get heading, bearing and speed information from Geo-controller.	Completed	11/29/2016
7	11/27/2016	12/15/2016	Motor - Integration with RC Car controllers as one system. Testing, debugging and optimization. Sensor - Integration testing with Master Controller and other boards. Optimize the code, Finalize the operation (validate correctness) & Documentation. GPS - Integrate Geo controller with the entire system. Test and debug code. Bluetooth - Integration Testing and Final testing after integration of all the modules on the car. *Master - Implement and test navigational algorithm. Integrate navigation and avoidance algorithm and perform final testing.	Completed	12/18/2016

Parts List & Cost

Item#	Part Description	Vendor	Qty	Cost
1	RC Car	RChobby Explosion	1	$190
2	RC Car Battery	Amazon	1	$27.29
3	CAN Transceiver	Texas Instruments	15	Free
4	M-F,F-F,M-M Jumper Wires	Amazon	120	7.97
5	Printed Circuit Boards	Amazon	1	$9.72
6	Ultrasonic Parallax Ping Sensor	Fry's Electronics	3	$98.85
7	9 DOF Razor IMU module	SparkFun	1	$74.95
8	Bluetooth Module	Amazon	1	$9.99
9	GPS Sensor	Adafruit	1	$44.38
10	Black/White line detection sensor - RPM sensor	Amazon	1	$10.10
11	SJOne Boards	From Preet	5	$400
12	LCD	4D systems	1	$111

DBC File Implementation

DBC files are widely used to define the system of CAN messages and their constituent signals. This allows CAN data to be accessed in terms of human-usable signal values, with different data types and scaling, instead of just raw message bytes. Below is the DBC file that we implemented in our project.

VERSION ""

NS_ :
	BA_
	BA_DEF_
	BA_DEF_DEF_
	BA_DEF_DEF_REL_
	BA_DEF_REL_
	BA_DEF_SGTYPE_
	BA_REL_
	BA_SGTYPE_
	BO_TX_BU_
	BU_BO_REL_
	BU_EV_REL_
	BU_SG_REL_
	CAT_
	CAT_DEF_
	CM_
	ENVVAR_DATA_
	EV_DATA_
	FILTER
	NS_DESC_
	SGTYPE_
	SGTYPE_VAL_
	SG_MUL_VAL_
	SIGTYPE_VALTYPE_
	SIG_GROUP_
	SIG_TYPE_REF_
	SIG_VALTYPE_
	VAL_
	VAL_TABLE_
	
BS_:
 
BU_: DRIVER BLUETOOTH SENSOR MOTOR GEO

BO_ 100 KILL_SWITCH: 1 DRIVER
 SG_ killSwitch : 0|1@1+ (1,0) [0|0] "Stop=1" MOTOR

BO_ 110 STOP_CMD: 1 BLUETOOTH
 SG_ BLUETOOTH_STOP_CMD_signal : 0|1@1+ (1,0) [0|0] "Stop=1" DRIVER

BO_ 120 MOTOR_SYNC: 1 MOTOR
 SG_ Motor_Sync : 0|1@1+ (1,0) [0|0] "MotorSync=1" DRIVER

BO_ 130 GEO_SYNC: 1 GEO
 SG_ Geo_sync_cmd : 0|1@1+ (1,0) [0|0] "GeoSync=1" DRIVER
  
BO_ 140 BLUETOOTH_SYNC_CMD: 1 BLUETOOTH
 SG_ BLUETOOTH_SYNC_CMD_signal : 0|1@1+ (1,0) [0|0] "BluetoothSync=1" DRIVER
  
BO_ 150 SENSOR_SYNC: 1 SENSOR
 SG_ Sensor_Sync : 0|1@1+ (1,0) [0|0] "SensorSync=1" DRIVER,MOTOR,BLUETOOTH
 
BO_ 160 ERROR_COMM_DRIVER: 1 DRIVER
 SG_ Sync_Miss_Info : 0|8@1+ (1,0) [0|0] "ErrorMsgType" MOTOR
 
BO_ 170 DRIVER_SYNC_ACK: 1 DRIVER
 SG_ Sync_Miss_Info : 0|1@1+ (1,0) [0|0] "DriverSync=1" MOTOR,BLUETOOTH,SENSOR,GEO
 
BO_ 180 MOTOR_CONTROL: 2 DRIVER
 SG_ steer : 0|8@1+ (1,0) [0|0] "DirectionType" MOTOR    
 SG_ speed : 8|8@1+ (1,0) [0|0] "SpeedType" MOTOR  
  
BO_ 181 MOTOR_RPS: 2 MOTOR
 SG_ Rps_Sensor : 0|8@1+ (1,0) [0|0] "RotationsPerSecondENum" DRIVER,BLUETOOTH
 SG_ Rps_Value : 8|8@1+ (1,0) [0|0] "RotationsPerSecondValue" BLUETOOTH,DRIVER

BO_ 190 SENSOR_SONAR: 5 SENSOR
 SG_ Sensor_Sonar_Front : 0|8@1+ (1,0) [0|0] "FrontDistance" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Sonar_FrontRight : 8|8@1+ (1,0) [0|0] "FRightDistance" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Sonar_FrontLeft : 16|8@1+ (1,0) [0|0] "FLeftDistance" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Sonar_Back : 24|8@1+ (1,0) [0|0] "BackDistance" DRIVER,MOTOR,BLUETOOTH
 
BO_ 200 GEO_SEND_LOCATION: 8 GEO
 SG_ Geo_latitude : 0|32@1+ (0.000001,-90.000000) [-90|90] "latitude" DRIVER,BLUETOOTH,MOTOR
 SG_ Geo_longitude : 32|32@1+ (0.000001,-180.000000) [-180|180] "longitude" DRIVER,BLUETOOTH,MOTOR

BO_ 210 GEO_SEND_HD_BR: 8 GEO
 SG_ Geo_heading : 0|29@1+ (0.000001,0) [0|360] "" DRIVER,MOTOR
 SG_ Geo_bearing : 29|29@1+ (0.000001,0) [0|360] "" DRIVER,MOTOR

BO_ 220 NAVIGATION_WAYPOINT: 2 BLUETOOTH
 SG_ Bluetooth_CurrWaypoint : 0|5@1+ (1,0) [0|0] "CurrentWaypointNumber" DRIVER,GEO
 SG_ Bluetooth_NumWaypoint : 5|5@1+ (1,0) [0|0] "NumberOfWaypoints" DRIVER,GEO

BO_ 250 LATITUDE_LONGITUDE: 8 BLUETOOTH
 SG_ Bluetooth_latitude : 0|32@1+ (0.000001,-90.000000) [-90|90] "latitude" DRIVER,GEO
 SG_ Bluetooth_longitude : 32|32@1+ (0.000001,-180.000000) [-180|180] "longitude" DRIVER,GEO

BO_ 230 START_CMD: 1 BLUETOOTH
 SG_ BLUETOOTH_START_CMD_signal : 0|8@1+ (1,0) [0|0] "" DRIVER
 
BO_ 240 SENSOR_BATTERY: 8 SENSOR 
 SG_ Sensor_Battery_Voltage : 0|8@1+ (0.1,0) [0|0] "Volts" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Battery_SOC : 8|10@1+ (0.1,0) [0|0] "Percent" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Light : 18|10@1+ (0.1,0) [0|0] "LightPercentValue" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Tilt_X : 28|12@1+ (0.1,0) [0|0] "TiltValueX" DRIVER,MOTOR,BLUETOOTH
 SG_ Sensor_Tilt_Y : 40|12@1+ (0.1,0) [0|0] "TiltValueY" DRIVER,MOTOR,BLUETOOTH
 
BO_ 500 DRIVER_TEST: 1 DRIVER
 SG_ Driver_Test_Msg : 0|8@1+ (1,0) [0|0] "" MOTOR,GEO,SENSOR,BLUETOOTH

BO_ 600 MOTOR_TEST: 1 MOTOR
 SG_ Motor_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR,BLUETOOTH
 
BO_ 700 SENSOR_TEST: 1 SENSOR
 SG_ Sensor_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GEO,BLUETOOTH
 
BO_ 800 GEO_TEST: 1 GEO
 SG_ Geo_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR,BLUETOOTH
 
BO_ 900 BLUETOOTH_TEST: 1 BLUETOOTH
 SG_ Bluetooth_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GEO,SENSOR
 
CM_ BU_ DRIVER "The DRIVER controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ BLUETOOTH "The bridge controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";

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

BA_DEF_DEF_ "BusType" "CAN";
BA_DEF_DEF_ "FieldType" "";
BA_DEF_DEF_ "GenMsgCycleTime" 0;

BA_ "GenMsgCycleTime" BO_ 500 10;
BA_ "FieldType" SG_ 180 steer "steer";
BA_ "FieldType" SG_ 180 speed "speed";
BA_ "FieldType" SG_ 181 Rps_Sensor "Rps_Sensor";
BA_ "FieldType" SG_ 190 Sensor_Sonar_Front "Sensor_Sonar_Front";
BA_ "FieldType" SG_ 190 Sensor_Sonar_FrontRight "Sensor_Sonar_FrontRight";
BA_ "FieldType" SG_ 190 Sensor_Sonar_FrontLeft "Sensor_Sonar_FrontLeft";
BA_ "FieldType" SG_ 190 Sensor_Sonar_Back "Sensor_Sonar_Back";

VAL_ 190 Sensor_Sonar_Front 3 "far_f" 2 "mid_f" 1 "near_f" 0 "danger_f" ;
VAL_ 190 Sensor_Sonar_FrontRight 2 "far_fr" 1 "mid_fr" 0 "near_fr" ;
VAL_ 190 Sensor_Sonar_FrontLeft 2 "far_fl" 1 "mid_fl" 0 "near_fl" ;
VAL_ 190 Sensor_Sonar_Back 2 "far_b" 1 "mid_b" 0 "near_b" ;
VAL_ 180 steer 4 "right" 3 "sright" 2 "sleft" 1 "left" 0 "straight" ;
VAL_ 180 speed 4 "brake" 3 "reverse" 2 "normal" 1 "slow" 0 "stop" ;
VAL_ 181 Rps_Sensor 2 "high" 1 "equal" 0 "low" ;

Design & Implementation

The flow of data from the beginning is shown by the diagram below.

System Block Diagram

Description

Assuming the car would be given the necessary connections and be powered up to navigate, we would give the first signal to start the car from the Bluetooth device by sending a start signal of "1". Once the Start signal is received by the Master controller, it would receive the signals from the sensors and the GPS as well. Based on the data from all these systems, Master controller decides the command to be given to the Motor controller. Motor on receiving the instructions from the Master would move in a particular direction suggested by Master. Motor would also revert the path in which it is going, RPM values to Master, Bluetooth and LCD display over the CAN. Meanwhile the Bluetooth would be fetching the messages from the CAN and would filter out on the messages by their ID's and later send the required signals such as GPS and RPM values to the Android device, which is displayed to the user in their respective text boxes.

CAN BUS

Below is the screenshot of messages from all five controllers on the CAN Bus, as seen in from a PCAN dongle, while testing the CAR after integration.

CAN BUS

P-CAN Dongle

The PCAN dongle would be connected to RX-480 Port on the CAR and other end to a PC via USB.This would enable the user to view the CAN messages on the CAN Bus in real-time on the computer screen and would largely help to debug errors on all the controllers. BusMaster is the software used to decode the messages on the CAN bus.

Sensor Controller

Team Members:

Vishwanath Balakuntla Ramesh

The sensor controller is one of the main controllers in the car, which enables the obstacle avoidance feature. There are multiple sensors available in the market, which can used to detect obstacles. The sensor controller may use IR sensor, ultrasonic sensors, sonar, lidar etc,. In our case w make use of Parallax ping sensor due to following reasons:

1. Ease of usage: Same pin for Echo and input pulse. 2. High S/N ratio: The signal to noise ratio is too high. The sensor does not abruptly issue any spike in its signal. More reliable and stable.

Hardware Design

We used 3 Parallax Ping ultrasonic distance sensors for obstacle detection and avoidance. Non-contact distance can be measured from about 2 cm (0.8 inches) to 3 meters (3.3 yards).

The PING sensor works by transmitting an ultrasonic burst and providing an output pulse that corresponds to the time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.

Three sensors were placed in front (front_left, front_center, front_right).

Parallax ping sensor

Hardware Interface

Three parallax ping sensors are used (front, left and right). As shown above, in the hardware design of parallax ping sensor, VCC pin of all the three sensors is connected to 5V, GND is connected to ground and SIG of all the three sensors is connected to P2.0, P2.1, and P2.2 of SJ One board.

Parallax Ping Sensor Operation

Software Design

Sensor Fields and Ranges

Sensor Controller Tasks
Task Name	Purpose
Period Init	Enable and initialize LPC timer, Initialize CAN, rising and falling edge of GPIO Interrupt
Periodic 1Hz Callback	Check can bus off
Periodic 10Hz Callback	Get and Send Sensor Data

Sensor_Sonar_Front_E calculate_range_front(double distance)
{
	if(distance>5&&distance<120)
		return danger_f;

	else if(distance<180)
		return near_f;

	else if(distance<250)
		return mid_f;

	else
		return far_f;
}


Sensor_Sonar_FrontRight_E calculate_range_frontRight(double distance)
{
	if(distance<100)
		return near_fr;

	else if(distance<200)
		return mid_fr;

	else
		return far_fr;
}


Sensor_Sonar_FrontLeft_E calculate_range_frontLeft(double distance)
{
	if(distance<100)
		return near_fl;

	else if(distance<200)
		return mid_fl;

	else
		return far_fl;
}


void start_trigger(GPIO trigger)
{
	trigger.setAsOutput();
	trigger.setHigh();
	delay_us(5);
	trigger.setLow();
}

Implementation

Sensor Controller Flow Diagram

Motor & I/O Controller

Team Members:

Sameer Saran
Jaswanth Bhimanapalli

Hardware Design

Block Diagram for Motor

Hardware/Software Interface

I/O Interface - LCD

The LCD is used to display some of the features to its application in our project.The sensor, GPS and current coordinates are displayed on LCD. 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 angulometer. 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 angulometer. 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 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

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

Below are the snaps of the LCD Screens:

LCD Screen 1

LCD Screen 2

LCD Screen 3

LCD Screen 4

LCD Screen 5

LCD Screens Table
Screen No.	Description
1	Welcome Screen
2	Displaying the menu
3	Displaying Sensor data
4	Displaying motor data
5	Displaying data to debug along with GPS data

LCD Flowchart

Motor Control Hardware/Software Interface

Tasks

Motor/IO Controller Tasks
Task Name	Purpose
Period Init	Initializing CAN bus, Motor, Interrupt for Motor Feedback and UART for LCD
Periodic 1Hz Callback	Displaying data on LCD and checking for CAN bus off
Periodic 10Hz Callback	Interpreting data from Master controller, driving car, calculating RPM

|

Motor Control Flowchart

Brushless DC Motor

Our car came with 3650 Brushless inrunner motor, 2080KV with 60A ESC(with Reverse). 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 Control
1	7.5	Stop
2	7.77	Slow
3	7.81	Normal
4	7.30	Reverse
5	5.5	Brake

Table3: DC Motor Duty Cycle v/s Speed Control

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

Motor Feedback

Initially we used to calculate feedback at 1Hz using one magnet and a telemetry sensor and if the current RPM was less than required RPM then we used to switch to the higher hard coded PWM value, But since the DC motor was dependent on the battery's state of charge. We had to redesign the Motor Feedback, we added more magnets so that we get enough data so that we can react at a faster rate of 10Hz. To make the DC motor's speed independent of state of charge and dependent only on RPM we changed the Motors's Algorithm.

Below is the Code snippet of DC Controller

void drive_DC(speed_E speed,int rpm)
{
	if(speed==reverse)
	{
        //Set DC to Reverse PWM Value
	}
	else if (speed==brake)
	{
	//Set DC to Brake PWM Value	
	}
	else if (speed == stop)
	{
	//Set DC to Stop/Idle PWM Value
	}
	else
	{
	        ReqRPM=get_rpm(speed);

		if(DC Value id with in safe range)
		{
			if(rpm>ReqRPM)
			{
			//If current RPM is greater then Required RPM then Reduce Speed
			}
			else if(rpm<ReqRPM)
			{
			//If current RPM is lesser then Required RPM then Increase  Speed
			}

			else if(rpm==ReqRPM)
			{
		        //If current RPM is equal to required RPM the maintain same Speed
			}
		}
	}

}

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	8.5	Hard Left
2	8	Slight Left
3	7.5	Straight
4	6.5	Slight Right
5	6.0	Hard 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

class MotorCtrl : public SingletonTemplate<MotorCtrl>
{
	public:
		MotorCtrl() : steerServo(PWM::pwm1),driveDc(PWM::pwm2)
		{
			//Constructor
		}
		void set_servo(float value) {steerServo.set(value);}
		void set_dc(float value){driveDc.set(value);}
		friend class SingletonTemplate<MotorCtrl>;

	private:
		PWM steerServo;
		PWM driveDc;

};

#define MotorCtrl MotorCtrl::getInstance()

Bluetooth and Bridge(Android) Connections

Team Members:

Sucharitha Sirigreddy
Karthikeya Rao G V

This section includes high level implementation details regarding the Android app connectivity with the Bluetooth module of the RC car. It gives a overview of building the android app, communication between the Bluetooth and Android app on a mobile device, and routing mechanisms during the navigation.

Bluetooth Controller Pin Connections

Node A Source	Node A Pin	Node B Source	Node B Pin	Description
Power Supply	3.3V	SJOne Board	3V3	SJOne Power
Power Supply	GND	SJOne Board	GND	SJOne Ground
CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
Bluetooth Module	TXD	SJOne Board	RXD3	SJOne RX3- Bluetooth module TXD
Bluetooth Module	RXD	SJOne Board	TXD3	SJOne TX3- Bluetooth module RXD
Bluetooth Module	Bluetooth module VCC(3.3V)	Power Supply	3.3V	Bluetooth module - Power supply 3.3V
Bluetooth Module	Bluetooth module GND	Power Supply	GND	Bluetooth module - Power supply GND

Below attached is the image of the Bluetooth Module HC-06.

Bridge Controller Design

Hardware Interface

Below is the representation of the bridge communication.

Bridge Controller Design

Hardware Interface between the Bluetooth controller and the car system has been wired through the CAN bus. P0.1 is connected to CAN Tx and P0.0 is connected to CAN Rx, where communication between the Bluetooth module and other modules happen. RXD and TXD pins are connected to Bluetooth HC-06 to enable communication between the Android mobile device and the Bluetooth module. Power supply and Ground pins to SJone board i.e Bluetooth module is provided by battery, which would power up all the SJone boards. Power to the HC-06 module is given by the SJone Bluetooth board 3.3V and GND pins. Thus enabling the Interface between Bluetooth module and the other controllers.

Software Design

Software interface between HC-06 and Android device is enabled via Bluetooth transmission and reception.

Below attached is the image showing the Android Application Development.

Stages of Android Application Development

Initially we developed the Application with just Enable and Disable Bluetooth Buttons, after which we added the Start and Stop Signals Button. Start and Stop buttons were given the functionality to send "1" and "0" respectively. In the next phase, we integrated the application with Google maps with few more buttons and obtained our location from the Google maps and cell phone GPS and marked our location on the App screen. In the Final phase we were able to display the application with all the values which we received from the Bluetooth controller, which includes RPS and Locations.

Below diagrams represent the different app screens in the selection sequence.

Pairing with Bluetooth

Destination set

Displaying CAN data

In the above image, we initially turn on the Bluetooth device. Once done, we set up the start and destination on the map, marked as red and green flags respectively. Clicking on the Start signal would enable the Car to receive the Signals Route button would send out the way points to the Bluetooth controller and the Master sending the signal to move the car in the way points direction.

Flow Chart:

Flow Chart of the Bluetooth and Android design is as follows.

Android and Bluetooth Controller Flow Chart

Android-Bluetooth Controller Button's Functionality Table

SI No.	Button	Functionality
1	BTON	User is prompted to Turn on Bluetooth device on the phone. User can either "allow" or "deny" the request. Application won't work till the request is allowed.
2	START	Sends string 1 over Bluetooth channel to indicate to to Master Controller to start of car.
3	STOP CAR	Sends string 0 over Bluetooth channel to indicate to Master Controller to stop the car(Wireless Kill switch).
4	BTOFF	Turns off the Bluetooth of the Android device.
5	LOC	Places a marker on Google Map based on cars Latitude and Longitude received from the GEO module on the car.
6	ROUTE	Send route from source to destination selected on map after filtering way-points to the Bluetooth Controller and to GEO controller there on.

Implementation

BT connection establishment

Through the Android application the Bluetooth would be paired with HC-06 module on click of BTon button, which turns on the Bluetooth on the android phone and connects to Car’s HC-06 Bluetooth device. Post which, we would send a start signal from the app, which would sync and start the car. This signal is encoded before sending from the android. This signal when received from the Bluetooth module, would decode and read the message and later encode and pass it on over the CAN to the Master.

Communication between BT and other controllers

BT Application and BT controller communicates over UART at 9600 bits/sec baud rate,as HC-06 operates at that baud rate.

Send data to Application

Bluetooth controller communicates with other controllers through CAN.Once BT App installed on mobile,App requests for BT permissions from user.Once allowed to access BT on the mobile phone, App can send and receive messages over UART.CAN messages received from other modules are decoded and the corresponding message is sent to BT application with the specified character sequence through UART. Ex:RPS value from the Motor controller is sent to Bluetooth controller is sent as "r" followed by "!" "<rps value>".IN this sequence "r" is the identification command for the rps value that is being sent from the motor and "!" is delimiter to indicate the app that the next characters are the received values from the motor.This characters are displayed in a text area on app under the heading RPM. Every time the app receives rpm value,the same is displayed on the text section assigned for the RPM on the app.Similarly Sensor,Geo controller sends right sensor value and geo co-ordinates respectively.These are displayed on the allocated text areas on the application.

Receive data from application

Based on the commands(button press on the application) send to the app,it will respond with the appropriate data.A thread starts running once START command on the application is pressed,this threads is alive till the application is closed.This is a way for the controller to know that Bluetooth connection is intact between BT app and controller.Any data sent to application is always listened through socket communication and the application responds if any command is programmed fro the received message. A circular buffer at the receiver part of the application is useful for the data to be received without corruption.Application sends data through socket communication at faster rate than that BT controller receive,hence buffer at the controller should be able to store the data received from application.

Sending route to SJone board

Route Button on the app would be initiated once we set the source and destination by 2 clicks on the maps in the app and start getting the location details from HC-06. Route Button ,on click would send the location from the car and send out next way points till the destination. The Kill switch is implemented as Stop Button, which sends of “0” signal, which is received by the Bluetooth and sent over the CAN Bus to master, to stop the Motor.

Code snippet to send rpm data to App

 if (dbc_decode_MOTOR_RPS(&motorrps, can_receive.data.bytes,&can_msg_hdr))
    {

         char a[3] ={ 0 };
         sprintf(a, "%d",  motorrps.Rps_Value);
         u3.putChar('r', 0);
         u3.putChar('!', 0);
         u3.putline(a, 0);
         u3.putChar('!', 0);
         LE.off(1);

   }

Geographical Controller

Team Members:

Veena Manasa Kanakamalla
Arpita Ramanath

Hardware Design

System Block Diagram

SJ One board is interfaced to GPS module and IMU through UART.

Hardware Interface of GeoController

Geographical Controller Hardware Design Components

GPS Module

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:

GGA- essential fix data which provide 3D location and accuracy data.

  $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
    GGA          Global Positioning System Fix Data
    123519       Fix taken at 12:35:19 UTC
    4807.038,N   Latitude 48 deg 07.038' N
    01131.000,E  Longitude 11 deg 31.000' E
    1            Fix quality: 
                  0 = invalid
                  1 = GPS fix (SPS)
                  2 = DGPS fix
                  3 = PPS fix
                  4 = Real Time Kinematic
                  5 = Float RTK
                  6 = estimated (dead reckoning) (2.3 feature)
                  7 = Manual input mode
                  8 = Simulation mode
    08           Number of satellites being tracked
    0.9          Horizontal dilution of position
    545.4,M      Altitude, Meters, above mean sea level
    46.9,M       Height of geoid (mean sea level) above WGS84
                     ellipsoid
    (empty field) time in seconds since last DGPS update
    (empty field) DGPS station ID number
    *47          the checksum data, always begins with *

GPS Pin Connections

GPS Pin Connections

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

IMU Pin Connections

IMU Pin Connections

Hardware Interface

Geographical Controller H/W Interface

Below table shows the pin connections of GPS and IMU module with SJ One Board. Both the modules are interfaced with Controller using UART interface. The operating voltage of GPS and IMU is 5V.

Geographical Controller Pin Connections
Description	Interface	Port Used	Controller Port
Supply Voltage	N/A	5V power supply	N/A
Ground	N/A	GND	GND
GPS Module	UART3	1 -> Rx 2 -> Tx	1 -> Tx P4.28 2 -> Rx P4.29
IMU Module	UART2	1 -> Rx 2 -> Tx	1 -> Tx P2.8 2 -> Rx P2.9

Software Design

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

GPS module
IMU module

Tasks

Geo Controller Tasks
Task Name	Purpose
Period Init	Initializing CAN bus, UART2 for IMU, UART3 for GPS
Periodic 1Hz Callback	Checking for CAN bus off
Periodic 10Hz Callback	Receiving and parsing GPS data and IMU data, receiving checkpoints, calculating heading, bearing and distance.

Flowchart

GeoController Flow Diagram

Implementation

Receiving and parsing GPS data

The first task was to interface the GPS module to the SJOne board (using UART3), and receive raw data over it. The module was configured to receive only GPGGA NMEA sentence at 9600 bps baud rate. The received NMEA data is a string, that has to be parsed to obtain current latitude and longitude values. This location data is continuously sent to the Master controller on the CAN bus at 10 Hz.

Heading Calculation

Heading of the car is the direction that the car is moving, with respect to true north. A compass gives heading with respect to magnetic north. True heading is calculated by adding magnetic declination at that particular location, to the magnetic heading.

The IMU module has to be calibrated initially. The board comes programmed with the 8MHz Arduino bootloader (stk500v1) and some example firmware that demos the output of all the sensors (accelerometer, magnetometer, gyroscope). The calibration was done by following this tutorial at https://github.com/Razor-AHRS/razor-9dof-ahrs/wiki/Tutorial. Calibration compensates for the magnetic field around the IMU. So this process has to be done once after mounting the IMU on the car.

The IMU module is interfaced to the SJOne board using UART2. The IMU firmware is updated such that it gives only Yaw readings. Yaw (or magnetic heading) is used to calculate the true heading using the below formula.

Heading = Yaw data from IMU + Magnetic Declination

Magnetic declination in San Jose is +13° 29'.

Bearing calculation

Bearing is the direction that the car desires to travel along, i.e., the direction of the destination. It is calculated using the current location coordinates and the destination coordinates (or next checkpoint coordinates). The formula to calculate bearing is

   X = cos(lat2) * sin(dLong)
   Y = cos(lat1) * sin(lat2) - sin(lat1) * cos(lat2) * cos(dLong)
   Bearing = atan2(X,Y)
  
   where,
   (lat1, long1) are the current location coordinates
   (lat2, long2) are the checkpoint coordinates
   dLong is (long2 - long1)

Distance calculation

The distance between the current location and the next checkpoint is calculated using the below formula.

Haversine formula to calculate distance

  a = sin²(Δφ /2) + (cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2))
  c = 2 x atan2( √a, √(1−a) )
  Distance d = R x c
       Where,
            Φ is latitude
            λ is longitude
            R is Earth’s radius = 6371 Km
            Δφ = latitude2 – latitude1
            Δλ = longitude2 – longitude1

A flag is set when the distance to the final checkpoint becomes zero, and sent to the Master controller, to indicate that the destination has been reached.

Master Controller

Team Members:

Ajai Krishna Velayutham
Goutam Madhukeshwar Hegde

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.

Hardware Design

The Hardware Design is as show below with just CAN bus connection to the Master Controller. Master has the connection with all the other controllers via CAN Bus. Hardware interface explains the signalling through the CAN bus.

Master Controller Interface

Hardware Interface

The Hardware interface is simpler compared to other controllers, by just connecting to the CAN bus as shown above. The messages on the CAN such as Start and Stop command's from Bluetooth controller, Heading, Bearing and destination check signals from Geo Controller and Sensor range values from the proximity sensors are received from the CAN Bus. Based on these signals master drives the Car by sending out signals to Motor Controller, such as speed and steer values, which signifies at what sped the car has to move and at what steer the car should take.

Software Design

Master controller software consists of a state machine running 3 different states based on the sensor and geo inputs.

Master Controller Flow Diagram

Above Flow diagram represents the control flow of the master. On start of the master controller, it waits for the Start command from Bluetooth controller i.e from the App. Once the signal is given, it checks if the way points are received and stored by the Geo Controller and if the way points are sent by clicking route on the app and stored in Geo controller, then the master checks if the Geo location is not the same as destination, then Navigation algorithm is used if there are no obstacles detected by sensors, else if there are obstacles detected, then Obstacle avoidance algorithm is implemented.

Master controller software mainly deals with obstacle avoidance and GPS navigation algorithms. Software is designed with the help of state machines to make it more modular and efficient. Design of algorithms using state machines is explained in following section.

Obstacle avoidance algorithm: Obstacle avoidance is done according to the enum values sent from the sensor controller. In the master controller, obstacle avoidance is handled separately in danger,near and medium regions. If sensor indicates danger region,it means that there is an obstacle very near to front sensor. So in this case car takes a reverse turn until the front sensor enters near region.So in this way car avoids obstacle very near to it.

If sensor indicates near region,master enters a states machine to intelligently avoid the obstacle as shown the below figure.

Obstacle Avoidance State Diagram for Near Region

State machines take the three ultrasonic sensors reading from sensor controller as inputs based on which it makes the decisions to issue speed and steer command to the motor controller. To elobarate, let's see an example state transition in the above state diagram. Let's assume that currently car is moving in the forward direction.So the current state is SLOW,STRAIGHT.Now if an obstacle is detected by the left sensor,input for the state machine will be 100.So car should take right turn to avoid the obstacle.So state transition happens to the next state SLOW,RIGHT.In the similar manner, all the decisions are made in the state diagram.

If sensor indicates medium region,master enters another state machine to handle the obstacles in medium region.

Obstacle Avoidance State Diagram for Mid Region

Bit representation are the sensor values detected i.e. the leftmost bit is the value of Left sensor, followed by front sensor value as mid bit and later the right sensor value as the final bit. Value is set to 1 if an obstacle is detected and 0 if there is no obstacle, in the above diagrams for Obstacle avoidance algorithm.

Navigation Algorithm:

Steer control based on turn angle

GPS Navigation is done based on the heading and bearing values from GEO controller.Master controller calculates the desired turn angle to reach the destination path.

Turn angle= GPS bearing-GPS heading;

Turn angle is a value between 0 to 360 degree.Entire 360 degrees is divided into various sub-regions based on the desired turn angles as shown in the above figure. GPS navigation is done with the help of a state machine.Turn angle is the input for the state machine based on which state machine determines the command to issue to the motor.

Implementation

Master controller software is implemented with the help of state machines.The main state machine consists of three states.

1.Obstacle avoidance state
2.GPS navigation state
3.Move reverse state

code snippet of state machine stucture:

typedef struct{
   state_t state; //state here corresponds to ST_REVERSE,ST_GPS_NAVIGATE and ST_OBSTACLE_AVOID
   state_t (*func)(void); //this is the funcction pointer declaration to switch between moveReverse,GPS_navigate and obstacleAvoid functions
} stateTrans_t;

stateTrans_t stateTrans[]=
{		 
		   {ST_REVERSE,moveReverse},
		   {ST_GPS_NAVIGATE,GPS_navigate},
		   {ST_OBSTACLE_AVOID,obstacleAvoid}
};

We have created a separate state for move reverse because in order to change the motor speed to reverse, ESC of the car needs brake pulse followed by reverse.So whenever an obstacle is in danger region,we issue break first for 3 to 4 seconds followed by reverse command.So we handled this with the help of count variable in 100Hz periodic function. In the obstacle avoidance state,first we check sensor readings and based on which program calls the state machines corresponding to near region or medium region. If the sensor readings indicate that there are no near by obstacles, state transits to navigation state. In the navigation state commands to motor is issued based on the turn angle calculated based on the heading and bearing values sent by geo controller.

Following function runs in the periodic function to update the state of the car.

cState= (stateTrans[cState].func)();

Following functions are implemented in the periodic functions.

Master Controller Tasks
Task Name	Purpose
Period Init	Initialize CAN bus
Periodic 1Hz Callback	Check can bus off
Periodic 10Hz Callback	decode_START_CMD, decode_GEO_SEND_HD_BR, dbc_decode_SENSOR_SONAR, State machine to change the system states
Periodic 100Hz Callback	encode_and_send_MOTOR_CONTROL

Testing & Technical Challenges

Motor & I/O Issues

Reverse Current from Motor: One of our boards got burnt while testing Brushless DC Motor. We would highly recommend using an Optoisolator such as ILQ74 for additional protection from reverse current etc. if you are synchronizing with the ESC for the first time.

ESC Synchronization: The slowest speed of Brushless DC motor was too fast for us. We tried to change ESC synchronization and reprogram it to change PWM frequency but it didn't work out for us. We recommend having Brushed DC Motor that is reprogrammable to any PWM frequency.

ESC Modes: ESC Board was only set to forward and reverse mode. So we were not able to control the speed to stop the motor, even after sending stop signal it would hit the obstacle. So we reprogrammed the ESC to forward, reverse and brake. Synchronizing took time and effort. ESC has various modes we can program it into.

Going Reverse issues: If we wanted to go reverse first without going forward, car would go full speed in reverse. So every time we got reverse command from master, we initialized the DC motor to idle and then go to reverse.

LCD Refresh Rate Issue: For debugging, we wanted to run LCD at 10hz but it took long time to refresh, so data didn't get printed. Hence we were forced to debug especially at 1 Hz.

Bluetooth Bridge Controller and Android application Issues

Issues

During the initial phase we were finding difficult to connect to the Bluetooth Module HC-06, later on proper UUID was given which solved the connection issue.
Sending out Start and Stop messages of "1" and "0" respectively continuously was a challenge. This was required to detect when Bluetooth goes out of range. We solved this issue using threads.
We had tested the application by hard coding the values from the Bluetooth controller end, which was displayed as messages on the application. The requirement was to display the CAN messages, therefore once we integrated on board, we faced issues like receiving junk and ? character on the application. We solved this by introducing circular buffers.
On integrating with on board GPS, we were unable to send out all the Navigation way points, say if we got 8 way points, we were able to send only first 4 of them. This was due to buffer size which we had set to 100. Once we updated it to 500, we were able to receive all the CAN messages flawlessly.

Testing

At Module level, we tested the communication between the Bluetooth Controller and the Android by sending out characters through UART and displaying the received messages on the app screen.
We increased the number of characters to 960 characters that was being sent on UART to check whether we were able to receive on the app.
Verified the Location of the maps on the app with the Google maps application.
Verified the messages displayed on the Bus Master and LCD with the app screen post integration.

Geo controller Issues

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. The IMU has to be calibrated once again after mounting it on the car to avoid drift in the Yaw values.

The GPGGA sentence received via UART was incomplete sometimes, resulting in incorrect parsing. This turned out to be an issue with the UART receive queue size. When this queue size was increased, complete NMEA sentences were received.

Initially, the coordinates received from the GPS module were pointing to Santa Clara, around 30 km away from our present location. This was due to incorrect parsing of the NMEA sentence from the GPS module. The latitude and longitude values from the GPS module are given in the form of ddmm.mmmm and dddmm.mmmm and not decimal degrees. The minutes have to be converted to degrees and added to the degrees value.

Conclusion

In a span of 3 months, we had an awesome experience in working together for the AutoNav project. We learnt a lot about GIT and CAN bus along with implementing DBC and working on real hardware. We were able to implement all these embedded concepts effectively from our course work. All essential phases of software development cycle such as design, implementation and testing were executed in stages effectively and debugging with CAN bus was really helpful in working. Finally it was an enchanting experience and we hope that we were able to share some of our learnings and difficulties we faced in this report, which would help the future students joining the course.

Project Video

AutoNav - The autonomous RC car

GitLab Source Code

Git Code for Team AutoNav

References

Acknowledgement

We would like to thank Preet for his guidance,consistent feedback and setting intermediate goals for the project completion on-time. We would like to thank ISA team for their support and valuable inputs at each step of the project,without which we would have not made our car work.

References Used

List of references used in the project.

[1] Preetpal Kang's lecture notes of CMPE 243, Computer Engineering, San Jose State University, Aug-Dec 2016.
[2] LPC1758 User Manual
[3] Parallax Ultrasonic Sensor
[4] Razor IMU
[5] Razor IMU Tutorial
[6] Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3
[7] Calculate distance between two points
[8] Programming Guide
[9] Google Maps Guide
[10] Video guide for Google maps implementation

@@ Line 1: / Line 1: @@
 == Project Title ==
-* Autonomous RC Car
-== Abstract ==
+=== AutoNav - The Autonomous RC Car ===
-This project report describes an attempt to develop an autonomous RC car which navigates from a source point to destination avoiding any obstacles in between. The project was divided into five modules namely Motor & Input/output Controller, Sensor Controller, Geo Controller, Communication Bridge & Android Controller and Master Controller, each performing specific set of tasks. Each of the five modules were established using SJOne Boards. Communication between all the five modules was established using CAN Bus.
-* '''Motor & I/O Controller''' - This controller was responsible for driving Brushless DC Motor interfaced through ESC, driving the stepper motor for steering and displaying the status of the RC car (speed, obstacle distance etc.) on the LCD.
+[[File:CMPE_243_F16_Autonav_RCcar_TopView.jpeg‎|left|550px|thumb|AutoNav RC Car(Controller View)]] [[File:CMPE_243_F16_Autonav_RCcar_FrontView.jpeg‎|right|550px|thumb|AutoNav RC Car(Sensor View)]]
-* '''Sensor Controller''' - This controller was responsible for obstacle detection and avoidance, interfacing done with Ultrasonic Ping Sensors.
-* '''Geo Controller''' - This controller focused on providing orientation (heading and bearing) and navigation route to the car.
-* '''Communication Bridge & Android Controller''' - Co-ordinates for navigation were provided by this controller using an android application. Communication was established via Bluetooth.
-* '''Master Controller''' - This controller was responsible for collecting the data from all the controllers, develop and implement obstacle avoidance algorithm to guide the car towards the final destination.
-== Objectives & Introduction ==
-The main objectives of this project include:
-* To develop an autonomous RC Car.
-* To navigate from a set source to destination.
-* To avoid any obstacles in between.
-* To establish all communication between controllers via CAN bus.
-The following peripherals of LPC 1758 were used to establish communications:
-* '''CAN Peripheral''': Communicate between all the controllers on a common CAN bus.
-* '''UART Peripheral''': Communicate between GEO Controller and GPS module, Bluetooth controller and Bluetooth module.
-* '''GPIO''': Communicate between sensors and sensor controller.
-* '''PWM''': Vary the speed of Brushless DC motor and Stepper motor via ESC interfaced through Motor Controller.
-The block diagram below gives an overview of the various peripherals used:
-[[File:CMPE_243_F16_Autonav_Peripherals_Block_Diagram.png‎|centre|700px|thumb|Peripheral block diagram]]
-== Team Members & Responsibilities ==
-'''Sensor Controller:'''
-*Vishwanath Balakuntla Ramesh
-'''Motor & I/O Controller:'''
-*[https://www.linkedin.com/in/sameersaran97 Sameer Saran]
-*Jaswanth Bhimanapalli
-'''Bluetooth (Communication Bridge) & Android Controller:'''
-*Sucharitha
-*Karthikeya Rao G V
-'''Geographical Controller:'''
-*Arpita Ramanath
-*Veena Manasa Kanakamalla
-'''Master Controller:'''
-*[https://www.linkedin.com/in/ajaikrishna Ajai Krishna Velayutham]<br>
-*Goutam Madhukeshwar Hegde
-== Schedule ==
-'''Consolidated Team 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/13/2016
-| 09/27/2016
-|
-*<span style="background:#FFDAB9">*Motor - Research and order RC car and additional batteries</span>
+== Abstract ==
-*<span style="background:#ADFF2F">*Sensor - Researching and understanding various sensor requirements for a self driving vehicle.
+This project report describes an attempt to develop an autonomous RC car which navigates from a source point to destination avoiding any obstacles in between. The project was divided into five modules namely Motor & Input/output Controller, Sensor Controller, Geo Controller, Communication Bridge & Android Controller and Master Controller, each performing specific set of tasks. Each of the five modules were established using SJOne Boards. Communication between all the five modules was established using CAN Bus.
-*<span style="background:#ADFF2F"> Shortlisting the sensors suitable for our application.
+* '''Motor & I/O Controller''' - This controller was responsible for driving Brushless DC Motor interfaced through ESC, driving the stepper motor for steering and displaying the status of the RC car (speed, obstacle distance etc.) on the LCD.
-*<span style="background:#F0E68C">*GPS - Research and order GPS and Compass module.</span>
+* '''Sensor Controller''' - This controller was responsible for obstacle detection and avoidance, interfacing done with Ultrasonic Ping Sensors.
-*<span style="background:#D3D3D3">*Bluetooth - Learning and Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API.</span>
+* '''Geo Controller''' - This controller focused on providing orientation (heading and bearing) and navigation route to the car.
-*<span style="background:#AFEEEE">*Master - Understanding the working of CAN Communication and research on obstacle avoidance and navigational algorithm.</span>
+* '''Communication Bridge & Android Controller''' - Co-ordinates for navigation were provided by this controller using an android application. Communication was established via Bluetooth.
-| Completed
+* '''Master Controller''' - This controller was responsible for collecting the data from all the controllers, develop and implement obstacle avoidance algorithm to guide the car towards the final destination.
-| 09/26/2016
-|-
+== Objectives & Introduction ==
-! scope="row"| 2
-| 09/27/2016
+The main objectives of this project include:
-| 10/11/2016
+* To develop an autonomous RC Car.
-|
+* To navigate from a set source to destination.
-*<span style="background:#FFDAB9">*Motor - Understand and implement PWM concepts to drive brushless DC motor and servo motor of the RC car. Set PWM frequency range for varying duty cycle.</span>
+* To avoid any obstacles in between.
-*<span style="background:#ADFF2F">*Sensor - Reading datasheets of shortlisted sensors, Understand pros and cons of each sensor. Make an Order.
+* To establish all communication between controllers via CAN bus.
-*<span style="background:#F0E68C">*GPS - Get familiar with data sheets of both modules. Identify relevant pins and understand the module schematics (GPS and IMU).</span>
-*<span style="background:#D3D3D3">*Bluetooth - Buttons and text insertion on the app. Ex: switch on and off Bluetooth, getting longitude latitude values on the phone Placement of route markers on Google maps between source and destination.</span>
+The following peripherals of LPC 1758 were used to establish communications:
-*<span style="background:#AFEEEE">*Master - Developing the required control messages to be used in CAN Bus for communication between different controllers.</span>
-|Completed
+* '''CAN Peripheral''': Communicate between all the controllers on a common CAN bus.
-| 10/11/2016
+* '''UART Peripheral''': Communicate between GEO Controller and GPS module, Bluetooth controller and Bluetooth module.
-|-
+* '''GPIO''': Communicate between sensors and sensor controller.
-! scope="row"| 3
+* '''PWM''': Vary the speed of Brushless DC motor and Stepper motor via ESC interfaced through Motor Controller.
-| 10/12/2016
-| 10/18/2016
+The block diagram below gives an overview of the various peripherals used:
-|
-*<span style="background:#FFDAB9">*Motor - Interfacing Brushless DC Motor & Servo Motors to SJ one board - implement duty cycles using provided PWM library. Use terminal commands to test basic functionality like drive straight, turn left or right.</span>
+[[File:CMPE_243_F16_Autonav_Peripherals_Block_Diagram.png‎|centre|1000px|thumb|Peripheral block diagram]]
-*<span style="background:#ADFF2F">*Sensor - Write sample code for sensors and experiment with sensor output(filtering).
-*<span style="background:#F0E68C">*GPS - Interface GPS and Compass modules to SJOne board using UART. Test functionality of each module.</span>
+== Team Members & Responsibilities ==
-*<span style="background:#D3D3D3">*Bluetooth - Establishment of communication between Bluetooth and the phone application by sending and receiving the values Routing markers display on google maps for a straight line between source and destination.</span>
+'''Sensor Controller:'''
-*<span style="background:#AFEEEE">*Master - Establishing CAN communication between master controller, sensor controller and Bluetooth controller with addition of handling MIA in all the controllers.</span>
+*Vishwanath Balakuntla Ramesh
-| Completed
-| 10/20/2016
+'''Motor & I/O Controller:'''
-|-
+*[https://www.linkedin.com/in/sameersaran97 Sameer Saran]
-! scope="row"| 4
+*Jaswanth Bhimanapalli
-| 10/19/2016
-| 10/30/2016
+'''Bluetooth (Communication Bridge) & Android Controller:'''
-|
+*Sucharitha
-*<span style="background:#FFDAB9">*Motor - Implement CAN bus communication - setup CAN Msg ID acceptance filters, integration with sensor data and Master Controller.Develop basic obstacle avoidance algorithm. Testing of obstacle avoidance algorithm in real time. </span>
+*Karthikeya Rao G V
-*<span style="background:#ADFF2F">*Sensor - DBC file implementation to establish CAN communication with Master controller.
-*<span style="background:#ADFF2F"> Collaborate with Motor I/O team to achieve basic obstacle avoidance.
+'''Geographical Controller:'''
-*<span style="background:#F0E68C">*GPS - Calibrate GPS and Compass modules. Write code to parse raw Compass and GPS readings. Test calibration of the modules.</span>
+*Arpita Ramanath
-*<span style="background:#D3D3D3">*Bluetooth - Interfacing Bluetooth module to SJ One board through UART and sending and receiving data between them.</span>
+*Veena Manasa Kanakamalla
-*<span style="background:#AFEEEE">*Master - Master Controller should acquire obstacle range sensor data from sensor controller, control commands from Bluetooth controller.</span>
-| Completed
+'''Master Controller:'''
-| 11/01/2016
+*[https://www.linkedin.com/in/ajaikrishna Ajai Krishna Velayutham]<br>
-|-
+*Goutam Madhukeshwar Hegde
-! scope="row"| 5
-| 10/31/2016
+== Schedule ==
-| 11/08/2016
-|
+'''Consolidated Team Schedule'''
-*<span style="background:#FFDAB9">*Motor - LCD interfacing to display messages from required controllers. DBC File Implementation and integrating data structures generated from auto gen code. </span>
+{| class="wikitable"
-*<span style="background:#ADFF2F">*Sensor - Identify and implement a mechanism to avoid sensors from interfering with each other.
-*<span style="background:#ADFF2F"> Add multiple sensors to the car and work on synchronization between them to achieve more precise obstacle avoidance.
-*<span style="background:#F0E68C">*GPS - Establish CAN communication from Geo controller to Master controller. Send CAN messages of latitude, longitude, heading and bearing from Geo controller to master to set destination.</span>
-*<span style="background:#D3D3D3">*Bluetooth -  Receive commands from SJ One to android application and test if right data is being sent.</span>
-*<span style="background:#AFEEEE">*Master - Master controller should send directional control messages to motor controller to control the car to its desired path. Implement and test a simple obstacle avoidance algorithm on to the Master controller. </span>
-| Completed
-| 11/12/2016
 |-
-! scope="row"| 6
+! scope="col"| SI No.
-| 11/09/2016
+! scope="col"| Start Date
-| 11/27/2016
+! scope="col"| End Date
-|
+! scope="col"| Task
-*<span style="background:#FFDAB9">*Motor - RPM sensor interfacing to develop Motor Feedback Control loop. Up/down hill driving testing in real world.</span>
+! scope="col"| Status
-*<span style="background:#ADFF2F">*Sensor- Design and implement the circuit and software for Car's battery voltage monitoring and determining the State of charge(SOC).
+! scope="col"| Actual Completion Date
-*<span style="background:#ADFF2F"> Design and implement the software to read light sensor values and Tilt (angle of the car) sensor values.
-*<span style="background:#F0E68C">*GPS - Test destination setting, navigation and synchronization with Master controller and Android app.</span>
-*<span style="background:#D3D3D3">*Bluetooth - Testing the routing path and the basic testing of the application.</span>
-*<span style="background:#AFEEEE">*Master - Master controller has to acquire coordinates from Geo controller to be used for navigational algorithm. Also get heading, bearing and speed information from Geo-controller.</span>
-|Completed
-| 11/29/2016
 |-
-! scope="row"| 7
+! scope="row"| 1
-| 11/27/2016
+| 09/13/2016
-| 12/15/2016
+| 09/27/2016
 |
-*<span style="background:#FFDAB9">*Motor - Integration with RC Car controllers as one system. Testing, debugging and optimization.</span>
+*<span style="background:#FFDAB9">*Motor - Research and order RC car and additional batteries</span>
-*<span style="background:#ADFF2F">*Sensor - Integration testing with Master Controller and other boards.
+*<span style="background:#ADFF2F">*Sensor - Researching and understanding various sensor requirements for a self driving vehicle.
-*<span style="background:#ADFF2F"> Optimize the code, Finalize the operation (validate correctness) & Documentation.
+*<span style="background:#ADFF2F"> Shortlisting the sensors suitable for our application.
-*<span style="background:#F0E68C">*GPS - Integrate Geo controller with the entire system. Test and debug code.</span>
+*<span style="background:#F0E68C">*GPS - Research and order GPS and Compass module.</span>
-*<span style="background:#D3D3D3">*Bluetooth -  Integration Testing and Final testing after integration of all the modules on the car.</span>
+*<span style="background:#D3D3D3">*Bluetooth - Learning and Getting familiarized with Android SDK, Java, Bluetooth API and Google Maps API.</span>
-*<span style="background:#AFEEEE">*Master - Implement and test navigational algorithm. Integrate navigation and avoidance algorithm and perform final testing.</span>
+*<span style="background:#AFEEEE">*Master - Understanding the working of CAN Communication and research on obstacle avoidance and navigational algorithm.</span>
 | Completed
-| 12/18/2016
+| 09/26/2016
 |-
-|}
+! scope="row"| 2
+| 09/27/2016
-== Parts List & Cost ==
+| 10/11/2016
-{| class="wikitable"
+|
+*<span style="background:#FFDAB9">*Motor - Understand and implement PWM concepts to drive brushless DC motor and servo motor of the RC car. Set PWM frequency range for varying duty cycle.</span>
+*<span style="background:#ADFF2F">*Sensor - Reading datasheets of shortlisted sensors, Understand pros and cons of each sensor. Make an Order.
+*<span style="background:#F0E68C">*GPS - Get familiar with data sheets of both modules. Identify relevant pins and understand the module schematics (GPS and IMU).</span>
+*<span style="background:#D3D3D3">*Bluetooth - Buttons and text insertion on the app. Ex: switch on and off Bluetooth, getting longitude latitude values on the phone Placement of route markers on Google maps between source and destination.</span>
+*<span style="background:#AFEEEE">*Master - Developing the required control messages to be used in CAN Bus for communication between different controllers.</span>
+|Completed
+| 10/11/2016
 |-
-! scope="col"| Item#
+! scope="row"| 3
-! scope="col"| Part Description
+| 10/12/2016
-! scope="col"| Vendor
+| 10/18/2016
-! scope="col"| Qty
+|
-! scope="col"| Cost
+*<span style="background:#FFDAB9">*Motor - Interfacing Brushless DC Motor & Servo Motors to SJ one board - implement duty cycles using provided PWM library. Use terminal commands to test basic functionality like drive straight, turn left or right.</span>
+*<span style="background:#ADFF2F">*Sensor - Write sample code for sensors and experiment with sensor output(filtering).
+*<span style="background:#F0E68C">*GPS - Interface GPS and Compass modules to SJOne board using UART. Test functionality of each module.</span>
+*<span style="background:#D3D3D3">*Bluetooth - Establishment of communication between Bluetooth and the phone application by sending and receiving the values Routing markers display on google maps for a straight line between source and destination.</span>
+*<span style="background:#AFEEEE">*Master - Establishing CAN communication between master controller, sensor controller and Bluetooth controller with addition of handling MIA in all the controllers.</span>
+| Completed
+| 10/20/2016
 |-
-! scope="row"| 1
+! scope="row"| 4
-| RC Car
+| 10/19/2016
-| [http://www.rchobbyexplosion.com/DHK_Hunter_4WD_Short_Course_Truck_with_2_4Ghz_p/dhk8135.htm RChobby Explosion ]
+| 10/30/2016
-| 1
+|
-| $190
+*<span style="background:#FFDAB9">*Motor - Implement CAN bus communication - setup CAN Msg ID acceptance filters, integration with sensor data and Master Controller.Develop basic obstacle avoidance algorithm. Testing of obstacle avoidance algorithm in real time. </span>
+*<span style="background:#ADFF2F">*Sensor - DBC file implementation to establish CAN communication with Master controller.
+*<span style="background:#ADFF2F"> Collaborate with Motor I/O team to achieve basic obstacle avoidance.
+*<span style="background:#F0E68C">*GPS - Calibrate GPS and Compass modules. Write code to parse raw Compass and GPS readings. Test calibration of the modules.</span>
+*<span style="background:#D3D3D3">*Bluetooth - Interfacing Bluetooth module to SJ One board through UART and sending and receiving data between them.</span>
+*<span style="background:#AFEEEE">*Master - Master Controller should acquire obstacle range sensor data from sensor controller, control commands from Bluetooth controller.</span>
+| Completed
+| 11/01/2016
 |-
-! scope="row"| 2
+! scope="row"| 5
-| RC Car Battery
+| 10/31/2016
-| [https://www.amazon.com/Turnigy-4000mAh-30C-Lipo-Pack/dp/B0072AFNDK Amazon]
+| 11/08/2016
-| 1
+|
-| $27.29
+*<span style="background:#FFDAB9">*Motor - LCD interfacing to display messages from required controllers. DBC File Implementation and integrating data structures generated from auto gen code. </span>
+*<span style="background:#ADFF2F">*Sensor - Identify and implement a mechanism to avoid sensors from interfering with each other.
+*<span style="background:#ADFF2F"> Add multiple sensors to the car and work on synchronization between them to achieve more precise obstacle avoidance.
+*<span style="background:#F0E68C">*GPS - Establish CAN communication from Geo controller to Master controller. Send CAN messages of latitude, longitude, heading and bearing from Geo controller to master to set destination.</span>
+*<span style="background:#D3D3D3">*Bluetooth -  Receive commands from SJ One to android application and test if right data is being sent.</span>
+*<span style="background:#AFEEEE">*Master - Master controller should send directional control messages to motor controller to control the car to its desired path. Implement and test a simple obstacle avoidance algorithm on to the Master controller. </span>
+| Completed
+| 11/12/2016
 |-
-! scope="row"| 3
+! scope="row"| 6
-| CAN Transceiver
+| 11/09/2016
-| [https://store.ti.com/SN65HVD251P.aspx Texas Instruments]
+| 11/27/2016
-| 15
+|
-| Free
+*<span style="background:#FFDAB9">*Motor - RPM sensor interfacing to develop Motor Feedback Control loop. Up/down hill driving testing in real world.</span>
-|-
+*<span style="background:#ADFF2F">*Sensor- Design and implement the circuit and software for Car's battery voltage monitoring and determining the State of charge(SOC).
-! scope="row"| 4
+*<span style="background:#ADFF2F"> Design and implement the software to read light sensor values and Tilt (angle of the car) sensor values.
-| M-F,F-F,M-M Jumper Wires
+*<span style="background:#F0E68C">*GPS - Test destination setting, navigation and synchronization with Master controller and Android app.</span>
-| [https://www.amazon.com/Honbay%C2%AE-120pcs-Multicolored-Female-Breadboard/dp/B017NEGTXC/ref=sr_1_3?ie=UTF8&qid=1476649080&sr=8-3&keywords=jumper+wires Amazon]
+*<span style="background:#D3D3D3">*Bluetooth - Testing the routing path and the basic testing of the application.</span>
-| 120
+*<span style="background:#AFEEEE">*Master - Master controller has to acquire coordinates from Geo controller to be used for navigational algorithm. Also get heading, bearing and speed information from Geo-controller.</span>
-| 7.97
+|Completed
-|-
+| 11/29/2016
-! scope="row"| 5
-| Printed Circuit Boards
-| [https://www.amazon.com/Prototyping-Tinned-Universal-Printed-150x200mm/dp/B00N3WTROC/ Amazon]
-| 1
-| $9.72
-|-
-! scope="row"| 6
-| Ultrasonic Parallax Ping Sensor
-| [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]
-| 3
-| $98.85
 |-
 ! scope="row"| 7
-| 9 DOF Razor IMU module
+| 11/27/2016
-| [https://www.sparkfun.com/products/10736 SparkFun]
+| 12/15/2016
-| 1
+|
-| $74.95
+*<span style="background:#FFDAB9">*Motor - Integration with RC Car controllers as one system. Testing, debugging and optimization.</span>
+*<span style="background:#ADFF2F">*Sensor - Integration testing with Master Controller and other boards.
+*<span style="background:#ADFF2F"> Optimize the code, Finalize the operation (validate correctness) & Documentation.
+*<span style="background:#F0E68C">*GPS - Integrate Geo controller with the entire system. Test and debug code.</span>
+*<span style="background:#D3D3D3">*Bluetooth -  Integration Testing and Final testing after integration of all the modules on the car.</span>
+*<span style="background:#AFEEEE">*Master - Implement and test navigational algorithm. Integrate navigation and avoidance algorithm and perform final testing.</span>
+| Completed
+| 12/18/2016
 |-
-! scope="row"| 8
+|}
-| Bluetooth Module
-| [https://www.amazon.com/KEDSUM%C2%AE-Arduino-Wireless-Bluetooth-Transceiver/dp/B0093XAV4U/ Amazon]
+== Parts List & Cost ==
-| 1
+{| class="wikitable"
-| $9.99
+|-
+! scope="col"| Item#
+! scope="col"| Part Description
+! scope="col"| Vendor
+! scope="col"| Qty
+! scope="col"| Cost
 |-
-! scope="row"| 9
+! scope="row"| 1
-| GPS Sensor
+| RC Car
-| [http://www.adafruit.com/products/746 Adafruit]
+| [http://www.rchobbyexplosion.com/DHK_Hunter_4WD_Short_Course_Truck_with_2_4Ghz_p/dhk8135.htm RChobby Explosion ]
 | 1
-| $44.38
+| $190
 |-
-! scope="row"| 10
+! scope="row"| 2
-| Black/White line detection sensor - RPM sensor
+| RC Car Battery
-| [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]
+| [https://www.amazon.com/Turnigy-4000mAh-30C-Lipo-Pack/dp/B0072AFNDK Amazon]
 | 1
-| $10.10
+| $27.29
 |-
-! scope="row"| 11
+! scope="row"| 3
-| SJOne Boards
+| CAN Transceiver
-| From Preet
+| [https://store.ti.com/SN65HVD251P.aspx Texas Instruments]
-| 5
+| 15
-| $400
+| Free
+|-
+! scope="row"| 4
+| M-F,F-F,M-M Jumper Wires
+| [https://www.amazon.com/Honbay%C2%AE-120pcs-Multicolored-Female-Breadboard/dp/B017NEGTXC/ref=sr_1_3?ie=UTF8&qid=1476649080&sr=8-3&keywords=jumper+wires Amazon]
+| 120
+| 7.97
 |-
-! scope="row"| 12
+! scope="row"| 5
-| LCD
+| Printed Circuit Boards
-| [http://www.4dsystems.com.au/product/gen4_uLCD_50D/ 4D systems]
+| [https://www.amazon.com/Prototyping-Tinned-Universal-Printed-150x200mm/dp/B00N3WTROC/ Amazon]
 | 1
-| $111
+| $9.72
 |-
-|}
+! scope="row"| 6
+| Ultrasonic Parallax Ping Sensor
-== DBC File Implementation==
+| [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]
-DBC files are widely used to define the system of CAN messages and their constituent signals. This allows CAN data to be accessed in terms of human-usable signal values, with different data types and scaling, instead of just raw message bytes.
+| 3
-Below is the DBC file that we implemented in our project.
+| $98.85
-<pre>
+|-
-VERSION ""
+! scope="row"| 7
+| 9 DOF Razor IMU module
-NS_ :
+| [https://www.sparkfun.com/products/10736 SparkFun]
-	BA_
+| 1
-	BA_DEF_
+| $74.95
-	BA_DEF_DEF_
+|-
-	BA_DEF_DEF_REL_
+! scope="row"| 8
-	BA_DEF_REL_
+| Bluetooth Module
-	BA_DEF_SGTYPE_
+| [https://www.amazon.com/KEDSUM%C2%AE-Arduino-Wireless-Bluetooth-Transceiver/dp/B0093XAV4U/ Amazon]
-	BA_REL_
+| 1
-	BA_SGTYPE_
+| $9.99
-	BO_TX_BU_
+|-
-	BU_BO_REL_
+! scope="row"| 9
-	BU_EV_REL_
+| GPS Sensor
-	BU_SG_REL_
+| [http://www.adafruit.com/products/746 Adafruit]
-	CAT_
+| 1
-	CAT_DEF_
+| $44.38
-	CM_
+|-
-	ENVVAR_DATA_
+! scope="row"| 10
-	EV_DATA_
+| Black/White line detection sensor - RPM sensor
-	FILTER
+| [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]
-	NS_DESC_
+| 1
-	SGTYPE_
+| $10.10
-	SGTYPE_VAL_
+|-
-	SG_MUL_VAL_
+! scope="row"| 11
-	SIGTYPE_VALTYPE_
+| SJOne Boards
-	SIG_GROUP_
+| From Preet
-	SIG_TYPE_REF_
+| 5
-	SIG_VALTYPE_
+| $400
-	VAL_
+|-
-	VAL_TABLE_
+! scope="row"| 12
+| LCD
-BS_:
+| [http://www.4dsystems.com.au/product/gen4_uLCD_50D/ 4D systems]
+| 1
-BU_: DRIVER BLUETOOTH SENSOR MOTOR GEO
+| $111
+|-
+|}
-BO_ 100 KILL_SWITCH: 1 DRIVER
+== DBC File Implementation==
- SG_ killSwitch : 0|1@1+ (1,0) [0|0] "Stop=1" MOTOR
+DBC files are widely used to define the system of CAN messages and their constituent signals. This allows CAN data to be accessed in terms of human-usable signal values, with different data types and scaling, instead of just raw message bytes.
+Below is the DBC file that we implemented in our project.
+<pre>
+VERSION ""
-BO_ 110 STOP_CMD: 1 BLUETOOTH
+NS_ :
- SG_ BLUETOOTH_STOP_CMD_signal : 0|1@1+ (1,0) [0|0] "Stop=1" DRIVER
+	BA_
+	BA_DEF_
-BO_ 120 MOTOR_SYNC: 1 MOTOR
+	BA_DEF_DEF_
- SG_ Motor_Sync : 0|1@1+ (1,0) [0|0] "MotorSync=1" DRIVER
+	BA_DEF_DEF_REL_
+	BA_DEF_REL_
-BO_ 130 GEO_SYNC: 1 GEO
+	BA_DEF_SGTYPE_
- SG_ Geo_sync_cmd : 0|1@1+ (1,0) [0|0] "GeoSync=1" DRIVER
+	BA_REL_
+	BA_SGTYPE_
-BO_ 140 BLUETOOTH_SYNC_CMD: 1 BLUETOOTH
+	BO_TX_BU_
- SG_ BLUETOOTH_SYNC_CMD_signal : 0|1@1+ (1,0) [0|0] "BluetoothSync=1" DRIVER
+	BU_BO_REL_
+	BU_EV_REL_
-BO_ 150 SENSOR_SYNC: 1 SENSOR
+	BU_SG_REL_
- SG_ Sensor_Sync : 0|1@1+ (1,0) [0|0] "SensorSync=1" DRIVER,MOTOR,BLUETOOTH
+	CAT_
+	CAT_DEF_
-BO_ 160 ERROR_COMM_DRIVER: 1 DRIVER
+	CM_
- SG_ Sync_Miss_Info : 0|8@1+ (1,0) [0|0] "ErrorMsgType" MOTOR
+	ENVVAR_DATA_
+	EV_DATA_
-BO_ 170 DRIVER_SYNC_ACK: 1 DRIVER
+	FILTER
- SG_ Sync_Miss_Info : 0|1@1+ (1,0) [0|0] "DriverSync=1" MOTOR,BLUETOOTH,SENSOR,GEO
+	NS_DESC_
+	SGTYPE_
+	SGTYPE_VAL_
+	SG_MUL_VAL_
+	SIGTYPE_VALTYPE_
+	SIG_GROUP_
+	SIG_TYPE_REF_
+	SIG_VALTYPE_
+	VAL_
+	VAL_TABLE_
+BS_:
-BO_ 180 MOTOR_CONTROL: 2 DRIVER
+BU_: DRIVER BLUETOOTH SENSOR MOTOR GEO
- SG_ steer : 0|8@1+ (1,0) [0|0] "DirectionType" MOTOR
- SG_ speed : 8|8@1+ (1,0) [0|0] "SpeedType" MOTOR
+BO_ 100 KILL_SWITCH: 1 DRIVER
+  SG_ killSwitch : 0|1@1+ (1,0) [0|0] "Stop=1" MOTOR
-BO_ 181 MOTOR_RPS: 2 MOTOR
-  SG_ Rps_Sensor : 0|8@1+ (1,0) [0|0] "RotationsPerSecondENum" DRIVER,BLUETOOTH
- SG_ Rps_Value : 8|8@1+ (1,0) [0|0] "RotationsPerSecondValue" BLUETOOTH,DRIVER
-BO_ 190 SENSOR_SONAR: 5 SENSOR
+BO_ 110 STOP_CMD: 1 BLUETOOTH
- SG_ Sensor_Sonar_Front : 0|8@1+ (1,0) [0|0] "FrontDistance" DRIVER,MOTOR,BLUETOOTH
+  SG_ BLUETOOTH_STOP_CMD_signal : 0|1@1+ (1,0) [0|0] "Stop=1" DRIVER
-  SG_ Sensor_Sonar_FrontRight : 8|8@1+ (1,0) [0|0] "FRightDistance" DRIVER,MOTOR,BLUETOOTH
- SG_ Sensor_Sonar_FrontLeft : 16|8@1+ (1,0) [0|0] "FLeftDistance" DRIVER,MOTOR,BLUETOOTH
- SG_ Sensor_Sonar_Back : 24|8@1+ (1,0) [0|0] "BackDistance" DRIVER,MOTOR,BLUETOOTH
-BO_ 200 GEO_SEND_LOCATION: 8 GEO
- SG_ Geo_latitude : 0|32@1+ (0.000001,-90.000000) [-90|90] "latitude" DRIVER,BLUETOOTH,MOTOR
- SG_ Geo_longitude : 32|32@1+ (0.000001,-180.000000) [-180|180] "longitude" DRIVER,BLUETOOTH,MOTOR
-BO_ 210 GEO_SEND_HD_BR: 8 GEO
+BO_ 120 MOTOR_SYNC: 1 MOTOR
-  SG_ Geo_heading : 0|29@1+ (0.000001,0) [0|360] "" DRIVER,MOTOR
+  SG_ Motor_Sync : 0|1@1+ (1,0) [0|0] "MotorSync=1" DRIVER
- SG_ Geo_bearing : 29|29@1+ (0.000001,0) [0|360] "" DRIVER,MOTOR
-BO_ 220 NAVIGATION_WAYPOINT: 2 BLUETOOTH
+BO_ 130 GEO_SYNC: 1 GEO
-  SG_ Bluetooth_CurrWaypoint : 0|5@1+ (1,0) [0|0] "CurrentWaypointNumber" DRIVER,GEO
+  SG_ Geo_sync_cmd : 0|1@1+ (1,0) [0|0] "GeoSync=1" DRIVER
- SG_ Bluetooth_NumWaypoint : 5|5@1+ (1,0) [0|0] "NumberOfWaypoints" DRIVER,GEO
+BO_ 140 BLUETOOTH_SYNC_CMD: 1 BLUETOOTH
-BO_ 250 LATITUDE_LONGITUDE: 8 BLUETOOTH
+  SG_ BLUETOOTH_SYNC_CMD_signal : 0|1@1+ (1,0) [0|0] "BluetoothSync=1" DRIVER
-  SG_ Bluetooth_latitude : 0|32@1+ (0.000001,-90.000000) [-90|90] "latitude" DRIVER,GEO
- SG_ Bluetooth_longitude : 32|32@1+ (0.000001,-180.000000) [-180|180] "longitude" DRIVER,GEO
+BO_ 150 SENSOR_SYNC: 1 SENSOR
+  SG_ Sensor_Sync : 0|1@1+ (1,0) [0|0] "SensorSync=1" DRIVER,MOTOR,BLUETOOTH
-BO_ 230 START_CMD: 1 BLUETOOTH
-  SG_ BLUETOOTH_START_CMD_signal : 0|8@1+ (1,0) [0|0] "" DRIVER
-BO_ 240 SENSOR_BATTERY: 8 SENSOR
+BO_ 160 ERROR_COMM_DRIVER: 1 DRIVER
- SG_ Sensor_Battery_Voltage : 0|8@1+ (0.1,0) [0|0] "Volts" DRIVER,MOTOR,BLUETOOTH
+  SG_ Sync_Miss_Info : 0|8@1+ (1,0) [0|0] "ErrorMsgType" MOTOR
-  SG_ Sensor_Battery_SOC : 8|10@1+ (0.1,0) [0|0] "Percent" DRIVER,MOTOR,BLUETOOTH
- SG_ Sensor_Light : 18|10@1+ (0.1,0) [0|0] "LightPercentValue" DRIVER,MOTOR,BLUETOOTH
- SG_ Sensor_Tilt_X : 28|12@1+ (0.1,0) [0|0] "TiltValueX" DRIVER,MOTOR,BLUETOOTH
- SG_ Sensor_Tilt_Y : 40|12@1+ (0.1,0) [0|0] "TiltValueY" DRIVER,MOTOR,BLUETOOTH
-BO_ 500 DRIVER_TEST: 1 DRIVER
+BO_ 170 DRIVER_SYNC_ACK: 1 DRIVER
-  SG_ Driver_Test_Msg : 0|8@1+ (1,0) [0|0] "" MOTOR,GEO,SENSOR,BLUETOOTH
+  SG_ Sync_Miss_Info : 0|1@1+ (1,0) [0|0] "DriverSync=1" MOTOR,BLUETOOTH,SENSOR,GEO
-BO_ 600 MOTOR_TEST: 1 MOTOR
- SG_ Motor_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR,BLUETOOTH
-BO_ 700 SENSOR_TEST: 1 SENSOR
+BO_ 180 MOTOR_CONTROL: 2 DRIVER
-  SG_ Sensor_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GEO,BLUETOOTH
+ SG_ steer : 0|8@1+ (1,0) [0|0] "DirectionType" MOTOR
+ SG_ speed : 8|8@1+ (1,0) [0|0] "SpeedType" MOTOR
+BO_ 181 MOTOR_RPS: 2 MOTOR
+ SG_ Rps_Sensor : 0|8@1+ (1,0) [0|0] "RotationsPerSecondENum" DRIVER,BLUETOOTH
+ SG_ Rps_Value : 8|8@1+ (1,0) [0|0] "RotationsPerSecondValue" BLUETOOTH,DRIVER
+BO_ 190 SENSOR_SONAR: 5 SENSOR
+  SG_ Sensor_Sonar_Front : 0|8@1+ (1,0) [0|0] "FrontDistance" DRIVER,MOTOR,BLUETOOTH
+ SG_ Sensor_Sonar_FrontRight : 8|8@1+ (1,0) [0|0] "FRightDistance" DRIVER,MOTOR,BLUETOOTH
+ SG_ Sensor_Sonar_FrontLeft : 16|8@1+ (1,0) [0|0] "FLeftDistance" DRIVER,MOTOR,BLUETOOTH
+ SG_ Sensor_Sonar_Back : 24|8@1+ (1,0) [0|0] "BackDistance" DRIVER,MOTOR,BLUETOOTH
-BO_ 800 GEO_TEST: 1 GEO
+BO_ 200 GEO_SEND_LOCATION: 8 GEO
-  SG_ Geo_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR,BLUETOOTH
+  SG_ Geo_latitude : 0|32@1+ (0.000001,-90.000000) [-90|90] "latitude" DRIVER,BLUETOOTH,MOTOR
+  SG_ Geo_longitude : 32|32@1+ (0.000001,-180.000000) [-180|180] "longitude" DRIVER,BLUETOOTH,MOTOR
-BO_ 900 BLUETOOTH_TEST: 1 BLUETOOTH
-  SG_ Bluetooth_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GEO,SENSOR
-CM_ BU_ DRIVER "The DRIVER controller driving the car";
-CM_ BU_ MOTOR "The motor controller of the car";
-CM_ BU_ SENSOR "The sensor controller of the car";
-CM_ BU_ GEO "The geo controller of the car";
-CM_ BU_ BLUETOOTH "The bridge controller of the car";
-CM_ BO_ 100 "Sync message used to synchronize the controllers";
-BA_DEF_ "BusType" STRING ;
+BO_ 210 GEO_SEND_HD_BR: 8 GEO
-BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
+ SG_ Geo_heading : 0|29@1+ (0.000001,0) [0|360] "" DRIVER,MOTOR
-BA_DEF_ SG_ "FieldType" STRING ;
+ SG_ Geo_bearing : 29|29@1+ (0.000001,0) [0|360] "" DRIVER,MOTOR
-BA_DEF_DEF_ "BusType" "CAN";
+BO_ 220 NAVIGATION_WAYPOINT: 2 BLUETOOTH
-BA_DEF_DEF_ "FieldType" "";
+ SG_ Bluetooth_CurrWaypoint : 0|5@1+ (1,0) [0|0] "CurrentWaypointNumber" DRIVER,GEO
-BA_DEF_DEF_ "GenMsgCycleTime" 0;
+ SG_ Bluetooth_NumWaypoint : 5|5@1+ (1,0) [0|0] "NumberOfWaypoints" DRIVER,GEO
-BA_ "GenMsgCycleTime" BO_ 500 10;
+BO_ 250 LATITUDE_LONGITUDE: 8 BLUETOOTH
-BA_ "FieldType" SG_ 180 steer "steer";
+ SG_ Bluetooth_latitude : 0|32@1+ (0.000001,-90.000000) [-90|90] "latitude" DRIVER,GEO
-BA_ "FieldType" SG_ 180 speed "speed";
+ SG_ Bluetooth_longitude : 32|32@1+ (0.000001,-180.000000) [-180|180] "longitude" DRIVER,GEO
-BA_ "FieldType" SG_ 181 Rps_Sensor "Rps_Sensor";
-BA_ "FieldType" SG_ 190 Sensor_Sonar_Front "Sensor_Sonar_Front";
-BA_ "FieldType" SG_ 190 Sensor_Sonar_FrontRight "Sensor_Sonar_FrontRight";
-BA_ "FieldType" SG_ 190 Sensor_Sonar_FrontLeft "Sensor_Sonar_FrontLeft";
-BA_ "FieldType" SG_ 190 Sensor_Sonar_Back "Sensor_Sonar_Back";
-VAL_ 190 Sensor_Sonar_Front 3 "far_f" 2 "mid_f" 1 "near_f" 0 "danger_f" ;
+BO_ 230 START_CMD: 1 BLUETOOTH
-VAL_ 190 Sensor_Sonar_FrontRight 2 "far_fr" 1 "mid_fr" 0 "near_fr" ;
+ SG_ BLUETOOTH_START_CMD_signal : 0|8@1+ (1,0) [0|0] "" DRIVER
-VAL_ 190 Sensor_Sonar_FrontLeft 2 "far_fl" 1 "mid_fl" 0 "near_fl" ;
-VAL_ 190 Sensor_Sonar_Back 2 "far_b" 1 "mid_b" 0 "near_b" ;
+BO_ 240 SENSOR_BATTERY: 8 SENSOR
-VAL_ 180 steer 4 "right" 3 "sright" 2 "sleft" 1 "left" 0 "straight" ;
+ SG_ Sensor_Battery_Voltage : 0|8@1+ (0.1,0) [0|0] "Volts" DRIVER,MOTOR,BLUETOOTH
-VAL_ 180 speed 4 "brake" 3 "reverse" 2 "normal" 1 "slow" 0 "stop" ;
+ SG_ Sensor_Battery_SOC : 8|10@1+ (0.1,0) [0|0] "Percent" DRIVER,MOTOR,BLUETOOTH
-VAL_ 181 Rps_Sensor 2 "high" 1 "equal" 0 "low" ;
+ SG_ Sensor_Light : 18|10@1+ (0.1,0) [0|0] "LightPercentValue" DRIVER,MOTOR,BLUETOOTH
-</pre>
+ SG_ Sensor_Tilt_X : 28|12@1+ (0.1,0) [0|0] "TiltValueX" DRIVER,MOTOR,BLUETOOTH
+ SG_ Sensor_Tilt_Y : 40|12@1+ (0.1,0) [0|0] "TiltValueY" DRIVER,MOTOR,BLUETOOTH
+BO_ 500 DRIVER_TEST: 1 DRIVER
+ SG_ Driver_Test_Msg : 0|8@1+ (1,0) [0|0] "" MOTOR,GEO,SENSOR,BLUETOOTH
-== Design & Implementation ==
+BO_ 600 MOTOR_TEST: 1 MOTOR
+ SG_ Motor_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR,BLUETOOTH
-Please refer to the system block diagram below:
+BO_ 700 SENSOR_TEST: 1 SENSOR
-[[File:Cmpe243_F2016_AutoNav_OverallFlow.gif|700px|centre|thumb|System Block Diagram]]
+ SG_ Sensor_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GEO,BLUETOOTH
-===Description===
+BO_ 800 GEO_TEST: 1 GEO
+ SG_ Geo_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR,BLUETOOTH
-Assuming the car would be given the necessary connections and be powered up to navigate, we would give the first signal to start the car from the Bluetooth device by sending a start signal of "1". Once the Start signal is received by the Master controller, it would receive the signals from the sensors and the GPS as well.
-Based on the data from all these systems, Master controller decides the command to be given to the Motor controller. Motor on receiving the instructions from the Master would move in a particular direction suggested by Master. Motor would also revert the path in which it is going, RPM values to Master, Bluetooth and LCD display over the CAN.
+BO_ 900 BLUETOOTH_TEST: 1 BLUETOOTH
-Meanwhile the Bluetooth would be fetching the messages from the CAN and would filter out on the messages by their ID's and later send the required signals such as GPS and RPM values to the Android device, which is displayed to the user in their respective text boxes.
+ SG_ Bluetooth_Test_Msg : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GEO,SENSOR
-===CAN BUS===
-Below is the screenshot of the CAN Bus while Testing the CAR after integration.
+CM_ BU_ DRIVER "The DRIVER controller driving the car";
-[[File:CmpE F16 AutoNav CAN Bus.JPG|700px|center|thumb|CAN BUS]]
+CM_ BU_ MOTOR "The motor controller of the car";
-[[File:CmpE243 F2016 PCAN Dongle.jpg|300px|center|thumb|P-CAN Dongle]]
+CM_ BU_ SENSOR "The sensor controller of the car";
+CM_ BU_ GEO "The geo controller of the car";
+CM_ BU_ BLUETOOTH "The bridge controller of the car";
+CM_ BO_ 100 "Sync message used to synchronize the controllers";
+BA_DEF_ "BusType" STRING ;
+BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
+BA_DEF_ SG_ "FieldType" STRING ;
-P-CAN would be connected to RX-480 Port on the CAR and other end to the system via USB on the system, shown in the image above.This would enable the user to view the CAN messages on the CAN Bus on his screen and would largely help to debug the error on all the controllers.
+BA_DEF_DEF_ "BusType" "CAN";
+BA_DEF_DEF_ "FieldType" "";
+BA_DEF_DEF_ "GenMsgCycleTime" 0;
-== Sensor Controller ==
+BA_ "GenMsgCycleTime" BO_ 500 10;
+BA_ "FieldType" SG_ 180 steer "steer";
-'''Team Members:'''
+BA_ "FieldType" SG_ 180 speed "speed";
- Vishwanath Balakuntla Ramesh
+BA_ "FieldType" SG_ 181 Rps_Sensor "Rps_Sensor";
+BA_ "FieldType" SG_ 190 Sensor_Sonar_Front "Sensor_Sonar_Front";
+BA_ "FieldType" SG_ 190 Sensor_Sonar_FrontRight "Sensor_Sonar_FrontRight";
+BA_ "FieldType" SG_ 190 Sensor_Sonar_FrontLeft "Sensor_Sonar_FrontLeft";
+BA_ "FieldType" SG_ 190 Sensor_Sonar_Back "Sensor_Sonar_Back";
+VAL_ 190 Sensor_Sonar_Front 3 "far_f" 2 "mid_f" 1 "near_f" 0 "danger_f" ;
+VAL_ 190 Sensor_Sonar_FrontRight 2 "far_fr" 1 "mid_fr" 0 "near_fr" ;
+VAL_ 190 Sensor_Sonar_FrontLeft 2 "far_fl" 1 "mid_fl" 0 "near_fl" ;
+VAL_ 190 Sensor_Sonar_Back 2 "far_b" 1 "mid_b" 0 "near_b" ;
+VAL_ 180 steer 4 "right" 3 "sright" 2 "sleft" 1 "left" 0 "straight" ;
+VAL_ 180 speed 4 "brake" 3 "reverse" 2 "normal" 1 "slow" 0 "stop" ;
+VAL_ 181 Rps_Sensor 2 "high" 1 "equal" 0 "low" ;
+</pre>
-<!--{| class="wikitable"
+== Design & Implementation ==
-|-
-! scope="col"| SI No.
+The flow of data from the beginning is shown by the diagram below.
-! scope="col"| Start Date
-! scope="col"| End Date
+[[File:Cmpe243_F2016_AutoNav_OverallFlow.gif|2000px|centre|thumb|System Block Diagram]]
-! scope="col"| Task
-! scope="col"| Status
+===Description===
-! scope="col"| Actual Completion Date
-|-
+Assuming the car would be given the necessary connections and be powered up to navigate, we would give the first signal to start the car from the Bluetooth device by sending a start signal of "1". Once the Start signal is received by the Master controller, it would receive the signals from the sensors and the GPS as well.
-! scope="row"| 1
+Based on the data from all these systems, Master controller decides the command to be given to the Motor controller. Motor on receiving the instructions from the Master would move in a particular direction suggested by Master. Motor would also revert the path in which it is going, RPM values to Master, Bluetooth and LCD display over the CAN.
-| 10/04/2016
+Meanwhile the Bluetooth would be fetching the messages from the CAN and would filter out on the messages by their ID's and later send the required signals such as GPS and RPM values to the Android device, which is displayed to the user in their respective text boxes.
-| 10/11/2016
+===CAN BUS===
-|
+Below is the screenshot of messages from all five controllers on the CAN Bus, as seen in from a PCAN dongle, while testing the CAR after integration.
-* Reading datasheets of multiple sensors, Understand pros and cons of each sensor. Make an Order.
+[[File:CmpE F16 AutoNav CAN Bus.JPG|1152px|left|thumb|CAN BUS]]
-| Completed
+[[File:CmpE243 F2016 PCAN Dongle.jpg|300px|left|thumb|P-CAN Dongle]]
-| 10/10/2016
-|-
+The PCAN dongle would be connected to RX-480 Port on the CAR and other end to a PC via USB.This would enable the user to view the CAN messages on the CAN Bus in real-time on the computer screen and would largely help to debug errors on all the controllers. BusMaster is the software used to decode the messages on the CAN bus.
-! scope="row"| 2
-| 10/12/2016
-| 10/18/2016
-|
-* Write sample code for sensors and experiment with sensor output(filtering).
-| Completed
-| 10/16/2016
-|-
-! scope="row"| 3
-| 10/19/2016
-| 10/25/2016
-|
-* DBC file implementation to establish CAN communication with Master controller.
-* Collaborate with Motor I/O team to achieve basic obstacle avoidance.
-|
-|
-|-
-! scope="row"| 4
-| 10/26/2016
-| 11/6/2016
-|
-* Identify and implement a mechanism to avoid sensors from interfering with each other.
-* Add multiple sensors to the car and work on synchronization between them to achieve more precise obstacle avoidance.
-|
+== Sensor Controller ==
-|
-|-
-! scope="row"| 5
-| 11/8/2016
-| 11/22/2016
-|
-* Design and implement the circuit and software for Car's battery voltage monitoring and determining the State of charge(SOC).
-* Design and implement the software to read light sensor values and Tilt (angle of the car) sensor values.
-|
-|
-|-
-! scope="row"| 6
+'''Team Members:'''
-| 11/23/2016
+ Vishwanath Balakuntla Ramesh
-| 12/5/2016
-|
+<!--{| class="wikitable"
-* Integration testing with Master Controller and other boards.
+|-
-* Optimize the code, Finalize the operation (validate correctness) & Documentation.
+! 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
+| 10/04/2016
+| 10/11/2016
 |
+* Reading datasheets of multiple sensors, Understand pros and cons of each sensor. Make an Order.
+| Completed
+| 10/10/2016
 |-
-|}-->
+! scope="row"| 2
-=== Hardware Design ===
+| 10/12/2016
-We used 3 Parallax Ping ultrasonic distance sensors for obstacle detection and avoidance. Non-contact distance can be measured from about 2 cm (0.8 inches) to 3 meters (3.3 yards).
+| 10/18/2016
+|
-The PING sensor works by transmitting an ultrasonic burst and providing an output pulse that corresponds to the time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.
+* Write sample code for sensors and experiment with sensor output(filtering).
+| Completed
-Three sensors were placed in front (front_left, front_center, front_right).
+| 10/16/2016
-<br>
+|-
+! scope="row"| 3
-[[File:CMPE_243_F16_Autonav_Parralax_Sensor.jpg|300px|centre|thumb|Parallax ping sensor]]
+| 10/19/2016
-<br>
+| 10/25/2016
+|
-=== Hardware Interface ===
+* DBC file implementation to establish CAN communication with Master controller.
+* Collaborate with Motor I/O team to achieve basic obstacle avoidance.
-Three parallax ping sensors are used (front, left and right).
+|
-As shown above, in the hardware design of parallax ping sensor, VCC pin of all the three sensors is connected to 5V, GND is connected to ground and SIG of all the three sensors is connected to P2.0, P2.1, and P2.2 of SJ One board.
+|
-'''Parralax Ping Sensor Operation'''
-[[File:CMPE_243_F16_Autonav_Sensor_Ping_Operation.png|600px|centre|thumb|Sensor Ping Operation]]
-=== Software Design ===
-[[File:Cmpe_243_F16_Autonav_SensorDesign.jpg|700px|centre|thumb|Sensor Fields and Ranges]]
-{| class="wikitable"
-|+ Sensor Controller Tasks
 |-
-! align="center"|Task Name
+! scope="row"| 4
-! align="center"|Purpose
+| 10/26/2016
+| 11/6/2016
+|
+* Identify and implement a mechanism to avoid sensors from interfering with each other.
+* Add multiple sensors to the car and work on synchronization between them to achieve more precise obstacle avoidance.
+|
+|
 |-
-| Period Init
+! scope="row"| 5
-| Enable and initialize LPC timer, Initialize CAN, rising and falling edge of GPIO Interrupt
+| 11/8/2016
+| 11/22/2016
+|
+* Design and implement the circuit and software for Car's battery voltage monitoring and determining the State of charge(SOC).
+* Design and implement the software to read light sensor values and Tilt (angle of the car) sensor values.
+|
+|
 |-
-| Periodic 1Hz Callback
-| Check can bus off
+! scope="row"| 6
+| 11/23/2016
+| 12/5/2016
+|
+* Integration testing with Master Controller and other boards.
+* Optimize the code, Finalize the operation (validate correctness) & Documentation.
+|
+|
 |-
-| Periodic 10Hz Callback
+|}-->
-| Get and Send Sensor Data
-|-
+The sensor controller is one of the main controllers in the car, which enables the obstacle avoidance feature. There are multiple sensors available in the market, which can used to detect obstacles. The sensor controller may use IR sensor, ultrasonic sensors, sonar, lidar etc,. In our case w make use of Parallax ping sensor due to following reasons:
-|}
+. Ease of usage: Same pin for Echo and input pulse.
+. High S/N ratio: The signal to noise ratio is too high. The sensor does not abruptly issue any spike in its signal. More reliable and stable.
-<br>
+=== Hardware Design ===
-<syntaxhighlight lang="C">
+We used 3 Parallax Ping ultrasonic distance sensors for obstacle detection and avoidance. Non-contact distance can be measured from about 2 cm (0.8 inches) to 3 meters (3.3 yards).
-Sensor_Sonar_Front_E calculate_range_front(double distance)
-{
-	if(distance>5&&distance<120)
-		return danger_f;
-	else if(distance<180)
+The PING sensor works by transmitting an ultrasonic burst and providing an output pulse that corresponds to the time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.
-		return near_f;
-	else if(distance<250)
+Three sensors were placed in front (front_left, front_center, front_right).
-		return mid_f;
+<br>
-	else
+[[File:CMPE_243_F16_Autonav_Parralax_Sensor.jpg|300px|centre|thumb|Parallax ping sensor]]
-		return far_f;
+<br>
-}
+=== Hardware Interface ===
-Sensor_Sonar_FrontRight_E calculate_range_frontRight(double distance)
+Three parallax ping sensors are used (front, left and right).
-{
+As shown above, in the hardware design of parallax ping sensor, VCC pin of all the three sensors is connected to 5V, GND is connected to ground and SIG of all the three sensors is connected to P2.0, P2.1, and P2.2 of SJ One board.
-	if(distance<100)
-		return near_fr;
-	else if(distance<200)
-		return mid_fr;
-	else
+[[File:CMPE_243_F16_Autonav_Sensor_Ping_Operation.png|600px|centre|thumb|Parallax Ping Sensor Operation]]
-		return far_fr;
-}
+=== Software Design ===
-Sensor_Sonar_FrontLeft_E calculate_range_frontLeft(double distance)
+[[File:Cmpe_243_F16_Autonav_SensorDesign.jpg|700px|centre|thumb|Sensor Fields and Ranges]]
-{
-	if(distance<100)
-		return near_fl;
-	else if(distance<200)
+{| class="wikitable"
-		return mid_fl;
+|+ Sensor Controller Tasks
+|-
-	else
+! align="center"|Task Name
-		return far_fl;
+! align="center"|Purpose
-}
+|-
+| Period Init
+| Enable and initialize LPC timer, Initialize CAN, rising and falling edge of GPIO Interrupt
-void start_trigger(GPIO trigger)
+|-
-{
+| Periodic 1Hz Callback
-	trigger.setAsOutput();
+| Check can bus off
-	trigger.setHigh();
+|-
-	delay_us(5);
+| Periodic 10Hz Callback
-	trigger.setLow();
+| Get and Send Sensor Data
-}
+|-
-</syntaxhighlight>
+|}
-<BR/>
-=== Implementation ===
-[[File:Cmpe_243_F16_Autonav_SensorFlowDiagram.jpg|700px|centre|thumb|Sensor Controller Flow Diagram]]
+<br>
+<syntaxhighlight lang="C">
+Sensor_Sonar_Front_E calculate_range_front(double distance)
+{
+	if(distance>5&&distance<120)
+		return danger_f;
-== '''Motor & I/O Controller''' ==
+	else if(distance<180)
-'''Team Members:'''
+		return near_f;
- [https://www.linkedin.com/in/sameersaran97 Sameer Saran]
- Jaswanth Bhimanapalli
-=== Hardware Design ===
+	else if(distance<250)
+		return mid_f;
-[[File:Cmpe243_F2016_AutoNav_HW_Interface.png|700px|thumb|centre|Block Diagram for Motor]]
+	else
+		return far_f;
+}
-=== Hardware/Software Interface ===
-====I/O Interface - LCD====
+Sensor_Sonar_FrontRight_E calculate_range_frontRight(double distance)
-<br>
+{
-The LCD is used to display some of the features to its application in our project.The sensor, GPS and current coordinates are displayed on LCD. 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 angulometer. 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 angulometer. 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.
+	if(distance<100)
+		return near_fr;
-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.
+	else if(distance<200)
-http://www.4dsystems.com.au/product/uLCD_32PTU/
+		return mid_fr;
-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
-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 angulometer. 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.
+	else
+		return far_fr;
+}
+Sensor_Sonar_FrontLeft_E calculate_range_frontLeft(double distance)
+{
+	if(distance<100)
+		return near_fl;
+	else if(distance<200)
+		return mid_fl;
-Below are the snaps of the LCD Screens:
+	else
-{|
+		return far_fl;
-|[[File:Cmpe243_F2016_AutoNav_LCD_Screen1.JPG|200px|left|thumb|LCD Screen 1]]
+}
-|[[File:Cmpe243_F2016_AutoNav_LCD_Screen2.JPG|200px|right|thumb|LCD Screen 2]]
-|[[File:Cmpe243_F2016_AutoNav_LCD_Screen3.JPG|200px|right|thumb|LCD Screen 3]]
-|[[File:Cmpe243_F2016_AutoNav_LCD_Screen4.JPG|200px|right|thumb|LCD Screen 4]]
-|[[File:Cmpe243_F2016_AutoNav_LCD_Screen5.JPG|200px|right|thumb|LCD Screen 5]]
-|}
-{| class="wikitable"
-|+ LCD Screens Table
-|-
-! align="center"|Screen No.
-! align="center"|Description
-|-
-| 1
-| Welcome Screen
-|-
-| 2
-| Displaying the menu
-|-
-| 3
-| Displaying Sensor data
-|-
-| 4
-| Displaying motor data
-|-
-| 5
-| Displaying data to debug along with GPS data
-|-
-|}
-[[File:CMPE_243_F16_LDCFlowchart.png|350px|centre|thumb|LCD Flowchart]]
-==== Motor Control Hardware/Software Interface ====
-==== Tasks ====
+void start_trigger(GPIO trigger)
-{| class="wikitable"
+{
-|+ Motor/IO Controller Tasks
+	trigger.setAsOutput();
-|-
+	trigger.setHigh();
-! align="center"|Task Name
+	delay_us(5);
-! align="center"|Purpose
+	trigger.setLow();
-|-
+}
-| Period Init
+</syntaxhighlight>
-| Initializing CAN bus, Motor, Interrupt for Motor Feedback and UART for LCD
+<BR/>
-|-
-| Periodic 1Hz Callback
-| Displaying data on LCD and checking for CAN bus off
-|-
-| Periodic 10Hz Callback
-| Interpreting data from Master controller, driving car, calculating RPM
-|-
-|}
-|[[File:CMPE_243_F16_MotorFlowchart.png|350px|centre|thumb|Motor Control Flowchart]]
-=== Brushless DC Motor ===
+=== Implementation ===
-<table>
+[[File:Cmpe_243_F16_Autonav_SensorFlowDiagram.jpg|700px|centre|thumb|Sensor Controller Flow Diagram]]
-<tr>
-<td valign="top" align="justify" width=600px>
+== '''Motor & I/O Controller''' ==
-Our car came with 3650 Brushless inrunner motor, 2080KV with 60A ESC(with Reverse). This motor has the power to run the car at a maximum speed of the 35mph.<br><br>
+'''Team Members:'''
-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>
+ [https://www.linkedin.com/in/sameersaran97 Sameer Saran]
+ Jaswanth Bhimanapalli
+=== Hardware Design ===
+[[File:Cmpe243_F2016_AutoNav_HW_Interface.png|700px|thumb|centre|Block Diagram for Motor]]
+=== Hardware/Software Interface ===
-{| class="wikitable"
+====I/O Interface - LCD====
-|-
+<br>
-! align="center"|S.R.
+The LCD is used to display some of the features to its application in our project.The sensor, GPS and current coordinates are displayed on LCD. 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 angulometer. 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 angulometer. 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.
-! align="center"|Duty Cycle
-! align="center"|Speed Control
+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/
-! scope="row" align="center"|1
+Next link is to the to the collection of go through materials for each every object the LCD uses.
-| scope="row" align="center"|7.5
+http://old.4dsystems.com.au/appnotes.php
-| scope="row" align="center"|Stop
-|-
-! scope="row" align="center"|2
-| scope="row" align="center"|7.77
-| scope="row" align="center"|Slow
-|-
-! scope="row" align="center"|3
-| scope="row" align="center"|7.81
-| scope="row" align="center"|Normal
-|-
-! scope="row" align="center"|4
-| scope="row" align="center"|7.30
-| scope="row" align="center"|Reverse
-|-
-! scope="row" align="center"|5
-| scope="row" align="center"|5.5
-| scope="row" align="center"|Brake
-|-
-|}
-Table3: DC Motor Duty Cycle v/s Speed Control
-</td>
+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 angulometer. 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.
-<td align="center">
-[[File:CMPE_243_Autonav_Brushless_Motor.jpeg|300px]]<br>
-Brushless DC Motor
-</td>
-</tr>
-</table>
-<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.
+Below are the snaps of the LCD Screens:
+{|
+|[[File:Cmpe243_F2016_AutoNav_LCD_Screen1.JPG|200px|left|thumb|LCD Screen 1]]
+|[[File:Cmpe243_F2016_AutoNav_LCD_Screen2.JPG|200px|right|thumb|LCD Screen 2]]
+|[[File:Cmpe243_F2016_AutoNav_LCD_Screen3.JPG|200px|right|thumb|LCD Screen 3]]
+|[[File:Cmpe243_F2016_AutoNav_LCD_Screen4.JPG|200px|right|thumb|LCD Screen 4]]
+|[[File:Cmpe243_F2016_AutoNav_LCD_Screen5.JPG|200px|right|thumb|LCD Screen 5]]
+|}
 {| class="wikitable"
+|+ LCD Screens Table
 |-
-! align="center"|S.R.
+! align="center"|Screen No.
-! align="center"|ESC Wire Pins
+! align="center"|Description
-! align="center"|SJOne Board Pins
 |-
-! scope="row" align="center"|1
+| 1
-| scope="row" align="center"|Vcc
+| Welcome Screen
-| scope="row" align="center"|-
+|-
+| 2
+| Displaying the menu
+|-
+| 3
+| Displaying Sensor data
 |-
-! scope="row" align="center"|2
+| 4
-| scope="row" align="center"|GND
+| Displaying motor data
-| scope="row" align="center"|GND
 |-
-! scope="row" align="center"|3
+| 5
-| scope="row" align="center"|Speed Control
+| Displaying data to debug along with GPS data
-| scope="row" align="center"|P2.1
 |-
 |}
-DC Motor Pin Connections
+[[File:CMPE_243_F16_LDCFlowchart.png|350px|centre|thumb|LCD Flowchart]]
-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.
+==== Motor Control Hardware/Software Interface ====
-=== Motor Feedback ===
+==== Tasks ====
-Initially we used to calculate feedback at 1Hz using one magnet and a telemetry sensor and if the current RPM was less than required RPM then we used to switch to the higher hard coded PWM value, But since the DC motor was dependent on the battery's state of charge. We had to redesign the Motor Feedback, we added more magnets so that we get enough data so that we can react at a faster rate of 10Hz.
+{| class="wikitable"
-To make the DC motor's speed independent of state of charge and dependent only on RPM we changed the Motors's Algorithm.
+|+ Motor/IO Controller Tasks
+|-
+! align="center"|Task Name
+! align="center"|Purpose
+|-
+| Period Init
+| Initializing CAN bus, Motor, Interrupt for Motor Feedback and UART for LCD
+|-
+| Periodic 1Hz Callback
+| Displaying data on LCD and checking for CAN bus off
+|-
+| Periodic 10Hz Callback
+| Interpreting data from Master controller, driving car, calculating RPM
+|-
+|}
+|[[File:CMPE_243_F16_MotorFlowchart.png|350px|centre|thumb|Motor Control Flowchart]]
+=== Brushless DC Motor ===
-Below is the Code snippet of DC Controller
+<table>
-<br>
+<tr>
-<syntaxhighlight lang="C">
+<td valign="top" align="left" width=600px>
-void drive_DC(speed_E speed,int rpm)
+Our car came with 3650 Brushless inrunner motor, 2080KV with 60A ESC(with Reverse). 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>
-	if(speed==reverse)
-	{
-        //Set DC to Reverse PWM Value
-	}
-	else if (speed==brake)
-	{
-	//Set DC to Brake PWM Value
-	}
-	else if (speed == stop)
-	{
-	//Set DC to Stop/Idle PWM Value
-	}
-	else
-	{
-	        ReqRPM=get_rpm(speed);
-		if(DC Value id with in safe range)
+{| class="wikitable"
-		{
+|-
-			if(rpm>ReqRPM)
+! align="center"|S.R.
-			{
+! align="center"|Duty Cycle
-			//If current RPM is greater then Required RPM then Reduce Speed
+! align="center"|Speed Control
-			}
+|-
-			else if(rpm<ReqRPM)
+! scope="row" align="center"|1
-			{
+| scope="row" align="center"|7.5
-			//If current RPM is lesser then Required RPM then Increase  Speed
+| scope="row" align="center"|Stop
-			}
+|-
+! scope="row" align="center"|2
-			else if(rpm==ReqRPM)
+| scope="row" align="center"|7.77
-			{
+| scope="row" align="center"|Slow
-		        //If current RPM is equal to required RPM the maintain same Speed
+|-
-			}
+! scope="row" align="center"|3
-		}
+| scope="row" align="center"|7.81
-	}
+| scope="row" align="center"|Normal
+|-
-}
+! scope="row" align="center"|4
-</syntaxhighlight>
+| scope="row" align="center"|7.30
-<BR/>
+| scope="row" align="center"|Reverse
+|-
+! scope="row" align="center"|5
+| scope="row" align="center"|5.5
+| scope="row" align="center"|Brake
+|-
+|}
+Table3: DC Motor Duty Cycle v/s Speed Control
+</td>
+<td align="left">
+[[File:CMPE_243_Autonav_Brushless_Motor.jpeg|400px]]<br>
+Brushless DC Motor
 </td>
 </tr>
 </table>
-=== Servo Motor ===
 <table>
 <tr>
 <td valign="top" align="justify" width=600px>
-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.
+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.
 {| class="wikitable"
 |-
 ! align="center"|S.R.
-! align="center"|Duty Cycle
+! align="center"|ESC Wire Pins
-! align="center"|Turn
+! align="center"|SJOne Board Pins
 |-
 ! scope="row" align="center"|1
-| scope="row" align="center"|8.5
+| scope="row" align="center"|Vcc
-| scope="row" align="center"|Hard Left
+| scope="row" align="center"|-
 |-
 ! scope="row" align="center"|2
-| scope="row" align="center"|8
+| scope="row" align="center"|GND
-| scope="row" align="center"|Slight Left
+| scope="row" align="center"|GND
 |-
 ! scope="row" align="center"|3
-| scope="row" align="center"|7.5
+| scope="row" align="center"|Speed Control
-| scope="row" align="center"|Straight
+| scope="row" align="center"|P2.1
-|-
-! scope="row" align="center"|4
-| scope="row" align="center"|6.5
-| scope="row" align="center"|Slight Right
-|-
-! scope="row" align="center"|5
-| scope="row" align="center"|6.0
-| scope="row" align="center"|Hard Right
 |-
 |}
-Servo Motor Duty Cycle v/s Turn
+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.
-</td>
+=== Motor Feedback ===
-<td align="center">
+Initially we used to calculate feedback at 1Hz using one magnet and a telemetry sensor and if the current RPM was less than required RPM then we used to switch to the higher hard coded PWM value, But since the DC motor was dependent on the battery's state of charge. We had to redesign the Motor Feedback, we added more magnets so that we get enough data so that we can react at a faster rate of 10Hz.
-[[File:CMPE_243_F16_Autonav_Servo_motor.gif|250px]]<br>
+To make the DC motor's speed independent of state of charge and dependent only on RPM we changed the Motors's Algorithm.
-Servo Motor
-</td>
-</tr>
-</table>
-<table>
+Below is the Code snippet of DC Controller
-<tr>
+<br>
-<td valign="top" align="justify" width=600px>
+<syntaxhighlight lang="C">
-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.
+void drive_DC(speed_E speed,int rpm)
+{
-{| class="wikitable"
+	if(speed==reverse)
-|-
+	{
-! align="center"|S.R.
+        //Set DC to Reverse PWM Value
-! align="center"|Servo Motor Pins
+	}
-! align="center"|SJOne Board Pins
+	else if (speed==brake)
-|-
+	{
-! scope="row" align="center"|1
+	//Set DC to Brake PWM Value
-| scope="row" align="center"|Vcc
+	}
-| scope="row" align="center"|Vcc
+	else if (speed == stop)
-|-
+	{
-! scope="row" align="center"|2
+	//Set DC to Stop/Idle PWM Value
-| scope="row" align="center"|GND
+	}
-| scope="row" align="center"|GND
+	else
-|-
+	{
-! scope="row" align="center"|3
+	        ReqRPM=get_rpm(speed);
-| scope="row" align="center"|Direction Control
-| scope="row" align="center"|P2.0
+		if(DC Value id with in safe range)
-|-
+		{
-|}
+			if(rpm>ReqRPM)
-Servo Motor Pin Connections
+			{
+			//If current RPM is greater then Required RPM then Reduce Speed
+			}
+			else if(rpm<ReqRPM)
+			{
+			//If current RPM is lesser then Required RPM then Increase  Speed
+			}
+			else if(rpm==ReqRPM)
+			{
+		        //If current RPM is equal to required RPM the maintain same Speed
+			}
+		}
+	}
+}
+</syntaxhighlight>
+<BR/>
-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.
 </td>
-<td align="center">
+</tr>
-[[File:Motor_cnt1.png|300px]]<br>
-Servo Motor Connector
-</td>
-</tr>
 </table>
-<syntaxhighlight lang="C">
+=== Servo Motor ===
-class MotorCtrl : public SingletonTemplate<MotorCtrl>
+<table>
-{
+<tr>
-	public:
+<td valign="top" align="justify" width=600px>
-		MotorCtrl() : steerServo(PWM::pwm1),driveDc(PWM::pwm2)
+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.
-		{
-			//Constructor
-		}
-		void set_servo(float value) {steerServo.set(value);}
-		void set_dc(float value){driveDc.set(value);}
-		friend class SingletonTemplate<MotorCtrl>;
-	private:
+{| class="wikitable"
-		PWM steerServo;
+|-
-		PWM driveDc;
+! align="center"|S.R.
+! align="center"|Duty Cycle
-};
+! align="center"|Turn
+|-
-#define MotorCtrl MotorCtrl::getInstance()
+! scope="row" align="center"|1
+| scope="row" align="center"|8.5
-</syntaxhighlight>
+| scope="row" align="center"|Hard Left
-== Bluetooth and Bridge(Android) Connections ==
-'''Team Members:'''
- Sucharitha Sirigreddy
- Karthikeya Rao G V
-This section includes high level implementation details regarding the Android app connectivity with the Bluetooth module of the RC car. It gives a overview of building the android app, communication between the Bluetooth and Android app on a mobile device, and routing mechanisms during the navigation.
-==== Bluetooth Controller Pin Connections ====
-{| class="wikitable"
 |-
-! scope="col"| Node A Source
+! scope="row" align="center"|2
-! scope="col"| Node A Pin
+| scope="row" align="center"|8
-! scope="col"| Node B Source
+| scope="row" align="center"|Slight Left
-! scope="col"| Node B Pin
-! scope="col"| Description
 |-
-! scope="row"| Power Supply
+! scope="row" align="center"|3
-| 3.3V
+| scope="row" align="center"|7.5
-| SJOne Board
+| scope="row" align="center"|Straight
-| 3V3
-| SJOne Power
 |-
+! scope="row" align="center"|4
+| scope="row" align="center"|6.5
+| scope="row" align="center"|Slight Right
 |-
-! scope="row"| Power Supply
+! scope="row" align="center"|5
-| GND
+| scope="row" align="center"|6.0
-| SJOne Board
+| scope="row" align="center"|Hard Right
-| GND
-| SJOne Ground
 |-
+|}
+Servo Motor Duty Cycle v/s Turn
+</td>
+<td align="center">
+[[File:CMPE243_F16_Autonav_Servo-Motor.jpg|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"
 |-
-! scope="row"| CAN Transceiver
+! align="center"|S.R.
-| CAN Tx
+! align="center"|Servo Motor Pins
-| SJOne Board
+! align="center"|SJOne Board Pins
-| P0.1 (Tx)
-| SJOne - CAN Tx
 |-
+! scope="row" align="center"|1
+| scope="row" align="center"|Vcc
+| scope="row" align="center"|Vcc
 |-
-! scope="row"| CAN Transceiver
+! scope="row" align="center"|2
-| CAN Rx
+| scope="row" align="center"|GND
-| SJOne Board
+| scope="row" align="center"|GND
-| P0.0 (Rx)
-| SJOne - CAN Rx
-|-
 |-
-! scope="row"| Bluetooth Module
+! scope="row" align="center"|3
-| TXD
+| scope="row" align="center"|Direction Control
-| SJOne Board
+| scope="row" align="center"|P2.0
-| RXD3
-| SJOne RX3-  Bluetooth module TXD
 |-
-|-
+|}
-! scope="row"| Bluetooth Module
+Servo Motor Pin Connections
-| RXD
-| SJOne Board
+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.
-| TXD3
+</td>
-| SJOne TX3-  Bluetooth module RXD
+<td align="center">
-|-
+[[File:Motor_cnt1.png|300px]]<br>
-|-
+Servo Motor Connector
-! scope="row"| Bluetooth Module
+</td>
-| Bluetooth module VCC(3.3V)
+</tr>
-| Power Supply
+</table>
-| 3.3V
-| Bluetooth module - Power supply 3.3V
-|-
-|-
-! scope="row"| Bluetooth Module
-| Bluetooth module GND
-| Power Supply
-| GND
-| Bluetooth module - Power supply GND
-|-
-|}
-Below attached is the image of the Bluetooth Module HC-06.
+<syntaxhighlight lang="C">
-[[File:CmpE243_F2016_AutoNav_HC-06.jpg|400px|center|thumb|Bridge Controller Design]]
+class MotorCtrl : public SingletonTemplate<MotorCtrl>
+{
+	public:
+		MotorCtrl() : steerServo(PWM::pwm1),driveDc(PWM::pwm2)
+		{
+			//Constructor
+		}
+		void set_servo(float value) {steerServo.set(value);}
+		void set_dc(float value){driveDc.set(value);}
+		friend class SingletonTemplate<MotorCtrl>;
-=== Hardware Interface ===
+	private:
+		PWM steerServo;
+		PWM driveDc;
-Below is the representation of the bridge communication.
+};
-[[File:Cmpe243_F2016_AutoNav_BluetoothAndroidInterface.JPG|700px|center|thumb|Bridge Controller Design]]
-Hardware Interface between the Bluetooth controller and the car system has been wired through the CAN bus.
+#define MotorCtrl MotorCtrl::getInstance()
-P0.1 is connected to CAN Tx and P0.0 is connected to CAN Rx, where communication between the Bluetooth module and other modules happen.
-RXD and TXD pins are connected to Bluetooth HC-06 to enable communication between the Android mobile device and the Bluetooth module.
-Power supply and Ground pins to SJone board i.e Bluetooth module is provided by battery, which would power up all the SJone boards.
-Power to the HC-06 module is given by the SJone Bluetooth board 3.3V and GND pins.
-Thus enabling the Interface between Bluetooth module and the other controllers.
-=== Software Design ===
+</syntaxhighlight>
-Software interface between HC-06 and Android device is enabled via Bluetooth transmission and reception.
+== Bluetooth and Bridge(Android) Connections ==
+'''Team Members:'''
+ Sucharitha Sirigreddy
+ Karthikeya Rao G V
-Below attached is the image showing the Android Application Development.
+This section includes high level implementation details regarding the Android app connectivity with the Bluetooth module of the RC car. It gives a overview of building the android app, communication between the Bluetooth and Android app on a mobile device, and routing mechanisms during the navigation.
-[[File:Cmpe243_F2016_AutoNav_BluetoothAppDevelopment.JPG|700px|centre|thumb|Stages of Android Application Development]]
-Initially we developed the Application with just Enable and Disable Bluetooth Buttons, after which we added the Start and Stop Signals Button.
-Start and Stop buttons were given the functionality to send "1" and "0" respectively.
-In the next phase, we integrated the application with Google maps with few more buttons and obtained our location from the Google maps and cell phone GPS and marked our location on the App screen.
-In the Final phase we were able to display the application with all the values which we received from the Bluetooth controller, which includes RPS and Locations.
-Below diagram represents the different app screens in the selection sequence.
-[[File:Cmpe243_F2016_AutoNav_BluetoothAppOperationSequence.JPG|700px|centre|thumb|Android Application Screens]]
-In the above image, we initially turn on the Bluetooth device. Once done, we set up the start and destination on the map, marked as red and green flags respectively. Clicking on the Start signal would enable the Car to receive the Signals Route button would send out the way points to the Bluetooth controller and the Master sending the signal to move the car in the way points direction.
+==== Bluetooth Controller Pin Connections ====
-====Flow Chart:====
-Flow Chart of the Bluetooth and Android design is as follows.
-[[File:Cmpe243 F2016 AutoNav BluetoothFlow.jpg|700px|centre|thumb|Android and Bluetooth Controller Flow Chart]]
-'''  Android-Bluetooth Controller Button's Functionality Table'''
 {| class="wikitable"
 |-
-! align="center"|SI No.
+! scope="col"| Node A Source
-! align="center"|Button
+! scope="col"| Node A Pin
-! align="center"|Functionality
+! scope="col"| Node B Source
+! scope="col"| Node B Pin
+! scope="col"| Description
+|-
+! scope="row"| Power Supply
+| 3.3V
+| SJOne Board
+| 3V3
+| SJOne Power
 |-
-| 1
-| BTON
-| User is prompted to Turn on Bluetooth device on the phone. User can either "allow" or "deny" the request. Application won't work till the request is allowed.
 |-
-| 2
+! scope="row"| Power Supply
-| START
+| GND
-| Sends string 1 over Bluetooth channel to indicate to to Master Controller to start of car.
+| SJOne Board
+| GND
+| SJOne Ground
 |-
-| 3
-| STOP CAR
-| Sends string 0 over Bluetooth channel to indicate to Master Controller to stop the car(Wireless Kill switch).
 |-
-| 4
+! scope="row"| CAN Transceiver
-| BTOFF
+| CAN Tx
-| Turns off the Bluetooth of the Android device.
+| SJOne Board
+| P0.1 (Tx)
+| SJOne - CAN Tx
 |-
-| 5
-|LOC
-| Places a marker on Google Map based on cars Latitude and Longitude received from the GEO module on the car.
 |-
-| 6
+! scope="row"| CAN Transceiver
-| ROUTE
+| CAN Rx
-| Send route from source to destination selected on map after filtering way-points to the Bluetooth Controller and to GEO controller there on.
+| SJOne Board
+| P0.0 (Rx)
+| SJOne - CAN Rx
+|-
 |-
-|}
+! scope="row"| Bluetooth Module
+| TXD
-=== Implementation ===
+| SJOne Board
-====BT connection establishment====
+| RXD3
+| SJOne RX3-  Bluetooth module TXD
+|-
+|-
+! scope="row"| Bluetooth Module
+| RXD
+| SJOne Board
+| TXD3
+| SJOne TX3-  Bluetooth module RXD
+|-
+|-
+! scope="row"| Bluetooth Module
+| Bluetooth module VCC(3.3V)
+| Power Supply
+| 3.3V
+| Bluetooth module - Power supply 3.3V
+|-
+|-
+! scope="row"| Bluetooth Module
+| Bluetooth module GND
+| Power Supply
+| GND
+| Bluetooth module - Power supply GND
+|-
+|}
-Through the Android application the Bluetooth would be paired with HC-06 module on click of BTon button, which turns on the Bluetooth on the android phone and connects to Car’s HC-06 Bluetooth device.
+Below attached is the image of the Bluetooth Module HC-06.
-Post which, we would send a start signal from the app, which would sync and start the car. This signal is encoded before sending from the android. This signal when received from the Bluetooth module, would decode and read the message and later encode and pass it on over the CAN to the Master.
+[[File:CmpE243_F2016_AutoNav_HC-06.jpg|400px|center|thumb|Bridge Controller Design]]
-====Communication between BT and other controllers====
+=== Hardware Interface ===
-BT Application and BT controller communicates over UART at 9600 bits/sec baud rate,as HC-06 operates at that baud rate.
+Below is the representation of the bridge communication.
+[[File:Cmpe243_F2016_AutoNav_BluetoothAndroidInterface.JPG|700px|center|thumb|Bridge Controller Design]]
-======Send data to Application======
+Hardware Interface between the Bluetooth controller and the car system has been wired through the CAN bus.
+P0.1 is connected to CAN Tx and P0.0 is connected to CAN Rx, where communication between the Bluetooth module and other modules happen.
+RXD and TXD pins are connected to Bluetooth HC-06 to enable communication between the Android mobile device and the Bluetooth module.
+Power supply and Ground pins to SJone board i.e Bluetooth module is provided by battery, which would power up all the SJone boards.
+Power to the HC-06 module is given by the SJone Bluetooth board 3.3V and GND pins.
+Thus enabling the Interface between Bluetooth module and the other controllers.
-Bluetooth controller communicates with other controllers through CAN.Once BT App installed on mobile,App requests for BT permissions from user.Once allowed to access BT on the mobile phone, App can send and receive messages over UART.CAN messages received from other modules are decoded and the corresponding message is sent to BT application with the specified character sequence through UART.
+=== Software Design ===
-Ex:RPS value from the Motor controller is sent to Bluetooth controller is sent as "r" followed by "!" "<rps value>".IN this sequence "r" is the identification command for the rps value that is being sent from the motor and "!" is delimiter to indicate the app that the next characters are the received values from the motor.This characters are displayed in a text area on app under the heading RPM. Every time the app receives rpm value,the same is displayed on the text section assigned for the RPM on the app.Similarly Sensor,Geo controller sends right sensor value and geo co-ordinates respectively.These are displayed on the allocated text areas on the application.
-======Receive data from application======
+Software interface between HC-06 and Android device is enabled via Bluetooth transmission and reception.
-Based on the commands(button press on the application) send to the app,it will respond with the appropriate data.A thread starts running once START command on the application is pressed,this threads is alive till the application is closed.This is a way for the controller to know that Bluetooth connection is intact between BT app and controller.Any data sent to application is always listened through socket communication and the application responds if any command is programmed fro the received message.
+Below attached is the image showing the Android Application Development.
-A circular buffer at the receiver part of the application is useful for the data to be received without corruption.Application sends data through socket communication at faster rate than that BT controller receive,hence buffer at the controller should be able to store the data received from application.
+[[File:Cmpe243_F2016_AutoNav_BluetoothAppDevelopment.JPG|700px|centre|thumb|Stages of Android Application Development]]
-======Sending route to SJone board======
+Initially we developed the Application with just Enable and Disable Bluetooth Buttons, after which we added the Start and Stop Signals Button.
+Start and Stop buttons were given the functionality to send "1" and "0" respectively.
+In the next phase, we integrated the application with Google maps with few more buttons and obtained our location from the Google maps and cell phone GPS and marked our location on the App screen.
+In the Final phase we were able to display the application with all the values which we received from the Bluetooth controller, which includes RPS and Locations.
-Route Button on the app would be initiated once we set the source and destination by 2 clicks on the maps in the app and start getting the location details  from HC-06.  Route Button ,on click would send the location from the car and send out next way points till the destination.
+Below diagrams represent the different app screens in the selection sequence.
-The Kill switch is implemented as Stop Button, which sends of “0” signal, which is received by the Bluetooth and sent over the CAN Bus to master, to stop the Motor.
+  {|
+   |[[File:CMPE_243_F16_Autonav_Screen1.png‎|left|250px|thumb|Pairing with Bluetooth]]
+   |[[File:CMPE_243_F16_Autonav_Screen2.png‎|center|250px|thumb|Destination set]]
+   |[[File:CMPE_243_F16_Autonav_Screen3.png‎|right|250px|thumb|Displaying CAN data]]
+  |}
-======Code snippet to send rpm data to App======
+In the above image, we initially turn on the Bluetooth device. Once done, we set up the start and destination on the map, marked as red and green flags respectively. Clicking on the Start signal would enable the Car to receive the Signals Route button would send out the way points to the Bluetooth controller and the Master sending the signal to move the car in the way points direction.
-<syntaxhighlight lang="c">
+====Flow Chart:====
+Flow Chart of the Bluetooth and Android design is as follows.
+[[File:Cmpe243 F2016 AutoNav BluetoothFlow.jpg|700px|centre|thumb|Android and Bluetooth Controller Flow Chart]]
- if (dbc_decode_MOTOR_RPS(&motorrps, can_receive.data.bytes,&can_msg_hdr))
-    {
-         char a[3] ={ 0 };
+'''  Android-Bluetooth Controller Button's Functionality Table'''
-         sprintf(a, "%d",  motorrps.Rps_Value);
-         u3.putChar('r', 0);
-         u3.putChar('!', 0);
-         u3.putline(a, 0);
-         u3.putChar('!', 0);
-         LE.off(1);
-   }
+{| class="wikitable"
-</syntaxhighlight>
+|-
+! align="center"|SI No.
-== Geographical Controller ==
+! align="center"|Button
-'''Team Members:'''
+! align="center"|Functionality
- Veena Manasa Kanakamalla
+|-
- Arpita Ramanath
+| 1
+| BTON
-=== Hardware Design ===
+| User is prompted to Turn on Bluetooth device on the phone. User can either "allow" or "deny" the request. Application won't work till the request is allowed.
+|-
-'''System Block Diagram'''
+| 2
+| START
-SJ One board is interfaced to GPS module and IMU through UART.
+| Sends string 1 over Bluetooth channel to indicate to to Master Controller to start of car.
+|-
-[[File:CmpE243_F16_AutoNav_GeoController_HWInterface.jpg|500px|thumb|centre|Hardware Interface of GeoController]]
+| 3
+| STOP CAR
+| Sends string 0 over Bluetooth channel to indicate to Master Controller to stop the car(Wireless Kill switch).
+|-
+| 4
+| BTOFF
+| Turns off the Bluetooth of the Android device.
+|-
+| 5
+|LOC
+| Places a marker on Google Map based on cars Latitude and Longitude received from the GEO module on the car.
+|-
+| 6
+| ROUTE
+| Send route from source to destination selected on map after filtering way-points to the Bluetooth Controller and to GEO controller there on.
+|-
+|}
-=== Geographical Controller Hardware Design Components ===
+=== Implementation ===
-<table>
+====BT connection establishment====
-<tr>
-<td valign="top" align="justify" width=550px>
-<b>Adafruit MTK3339 GPS:</b>
-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.
+Through the Android application the Bluetooth would be paired with HC-06 module on click of BTon button, which turns on the Bluetooth on the android phone and connects to Car’s HC-06 Bluetooth device.
+Post which, we would send a start signal from the app, which would sync and start the car. This signal is encoded before sending from the android. This signal when received from the Bluetooth module, would decode and read the message and later encode and pass it on over the CAN to the Master.
-The GPS module comes with following capabilities:
+====Communication between BT and other controllers====
+BT Application and BT controller communicates over UART at 9600 bits/sec baud rate,as HC-06 operates at that baud rate.
+======Send data to Application======
-*-165 dBm sensitivity, 10 Hz updates, 66 channels
+Bluetooth controller communicates with other controllers through CAN.Once BT App installed on mobile,App requests for BT permissions from user.Once allowed to access BT on the mobile phone, App can send and receive messages over UART.CAN messages received from other modules are decoded and the corresponding message is sent to BT application with the specified character sequence through UART.
-* 5V friendly design and only 20mA current draw
+Ex:RPS value from the Motor controller is sent to Bluetooth controller is sent as "r" followed by "!" "<rps value>".IN this sequence "r" is the identification command for the rps value that is being sent from the motor and "!" is delimiter to indicate the app that the next characters are the received values from the motor.This characters are displayed in a text area on app under the heading RPM. Every time the app receives rpm value,the same is displayed on the text section assigned for the RPM on the app.Similarly Sensor,Geo controller sends right sensor value and geo co-ordinates respectively.These are displayed on the allocated text areas on the application.
-* 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.
+======Receive data from application======
-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 GGA (Time, Position and Fix type data), which will look similar to:
-GGA- essential fix data which provide 3D location and accuracy data.
+Based on the commands(button press on the application) send to the app,it will respond with the appropriate data.A thread starts running once START command on the application is pressed,this threads is alive till the application is closed.This is a way for the controller to know that Bluetooth connection is intact between BT app and controller.Any data sent to application is always listened through socket communication and the application responds if any command is programmed fro the received message.
-   $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
+A circular buffer at the receiver part of the application is useful for the data to be received without corruption.Application sends data through socket communication at faster rate than that BT controller receive,hence buffer at the controller should be able to store the data received from application.
-     GGA          Global Positioning System Fix Data
-       Fix taken at 12:35:19 UTC
-.038,N   Latitude 48 deg 07.038' N
-.000,E  Longitude 11 deg 31.000' E
-            Fix quality:
-= invalid
-= GPS fix (SPS)
-= DGPS fix
-= PPS fix
-= Real Time Kinematic
-= Float RTK
-= estimated (dead reckoning) (2.3 feature)
-= Manual input mode
-= Simulation mode
-           Number of satellites being tracked
-.9          Horizontal dilution of position
-.4,M      Altitude, Meters, above mean sea level
-.9,M       Height of geoid (mean sea level) above WGS84
-                      ellipsoid
-     (empty field) time in seconds since last DGPS update
-     (empty field) DGPS station ID number
-     *47          the checksum data, always begins with *
-</td>
-<td>
-</td>
-<td>
-[[File:CMPE_243_F16_Autonav_GPS.jpg|250px|center|thumb|GPS]]
-</td>
-</tr>
-<tr>
-<td valign="top" align="justify" width=550px>
-'''GPS Pin Connections'''
+======Sending route to SJone board======
-[[File:CMPE_243_F16_Autonav_gps_pin.png|600px|centre|thumb|GPS Pin Connections]]
+Route Button on the app would be initiated once we set the source and destination by 2 clicks on the maps in the app and start getting the location details  from HC-06.  Route Button ,on click would send the location from the car and send out next way points till the destination.
+The Kill switch is implemented as Stop Button, which sends of “0” signal, which is received by the Bluetooth and sent over the CAN Bus to master, to stop the Motor.
-<b>9 Degrees of Freedom- Razor IMU:</b>
+======Code snippet to send rpm data to App======
-In our project, we used IMU module to get the heading of the device.
+<syntaxhighlight lang="c">
-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:
+ if (dbc_decode_MOTOR_RPS(&motorrps, can_receive.data.bytes,&can_msg_hdr))
+    {
-*9 Degrees of Freedom on a single, flat board:
+         char a[3] ={ 0 };
-**ITG-3200 - triple-axis digital-output gyroscope
+         sprintf(a, "%d",  motorrps.Rps_Value);
-**ADXL345 - 13-bit resolution, ±16g, triple-axis accelerometer
+         u3.putChar('r', 0);
-**HMC5883L - triple-axis, digital magnetometer
+         u3.putChar('!', 0);
-*Outputs of all sensors processed by on-board ATmega328 and sent out via a serial stream
+         u3.putline(a, 0);
-*Autorun feature and help menu integrated into the example firmware
+         u3.putChar('!', 0);
-*Output pins match up with FTDI Basic Breakout, Bluetooth Mate, XBee Explorer
+         LE.off(1);
-*3.5-16VDC input
-*ON-OFF control switch and reset switch
+   }
-</td>
+</syntaxhighlight>
-<td>
-</td>
-<td>
-[[File:CMPE_243_F16_Autonav_IMU.jpg|300px|thumb|right|9DOF-IMU]]
-</td>
-</tr>
-</table>
-'''IMU Pin Connections'''
-[[File:Cmpe243_F2016_AutoNav_imu_pin.png|600px|centre|thumb|IMU Pin Connections]]
-=== Hardware Interface ===
+== Geographical Controller ==
-=== Geographical Controller H/W Interface ===
+'''Team Members:'''
+ Veena Manasa Kanakamalla
+ Arpita Ramanath
-* Below table shows the pin connections of GPS and IMU module with SJ One Board. Both the modules are interfaced with Controller using UART interface. The operating voltage of GPS and IMU is 5V.
+=== Hardware Design ===
-{| class="wikitable"
+'''System Block Diagram'''
-|+ Geographical Controller Pin Connections
-|-
+SJ One board is interfaced to GPS module and IMU through UART.
-! scope="col"| '''Description'''
-! scope="col"| '''Interface'''
+[[File:CmpE243_F16_AutoNav_GeoController_HWInterface.jpg|500px|thumb|centre|Hardware Interface of GeoController]]
-! scope="col"| '''Port Used'''
-! scope="col"| '''Controller Port'''
+=== Geographical Controller Hardware Design Components ===
-|-
+<table>
-| Supply Voltage
+<tr>
-| N/A
+<td valign="top" align="justify" width=550px>
-| 5V power supply
+<b>Adafruit MTK3339 GPS:</b>
-| N/A
-|-
+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.
-| Ground
-| N/A
-| GND
-| GND
-|-
-| GPS Module
-| UART3
-|
--> Rx
--> Tx
-|
--> Tx P4.28
--> Rx P4.29
-|-
-| IMU Module
-| UART2
-|
--> Rx
--> Tx
-|
--> Tx P2.8
--> Rx P2.9
-|-
-|}
-=== Software Design ===
+The GPS module comes with following capabilities:
-Geographical controller uses two modules to get GPS data and heading. These are:
+*-165 dBm sensitivity, 10 Hz updates, 66 channels
-*GPS module
+* 5V friendly design and only 20mA current draw
-*IMU module
+* 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:
-==== Tasks ====
+GGA- essential fix data which provide 3D location and accuracy data.
-{| class="wikitable"
+   $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
-|+ Geo Controller Tasks
+     GGA          Global Positioning System Fix Data
-|-
+       Fix taken at 12:35:19 UTC
-! align="center"|Task Name
+.038,N   Latitude 48 deg 07.038' N
-! align="center"|Purpose
+.000,E  Longitude 11 deg 31.000' E
-|-
+            Fix quality:
-| Period Init
+= invalid
-| Initializing CAN bus, UART2 for IMU, UART3 for GPS
+= GPS fix (SPS)
-|-
+= DGPS fix
-| Periodic 1Hz Callback
+= PPS fix
-| Checking for CAN bus off
+= Real Time Kinematic
-|-
+= Float RTK
-| Periodic 10Hz Callback
+= estimated (dead reckoning) (2.3 feature)
-| Receiving and parsing GPS data and IMU data, receiving checkpoints, calculating heading, bearing and distance.
+= Manual input mode
-|-
+= Simulation mode
-|}
+           Number of satellites being tracked
+.9          Horizontal dilution of position
+.4,M      Altitude, Meters, above mean sea level
-'''Flowchart'''
+.9,M       Height of geoid (mean sea level) above WGS84
-[[File:CMPE_243_F16_Autonav_GeoControllerFlowchart.jpeg|1000px|centre|thumb|GeoController Flow Diagram]]
+                      ellipsoid
+     (empty field) time in seconds since last DGPS update
+     (empty field) DGPS station ID number
+     *47          the checksum data, always begins with *
+</td>
+<td>
+</td>
+[[File:CMPE_243_F16_Autonav_GPS.jpg|250px|right|thumb|GPS Module]]
+<td>
+</td>
+</tr>
+<tr>
+<td valign="top" align="justify" width=550px>
-=== Implementation ===
+'''GPS Pin Connections'''
+[[File:CMPE_243_F16_Autonav_gps_pin.png|600px|centre|thumb|GPS Pin Connections]]
-==== Receiving and parsing GPS data ====
+<b>9 Degrees of Freedom- Razor IMU:</b>
-The first task was to interface the GPS module to the SJOne board (using UART3), and receive raw data over it. The module was configured to receive only GPGGA NMEA sentence at 9600 bps baud rate. The received NMEA data is a string, that has to be parsed to obtain current latitude and longitude values. This location data is continuously sent to the Master controller on the CAN bus at 10 Hz.
+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:
-==== Heading Calculation ====
+*9 Degrees of Freedom on a single, flat board:
+**ITG-3200 - triple-axis digital-output gyroscope
-Heading of the car is the direction that the car is moving, with respect to true north. A compass gives heading with respect to magnetic north. True heading is calculated by adding magnetic declination at that particular location, to the magnetic heading.
+**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:CMPE_243_F16_Autonav_IMU.jpg|300px|thumb|right|9DOF-IMU]]
+</td>
+</tr>
+</table>
+'''IMU Pin Connections'''
+[[File:Cmpe243_F2016_AutoNav_imu_pin.png|600px|centre|thumb|IMU Pin Connections]]
-The IMU module has to be calibrated initially. The board comes programmed with the 8MHz Arduino bootloader (stk500v1) and some example firmware that demos the output of all the sensors (accelerometer, magnetometer, gyroscope). The calibration was done by following this tutorial at https://github.com/Razor-AHRS/razor-9dof-ahrs/wiki/Tutorial. Calibration compensates for the magnetic field around the IMU. So this process has to be done once after mounting the IMU on the car.
+=== Hardware Interface ===
+=== Geographical Controller H/W Interface ===
-The IMU module is interfaced to the SJOne board using UART2. The IMU firmware is updated such that it gives only Yaw readings. Yaw (or magnetic heading) is used to calculate the true heading using the below formula.
+* Below table shows the pin connections of GPS and IMU module with SJ One Board. Both the modules are interfaced with Controller using UART interface. The operating voltage of GPS and IMU is 5V.
- '''Heading = Yaw data from IMU + Magnetic Declination'''
+{| class="wikitable"
+|+ Geographical Controller Pin Connections
-Magnetic declination in San Jose is +13° 29'.
+|-
+! scope="col"| '''Description'''
+! scope="col"| '''Interface'''
-==== Bearing calculation ====
+! scope="col"| '''Port Used'''
+! scope="col"| '''Controller Port'''
-Bearing is the direction that the car desires to travel along, i.e., the direction of the destination. It is calculated using the current location coordinates and the destination coordinates (or next checkpoint coordinates). The formula to calculate bearing is
+|-
+| Supply Voltage
- '''
+| N/A
-    X = cos(lat2) * sin(dLong)
+| 5V power supply
-    Y = cos(lat1) * sin(lat2) - sin(lat1) * cos(lat2) * cos(dLong)
+| N/A
-    Bearing = atan2(X,Y)
+|-
+| Ground
-    where,
+| N/A
-    (lat1, long1) are the current location coordinates
+| GND
-    (lat2, long2) are the checkpoint coordinates
+| GND
-    dLong is (long2 - long1) '''
+|-
+| GPS Module
+| UART3
+|
+-> Rx
+-> Tx
+|
+-> Tx P4.28
+-> Rx P4.29
+|-
+| IMU Module
+| UART2
+|
+-> Rx
+-> Tx
+|
+-> Tx P2.8
+-> Rx P2.9
+|-
+|}
+=== Software Design ===
-==== Distance calculation ====
-The distance between the current location and the next checkpoint is calculated using the below formula.
+Geographical controller uses two modules to get GPS data and heading. These are:
+*GPS module
-'''Haversine formula to calculate distance'''
+*IMU module
-   a = sin²(Δφ /2) + (cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2))
-   c = 2 x atan2( √a, √(1−a) )
-   Distance d = R x c
-        Where,
-             Φ is latitude
-             λ is longitude
-             R is Earth’s radius = 6371 Km
-             Δφ = latitude2 – latitude1
-             Δλ = longitude2 – longitude1
-A flag is set when the distance to the final checkpoint becomes zero, and sent to the Master controller, to indicate that the destination has been reached.
-== Master Controller ==
+==== Tasks ====
-'''Team Members:'''
+{| class="wikitable"
- Ajai Krishna Velayutham
+|+ Geo Controller Tasks
- Goutam Madhukeshwar Hegde
+|-
+! align="center"|Task Name
+! align="center"|Purpose
+|-
+| Period Init
+| Initializing CAN bus, UART2 for IMU, UART3 for GPS
+|-
+| Periodic 1Hz Callback
+| Checking for CAN bus off
+|-
+| Periodic 10Hz Callback
+| Receiving and parsing GPS data and IMU data, receiving checkpoints, calculating heading, bearing and distance.
+|-
+|}
-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.
-=== Hardware Design ===
+'''Flowchart'''
-The Hardware Design is as show below with just CAN bus connection to the Master Controller. Master has the connection with all the other controllers via CAN Bus. Hardware interface explains the signalling through the CAN bus.
+[[File:CMPE_243_F16_Autonav_GeoControllerFlowchart.jpeg|1000px|centre|thumb|GeoController Flow Diagram]]
-[[File:Cmpe 243 F16 Autonav MasterInterface.jpg|centre|500px|thumb|Master Controller Interface]]
+=== Implementation ===
-=== Hardware Interface ===
+==== Receiving and parsing GPS data ====
-The Hardware interface is simpler compared to other controllers, by just connecting to the CAN bus as shown above. The messages on the CAN such as Start and Stop command's from Bluetooth controller, Heading, Bearing and
-destination check signals from Geo Controller and Sensor range values from the proximity sensors are received from the CAN Bus. Based on these signals master drives the Car by sending out signals to Motor Controller, such as speed and steer values, which signifies at what sped the car has to move and at what steer the car should take.
-=== Software Design ===
+The first task was to interface the GPS module to the SJOne board (using UART3), and receive raw data over it. The module was configured to receive only GPGGA NMEA sentence at 9600 bps baud rate. The received NMEA data is a string, that has to be parsed to obtain current latitude and longitude values. This location data is continuously sent to the Master controller on the CAN bus at 10 Hz.
-Obstacle avoidance algorithm:
-Obstacle avoidance is done according to the enum values sent from the sensor controller.
-In the master controller, obstacle avoidance is handled separately in danger,near and medium regions.
-If sensor indicates danger region,it means that there is an obstacle very near to front sensor. So in this case car takes a reverse turn until the front sensor enters near region.So in this way car avoids obstacle very near to it.
-If sensor indicates near region,master enters a states machine to intelligently avoid the obstacle as shown the above figure.
-If sensor indicates medium region,master enters another state machine to handle the obstacles in medium region.
-[[File:Cmpe243 F2016 AutoNav NavigationStateDiagram.jpg|600px|centre|thumb| Obstacle Avoidance State Diagram for Near Region]]
+==== Heading Calculation ====
-[[File:Cmpe 243 F16 Autonav ObstacleAvoidanceMidRegionStateDiagram.jpg|700px|centre|thumb| Obstacle Avoidance State Diagram for Mid Region]]
+Heading of the car is the direction that the car is moving, with respect to true north. A compass gives heading with respect to magnetic north. True heading is calculated by adding magnetic declination at that particular location, to the magnetic heading.
-Bit representation are the sensor values detected i.e. the leftmost bit is the value of Left sensor, followed by front sensor value as mid bit and later the right sensor value as the final bit. Value is set to 1 if an obstacle is detected and 0 if there is no obstacle, in the above diagrams for Navigation and Obstacle avoidance algorithm.
+The IMU module has to be calibrated initially. The board comes programmed with the 8MHz Arduino bootloader (stk500v1) and some example firmware that demos the output of all the sensors (accelerometer, magnetometer, gyroscope). The calibration was done by following this tutorial at https://github.com/Razor-AHRS/razor-9dof-ahrs/wiki/Tutorial. Calibration compensates for the magnetic field around the IMU. So this process has to be done once after mounting the IMU on the car.
-[[File:Cmpe243 F2016 AutoNav MasterControlFlow.png|700px|centre|thumb| Master Controller Flow Diagram]]
+The IMU module is interfaced to the SJOne board using UART2. The IMU firmware is updated such that it gives only Yaw readings. Yaw (or magnetic heading) is used to calculate the true heading using the below formula.
-Above Flow diagram represents the control flow of the master. On start of the master controller, it waits for the Start command from Bluetooth controller i.e from the App. Once the signal is given, it checks if the way points are received and stored by the Geo Controller and if the way points are sent by clicking route on the app and stored in Geo controller, then the master checks if the Geo location is not the same as destination, then Navigation algorithm is used if there are no obstacles detected by sensors, else if there are obstacles detected, then Obstacle avoidance algorithm is implemented.
+ '''Heading = Yaw data from IMU + Magnetic Declination'''
+Magnetic declination in San Jose is +13° 29'.
-Navigation Algorithm:
-[[File:Cmpe243_F2016_AutoNav_StreerControlBasedOnTurnAngle.JPG|600px|centre|thumb|Steer control based on turn angle]]
-GPS Navigation is done based on the heading and bearing values from GEO controller.Master controller calculates the desired turn angle to reach the destination path.
+==== Bearing calculation ====
- Turn angle= GPS bearing-GPS heading;
-Turn angle is a value between 0 to 360 degree.Entire 360 degrees is divided into various sub-regions based on the desired turn angles as shown in the above figure.
-GPS navigation is done with the help of a state machine.Turn angle is the input for the state machine based on which state machine determines the command to issue to the motor.
-=== Implementation ===
+Bearing is the direction that the car desires to travel along, i.e., the direction of the destination. It is calculated using the current location coordinates and the destination coordinates (or next checkpoint coordinates). The formula to calculate bearing is
-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.
-== Testing & Technical Challenges ==
+ '''
+    X = cos(lat2) * sin(dLong)
+    Y = cos(lat1) * sin(lat2) - sin(lat1) * cos(lat2) * cos(dLong)
+    Bearing = atan2(X,Y)
+    where,
+    (lat1, long1) are the current location coordinates
+    (lat2, long2) are the checkpoint coordinates
+    dLong is (long2 - long1) '''
-=== Motor & I/O Issues ===
-* '''''Reverse Current from Motor:''''' One of our boards got burnt while testing Brushless DC Motor. We would highly recommend using an Optoisolator such as ILQ74 for additional protection from reverse current etc. if you are synchronizing with the ESC for the first time.
+==== Distance calculation ====
-* '''''ESC Synchronization: ''''' The slowest speed of Brushless DC motor was too fast for us. We tried to change ESC synchronization and reprogram it to change PWM frequency but it didn't work out for us. We recommend having Brushed DC Motor that is reprogrammable to any PWM frequency.
+The distance between the current location and the next checkpoint is calculated using the below formula.
+'''Haversine formula to calculate distance'''
-* '''''ESC Modes:''''' ESC Board was only set to forward and reverse mode. So we were not able to control the speed to stop the motor, even after sending stop signal it would hit the obstacle. So we reprogrammed the ESC to forward, reverse and brake. Synchronizing took time and effort. ESC has various modes we can program it into.
+   a = sin²(Δφ /2) + (cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2))
+   c = 2 x atan2( √a, √(1−a) )
+   Distance d = R x c
+        Where,
+             Φ is latitude
+             λ is longitude
+             R is Earth’s radius = 6371 Km
+             Δφ = latitude2 – latitude1
+             Δλ = longitude2 – longitude1
-* '''''Going Reverse issues:''''' If we wanted to go reverse first without going forward, car would go full speed in reverse. So every time we got reverse command from master, we initialized the DC motor to idle and then go to reverse.
+A flag is set when the distance to the final checkpoint becomes zero, and sent to the Master controller, to indicate that the destination has been reached.
+== Master Controller ==
+'''Team Members:'''
+ Ajai Krishna Velayutham
+ Goutam Madhukeshwar Hegde
+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.
+=== Hardware Design ===
+The Hardware Design is as show below with just CAN bus connection to the Master Controller. Master has the connection with all the other controllers via CAN Bus. Hardware interface explains the signalling through the CAN bus.
+[[File:Cmpe 243 F16 Autonav MasterInterface.jpg|centre|500px|thumb|Master Controller Interface]]
+=== Hardware Interface ===
+The Hardware interface is simpler compared to other controllers, by just connecting to the CAN bus as shown above. The messages on the CAN such as Start and Stop command's from Bluetooth controller, Heading, Bearing and
+destination check signals from Geo Controller and Sensor range values from the proximity sensors are received from the CAN Bus. Based on these signals master drives the Car by sending out signals to Motor Controller, such as speed and steer values, which signifies at what sped the car has to move and at what steer the car should take.
+=== Software Design ===
+Master controller software consists of a state machine running 3 different states based on the sensor and geo inputs.
+[[File:Cmpe243 F2016 AutoNav MasterControlFlow.png|700px|centre|thumb| Master Controller Flow Diagram]]
+Above Flow diagram represents the control flow of the master. On start of the master controller, it waits for the Start command from Bluetooth controller i.e from the App. Once the signal is given, it checks if the way points are received and stored by the Geo Controller and if the way points are sent by clicking route on the app and stored in Geo controller, then the master checks if the Geo location is not the same as destination, then Navigation algorithm is used if there are no obstacles detected by sensors, else if there are obstacles detected, then Obstacle avoidance algorithm is implemented.
-* '''''LCD Refresh Rate Issue:''''' For debugging, we wanted to run LCD at 10hz but it took long time to refresh, so data didn't get printed. Hence we were forced to debug especially at 1 Hz.
+Master controller software mainly deals with obstacle avoidance and GPS navigation algorithms.
+Software is designed with the help of state machines to make it more modular and efficient.
+Design of algorithms using state machines is explained in following section.
+'''Obstacle avoidance algorithm:'''
+Obstacle avoidance is done according to the enum values sent from the sensor controller.
+In the master controller, obstacle avoidance is handled separately in danger,near and medium regions.
+If sensor indicates danger region,it means that there is an obstacle very near to front sensor. So in this case car takes a reverse turn until the front sensor enters near region.So in this way car avoids obstacle very near to it.
+If sensor indicates near region,master enters a states machine to intelligently avoid the obstacle as shown the below figure.
+[[File:Cmpe243 F2016 AutoNav NavigationStateDiagram.jpg|600px|centre|thumb| Obstacle Avoidance State Diagram for Near Region]]
+State machines take the three ultrasonic sensors reading from sensor controller as inputs based on which it makes the decisions to issue speed and steer command to the motor controller.
+To elobarate, let's see an example state transition in the above state diagram.
+Let's assume that currently car is moving in the forward direction.So the current state is SLOW,STRAIGHT.Now if an obstacle is detected by the left sensor,input for the state machine will be 100.So car should take right turn to avoid the obstacle.So state transition happens to the next state  SLOW,RIGHT.In the similar manner, all the decisions are made in the state diagram.
+If sensor indicates medium region,master enters another state machine to handle the obstacles in medium region.
+[[File:Cmpe 243 F16 Autonav ObstacleAvoidanceMidRegionStateDiagram.jpg|700px|centre|thumb| Obstacle Avoidance State Diagram for Mid Region]]
+Bit representation are the sensor values detected i.e. the leftmost bit is the value of Left sensor, followed by front sensor value as mid bit and later the right sensor value as the final bit. Value is set to 1 if an obstacle is detected and 0 if there is no obstacle, in the above diagrams for Obstacle avoidance algorithm.
+'''Navigation Algorithm:'''
+[[File:Cmpe243_F2016_AutoNav_StreerControlBasedOnTurnAngle.JPG|600px|centre|thumb|Steer control based on turn angle]]
+GPS Navigation is done based on the heading and bearing values from GEO controller.Master controller calculates the desired turn angle to reach the destination path.
+ Turn angle= GPS bearing-GPS heading;
+Turn angle is a value between 0 to 360 degree.Entire 360 degrees is divided into various sub-regions based on the desired turn angles as shown in the above figure.
+GPS navigation is done with the help of a state machine.Turn angle is the input for the state machine based on which state machine determines the command to issue to the motor.
+=== Implementation ===
+Master controller software is implemented with the help of state machines.The main state machine consists of three states.
+.Obstacle avoidance state
+.GPS navigation state
+.Move reverse state
+code snippet of state machine stucture:
+<br>
+<syntaxhighlight lang="C">
+typedef struct{
+   state_t state; //state here corresponds to ST_REVERSE,ST_GPS_NAVIGATE and ST_OBSTACLE_AVOID
+   state_t (*func)(void); //this is the funcction pointer declaration to switch between moveReverse,GPS_navigate and obstacleAvoid functions
+} stateTrans_t;
+stateTrans_t stateTrans[]=
+{
+		   {ST_REVERSE,moveReverse},
+		   {ST_GPS_NAVIGATE,GPS_navigate},
+		   {ST_OBSTACLE_AVOID,obstacleAvoid}
+};
+</syntaxhighlight>
+<BR/>
+We have created a separate state for move reverse because in order to change the motor speed to reverse, ESC of the car needs brake pulse followed by reverse.So whenever an obstacle is in danger region,we issue break first for 3 to 4 seconds followed by reverse command.So we handled this with the help of count variable in 100Hz periodic function.
+In the obstacle avoidance state,first we check sensor readings and based on which program calls the state machines corresponding to near region or medium region.
+If the sensor readings indicate that there are no near by obstacles, state transits to navigation state.
+In the navigation state commands to motor is issued based on the turn angle calculated based on the heading and bearing values sent by geo controller.
+Following function runs in the periodic function to update the state of the car.
+<br>
+<syntaxhighlight lang="C">
+cState= (stateTrans[cState].func)();
+</syntaxhighlight>
+<BR/>
+Following functions are implemented in the periodic functions.
+{| class="wikitable"
+|+ Master Controller Tasks
+|-
+! align="center"|Task Name
+! align="center"|Purpose
+|-
+| Period Init
+| Initialize CAN bus
+|-
+| Periodic 1Hz Callback
+| Check can bus off
+|-
+| Periodic 10Hz Callback
+| decode_START_CMD, decode_GEO_SEND_HD_BR, dbc_decode_SENSOR_SONAR, State machine to change the system states
+|-
+|-
+| Periodic 100Hz Callback
+| encode_and_send_MOTOR_CONTROL
+|}
+== Testing & Technical Challenges ==
+=== Motor & I/O Issues ===
+* '''''Reverse Current from Motor:''''' One of our boards got burnt while testing Brushless DC Motor. We would highly recommend using an Optoisolator such as ILQ74 for additional protection from reverse current etc. if you are synchronizing with the ESC for the first time.
+* '''''ESC Synchronization: ''''' The slowest speed of Brushless DC motor was too fast for us. We tried to change ESC synchronization and reprogram it to change PWM frequency but it didn't work out for us. We recommend having Brushed DC Motor that is reprogrammable to any PWM frequency.
+* '''''ESC Modes:''''' ESC Board was only set to forward and reverse mode. So we were not able to control the speed to stop the motor, even after sending stop signal it would hit the obstacle. So we reprogrammed the ESC to forward, reverse and brake. Synchronizing took time and effort. ESC has various modes we can program it into.
+* '''''Going Reverse issues:''''' If we wanted to go reverse first without going forward, car would go full speed in reverse. So every time we got reverse command from master, we initialized the DC motor to idle and then go to reverse.
+* '''''LCD Refresh Rate Issue:''''' For debugging, we wanted to run LCD at 10hz but it took long time to refresh, so data didn't get printed. Hence we were forced to debug especially at 1 Hz.
 === Bluetooth Bridge Controller and Android application Issues ===
 ====Issues====
 * During the initial phase we were finding difficult to connect to the Bluetooth Module HC-06, later on proper UUID was given which solved the connection issue.
 * Sending out Start and Stop messages of "1" and "0" respectively continuously was a challenge. This was required to detect when Bluetooth goes out of range. We solved this issue using threads.
 * We had tested the application by hard coding the values from the Bluetooth controller end, which was displayed as messages on the application. The requirement was to display the CAN messages, therefore once we integrated on board, we faced issues like receiving junk and ? character on the application. We solved this by introducing circular buffers.
 * On integrating with on board GPS, we were unable to send out all the Navigation way points, say if we got 8 way points, we were able to send only first 4 of them. This was due to buffer size which we had set to 100. Once we updated it to 500, we were able to receive all the CAN messages flawlessly.
 ====Testing====
 * At Module level, we tested the communication between the Bluetooth Controller and the Android by sending out characters through UART and displaying the received messages on the app screen.
 *We increased the number of characters to 960 characters that was being sent on UART to check whether we were able to receive on the app.
 *Verified the Location of the maps on the app with the Google maps application.
 *Verified the messages displayed on the Bus Master and LCD with the app screen post integration.
 === Geo controller Issues ===
 * 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. The IMU has to be calibrated once again after mounting it on the car to avoid drift in the Yaw values.
 * The GPGGA sentence received via UART was incomplete sometimes, resulting in incorrect parsing. This turned out to be an issue with the UART receive queue size. When this queue size was increased, complete NMEA sentences were received.
 * Initially, the coordinates received from the GPS module were pointing to Santa Clara, around 30 km away from our present location. This was due to incorrect parsing of the NMEA sentence from the GPS module. The latitude and longitude values from the GPS module are given in the form of ddmm.mmmm and dddmm.mmmm and not decimal degrees. The minutes have to be converted to degrees and added to the degrees value.
 == Conclusion ==
 In a span of 3 months, we had an awesome experience in working together for the AutoNav project. We learnt a lot about GIT and CAN bus along with implementing DBC and working on real hardware. We were able to implement all these embedded concepts effectively from our course work.  All essential phases of software development cycle such as design, implementation and testing were executed in stages effectively and debugging with CAN bus was really helpful in working. Finally it was an enchanting experience and we hope that we were able to share some of our learnings and difficulties we faced in this report, which would help the future students joining the course.
 === Project Video ===
-Upload a video of your project and post the link here.
+[https://youtu.be/1Y_41_RXWGM AutoNav - The autonomous RC car]
 === GitLab Source Code ===
@@ Line 1,397: / Line 1,533: @@
   [9] [https://developers.google.com/maps/ Google Maps Guide]
   [10] [https://www.youtube.com/watch?v=lchyOhPREh4/ Video guide for Google maps implementation]
-=== Appendix ===
-You can list the references you used.

Difference between revisions of "F16: AutoNav"

Latest revision as of 19:18, 22 December 2016

Contents

Project Title

AutoNav - The Autonomous RC Car

Abstract

Objectives & Introduction

Team Members & Responsibilities

Schedule

Parts List & Cost

DBC File Implementation

Design & Implementation

Description

CAN BUS

Sensor Controller

Hardware Design

Hardware Interface

Software Design

Implementation

Motor & I/O Controller

Hardware Design

Hardware/Software Interface

I/O Interface - LCD

Motor Control Hardware/Software Interface

Tasks

Brushless DC Motor

Motor Feedback

Servo Motor

Bluetooth and Bridge(Android) Connections

Bluetooth Controller Pin Connections

Hardware Interface

Software Design

Flow Chart:

Implementation

BT connection establishment

Communication between BT and other controllers

Send data to Application

Receive data from application

Sending route to SJone board

Code snippet to send rpm data to App

Geographical Controller

Hardware Design

Geographical Controller Hardware Design Components

Hardware Interface

Geographical Controller H/W Interface

Software Design

Tasks

Implementation

Receiving and parsing GPS data

Heading Calculation

Bearing calculation

Distance calculation

Master Controller

Hardware Design

Hardware Interface

Software Design

Implementation

Testing & Technical Challenges

Motor & I/O Issues

Bluetooth Bridge Controller and Android application Issues

Issues

Testing

Geo controller Issues

Conclusion

Project Video

GitLab Source Code

References

Acknowledgement

References Used

Navigation menu

Search