Difference between revisions of "F17: Viserion"

Latest revision as of 08:28, 23 December 2017

1 Viserion Team RC Car
2 Abstract
3 Objectives & Introduction
4 Schedule
5 Viserion DBC File
6 Parts List & Cost
7 Process Control
8 PCB Design
9 Sensors Controller
10 Motor and I/O Controller
11 Master Controller
12 Bluetooth Controller And Android Application
13 Geographical Controller
14 Major issues
15 Conclusion
- 15.1 Project Video
- 15.2 Project Source Code
16 References
- 16.1 Acknowledgement
- 16.2 References Used

Viserion Team RC Car

Viserion

Abstract

Aim of this project is to build a self-navigating car. The car is composed of five important modules. Each module consists of SJ One board as the main controller.

The five modules of the car are :
Sensor Controller: This module detects obstacles in the driving path with the help of ultrasonic sensors.
Motor Controller: This controller drives the DC motor and Servo in the car.
Geographical Controller: This module assists the car in navigating to a destination with the help of location details provided by GPS and the orientation(bearing and heading angle) provided by the compass.
Bluetooth Controller: The controller uses Bluetooth to communicate with an Android application. Destination coordinates are provided by this module. The bluetooth module also displays important data like sensor readings, GPS coordinates and speed.
Master Controller: This module will collect data from all modules and direct the motor towards the destination.

The car has a centralized CAN bus to communicate between the modules.

Objectives & Introduction

Objectives

The objectives are as follows:

1.To detect and avoid obstacles encountered in the path.
2.To move at an appropriate speed depending upon the path requirement.
3.To use Bluetooth module to start/stop the car and display important data on the LCD.
4.To integrate gps and compass to make sure that the car navigates from source to destination.
5.To efficiently establish communication between all the modules using CAN protocol.
6.To reach a destination given by the Bluetooth module autonomously for a valid path.

System Block Diagram

Viserion Block Diagram

Team Members & Responsibilities

Master Controller

Aakash Menon
Omkar Kale

Geographical Controller

Ajinkya Mandhre
Aniket Dali
Jean Mary Madassery

Sensor Controller

Miroslav Grubic

MOTOR & I/O CONTROLLER

Manoj Ramesh Rao
Pratap Ramachandran

BLUETOOTH CONTROLLER & ANDROID APP

Dheemanth Bangalore Vishwanatha
Pratap Kishore Desai

Schedule

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Legend: Motor & I/O Controller , Master Controller , Communication Bridge Controller, Geographical Controller, Sensor Controller , Team Goal , Team PCB, , Team Android

Week#	Start Date	End Date	Task	Actual Completion Date / Notes	Status
1	10/09/2017	10/15/2017	Research previous projects wiki page, gather useful information. Discuss about roles and study data sheet of the required parts and list down minimum two parts for each required function. Setup Git and slack accounts and verify that access is provided to all the team mates.	10/15/2017	Done
2	10/16/2017	10/22/2017	Design Hardware layout for the project, schematic shall identify all the modules, ports and the pins interfaced. Design sensor and motor board's schematic in eagle PCB. Design data flow diagram for all the software exchanges between the modules and the master. Complete DBC file based upon the design data flow diagram and share the file via GIT repo. Study about GPS and Compass calibration . Interface motor and drive using Preet's PWM driver API. Find different levels of speed and direction. Interface one sonic sensor to the sensor controller. Receive data and calculate distance. Write send, receive and MIA functions to be able to perform basic CAN communication. Study Android application software and approaches from previous projects and document the required features being provided by the application. Order finalized Components.	10/22/2017	Done on time except PCB design was changed to only one PCB that will gather all controllers and have Can Bus on it.
3	10/23/2017	10/29/2017	Start interfacing received components to respective Nodes and do a superficial testing of components. Design GPS/Compass, Bluetooth and master board's schematic in eagle PCB. Identify and document best approach to calibrate Compass. Experiment on duty cycle suitable for direction and speed of the motors Communicate with Master and set speed and directions. Interface RPM sensor and calculate speed in KPH Interface all three front sonic sensor to the sensor controller. Apply filtering to get reliable data and send data to Master Controller. Document Android approaches and decide on how to design the app and fix the protocol to exchange data with Bluetooth module.	10/29/2017	Done on time except Filtering was not applied at this time
4	10/30/2017	11/05/2017	Interface RPM sensor and measure Speed.Maintain the speed based on feedback for uphill and downhill Improve the trajectory of the car using algorithm based on speed and directions Stress test front sensors in different environment conditions indoor, outdoor and compare data. Also change different angles for sensors and find best angles for most reliable data and maximum coverage. Start development of software modules for GPS and Compass modules and document the efforts and ways to test the algorithm. Test can bus communication by mounting master, sensor and motor modules and transmitting master related commands. Mount the parts on off shelf PCB for Demo 1 and verify the wiring connections and verify that CAR is ready for the demo,	11/03/2017	Done on time
5	11/06/2017	11/12/2017	Finish Bearing Angle Calculation. Control the Car's speed on detection of obstacle. Interface back sensor, receive, filter and send data. All sensors should be working properly by now and master should be getting stable values even while car is on the move. Finish development of algorithm for Compass & GPS calibration and verify that the direction obtained from the modules with that of any off shelf smartphone's Compass. Car should now move without hitting "any" obstacle when powered on. Car should be able to take a reverse if required.	11/12/2017	Done. Back sensor was not yet interfaced. Filtering applied for front sensors.
6	11/13/2017	11/19/2017	Interface the LCD with micro controller and do basic display of text Prepare design and possibly try to finish 3D printing or figure out some other hardware solution for sensor mount for final car design. Share Gerber files with the PCB fabrication house and order 2 PCB. Design basic Android application UI, which can verify that the communication with BT module was successful or not Fetch current longitude and latitude values from GPS modules via BT app and send all the checkpoints to the destination via BT app and BT module to master and verify the link between GPS/Compass, master and BT module and Application is working as expected.	11/18/2017	Done except, PCB design not finished yet. Back sensor interfaced.
7	11/20/2017	11/25/2017	Display speedometer, longitude and direction values Mount sensors on new/final hardware solution, position them properly and test again received data while car is in move. If the link between Geo, BT, master and Motor module is working, perform outdoor system testing.	11/25/2017	Done. PCB design finished and main PCB board ordered Still waiting for sensor mounts 3D printing to be finished.
8	11/26/2017	12/01/2017	Connect battery output to ADC channel and read back the battery parameters. Interface Head lights and turn them ON based on light sensor value. Implement automatic bluetooth connection between APP and bluetooth module Sensor breakout PCB design and ordered	12/01/2017	Done. Decided not to interface head lights, to prolong the battery.
9	12/03/2017	12/08/2017	Display the battery parameters on LCD. Perform round 1 of system testing. Start documenting project report by collaborating artifacts produced during project development. Fix the bugs in system testing.	12/08/2017	Done. Discovered the bugs with respect to bearing angle calculation, GPS configuration and Motor Speed. Modified the bearing angle calculation algorithm to use haversine formula instead of vector projection method. Configured GPS to use GNGGA.
10	12/10/2017	12/12/2017	Perform round 2 of system testing. Start documenting project report by collaborating artifacts produced during project development. Fix the bugs in system testing.	12/12/2017	Done. Created a rough draft report of all the modules. Applied averaging on GPS values.
11	12/13/2017	12/16/2017	Perform round 3 of system testing. Work on unfinished project report documentation. Fix the bugs in system testing.	12/16/2017	Done Improved GPS stability by enabling differential correction for GPS.
12	12/17/2017	12/19/2017	Perform round 4 of system testing. Fix the bugs in system testing. Record a video to demonstrate project working and features. Complete Documentation of wiki page.	12/19/2017	Done. Car is ready for the demo. Video editing is in progress.
13	12/20/2017		Ready for Demo.	12/20/2017	Done. Car successfully navigated to it's destination

Viserion DBC File

The DBC is designed to allow high priority message with the least message ID.
message ID 80-90 are critical messages which initializes all the modules or stop all the modules (Abort) when required.
message ID 90-100 are reserved for module heart beats, to make sure that the modules are working fine.
The Next important message ID 101 is reserved for sensor to periodically inform master about the obstacles,Detection of obstacle is given the highest priority to ensure that the car does not hit the obstacles. To achieve that it's important that the sensor have right to the bus whenever they wish to inform the master about obstacles.

Depending upon sensor feedback motor has to act, hence master uses next important message ID range 200 to inform Motor as per the sensor values.

Message ID 400-600 is reserved for communication between BT and GEO modules. This range is used for receiving car's current location, checkpoints to the destination, to periodically send bearing and compass angles. Since these values do not update frequently hence this communication is assigned the least priority on the CAN bus.

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_: DBG MASTER MOTOR SENSORS GEO BT

BO_ 80 MASTER_STOP_CMD: 1 MASTER
 SG_ CAR_HALT : 0|1@1+ (1,0) [0|0] "" BT,SENSORS,MOTOR,GEO

BO_ 81 MASTER_START_CMD: 1 MASTER
 SG_ CAR_INIT : 0|1@1+ (1,0) [0|0] "" BT,SENSORS,MOTOR,GEO

BO_ 83 BT_START_CMD: 1 BT
 SG_ BT_CAR_READY : 0|8@1+ (1,0) [0|0] "" MASTER, GEO

BO_ 84 BT_STOP_CMD: 1 BT
 SG_ BT_CAR_ABORT : 0|8@1+ (1,0) [0|0] "" MASTER

BO_ 95 HB_SENSORS: 1 SENSORS
 SG_ SENSOR_ALIVE : 0|1@1+ (1,0) [0|0] "HB-S" MASTER,MOTOR,GEO,BT

BO_ 96 HB_MOTORS: 1 MOTOR
 SG_ MOTOR_ALIVE : 0|1@1+ (1,0) [0|0] "HB-M" MASTER,SENSORS,GEO,BT

BO_ 97 HB_GEO: 1 GEO
 SG_ GEO_ALIVE : 0|1@1+ (1,0) [0|0] "HB-G" MASTER,SENSORS,MOTOR,BT

BO_ 98 HB_BT: 1 BT
 SG_ BT_ALIVE : 0|1@1+ (1,0) [0|0] "HB-BT" MASTER,SENSORS,MOTOR,GEO

BO_ 99 HB_MASTER: 1 MASTER
 SG_ MASTER_ALIVE : 0|1@1+ (1,0) [0|0] "HB-MT" BT,SENSORS,MOTOR,GEO

