Difference between revisions of "F16: AutoNav"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Hardware Interface)
(Software Design)
Line 1,196: Line 1,196:
 
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
 
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
  
[[File:Cmpe243 F2016 AutoNav NavigationStateDiagram.jpg|600px|centre|thumb|Navigation Algorithm]]
+
[[File:Cmpe243 F2016 AutoNav NavigationStateDiagram.jpg|600px|centre|thumb| Obstacle Avoidance State Diagram for Near Region]]
  
 
[[File:Cmpe 243 F16 Autonav ObstacleAvoidanceMidRegionStateDiagram.jpg|700px|centre|thumb| Obstacle Avoidance State Diagram for Mid Region]]
 
[[File:Cmpe 243 F16 Autonav ObstacleAvoidanceMidRegionStateDiagram.jpg|700px|centre|thumb| Obstacle Avoidance State Diagram for Mid Region]]

Revision as of 05:35, 20 December 2016

Project Title

  • Autonomous RC Car

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:

Bluetooth (Communication Bridge) & Android Controller:

  • Sucharitha
  • Karthikeya Rao G V

Geographical Controller:

  • Arpita Ramanath
  • Veena Manasa Kanakamalla

Master Controller:

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

Please refer to the system block 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.

Sensor Controller

Team Members:

Vishwanath Balakuntla Ramesh

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

S No Sensor Pin SJOne Board Pin
1 Vcc 5V
2 GND GND
3 SIG P2.0

Parralax Ping Sensor Operation

Sensor Ping Operation

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Sensor Fields and Ranges
Sensor Controller Tasks
Task Name Purpose
Period Init Can bus initialization Enable LPC timer Initialize LPC timer Initialize rising edge GPIO interrupt Initialize falling edge GPIO interrupt
Periodic 1Hz Callback Check can bus off
Periodic 10Hz Callback Get and Send Sensor Data

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Sensor Controller Flow Diagram

Motor & I/O Controller

Team Members:

Sameer Saran
Jaswanth Bhimanapalli

Hardware Design

Block Diagram for Motor

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Hardware/Software Interface

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

Tasks

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

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.63 Slow
3 7.68 Normal

Table3: DC Motor Duty Cycle v/s Speed Control

CMPE 243 Autonav Brushless Motor.jpeg
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.

void drive(steer_E steer,speed_E speed)
{

	static int servoVal,servo_Currentval=STRAIGHT*100;
	servoVal = get_Servopwm(steer);
	while(servoVal!=servo_Currentval)
		{	
			if(servo_Currentval>servoVal)
			{
			servo_Currentval-=5;
			MotorCtrl.set_servo(servo_Currentval*0.01);
			delay_ms(5);
			}
			else if(servo_Currentval<servoVal)
			{
			servo_Currentval+=5;
			MotorCtrl.set_servo(servo_Currentval*0.01);
			delay_ms(5);
			}
		}
		if(servoVal==servo_Currentval)
		{
		MotorCtrl.set_servo(servo_Currentval*0.01);
		delay_ms(5);
		}
}


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

Servo Motor Duty Cycle v/s Turn

CMPE 243 F16 Autonav Servo motor.gif
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.

Motor cnt1.png
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()


Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Bluetooth and Bridge(Android) Connections

Team Members:

Sucharitha Sirigreddy
Karthikeya Rao GV

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.


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

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 hardcoded as ‘1’, and 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.

After this syncing, the Master would initiate other modules; post which GPS module would send the location signal over the CAN. This signal is again decoded and sent over to the Android as a line having latitude and longitude and prefixed with respective signals, ex: RPM for RPM values and post-fixed with “!” , for easier identification in the Android. Location button would enable the current location of the device, which would be marked on the map, this would be enabled on click of start itself. This would also enable Bluetooth module to detect the messages over the CAN to be displayed on the app, like RPM values and GPS data. These are again encoded and sent over to Android, which would display them in respective text boxes.

Route Button on the app would be initiated once we set these and the source and destination by 2 clicks on the maps in the app and start getting the GPS location from HC-06. Route Button on click would detect the GPS 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.

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

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 GGA (Time, Position and Fix type data), 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 
    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

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

Flowchart

IMU Pin Connections

Implementation

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

Master Controller

Team Members:

Ajai Krishna Velayutham
Goutam Madhukeshwar Hegde


Master Controller Schedule

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Master Controller Interface

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Obstacle Avoidance State Diagram for Near Region
Obstacle Avoidance State Diagram for Mid Region
Steer control based on turn angle

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Issue #1 (Motor I/O)

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

Issue #2 (Project Hardware)

Issue #3 (Project Hardware)

Issue #4 (Geo controller)

  • 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 raw values.

Issue #5 (Motor Controller software)

Issue #6 (Master Controller software)

Miscellaneous Issues

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

GitLab Source Code

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

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

Appendix

You can list the references you used.