BO_ 101 SENSORS_VALUES: 4 SENSORS
 SG_ SENSOR_left_in : 0|8@1+ (1,0) [0|0] "Inches" MASTER
 SG_ SENSOR_middle_in : 8|8@1+ (1,0) [0|0] "Inches" MASTER
 SG_ SENSOR_right_in : 16|8@1+ (1,0) [0|0] "Inches" MASTER
 SG_ SENSOR_back_in : 24|8@1+ (1,0) [0|0] "Inches" MASTER

BO_ 200 MASTER_INITIALIZE: 1 MASTER
 SG_ MASTER_Init_Boards : 0|8@1+ (1,0) [0|0] "" SENSORS, MOTOR, BT, GEO

BO_ 203 MASTER_SPEED: 2 MASTER
 SG_ MASTER_Maintain_Speed : 0|8@1+ (1,0) [0|30] "mph" MOTOR
 SG_ MASTER_Maintain_Direction : 8|8@1+ (1,0) [0|12] "" MOTOR

BO_ 301 MOTOR_STATUS: 3 MOTOR
 SG_ MOTOR_Send_Speed : 0|8@1+ (0.1,0) [0|0] "mph" BT
 SG_ MOTOR_Send_PWM : 8|12@1+ (0.01,0) [0|0] "PWM" BT

BO_ 400 SEND_COORDINATES: 8 GEO
 SG_ SEND_LATTITUDE : 0|30@1+ (0.000001,-180) [-180|180] "DEGREE" MASTER,BT
 SG_ SEND_LONGITUDE : 30|30@1+ (0.000001,-180) [-180|180] "DEGREE" MASTER, BT
 
BO_ 401 SEND_GEO_ANGLES: 8 GEO
 SG_ SEND_HEAD : 0|16@1+ (1,0) [0|360] "DEGREE" MASTER,BT
 SG_ SEND_BEAR : 16|16@1- (1,0) [-180|180] "DEGREE" MASTER,BT
 SG_ SEND_DIST_CHKPOINT : 32|32@1- (1,0) [0|0] "cm" MASTER

BO_ 403 SEND_GEO_READY: 1 GEO
 SG_ SAT_LOCK : 0|8@1+ (1,0) [0|0] "" MASTER,BT

BO_ 404 ALL_CHECKPOINTS_RECEIVED: 1 GEO
 SG_ GEO_CHECKPOINTS_READY : 0|8@1+ (1,0) [0|0] "" BT 
 
BO_ 405 DESTINATION_REACHED: 1 GEO
 SG_ GEO_DESTINATION : 0|8@1+ (1,0) [0|0] "" MASTER  
 
BO_ 406 SEND_GEO_NOT_READY: 1 GEO
 SG_ GPS_NOT_READY : 0|1@1+ (1,0) [0|1] "" BT
 
BO_ 407 SEND_CURRENT_COORDINATES: 8 GEO
 SG_ SEND_CURRENT_LATTITUDE : 0|30@1+ (0.000001,-180) [-180|180] "DEGREE" BT
 SG_ SEND_CURRENT_LONGITUDE : 30|30@1+ (0.000001,-180) [-180|180] "DEGREE" BT

BO_ 500 GET_START_COORDINATES: 1 BT
 SG_ GET_COORDINATES : 0|8@1+ (1,0) [0|0] "" GEO

BO_ 503 SEND_R_COORDINATES: 8 BT
 SG_ SET_LATTITUDE : 0|30@1+ (0.000001,-180) [-180|180] "DEGREE" MASTER,GEO
 SG_ SET_LONGITUDE : 30|30@1+ (0.000001,-180) [-180|180] "DEGREE" MASTER,GEO

BO_ 504 SEND_NO_OF_CHECKPOINTS: 1 BT
 SG_ BT_NO_OF_COR : 0|8@1+ (1,0) [0|0] "" MASTER,GEO

BO_ 505 COORDINATES_SENT: 1 BT
 SG_ BT_COORDINATES_DONE : 0|8@1+ (1,0) [0|0] "" MASTER,GEO

Parts List & Cost

Item#	Part Desciption	Vendor	Qty	Cost
1	RC Car - Traxxas 1/10 Slash 2WD	Amazon	1	$189.95
2	Battery - Traxxas 7600mAh 7.4V 2-Cell 25C LiPo Battery	Amazon	2	$143.26
3	Charger - Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger	Amazon	1	$49.95
4	GPS - Readytosky Ublox NEO-M8N GPS Module	Amazon	1	$29.98
5	Bluetooth Module HC-05	Amazon	1	$8.99
6	IMU SparkFun 9DoF Razor IMU M0	SparkFun	1	$49.95
7	LV Maxsonar EZ0 Ultrasonic sensors	Robotshop	6	$158.7
8	RPM Sensor - Traxxas 6520 RPM Sensor	Amazon	1	$10.25
9	Jumper Wires	Amazon	1	$10
10	Acrylic Board MIFFLIN Acrylic Plexiglass 12 x 12	Amazon	1	$11
11	CAN tranceivers	Microchip Samples	30	Free
12	SJOne Boards	Provided by Preet	5	$400.0

Process Control

Progress Tracking

- For efficient progress tracking purposes, we exclusively created Milestones in GIT project repository and assigned tasks to the respective module owners.
- Milestones divided into smaller tasks and assigned to the module members.
- The task assignee had to regularly update the tasks with the impediments and useful information.
- Once the task was completed, it was dragged forward from "doing" stage to "closed" stage on the task board. In this way we were able to keep regular track on the completed and pending tasks.

Viserion task board

Unit Testing

Unit testing is a level of software testing where individual components or modules are tested. The purpose of unit testing is to validate that your code performs as you designed it. With the use of unit testing frameworks, stubs, and mock objects, code can be manipulated and tested without having to load compiled code onto a controller. We used Cgreen framework for our unit testing and the major functionalities of all the modules were unit tested for timely bug catching and fixes.

Code review

- During the planning phase of the project we had listed a set of coding guidelines to be followed uniformly within the team. This included naming conventions, code commenting formats, committing formats etc. For example: The whole team followed the below rule while committing the code:

 Git commit – m “Modulename_Personsinitial: short description of what was added”

 Ex: if ABC wants to make a commit to GEO module ABC would:
 Git commit –m “GC_ABC: Added new file for XYZ”

- After the code has been pushed by a module member onto GIT, all the respective module members would meet up in the presence of 1 or 2 external module member and brainstorm on the written code to find code bugs, cosmetic errors, logical errors etc. The team member would then fix the bugs and push the final code.

PCB Design

Main approach for PCB was to try to get rid of as much cables as possible. So far we saw many previous teams using ribbon cable to connect SJOne boards to PCBs but since there is 5 controllers we thought even that will not look nice and clean so we were looking for different solution. Our solution was to design PCB with female headers facing down so that match 17x2 male headers on SJOne boards facing up. This was also done in order to be able to see built-in LED diodes and two digits display on SJOne boards which we used for debugging and to display important information. We used Eagle PCB designer free version we were restricted with max PCB size so there was place to connect only four boards like this. Fifth board was remote and also connected to this PCB but with only three wires, CANH, CANL and GND. Of course, main PCB also provided connections for power for all SJOne boards as for "Sensor Breakthrough PCB"

Up facing Main PCB

Down facing Main PCB

Final product

Second PCB we designed was "Sensor Breakout PCB" which task was to reduce wiring from sensors to Main PCB, to collect all wiring and to use only 12-pin ribbon cable to connect it to Main PCB> More about this PCB you can find under Sensors section.

Sensors PCB

Sensors Controller

Based on research done on previous projects we decided to use Maxbotix EZ0 Ultrasonic sensors due to its reliability and cost. Four sensors total are used in this project. Three front sensors and one back sensor. They are all of the same type and manufacturer. Since they are triggered at different time, every 50ms, there was no need to use different sensor with different ranging frequency.

Hardware Design

There are two PCBs on car that are involved in wiring sensors, providing them with power and collecting data from them. “Main PCB” which is directly connected to Sensor Controller and “Sensors breakout PCB” which is mounted at the front of the car as close to sensors as possible to reduce wire length that goes through air. Two PCBs are connected with 12-pin ribbon cable. The sensors are powered with 3.3V and since we had only 5V power from power bank, we had to use 3.3V voltage regulator mounted on “Sensors breakout PCB”. Providing stable input voltage for sensors was also required because of unstable reading we were getting from sensors, caused by electrical interference. Our front sensors were interfaced by ADC, so stable input voltage was a must. Back sensor was interfaced by PWM since SJOne board has only three ADC pins.

Two PCBs connection

3D Printing Design

As a really important part of hardware design, 3D printing part was fun to make. After testing sensors on different heights from the ground and different angles we noticed that best results are when sensors are mounted as closer to the ground as possible, so we came out with our own design for sensors mount. Most important thing to consider when making design was to be able to adjust tilt of the sensors since we were receiving lot of reflection from the ground with temporarly mounts we used until we got the final printed version. So in order to satisfy that requirement mount is constructed from two parts, the stand and part that holds the sensor what gave us freedom to test sensors positioning during testing phase.

3D Design for Sensor stand

3D Design for Sensor mount

Final product

Sensor Mount in action

Hardware Interface

Sensors are interfaced with combination of GPIO, ADC and PWM pins. GPIO pins are used to trigger all sensors. Three ADC pins collect output from front sensors and PWM pin collect output from back sensor. Below you can see pin layout and schematics.

Sensors Pin Layout
Pin Name	Function
P2.6	Trigger for left sensor
P2.7	Trigger for right sensor
P2.8	Trigger for middle sensor
P2.9	Trigger for back sensor
P0.26	ADC input from left sensor
P1_30	ADC input from right sensor
P1_31	ADC input from middle sensor
P2_0	PWM input from back sensor

Sensors Connection Schematics

Software Design and Implementation

Sensor software part is mostly written in 100Hz task. The idea is to trigger sensors, get the readings and calculate distance (readings from sensors are just raw values not real distance in inches). Since values are not perfectly stable we used filter to clear garbage values, which we were getting from sensors from time to time. Filter used here is mode filter but in combination with simple averaging since there is no mode value if all values in the list are different. Here you can see flowchart where all boxes you can see represent separate functions defined in separate files, just called in 100Hz task.

Sensors SW Flowchart

Trigger Sensors Front three sensors are triggered at the different times, every 50ms. It was easily done by calculating modulus (count % 15) and comparing it with 0, 5 or 10 based which sensor we want to trigger. With this approach it easily to switch and to make left and right sensors triggered at the same time and then trigger middle sensor in order to avoid interference.

Calculate Distance Since we were using ADC to integrate front three sensors first thing to do in Calculate section was to get readings which actually are just number of steps that represent voltage level. In order to get real voltage value from the sensor and thus real distance, raw value got from sensors is multiplied with add_step_voltage, and then divided by voltage_scaling which is defined by voltage level powering the sensors (our was 3.3V) and manufacturer scaling (VCC/512).

Push and Pop is just simple function to add calculated values into lists used for filtering.

Filter Applied is mode filter. More about it you can find online but shortly it returns value that occurs most often. Since there was situation when car is in move all values in list are different and mode was not possible to find, we applied simple averaging to tackle this problem.

Motor and I/O Controller

The motor controller is responsible for the steering and controlling the speed of the car. Both direction and speed of the car is controlled using the duty cycle of PWM signal. The RC car comes with a DC motor for driving the car and a servo motor for steering the vehicle. The speed of the car can also be controlled using the Electronic Speed Controller(ESC), which drives the motor based on the PWM signal. Additionally, a RPM sensor was mounted inside the DC motor bracket, to control the speed of the car based on this feedback.These modules where interfaced such that it can work solely on the command from the Master Controller. These modules are explained in further detail in the hardware interface section below.

Design and Implementation

For controlling both the DC motor and Servo motor using the SJ-one board, we require to transmit the required duty cycle. Initially the Radio Control remote provided by Traxxas was used to determine the duty cycle for speed and direction by probing it to using a Oscilloscope. Hence, based on our requirements for steering five different PWM duty cycles were captured for center, slight left, left , right and slight right positions. Before implementing speed control based on feedback, ideal speed for testing was chosen and corresponding PWM cycle was captured.

After mounting the RPM sensor, the rotations per second(rps) could be calculated as it generated a signal for every rotation of the motor shaft. Using this signal as interrupt, the rps was calculated in the 1Hz periodic function. Based on the rps value calculated every second the PWM signal sent to drive the DC motor was calculated dynamically to achieve the required rps specified by the Master controller.

Block diagram

Hardware Design

The hardware design includes the servo motor, DC motor, ESC and the SJ-one board. Both the ESC and Servo motor are connected to PWM pins on the SJ-one board for sending PWM signals to steer and drive the vehicle. The ESC is used to control the DC motor of the car.The power source for both ESC and DC motor is a LiPo battery. The servo motor, RPM sensor and other LEDs are powered using 5v from a power bank.

Schematic of Motor Controller

Hardware Interface

DC Motor

Titan 12-turn DC Motor

The DC motor is used to drive the vehicle using PWM signal transmitted to ESC. The DC motor in the car is provided by Traxxas and is a 12-turn brush-less motor. It can be considered as the most important part of the vehicle as it drives the vehicle ahead. The motor can be driven either in the forward direction or reverse by setting appropriate duty cycle to the ESC. In order to achieve reverse direction, the motor has to cycle through states of neutral at least once before going into reverse.

DC Motor Pin Connection
Wires on (ESC)	Description	Wire Color Code
(+)ve	Positive Terminal	RED
(-)ve	Negetive terminal	BLACK

ESC

ESC and DC Motor

The Electronic Speed Controller is also powered on by the LiPo battery and is used to control the DC motor based on the PWM signals sent to the ESC. In the figure below it can be seen that the ESC has three color coded wires which serve as pins for PWM signal(WHITE Color), VCC(RED Color) and GND(BLACK Color).

The ESC comes with the feature of calibrating the DC motor using the EZ set button that is present. It comes with three modes namely Training mode, racing mode and Sport mode and also with low voltage detection. For our project we initially used the training mode and then shifted to the Sport mode because we needed full capability of the motor for uphills and rough terrains.

ESC Pin Connection
S.No	Wires on (ESC)	Description	Wire Color Code
1.	(+)ve	Connects to DC Motor (+)ve	RED
2.	(-)ve	Connects to DC Motor (-)ve	BLACK
3.	(+)ve	Connects to (+)ve of Battery	RED
4.	(-)ve	Connects to (-)ve of Battery	BLACK
5.	P2.1 (PWM2)	PWM Signal From SJOne	WHITE
6.	NC	NC	RED
7.	(-)ve	Negetive terminal	BLACK

Servo

Traxxas Servo Motor

The servo motor is used to steer the vehicle based on commands received from the master controller. The servo motor is powered on using 5V power supply via PCB from the power-bank. The servo motor also has three pins which serve as pins for PWM signal(WHITE Color), VCC(RED Color) and GND(BLACK Color). The PWM pin configured to supply steering signal on the SJ-one board is connected to the PWM pin on the servo. We have used PWM signals at 120Hz, the values were sent for the five different positions as per the Master controller commands.

Servo Motor Pin Connection
Pin No. (SJOne Board)	Function	Wire Color Code
P2.3 (PWM4)	PWM Signal	WHITE
VCC	5 Volts	RED
GND	0 volts	BLACK

RPM Sensor

Traxxas RPM Sensor

The RPM sensor is used to measure the RPS of the shaft attached to DC motor. The sensor consists of magnet and a signal is generated every time the motor shaft cuts the magnet. This signal is used received as an interrupt on a GPIO pin in the SJ-one board. By using this, the rotations per second is calculated by clearing the interrupt every one second in the 1Hz periodic function. The sensor is installed in the gear compartment of the Traxxas car along with the magnet trigger. The pulse gets generated every time the wheel roattes and is sent on the white wire. The other two wires are used for 5V power Supply (Red) and Ground(Black).

Speed Sensor Pin Connection
Pin No. (SJOne Board)	Description	Wire Color Code
P2.6	GPIO (INPUT)	WHITE
VCC	5V	RED
GND	Ground	BLACK

IO module

The LCD is integrated with the SJOne board via SPI. The LCD is used to display speed, heading angle, bearing angle and required Heading angle.

LCD Connections

Information Displayed on LCD

LCD Pin Connection
Pin No. (SJOne Board)	LCD pin
P0.15	SCK
P0.17	MISO
P0.18	MOSI
P0.29	CS
P0.30	RESET
P1.19	DC/RS
P1.28	LED Power
VCC	3.3V
GND	Ground

Features

Display resolution: [240xRGB](H) x 320(V)
a-TFT LCD driver with on-chip full display RAM: 172,800 bytes
3-line / 4-line serial interface [SPI/I2C]
Full color mode (Idle mode OFF): 262K-color
Reduce color mode (Idle mode ON): 8-color
Timing generator
Oscillator
DC/DC converter
Line/frame inversion
4 preset Gamma curves with separate RGB Gamma correction

Software Design and Implementation

Steering and Drive Control

The steering control and speed control is done in 100Hz periodic callback loop with 5 positions SERVO_CENTER,SERVO_HARD_LEFT,SERVO_SLIGHT_LEFT,SERVO_HARD_RIGHT and SERVO_SLIGHT_RIGHT for steering and 5 values of speed FORWARD_SLOW,FORWARD_MEDIUM,FORWARD_FAST,REVERSE and BRAKES given in switch case.Only when there is a change of state it enters the switch case.If the previous state and present state are same it will not enter the switch case and stays in the previous value.

Steering control flowchart

 #define SERVO_CENTER        17.7
 #define SERVO_HARD_LEFT     10.9
 #define SERVO_SLIGHT_LEFT   14.9
 #define SERVO_HARD_RIGHT    25
 #define SERVO_SLIGHT_RIGHT  20.7

Drive Control

 #define FORWARD_SLOW        19
 #define FORWARD_MEDIUM      19.2
 #define FORWARD_FAST        20.5
 #define REVERSE             16.1
 #define BRAKES              17

Consistent speed based on feedback

The RPM sensor is connected to a interrupt capable pin.It gives the no of revolutions in one second which is interrupt based and it is cleared in every second.The speed control switch case gives the required rps for the feedback loop to achieve this rps.To achieve this rps the feedback loop will increment or decrement the PWM based on the difference between the current rps and req rps.

Feedback based Speed control

 #define GEAR_RATIO 	12.58
 #define PI		3.14159
 #define WHEEL_RADIUS	2.794			
 #define CONST_KPH     0.036

 kph = (2 * PI * WHEEL_RADIUS * CONST_KPH * no_of_rev);

IO module

The LCD is initialized by sending commands to set the power, frame rate, pixel depth.The LCD is integrated with the Bluetooth controller via SPI. The Bluetooth controller receives the CAN messages from other nodes then decode and transmit to the LCD via SPI.

LCD design

Testing & Technical Challenges

PWM Signal

We connected the oscilloscope parallel to the input of the ESC and found the PWM values that has to be given initialization.When the same PWM values was given to the ESC for initialization from the board it was not getting initialized.So we connected the output of the SJ one board to oscilloscope and found that the output frequency was different from the values it was supposed to be.Irrespective of the input frequency the output frequency is always constant.So we changed the duty cyle according the output of the micro-controller and then the ESC got initialized.

Ramp

The motor calibration for uphill and downhill requires precise PWM control for the car to be given from the SJ one board to climb the ramp.In order to determine the uphill or downhill motion of the car we used the on board tilt sensor to determine if the car is going uphill or downhill.

   tilt_x = AS.getX();
   tilt_y=AS.getY();
   if(tilt_x>46) {
       //uphill }
   else if(tilt_x<(-150)) {
       //downhill }
   }

Master Controller

The master controller is the brain of the car. It communicates over CAN bus with other modules to receive data. It accepts the values of different sensors mounted in front and rear, and takes decision based on this data. It uses heartbeat mechanisms to keep a check on other modules in the system. The entire module has two main algorithms : one for Obstacle Avoidance and another for Navigation.

Hardware Design

This module was interfaced with Microchip CAN transceiver MCP2551 to communicate with other nodes in the bus. No external peripherals were connected to the master controller.
The figure below shows the hardware design of the master.

Hardware Design of Master

Software Design

Main flow of Master controller

Master Controller uses 100Hz periodic task to receive values from other controllers. Using 100Hz periodic function ensures that most of the messages are received reliably.We have used 1 Hz task to check whether the CAN bus is working or not.

Master Control Flow

Obstacle Avoidance

For obstacle avoidance, priority was given to the middle sensor. The values obtained from middle sensor were checked first and then various conditions were applied to check the values of the left and right sensor.
The flowchart below shows the obstacle avoidance algorithm.

Obstacle Avoidance Algorithm

We used two enums to represent the various speeds and directions we would be sending to the motor module.The following snippet shows the enums we used. Such enums make the code readable and easily understandable.

Enums Used for Speed and Direction

Directions And Steering Signals

The compass readings gave a heading angle between 0 and 360. The bearing angle was obtained from the GPS module. The difference between this values would give us the direction in which the car should head if there is no obstacle.
The flowchart below shows the navigation algorithm.

Steering Angle Algorithm

Implementation

The master has to coordinate with other nodes and take decisions. To achieve this, we have used a state machine. The master takes specific decisions depending upon the state in which the car is. We have used five states : initial state, send start, get distance and heading angle, get sensor values and stop car state.

Initial State: The car will not move till all the initialization is done. The car will wait till it receives a start signal from bluetooth module.
Send Start State: In this state, the master will send a start signal to all the modules and wait till this message is transmitted over the CAN bus.
Get Distance and Heading Angle State: The master receives the heading,bearing angles and the direction from the geo module and then switches to other state.
Get Sensor Values State: The master will check for sensor values. Once it receives the values, master has to make a decision either to avoid obstacle or to go in the direction of the checkpoint.The master will go from 'get sensor values state' and 'get distance and heading angle state' till it reaches the destination or in other words, it reaches the stop state.
Stop Car State: The car goes to this state when it receives stop signal from bluetooth module or when it receives Destination reached message from the Geo module. In this state, the master will send a stop car signal to all the other modules.Once the stop signal is sent, the car will go back to initial state where it will wait for start message from the bluetooth module.

Master: State Diagram

Technical Challenges

1. Problem: Initially the sensor module was sending sensors values at 100Hz (every 10ms) to the master and the sensor module was given highest priority CAN message ID. As a result the sensor always got the arbitration of the CAN bus and there was a significant delay in the master taking action, sending appropriate control signal to motor module and the motor module taking action and this caused the car to bump into obstacles.

Solution: We changed the frequency of sensor module transmitting messages to 10Hz (every 100ms). This gave ample time for the master to send control action to the motor and the motor to act on it. The car could avoid obstacles after this change.

Bluetooth Controller And Android Application

Design And Implementation

The user selects a destination on the android application which then communicates with the Bluetooth module HC-05 through which car gets to know the route to destination. The user can directly interact with the car using the android application so this is one of the most important modules. The detailed software and hardware design is mentioned in below sub sections.

Hardware Design

This includes
• SJ-One Board
• Bluetooth Module HC-05
• Android Smartphone
• CAN transceiver

Bluetooth And SJOne Board Connection Diagram

Bluetooth Module

Bluetooth Module -HC 05

Specifications
• Bluetooth protocol: Bluetooth Specification v2.0+EDR
• Frequency: 2.4GHz ISM band
• Speed: Asynchronous: 2.1Mbps(Max) / 160 kbps, Synchronous: 1Mbps/1Mbps
• Profiles: Bluetooth serial port
• Power supply: +3.3VDC 50mA
• Working temperature: -20 ~ +75Centigrade
• Dimension: 26.9mm x 13mm x 2.2 mm
• Modulation: GFSK(Gaussian Frequency Shift Keying)
• Sensitivity: ≤-84dBm at 0.1% BER
• Security: Authentication and encryption

Hardware Interface

The Bluetooth module HC05 is connected to Bluetooth-ECU using UART3. The transmission rate is 9600bps. Bluetooth-ECU communicates with all other ECU's using CAN-Transceiver.The following pins were used for connections.

Bluetooth-ECU

Function On ECU	Pin NO of ECU	Function On HC05
RX	P4_28	TX
TX	P4_29	RX

Software Design

Bluetooth Module

The SJ One part of the Bluetooth Module plays an important role. HC-05 our Bluetooth module is interfaced to SJ one board using Uart3 Pins. On the software side, Uart3 is used for communication at 9600 Baudrate. Data received from App includes Route Co-ordinates, Drive or Abort Command. Data sent to APP includes various different parameters of the car as mentioned below. We used a semaphore to divide Data processing and transmission into the app.In-depth testing on hardware and software level were performed to ensure Data received from APP like route co-ordinates was transmitted accurately on the bus.

•Data Processing
Bluetooth module gets the current location from geo module and transmits this to android application. It then communicates the route details between source and destination. Once the Drive command is sent to the Bluetooth module, It then starts processing data periodically in a 100Hz task. The Bluetooth module will be processing data but to transmit the processed data to the Android application it waits for the command from the Android application. Once it receives the command it starts transmitting.

•Data Transmission
Bluetooth module transmits important data to Android Application.The data includes Speed of the car, current Direction of the car, Location of the car, Bearing Angle and Sensor Values. All these data is received from other modules over CAN and transmitted to the Android Application.The implementation of this algorithm is depicted in the flowchart.

Flowchart for Data Processing and Transmitting in BT Module

Android App showing recieved data

Android Application

The software implementation of android application mainly has 2 activities.
• Main Activity
The main activity checks for the Bluetooth connectivity, if the phone Bluetooth is turned off then it requests to turn it on. When the Bluetooth module is in a well-defined range then it automatically connects to it. Once the connection is established we need to get the location of the Car. A marker will be seen on the Google Maps and we need to drag this to our destination position, transmit these details to the Bluetooth module. Now we are ready to drive. There is an abort button using which we can stop the car anytime.
• Stats Activity
This page gives the important details regarding the car. It includes the current speed of the car, where is heading, the bearing angle to the next checkpoint, its current location. We can also visualize the obstacles the sensors detect through a small GIF created in the Application. Below are the flowchart and the screenshots of the application.

APP Asking User to turn on Bluetooth

Route Showing Initial Co-ordinates

Slecting Destination from Current Location

Route Showing Destination Co-ordinates

Flowchart for recieveing and transmitting co-ordinates in Android APP

Implementation

A wireless Bluetooth socket is created from the android app, connecting the Bluetooth module HC-05 and the Application. The Bluetooth module is then connected to the ECU using UART.This enables an interface for controlling the car.

Technical Challenges

Establising Stable Connection with Car: Establishing a stable connection with the car is crucial as this is the only means of controlling and monitoring the car. As the Bluetooth range is low, the connection used to end as the car started moving and re-connection was necessary to abort the car when required. This was overcome by implementing an automatic connection between android app and CAR. Every time the CAR was in the range of APP it was re-connecting automatically.
Data Transmission: Data Processing and Transmission into APP by ECU was causing problems as the ECU could not handle simultaneous processing and transmission of all the data received over can into UART. This was overcome by processing the received data in 100Hz task and Transmission over BT was performed in 10Hz task
Receiving data from Bluetooth at 2 different activity using a single socket was a big challenge this was overcome by using a singleton class for Bluetooth connection

Geographical Controller

Design And Implementation

The Geographical controller acts as the navigation unit for the Viserion. It communicates with the attached GPS and compass unit over UART interfaces. It determines the location of the car in terms of Latitude and Longitude and figures out the car's direction with respect to Magnetic North axis. The Geo controller sends the Car's current location to BT application and then receives the source to destination check points, back from the BT application. Geo module periodically calculates the bearing angle with respect to the destination (subsequent checkpoints) and it sends the bearing angle and the compass angle to master module to steer the car towards the destination.

Hardware Design

The components included in Geo Module are as follows
• SJ-One Board
• GPS Module
• Compass Module
• CAN transceiver

The following block diagram captures how the GPS and Compass modules are interfaced with Geographical Controller.

Block Diagram for Geo Module

Software Design

Software flow diagram for Geo Module

- The GEO module is split into modular files containing the compass functions and GPS functions separately.
- The GPS comprises majorly of the state machine implementation and the bearing angle calculation block as discussed below.
- The software design involves a state machine implementation as depicted above, in which few of the cases are dependent on the flag set in the previous case.

State machine for Geo Module

- Angle computation block involves:

       /*calculate the numerator and denominator for haversine formula*/
       numerator = (cos(lat2)*sin(dlon));
       denominator = (cos(lat1)*sin(lat2)) - (sin(lat1)*cos(lat2)*cos(dlon));
       /*Calculate bearing angle*/
       theta = atan2(numerator, denominator);

- The compass module majorly consists of the angle retrieving block and the offset compensation block.

Rest of the data flow is self explanatory as seen from the flow diagram above.

Components

Accuracy of Compass and GPS module is of paramount importance, to successfully navigate the car towards the destination. The compass module is sensitive to the magnetic interference generated from the other components on the car and thus needs to be calibrated to compensate those interfaces. GPS module offers different configuration such as baud rate, selection of positioning systems etc, The module needs to be configured using u-center application from UBlocks.

Compass Module

The Sparkfun's SEN-14001 9DOF Razor's MPU-9250 module has ability to detect linear acceleration, angular rotation velocity and magnetic field vectors using on board 3 axis sensors such as accelerometer, gyroscope and magnetometer.

Compass Calibration

The Calibration of compass module is done with the help of Arduino IDE and the Magnetometer script written using open GL framework "processing".

The Guide https://learn.sparkfun.com/tutorials/9dof-razor-imu-m0-hookup-guide
from Sparkfun walks through the steps required to setup the environment to communicate with the compass module.

We followed the following procedure to calibrate the compass module.
Note the procedure mention is with respect to the east coast, it will differ sligtly for west coast

1. Download and flash the application written by "elizabethsrobert" to output the maximum and minimum values from all the three sensors.
The firmware can be obtained from the following link
https://github.com/sparkfun/9DOF_Razor_IMU
2.Calibrating accelerometer
To calibrate the accelerometer, tune the calibration application to output the maximum and minimum readings for all the three axes from accelerometer. To calibrate X axis,Hold the accelerometer flat to the surface and rotate it along Y-axis such to get the Xmax and Xmin value. Be careful to move the accelerometer slowly so that it is not affected by the acceleration of gravity. Repeat the sequence for all the axes.
3.Calibrating Gyroscope
Keep the module stable on the surface, select the gyroscope calibration, the module will average out noise on all the axes.
4.Calibrating Magnetometer [Hard Iron effects]
Align the X-axis of the magnetometer with North pole of the earth and rotate the module along E-W axis, tilt the compass in little further in both the axes until you the max/min values are increasing. Repeat the step for all the other axes.

Offsetting Hard Iron Effects

5.Magnetic declination
The true magnetic north pole is deviated by +13.22 degrees as of December 18,2017, consider the declination values to calibrate the compass. The following Picture shows the magnetic declination at sanjose. Magnetic Declination Calculator http://www.magnetic-declination.com

Magnetic Declination at San Jose

6. Feed all the calculated values back to the application written by "elizabethsrobert to output the calibrated pitch,roll,yaw values. The Yaw value points to the Y axis of Magneto meter which provides the Head angle of compass with respect to the magnetic north.

GPS Module

Ublox Ready to Sky

The GPS module is the core unit of the car that is responsible to accurately navigate the car to it's destination based on the Latitude and Longitude values it provide. Choosing the right, stable and a good GPS module is crucial for the car's ultimate working. If the GPS used is of cheap quality then there are lot's of trouble in it's calibration and navigation. Investing in a right GPS module is the most important thing for the team and car's functioning. After a lot of study and understanding the previous projects we decided to select the Ublox GPS chip[1]

There are some modules available that have incorporated the Ublox GPS chip and created a product that can be directly used by the user in their system with minimum technical challenges. We also decided to go with one such module. Readytosky Ublox NEO-M8N GPS Module w/ Built-in HMC5883L Compass Protective Case with GPS Antenna Mount[2]

Why we selected Ublox GPS module?

The very first reason is the quality and technical support provided by the Ublox. Also the Ublox module was available on Amazon at a fairly good price. Having a good review on internet across various websites, it was seen that this module found its application use in many projects including quad copters and drones. This significantly shows that how stable, good and reliable the module is.

Some of the technical features of the module are:

The NEO-M8 series utilizes concurrent reception of up to three GNSS systems (GPS/Galileo together with BeiDou or GLONASS), recognizes multiple constellations simultaneously and provides outstanding positioning accuracy in scenarios where urban canyon or weak signals are involved. For even better and faster positioning improvement, the NEO-M8 series supports augmentation of QZSS, GAGAN and IMES together with WAAS, EGNOS, MSAS. The NEO-M8 series also supports message integrity protection, geofencing, and spoofing detection with configurable interface settings to easily fit to customer applications. The NEO form factor allows easy migration from previous NEO generations. The NEO-M8M is optimized for cost sensitive applications, while NEO-M8N/M8Q provides best performance and easier RF integration. The NEO-M8N offers high performance also at low power consumption levels. The future-proof NEO-M8N includes an internal Flash that allows future firmware updates. This makes NEO-M8N perfectly suited to industrial and automotive applications.

Support for the GPS module:

Apart from this the Ublox provides user with a Software frame work called the U-center. u-center evaluation software provides system integrators and end users with a quick and simple way to interface with u-blox GNSS chipsets, modules and boards. It enables easy evaluation, performance testing, development and debugging of GNSS positioning chips and modules. u-center allows easy connection to u-blox products and provides a suite of features to view, log, and analyze performance.

Ucenter: Software Package for Configuration of GPS

GPS Calibration

The GPS module that is received from the vendor is not calibrated or configured. Directly using the module in the car would result in lot of technical challenges and problems. We first need to understand our application use case and then configure and calibrate the GPS as per our requirement.

Now what exactly are we looking in terms of configuration/calibration for the GPS module?

The GPS module by default has multiple GNSS (GPS, Galileo, GLONASS and BeiDou) constellations active. Also there are other Augmentation systems(SBAS, QZSS, IMES, D-GPS) that are active. There are different NMEA protocol (GPGGA, GLL, GSV, GST, RMC, etc) messages that are simultaneously received as well. The baud rate is at different speed (9600 default) for the UART communication.

To have the GPS module perfectly work for the autonomous car requirement we had to do many configurations including.

1-Setting the NMEA messages to GPGGA format

2-Increasing the baud rate to 115200

3-Activating the pedestrian mode

4-Refresh rate of the GPS to 10Hz

5-Using the GNSS constellation of choice. We used all the constellations so as to get a deferentially corrected position,there by increasing the accuracy

For detailed configuration settings refer the U-center guide [3]

GNSS configuration of GPS

Pedestrian mode configuration of GPS

NMEA configuration of GPS

Implementation

Algorithm

Sequence diagram for Geo Module

As seen in the above sequence diagram, the heading and bearing angle calculation only start after the start signal is received from the master after following the above mentioned handshake to initiate the system communication.

The following is the algorithm:

- Follow the above handshake sequence and wait till the start signal is received from the master.
- Start retrieving the compass angle from the compass module over UART.
- Simultaneously start calculating the bearing angle after filtering the GPS module current coordinates received over UART and offset checkpoints received from Bluetooth.
- Encode the message with these angles and send them to the master at every 10Hz.
- The same data along with the GPS current coordinates is also sent to the Bluetooth module every 3 seconds, so that it could be displayed on the android app.
- Alongside the above calculations, the checkpoint reached and destination reach checks are made simultaneously.
- Once the destination is reached a stop signal is received from the master, post which the calculations stop and the parameters reset.

Bearing angle calculation

In general, your current heading will vary as you follow a great circle path along the globe, the final heading will differ from the initial heading by varying degrees according to distance and latitude.

This formula is for the initial bearing (sometimes referred to as forward azimuth) which if followed in a straight line along a great-circle arc will take you from the start point to the end point:1

Haversine Formula: θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ ) where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

 var y = Math.sin(λ2-λ1) * Math.cos(φ2);
 var x = Math.cos(φ1)*Math.sin(φ2) -
       Math.sin(φ1)*Math.cos(φ2)*Math.cos(λ2-λ1);
 Bearing = Math.atan2(y, x).toDegrees();

 Bearing angle(summarized)
 =ATAN2(COS(lat1)*SIN(lat2)-SIN(lat1)*COS(lat2)*COS(lon2-lon1), 
      SIN(lon2-lon1)*COS(lat2))

The above formula is used to find the bearing angle dynamically. We have the set of checkpoints coordinates from Bluetooth and the current location coordinates from the cars' GPS module. Dynamically while the car is running, it calculates this angle based on its current checkpoint and its next checkpoint to understand the angle, the plane in which these points reside make with the north plane. It is very important to know this angle and the heading angle of the car to make the stereo motion decision.

Decision making

Decision making based on angles

Once the bearing angle has been calculated, the heading error angle can now be calculated. Heading error angle is simply the bearing angle (B) minus the compass heading angle (H). Refer to above image.

   Heading Error = A - H

The heading error will dictate whether the car needs to take a left or right. Hence, whenever the heading error is positive, the cars needs to keep right and whenever heading error is negative, it keeps left. This decision is finally based by the master once the angles are provided to him.

Testing

Performance Analysis of Compass

1. Compare the performance with the off-shelf compass module. Make the heading angle given by compass module by rotating the compass, turn off the compass module, Place an off-shelf compass module exactly at the same place (direction same as pointed by Y axis of Magnetometer) note down the reading, rotate the compass by 90 degrees and repeat the same procedure. If the difference in all the readings is in within single digit, the performance of the compass is satisfactory.
2. Analyzing the 3D model of IMU on AHRS test using open GL processing framework.
Periodically send yaw,pitch,roll values to the AHRS test application, to plot the 3D model of IMU. The plotted 3D model should mimic the rotation and movements of the IMU.

3D model of IMU on processing framework

Technical Challenges

Soft Iron Effect for Compass

While Hard Iron Effects are constant and could be compensated by calibrating the offset, the soft iron effects are caused by the distortions produced by orientation of the material relative to the sensor and are not constant.

The initial mount for the compass module was made up of a string of stand-offs made up of aluminium.

Aluminum stand offs

Plastic stand offs

The magnetometer calibration tool based on processing framework plots the sample received from the IMU in a 2D plane, for a calibrated compass the value received from the magnet from the should lie inside the "Sphere of Magnet", however the values obtained were sprayed all over the place.

To resolve the issue, we modified our choice of material used, we used a stand made up of plastic to mount the compass on the car, and made a PCB to reduce the number of wires near the compass.

The resulted output was excellent, majority of the magnetometer values were inside the sphere, as shown in the figure below.

Sphere of Magnet

GPS Challenges

The biggest problem was to determine whether our GPS module is working good, giving stable and accurate readings. Other than that the problems faced were:

1- The dynamic drifting of the GPS latitude and longitude values

2- Achieving the GPS lock

3- Isolating the exact NMEA message

4- Getting the highest precision of location

5- Configuring the baud rate to match the refresh rate of the GPS module to navigate the car accurately

Visual representation of latitude and longitude

Solutions to the problems:

The solution to the problem to determine whether our GPS module is working good, giving stable and accurate readings was to do analysis on the latitude and longitude readings. For that we first need to understand the structure of the earth, the layout of latitude and longitude, and it's relation to distance between two points on earth.

The radius of the semi-major axis of the Earth at the equator is 6,378,137.0 meters resulting in a circumference of 40,075,161.2 meters. The equator is divided into 360 degrees of longitude, so each degree at the equator represents 111,319.9 meters or approximately 111.32 km. As one moves away from the equator towards a pole, however, one degree of longitude is multiplied by the cosine of the latitude, decreasing the distance, approaching zero at the pole. The number of decimal places required for a particular precision at the equator is given below. We then calculate it for San Jose to determine the change in distance for change in latitude/longitude.

One degree change in longitude at equator = 111.32 km and becomes zero at the poles.

therefore at San Jose we have

1 degree longitude distance = distance at equator x COS (latitude)

                           = 111.32 x COS(37.3382)
                           = 88.94 km

The GPS lock is said to be achieved when there are 3 or more satellites tracking a GPS module. Initially when testing in the University rooms/buildings, it was difficult to get the GPS lock. The lock was achieved in the open area or in the regions where there was adequate space for the module to receive messages from the satellite. If the GPS lock is not present the GPS will not give you the proper readings of the location.

After having the GPS lock it was observed that there are multiple NMEA messages that are received from the module, making it difficult for us to exactly isolate the string of interest and extract the latitude and longitude values from it. NMEA messages are shown with heading $Gxyyy, where x stands for the satellite system (P = GPS, SBAS, QZSS, L = GLONASS, A = Galileo, B = BeiDou, N = Any combination of GNSS) and yyy for the type of message (e.g. ZDA=Time & Date). We then disabled the other NMEA messages from the system and only activated the GPGGA string, as that was what we were interested in. There are many NMEA formats available, the reason why we selected this was because this string provides the information about the number of satellites it has locked, as well as it gives high precision latitude and longitude values by using other GNSS constellation if enabled.

Multiple NMEA messages being received

$GPGGA,HHMMSS.SS,DDMM.MMMMM,K,DDDMM.MMMMM,L,N,QQ,PP.P,AAAA.AA,M,±XX.XX,M,SSS,RRRR*CC<CR><LF>

where

example:

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:

    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

To get the highest and accurate data from the GPS module we enabled the GNGGA string. The GNGGA is the deferentially corrected position from the multiple satellites, here N means we enabled the multiple satellite tracking for our module to obtain the precise location from the satellite.

Only GNGGA messages being received

Major issues

Issue #1: GEO Issues

1. Compass offset error correction: While mounting the compass on the actual system, it was seen that the heading was drifted with respect to north. To fix this issue we had implemented a button functionality which would start the offset calculation on press of switch 1 based on its alignment with the true north and then would increment the offset by +5 degrees on switch 2 press and -1 degrees on switch 3 press and end the offset calculation on switch 4 press.

2. Geo offset fix: While testing we noticed that there was GPS coordinates drift between the checkpoint coordinates obtained from the Google maps and the current coordinates obtained from the GPS module mounted on the car. We fixed this by adding an offset and by increasing the number of checkpoints.

Issue #2: Motor issues

Oscilloscope was connected parallel to the input of the ESC and the PWM values were recorded.When the same PWM values were given to the ESC, the for initialization was not happening.We saw that, irrespective of the input frequency the output frequency is always constant.So we changed the duty cycle according the output of the controller to fix this.

Issue #3: Android App issues

1. Establishing a stable connection with the car is crucial as this is the only means of controlling and monitoring the car. As the Bluetooth range is low, the connection used to end as the car started moving and re-connection was necessary to abort the car when required. This was overcome by implementing an automatic connection between android app and CAR. Every time the CAR was in the range of App it was re-connecting automatically.

2. There had to be a mechanism to assure that the sent checkpoints were correctly received by the GEO module without any loss. Hence, we devised an initial handshake state machine logic which would ensure that the start signal from master comes only after proper reception of the checkpoint coordinates.

Conclusion

With immense sense of satisfaction, we would like to mention that we are fortunate for having taken this course which led us through challenges, helped us boost our technical and managerial skills and built confidence in us. Segregating work into modules and further splitting them into smaller tasks with estimated deadlines, kept us focused throughout and helped us achieve our target

We definitely got a chance to learn from a diverse set of experienced people within the group. Some of us were good at hardware, some at algorithms and some in app development etc. However, each of us strived to learn from every other module. The theoretical concepts that we acquired from the lectures helped us apply them practically on the car. We got hands on experience on GIT and unit testing which is an icing on the cake. Interacting with other team members helped us resolve similar issues quicker. We also progressed in our documentation skills.

Talking about the problems, persistent testing of our design and brainstorming with other team members helped us find hidden problems such as car drifting because of inaccurate Google assigned coordinate, issues in obstacle detection due to delay in the response, calibration of the magnetic compass getting worse every time the environment is changed, motor speed control issues etc. We were able to fix all these issues on time. Various techniques were tried and finally the best of all approach was implemented.

Finally, we would like to acknowledge the contribution of each and every team member, the knowledge sharing sessions we had and the patience within the team to successfully achieve this target.

Project Video

Car Navigation

Project Source Code

Viserion Team GitLab Source Code

References

Acknowledgement

This project was a very good learning curve for the whole team. We would like to thank Prof. Preetpal Kang for the Embedded Industrial Applications course. We appreciate Prof. Preetpal Kang's efforts to improve the course every year and the guidance he has provided throughout the semester.We gained lot of practical knowledge from this course. The project made us utilize many aspects of a practical embedded system. We would also like to thank the ISA team for their guidance during the project. Their experiences helped us take better decisions during the course of the project.

References Used

[1] CMPE 243 Lecture notes from Preetpal Kang, Computer Engineering, San Jose State University. Aug-Dec 2017.
[2] Fall 2016 Wiki Projects
[3] Google Maps API
[4] Maxbotix Ultrasonic Sensor
[5] CAN Transceiver: MCP2551
[6] GPS datasheet

@@ Line 5: / Line 5: @@
 == Abstract ==
-Aim of this project is to build a self-navigating car. The car is divided into five modules. Each module consists of SJ One board as the main controller. The different modules in the car are master, sensors, geo, motor and bluetooth module. The car uses CAN communication protocol for communication between the modules.
+Aim of this project is to build a self-navigating car. The car is composed of five important modules. Each module consists of SJ One board as the main controller.
 The five modules of the car are :<br>
@@ Line 13: / Line 13: @@
 '''Bluetooth Controller:''' The controller uses Bluetooth to communicate with an Android application. Destination coordinates are provided by this module. The bluetooth module also displays important data like sensor readings, GPS coordinates and speed. <br>
 '''Master Controller:''' This module will collect data from all modules and direct the motor towards the destination.<br>
+The car has a centralized CAN bus to communicate between the modules.
 == Objectives & Introduction ==
@@ Line 74: / Line 76: @@
 *<font color="black">Research previous projects wiki page, gather useful information. </font>
 *<font color="black"> Discuss about roles and study data sheet of the required parts and list down minimum two parts for each required function.</font>
-*<font color="black"> Setup Git and slack accounts and verify that access is provided to all the team mates.
+*<font color="black"> Setup Git and slack accounts and verify that access is provided to all the team mates.</font>
-| Done</font>
+|10/15/2017
+|Done
 |
 |-
@@ Line 91: / Line 94: @@
 *<font color="purple"> Study Android application software and approaches from previous projects and document the required features being provided by the application.
 *<font color="black"> Order finalized Components.</font>
-| Done on time except
+|10/22/2017
-*<font color="grey">PCB design was changed to only one PCB that will gather all controllers and have Can Bus on it.
+|Done on time except
+*PCB design was changed to only one PCB that will gather all controllers and have Can Bus on it.
 |
@@ Line 98: / Line 102: @@
 ! scope="row" | 3
 | 10/23/2017
-| 29/10/2017
+| 10/29/2017
 |
 *<font color="black"> Start interfacing received components to respective Nodes and do a superficial testing of components. </font>
@@ Line 108: / Line 112: @@
 *<font color="orange"> Interface all three front sonic sensor to the sensor controller. Apply filtering to get reliable data and send data to Master Controller.
 *<font color="purple">Document Android approaches and decide on how to design the app and fix the protocol to exchange data with Bluetooth module.
-| Done on time except
+|10/29/2017
-*<font color="grey">Basic PCB design is done
+|Done on time except
-*<font color="orange"> Filtering was not applied at this time
+*Filtering was not applied at this time
 |
@@ Line 124: / Line 128: @@
 *<font color="clouds">Test can bus communication by mounting master, sensor and motor modules and transmitting master related commands.</font>
 *<font color="black">Mount the parts on off shelf PCB for Demo 1 and verify the wiring connections and verify that CAR is ready for the demo, </font>
+| 11/03/2017
 | Done on time
 |
@@ Line 139: / Line 143: @@
 *<font color="black"> Car should now move without hitting "any" obstacle when powered on. Car should be able to take a reverse if required.
 </font>
-|
+| 11/12/2017
-*<font color="orange"> Back sensor was not yet interfaced. Filtering applied for front sensors.
+|Done.
+*Back sensor was not yet interfaced. Filtering applied for front sensors.
 |
@@ Line 153: / Line 158: @@
 *<font color="purple">Design basic Android application UI, which can verify that the communication with BT module was successful or not </font>
 *<font color="black"> Fetch current longitude and latitude values from GPS modules via BT app and send all the checkpoints to the destination via BT app and BT module to master and verify the link between GPS/Compass, master and BT module and Application is working as expected.</font>
-|
+|11/18/2017
-*<font color="grey">PCB design not finished yet.
+|Done except,
-*<font color="orange"> Back sensor interfaced.
+*PCB design not finished yet.
+*Back sensor interfaced.
 |
@@ Line 166: / Line 172: @@
 *<font color="orange"> Mount sensors on new/final hardware solution, position them properly and test again received data while car is in move. </font>
 *<font color="black"> If the link between Geo, BT, master and Motor module is working, perform outdoor system testing. </font>
-|
+|11/25/2017
-*<font color="grey">PCB design finished and main PCB board ordered
+|Done.
-*<font color="orange"> Still waiting for sensor mounts 3D printing to be finished.
+*PCB design finished and main PCB board ordered
+*Still waiting for sensor mounts 3D printing to be finished.
 |
@@ Line 179: / Line 186: @@
 *<font color="orange"> Interface Head lights and turn them ON based on light sensor value. </font>
 *<font color="purple">Implement automatic bluetooth connection between APP and bluetooth module</font>
-|
 *<font color="grey">Sensor breakout PCB design and ordered </font>
+|12/01/2017
+|Done.
+*Decided not to interface head lights, to prolong the battery.
 |
@@ Line 192: / Line 201: @@
 *<font color="black">Start documenting project report by collaborating artifacts produced during project development. </font>
 *<font color="black">Fix the bugs in system testing. </font>
-|
+|12/08/2017
+|Done.
+*Discovered the bugs with respect to bearing angle calculation, GPS configuration and Motor Speed.
+* Modified the bearing angle calculation algorithm to use haversine formula instead of vector projection method. Configured GPS to use GNGGA.
 |
@@ Line 203: / Line 215: @@
 *<font color="black"> Start documenting project report by collaborating artifacts produced during project development.</font>
 *<font color="black"> Fix the bugs in system testing.</font>
-|
+|12/12/2017
+|Done.
+* Created a rough draft report of all the modules. Applied averaging on GPS values.
 |
@@ Line 214: / Line 228: @@
 *<font color="black"> Work on unfinished project report documentation.</font>
 *<font color="black"> Fix the bugs in system testing.</font>
-|
+| 12/16/2017
+| Done
+* Improved GPS stability by enabling differential correction for GPS.
 |
@@ Line 226: / Line 242: @@
 *<font color="black"> Record a video to demonstrate project working and features.</font>
 *<font color="black"> Complete Documentation of wiki page. </font>
-|
+| 12/19/2017
+| Done.
+* Car is ready for the demo. Video editing is in progress.
 |
@@ Line 235: / Line 253: @@
 |
 *<font color="black"> Ready for Demo.</font>
-|
+| 12/20/2017
-|
+| Done.
+*Car successfully navigated to it's destination
 |}
 == Viserion DBC File ==
+The DBC is designed to allow high priority message with the least message ID.<br>
+message ID 80-90 are critical messages which initializes all the modules or stop all the modules (Abort) when required.<br>
+message ID 90-100 are reserved for module heart beats, to make sure that the modules are working fine.<br>
+The Next important message ID 101 is reserved for sensor to periodically inform master about the obstacles,Detection of obstacle is given the highest priority to ensure that the car does not hit the obstacles. To achieve that it's important that the sensor have right to the bus whenever they wish to inform the master about obstacles. <br>
+Depending upon sensor feedback motor has to act, hence master uses next important message ID range 200 to inform Motor as per the sensor values. <br>
+Message ID 400-600 is reserved for communication between BT and GEO modules. This range is used for receiving car's current location, checkpoints to the destination, to periodically send bearing and compass angles. Since these values do not update frequently hence this communication is assigned the least priority on the CAN bus.
 <pre>
@@ Line 456: / Line 484: @@
 === Unit Testing ===
+Unit testing is a level of software testing where individual components or modules are tested. The purpose of unit testing is to validate that your code performs as you designed it. With the use of unit testing frameworks, stubs, and mock objects, code can be manipulated and tested without having to load compiled code onto a controller. We used Cgreen framework for our unit testing and the major functionalities of all the modules were unit tested for timely bug catching and fixes.
 === Code review ===
 - During the planning phase of the project we had listed a set of coding guidelines to be followed uniformly within the team. This included naming
@@ Line 467: / Line 497: @@
 == PCB Design ==
+Main approach for PCB was to try to get rid of as much cables as possible. So far we saw many previous teams using ribbon cable to connect SJOne boards to PCBs  but since there is 5 controllers we thought even that will not look nice and clean so we were looking for different solution. Our solution was to design PCB with female headers facing down so that match 17x2 male headers on SJOne boards facing up. This was also done in order to be able to see built-in LED diodes and two digits display on SJOne boards which we used for debugging and to display important information. We used Eagle PCB designer free version we were restricted with max PCB size so there was place to connect only four boards like this. Fifth board was remote and also connected to this PCB but with only three wires, CANH, CANL and GND. Of course, main PCB also provided connections for power for all SJOne boards as for "Sensor Breakthrough PCB"
+<center>
+<table>
+<tr>
+<td>
+[[File:CmpE243_F17_Viserion_mainPCB_up.png|center|250px|thumb|Up facing Main PCB]]
+</td>
+<td>
+[[File:CmpE243_F17_Viserion_mainPCB_down.png|centre|240px|thumb|Down facing Main PCB]]
+</td>
+</tr>
+</table>
+</center>
+[[File:CmpE243_F17_Viserion_mainPCB_idea.png|centre|260px|thumb|Final product]]
+Second PCB we designed was "Sensor Breakout PCB" which task was to reduce wiring from sensors to Main PCB, to collect all wiring and to use only 12-pin ribbon cable to connect it to Main PCB> More about this PCB you can find under Sensors section.
+[[File:CmpE243 F17 Viserion sensorPCB.png|centre|700px|thumb|Sensors PCB]]
 == Sensors Controller ==
@@ Line 547: / Line 596: @@
 </center>
-=== Software Design ===
+=== Software Design and Implementation===
-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 pseudocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
+Sensor software part is mostly written in 100Hz task. The idea is to trigger sensors, get the readings and calculate distance (readings from sensors are just raw values not real distance in inches). Since values are not perfectly stable we used filter to clear garbage values, which we were getting from sensors from time to time. Filter used here is mode filter but in combination with simple averaging since there is no mode value if all values in the list are different.
+Here you can see flowchart where all boxes you can see represent separate functions defined in separate files, just called in 100Hz task.
+[[File:CmpE243_F17_Viserion_sensor_flowchart.png|centre|260px|thumb|Sensors SW Flowchart]]
+'''Trigger Sensors'''
+Front three sensors are triggered at the different times, every 50ms. It was easily done by calculating modulus (count % 15) and comparing it with 0, 5 or 10 based which sensor we want to trigger. With this approach it easily to switch and to make left and right sensors triggered at the same time and then trigger middle sensor in order to avoid interference.
+'''Calculate Distance'''
+Since we were using ADC to integrate front three sensors first thing to do in Calculate section was to get readings which actually are just number of steps that represent voltage level. In order to get real voltage value from the sensor  and thus real distance, raw value got from sensors is multiplied with add_step_voltage, and then divided by voltage_scaling which is defined by voltage level powering the sensors (our was 3.3V) and manufacturer scaling (VCC/512).
+'''Push and Pop'''
+is just simple function to add calculated values into lists used for filtering.
-=== Implementation ===
+'''Filter'''
-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.
+Applied is mode filter. More about it you can find online but shortly it returns value that occurs most often. Since there was situation when car is in move all values in list are different and mode was not possible to find, we applied simple averaging to tackle this problem.
 == Motor and I/O Controller ==
@@ Line 571: / Line 632: @@
 === 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 the inner working of your project.
 ==== DC Motor ====
 [[File:CmpE243_F17_Viserion_traxxas_12turn_dc_motor.jpg|300x300px|thumb|right|Titan 12-turn DC Motor]]
@@ Line 708: / Line 767: @@
 |-
 |}
+<br>
+<br>
+==== IO module ====
+The LCD is integrated with the SJOne board via SPI. The LCD is used to display speed, heading angle, bearing angle and required Heading angle.
+<table align=center>
+<tr>
+<td  valign = top>
+[[File:CmpE244 F17 T5 LCD HW.jpg|600px|thumb|center|LCD Connections]]
+</td>
+<td  valign = top>
+[[File:CMPE243 F17 Viserion LCD.jpg|217px|thumb|center|Information Displayed on LCD]]
+</td>
+</tr>
+</table>
+{| class="wikitable"
+|+ LCD Pin Connection
+|-
+! scope="col"| Pin No. (SJOne Board)
+! scope="col"| LCD pin
+|-
+! scope="row"| P0.15
+| SCK
+|-
+! scope="row"| P0.17
+| MISO
+|-
+! scope="row"| P0.18
+| MOSI
+|-
+! scope="row"| P0.29
+| CS
+|-
+! scope="row"| P0.30
+| RESET
+|-
+! scope="row"| P1.19
+| DC/RS
+|-
+! scope="row"| P1.28
+| LED Power
+|-
+! scope="row"| VCC
+| 3.3V
+|-
+! scope="row"| GND
+| Ground
+|}
+===== Features =====
+* Display resolution: [240xRGB](H) x 320(V)
+* a-TFT LCD driver with on-chip full display RAM: 172,800 bytes
+* 3-line / 4-line serial interface [SPI/I2C]
+* Full color mode (Idle mode OFF): 262K-color
+* Reduce color mode (Idle mode ON): 8-color
+* Timing generator
+* Oscillator
+* DC/DC converter
+* Line/frame inversion
+* 4 preset Gamma curves with separate RGB Gamma correction
 === Software Design and Implementation===
-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 pseudocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
-==== Steering Control ====
+==== Steering and Drive Control ====
+The steering control and speed control is done in 100Hz periodic callback loop with 5 positions SERVO_CENTER,SERVO_HARD_LEFT,SERVO_SLIGHT_LEFT,SERVO_HARD_RIGHT and SERVO_SLIGHT_RIGHT for steering and 5 values of speed FORWARD_SLOW,FORWARD_MEDIUM,FORWARD_FAST,REVERSE and BRAKES given in switch case.Only when there is a change of state it enters the switch case.If the previous state and present state are same it will not enter the switch case and stays in the previous value.
 [[File:CmpE243_F17_Viserion_SteeringControl_flowchart.png|600px|thumb|center|Steering control flowchart]]
@@ Line 721: / Line 847: @@
    #define SERVO_SLIGHT_RIGHT  20.7
-==== Drive Control ====
 [[File:CmpE243_F17_Viserion_DriveControl_flowchart.png|600px|thumb|center|Drive Control]]
@@ Line 731: / Line 856: @@
 ==== Consistent speed based on feedback ====
-The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
+The RPM sensor is connected to a interrupt capable pin.It gives the no of revolutions in one second which is interrupt based and it is cleared in every second.The speed control switch case gives the required rps for the feedback loop to achieve this rps.To achieve this rps the feedback loop will increment or decrement the PWM based on the difference between the current rps and req rps.
 [[File:CmpE243_F17_Viserion_FeedbackControl_flowchart.png|450px|thumb|center|Feedback based Speed control]]
@@ Line 742: / Line 867: @@
    kph = (2 * PI * WHEEL_RADIUS * CONST_KPH * no_of_rev);
-=== Testing ===
-==== Unit Testing ====
+==== IO module ====
-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
+The LCD is initialized by sending commands to set the power, frame rate, pixel depth.The LCD is integrated with the Bluetooth controller via SPI. The Bluetooth controller receives the CAN messages from other nodes then decode and transmit to the LCD via SPI.
-==== On-road Testing ====
+[[File:CmpE243_F17_T5_LCDSWDesign.jpg|450px|thumb|center|LCD design]]
-=== Technical Challenges ===
+=== Testing & Technical Challenges ===
 ==== PWM Signal ====
 We connected the oscilloscope parallel to the input of the ESC and found the PWM values that has to be given initialization.When the same PWM values was given to the ESC for initialization from the board it was not getting initialized.So we connected the output of the SJ one board to oscilloscope and found that the output frequency was different from the values it was supposed to be.Irrespective of the input frequency the output frequency is always constant.So we changed the duty cyle according the output of the micro-controller and then the ESC got initialized.
@@ Line 771: / Line 896: @@
 This module was interfaced with Microchip CAN transceiver MCP2551 to communicate with other nodes in the bus. No external peripherals were connected to the master controller.<br>
 The figure below shows the hardware design of the master.<br>
-[[File:CmpE243_F17_MasterHardwareDesign.jpg|center|thumb|Hardware Design of Master]]
+[[File:CmpE243_F17_MasterHardwareDesign.jpg|center|600px|thumb|Hardware Design of Master]]
 === Software Design ===
@@ Line 777: / Line 902: @@
 Master Controller uses 100Hz periodic task to receive values from other controllers. Using 100Hz periodic function ensures that most of the messages are received reliably.We have used 1 Hz task to check whether the CAN bus is working or not.<br>
-[[File:CMPE243_F17_Master_Mainflow.jpg|center|400px|thumb|Master Control Flow]]
+[[File:CMPE243_F17_Viserion_MasterControlFlow.jpg|center|400px|thumb|Master Control Flow]]
 ==== Obstacle Avoidance ====
@@ Line 783: / Line 908: @@
 The flowchart below shows the obstacle avoidance algorithm.<br>
-[[File:CMPE243_F17_Viserion_ObstacleAvoidanceAlgorithm.jpg|center|thumb|600px|Obstacle Avoidance Algorithm]]
+[[File:CMPE243_F17_Viserion_MasterObstacleAvoidance.jpg|center|thumb|600px|Obstacle Avoidance Algorithm]]
 We used two enums to represent the various speeds and directions we would be sending to the motor module.The following snippet shows the enums we used. Such enums make the code readable and easily understandable.<br>
 [[File:CmpE243_F17_Master_Enums.PNG|center|thumb|Enums Used for Speed and Direction]]
@@ Line 790: / Line 915: @@
 The compass readings gave a heading angle between 0 and 360. The bearing angle was obtained from the GPS module. The difference between this values would give us the direction in which the car should head if there is no obstacle.<br>
 The flowchart below shows the navigation algorithm.<br>
-[[File:CMPE243_F17_Viserion_GPSAlgorithm.jpg|center|thumb|250px|Steering Angle Algorithm]]
+[[File:CMPE243_F17_Viserion_MasterGPSAlgorithm.jpg|center|thumb|250px|Steering Angle Algorithm]]
-=== Testing Challenges ===
-==== Technical Challenges ====
-. Problem:
-Initially the sensor module was sending sensors values at 100Hz (every 10ms) to the master and the sensor module was given highest priority CAN message ID. As a result the sensor always got the arbitration of the CAN bus and there was a significant delay in the master taking action, sending appropriate control signal to motor module and the motor module taking action and this caused the car to bump into obstacles.
-Solution:
-We changed the frequency of sensor module transmitting messages to 10Hz (every 100ms). This gave ample time for the master to send control action to the motor and the motor to act on it. The car could avoid obstacles after this change.
 === Implementation ===
@@ Line 808: / Line 925: @@
 '''Stop Car State''': The car goes to this state when it receives stop signal from bluetooth module or when it receives Destination reached message from the Geo module. In this state, the master will send a stop car signal to all the other modules.Once the stop signal is sent, the car will go back to initial state where it will wait for start message from the bluetooth module.<br>
 [[File:CmpE243_F17_MasterStateMachine.jpg|center|600px|thumb|Master: State Diagram]]
+=== Technical Challenges ===
+. Problem:
+Initially the sensor module was sending sensors values at 100Hz (every 10ms) to the master and the sensor module was given highest priority CAN message ID. As a result the sensor always got the arbitration of the CAN bus and there was a significant delay in the master taking action, sending appropriate control signal to motor module and the motor module taking action and this caused the car to bump into obstacles.
+Solution:
+We changed the frequency of sensor module transmitting messages to 10Hz (every 100ms). This gave ample time for the master to send control action to the motor and the motor to act on it. The car could avoid obstacles after this change.
 == Bluetooth Controller And Android Application ==
@@ Line 822: / Line 946: @@
 ====Bluetooth And SJOne Board Connection Diagram====
-[[File:CMPE243_F17_Viserion_BT_Tranismission.gif|center|thumb|600px|Bluetooth Communication]]
+[[File:CMPE243_F17_Viserion_BT_Tranismission.gif|center|700px|Bluetooth Communication]]
 ====Bluetooth Module====
@@ Line 840: / Line 964: @@
 ===Hardware Interface===
-The Bluetooth module HC05 is connected to Bluetooth-ECU using UART3. The transmission rate is 9600bps. Bluetooth-ECU communicates with all other ECU's using CAN-Transceiver.The following pins where used for connections.
+The Bluetooth module HC05 is connected to Bluetooth-ECU using UART3. The transmission rate is 9600bps. Bluetooth-ECU communicates with all other ECU's using CAN-Transceiver.The following pins were used for connections.
 Bluetooth-ECU
@@ Line 846: / Line 970: @@
 |-
 ! scope="col"| Function On ECU
-! scope="col"| Pin NO On ECU
+! scope="col"| Pin NO of ECU
 ! scope="col"| Function On HC05
 |-
@@ Line 867: / Line 991: @@
 <tr>
 <td valign = top width= 60%>
-The Bluetooth module establishes communication between the car and the user. Here there is a need for simultaneous communication between other modules and the android application. To achieve this with ease we distributed the data processing and transmission.
+The SJ One part of the Bluetooth Module plays an important role. HC-05 our Bluetooth module is interfaced to SJ one board using Uart3 Pins. On the software side, Uart3 is used for communication at 9600 Baudrate. Data received from App includes Route Co-ordinates, Drive or Abort Command. Data sent to APP includes various different parameters of the car as mentioned below. We used a semaphore to divide Data processing and transmission into the app.In-depth testing on hardware and software level were performed to ensure Data received from APP like route co-ordinates was transmitted accurately on the bus.
 <br>
 <b>•Data Processing</b>
@@ Line 873: / Line 998: @@
 Bluetooth module gets the current location from geo module and transmits this to android application. It then communicates the route details between source and destination.
 Once the Drive command is sent to the Bluetooth module, It then starts processing data periodically in a 100Hz task. The Bluetooth module will be processing data but to transmit the processed data to the Android application it waits for the command from the Android application. Once it receives the command it starts transmitting.
+<br>
 <br>
 <b>•Data Transmission</b>
 <br>
-Bluetooth module transmits important data to Android Application.The data includes Speed of the car, current Direction of the car, Location of the car, Bearing Angle, Sensor Values.
+Bluetooth module transmits important data to Android Application.The data includes Speed of the car, current Direction of the car, Location of the car, Bearing Angle and Sensor Values.
 All these data is received from other modules over CAN and transmitted to the Android Application.The implementation of this algorithm is depicted in the flowchart.
 </td>
@@ Line 908: / Line 1,034: @@
 </td>
 <td  valign = top>
-[[ File:CMPE243 F17 Viserion BT Module- APP Init.png|thumb|200px|right|Flowchart for Data Processing and Transmitting in BT Module]]
+[[ File:CMPE243 F17 Viserion BT Module- APP Init.png|thumb|200px|right|Flowchart for recieveing and transmitting co-ordinates in Android APP]]
 </td>
 </tr>
@@ Line 1,257: / Line 1,383: @@
-[[File:CMPE243 F17 Viserion GPS GNGGA Message.png|500px|thumb|center|Only GNGGA messages being received]]
+[[File:CMPE243 F17 Viserion GPS GNGGA Message.png|500px|thumb|center|Only GNGGA messages being received]]<br>
+== Major issues ==
+=== Issue #1: GEO Issues ===
+. Compass offset error correction: While mounting the compass on the actual system, it was seen that the heading was drifted with respect to north. To fix this issue we had implemented a button functionality which would start the offset calculation on press of switch 1 based on its alignment with the true north and then would increment the offset by +5 degrees on switch 2 press and -1 degrees on switch 3 press and end the offset calculation on switch 4 press.<br>
+. Geo offset fix: While testing we noticed that there was GPS coordinates drift between the checkpoint coordinates obtained from the Google maps and the current coordinates obtained from the GPS module mounted on the car. We fixed this by adding an offset and by increasing the number of checkpoints.<br>
-== Testing & Technical Challenges ==
+=== Issue #2: Motor issues ===
-Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
-Make a smooth transition to testing section and described what it took to test your project.
-Include sub-sections that list out a problem and solution, such as:
+Oscilloscope was connected parallel to the input of the ESC and the PWM values were recorded.When the same PWM values were given to the ESC, the for initialization was not happening.We saw that, irrespective of the input frequency the output frequency is always constant.So we changed the duty cycle according the output of the controller to fix this.
-=== <Bug/issue name> ===
+=== Issue #3: Android App issues ===
-Discuss the issue and resolution.
+. Establishing a stable connection with the car is crucial as this is the only means of controlling and monitoring the car. As the Bluetooth range is low, the connection used to end as the car started moving and re-connection was necessary to abort the car when required. This was overcome by implementing an automatic connection between android app and CAR. Every time the CAR was in the range of App it was re-connecting automatically.
+. There had to be a mechanism to assure that the sent checkpoints were correctly received by the GEO module without any loss. Hence, we devised an initial handshake state machine logic which would ensure that the start signal from master comes only after proper reception of the checkpoint coordinates.
 == 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?
+With immense sense of satisfaction, we would like to mention that we are fortunate for having taken this course which led us through challenges, helped us boost our technical and managerial skills and built confidence in us. Segregating work into modules and further splitting them into smaller tasks with estimated deadlines, kept us focused throughout and helped us achieve our target
+We definitely got a chance to learn from a diverse set of experienced people within the group. Some of us were good at hardware, some at algorithms and some in app development etc. However, each of us strived to learn from every other module. The theoretical concepts that we acquired from the lectures helped us apply them practically on the car. We got hands on experience on GIT and unit testing which is an icing on the cake. Interacting with other team members helped us resolve similar issues quicker. We also progressed in our documentation skills.
+Talking about the problems, persistent testing of our design and brainstorming with other team members helped us find hidden problems such as car drifting because of inaccurate Google assigned coordinate, issues in obstacle detection due to delay in the response, calibration of the magnetic compass getting worse every time the environment is changed, motor speed control issues etc. We were able to fix all these issues on time. Various techniques were tried and finally the best of all approach was implemented.
+Finally, we would like to acknowledge the contribution of each and every team member, the knowledge sharing sessions we had and the patience within the team to successfully achieve this target.
 === Project Video ===
-*[https://youtu.be/gmF8OyNH2Ro RC Car Navigation]
+*[https://m.youtube.com/watch?feature=youtu.be&v=xdiPTM7UUTkRC Car Navigation]
 === Project Source Code ===
-*  [https://gitlab.com/aakashmenon/Viserion.git Viserion Team GitLab Source Code]
+*  [https://gitlab.com/aakashmenon/Viserion.git Viserion Team GitLab Source Code]<br>
 == References ==
@@ Line 1,288: / Line 1,426: @@
 [5] [http://ww1.microchip.com/downloads/en/DeviceDoc/20001667G.pdf CAN Transceiver: MCP2551]<br>
 [6] [https://www.u-blox.com/sites/default/files/NEO-M8_DataSheet_%28UBX-13003366%29.pdf GPS datasheet]<br>
-=== Appendix ===
-You can list the references you used.

Difference between revisions of "F17: Viserion"

Latest revision as of 08:28, 23 December 2017

Contents

Viserion Team RC Car

Abstract

Objectives & Introduction

Objectives

System Block Diagram

Team Members & Responsibilities

Schedule

Viserion DBC File

Parts List & Cost

Process Control

Progress Tracking

Unit Testing

Code review

PCB Design

Sensors Controller

Hardware Design

3D Printing Design

Hardware Interface

Software Design and Implementation

Motor and I/O Controller

Design and Implementation

Hardware Design

Hardware Interface

DC Motor

ESC

Servo

RPM Sensor

IO module

Features

Software Design and Implementation

Steering and Drive Control

Consistent speed based on feedback

IO module

Testing & Technical Challenges

PWM Signal

Ramp

Master Controller

Hardware Design

Software Design

Main flow of Master controller

Obstacle Avoidance

Directions And Steering Signals

Implementation

Technical Challenges

Bluetooth Controller And Android Application

Design And Implementation

Hardware Design

Bluetooth And SJOne Board Connection Diagram

Bluetooth Module

Hardware Interface

Software Design

Bluetooth Module

Android Application

Implementation

Technical Challenges

Geographical Controller

Design And Implementation

Hardware Design

Software Design

Components

Compass Module

Compass Calibration

GPS Module

GPS Calibration

Implementation

Algorithm

Bearing angle calculation

Decision making

Testing

Performance Analysis of Compass

Technical Challenges

Soft Iron Effect for Compass

GPS Challenges

Major issues

Issue #1: GEO Issues

Issue #2: Motor issues

Issue #3: Android App issues