F16: Titans

Titans

Titans - Autonomous Navigating Car

Abstract

This section should be a couple lines to describe what your project does.

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Track Progress in KanBan

• Titans Kanban Board

Team Members & Responsibilities

• Master Controller
  • Haroldo Filho
  • Urvashi Agrawal
• Motor Controller & I/O Module
  • Sant Prakash Soy
  • Saketh Sai Narayana
  • Kayalvizhi Rajagopal (LCD)
• GPS/Compass Module
  • Yang Thao (GPS)
  • Daamanmeet Paul (Compass)
• Sensors
  • Kayalvizhi Rajagopal
• Communication Bridge/Android App
  • Parth Pachchigar
  • Purvil Kamdar

Project Schedule

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

Week#	Start Date	End Date	Task	Status
1	09/13/2016	09/20/2016	Order Components and work distribution. Research on the type and model of sensors to use and order them. Research on components requirement based on past projects. Order motor controller related components: Traxxas RPM sensor, (Servo motor, DC motor and ESC)Included in traxxas RC car. Reverse engineering Traxxas ESC, signal receiver, and signal transmitter to learn about basic functionality of the car. Android Development Environment Setup. Map API fundamental study.	Completed
2	09/21/2016	09/27/2016	Set up git and wiki page Study the data sheet of sensor & prepare a high level design. Interface the sonic sensor to the sensor controller. Experiment and Research on voltage requirements for Servo and DC motor. Experiment and Research on PWM frequency requirements for DC and Servo motor. Experiment and Research on duty cycle required for controlling steer and speed of the car. Bluetooth BLE related android programming study and BLE protocol study.	Completed
3	09/28/2016	10/04/2016	Receive Components and distribute to group members. Interface all the front sensors and test the readings with different environment conditions. Interface the SJ One Board to car's ESC(Electronic Speed Controller) and servo motor and test research results. Decide on the CAN ids and the priorities of the CAN messaged for various nodes. Basic Android Application development, Intent passing, Finalize GUI template.	Completed
4	10/05/2016	10/11/2016	Agree on control system architecture, assign CAN node priorities and decide on communication paradigm between Master and Nodes. Prep for prototype. Stress test the sensors and design a filter so that reliable readings are sent to the master. Experiment and research on precision control of speed and steering using signals from SJ One board. Developing the framework for the I/O display and setting up SPI framework to read the CAN messages. Design the barebones basic functionality of the algorithm. Create a skeleton code. Controlling Bluetooth of Mobile Phone(i.e. Turn on, Connect), Connect Mobile phone with Bluetooth BLE module on SJOne.	Completed
5	10/12/2016	10/17/2016	Testing week for all nodes. Goal is for each node to have a basic interface to their sensors and actuators in place, where they are able to read data and manipulate control signals. For instance: sensors node should be reading distance, motors node should be able to generate motor speed control signals. Modify the necessary parts in the CAN.dbc file. Interface back sensor and test all the sensors together. Debug and fix any issues. Design software filter to filter CAN messages required for motor controller. Get readings from the RPM sensor. Read the CAN messages to display on the LCD connected to the SJ One board. Set up CAN communication between the sensor,motor and the master. Test for correct data transmission. Establishing basic communication between Android phone and SJOne Board.	Completed
6	10/18/2016	10/24/2016	Interface all nodes over Can bus and coordinate order and status message transfers between Master and Nodes. PCAN interface should be built to view & test CAN messages via Busmaster. Integrate sensors with other nodes via CAN and test the sensor values while the car is on the move. The master should have reliable data from sensors by now. Send signals to the motor controller from another CAN Node to control speed and steering using CAN interface. Creating necessary display messages and graphics related to the I/O modules. Design the algorithm to process the data received from the sensors and motors by the master. Integrate Google Map, Get Longitude and Latitude data from the position where Marker is placed, Get important data of other nodes from CAN bus.	Completed
7	10/25/2016	10/31/2016	Integrate all hardware to the RC car, including power supplies from batteries. Test self powered prototype with the goal of controlling forward, reverse, left and right with start/stop command from the phone app. Test & fix basic integration bugs. Integrating and testing motor & I/O controller with other nodes. Extend the algorithm to control the motors along with the obstacle information received from the sensors. Integrate bridge controller with other modules via CAN. Test & fix basic integration bugs.	Completed
8	11/1/2016	11/7/2016	Continue with hardware/software development & integration and complete first prototype of the collision avoidance feature. Design sensor mounts and 3D print them. Test and fine tune the algorithm developed so far for the first demo. Put multiple markers on Map and implement logic to find shortest route to destination and pass route information on CAN bus.	Completed
9	11/8/2016	11/14/2016	Integrate GPS coordinates from Android app into Master Node for autonomous feature. Mount the sensors and test for any dead band. Position them for maximum coverage. Obtain the data from the GPS and process the data to design the algorithm for navigation. Design and implement the kill switch to avoid the car from crashing. Integrate GPS coordinates from Android app into Master Node for autonomous feature. Testing and Bug fixing.	Completed
10	11/15/2016	11/21/2016	Integrate all nodes into one. Start testing car's autonomous driving capabilities with path following from GPS waypoints from Android app. Tune & optimize the sensor filter logic and the sensor mount as required. Integrate all the modules and test for the functionality. Save the data received from various modules into a log file for debugging purpose.	In Progress
11	11/22/2016	11/28/2016	Autonomous driving should be working by now. Focus on improving car's performance. Tweak all nodes to better performance, and fix last minutes bugs. Interface Head lights and turn them ON based on light sensor value. Include the headlights and the LCD on the car and display messages on them.	Not Started
12	11/22/2016	11/28/2016	Stress test the car with different environment scenarios. Improvise the algorithm and carry out stress testing and integration testing. Work on the modifications required and test previous hardware additions to the car.	Not Started
13	11/29/2016	Presentation date	Final touches to improve overall vehicle's robustness. Self-fixing nodes, reduce/eliminate unexpected behaviors and crashes. Integration and testing. Work to improvise on the algorithms and make sure individual modules work. Addition of any extra features and software development.	Not Started

Parts List & Cost

Item#	Part Desciption	Vendor	Qty	Cost
1	RC Car - Traxxas 1/10 Slash 2WD	Amazon	1	$189.95
2	Traxxas 2872X 5000mAh 11.1V 3S 25C LiPo Battery	Amazon	1	$56.99
3	Traxxas 7600mAh 7.4V 2-Cell 25C LiPo Battery	Amazon	1	$70.99
4	Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger	Amazon	1	$35.99
5	Bluetooth 4.0 BLE Bee Module (Dual Mode)	Robotshop	1	$19.50
6	4D systems 32u LCD	4D systems	1	$41.55
7	LV Maxsonar EZ0 Ultrasonic sensors	Robotshop	5	$124.75
8	Devantech SF05 Ultrasonic sensor	Provided by Preet	1	Free
9	Venus GPS with SMA connector	Amazon	1	$49.95
10	SMA Male Plug GPS Active Antenna	Amazon	1	$9.45
11	Wire wrapping board	Radio shack	1	$20.0
12	CAN tranceivers	Digikey	10	$10.0
13	SJOne Boards	Provided by Preet	5	$400.0

DBC File Implementation

• The following is the DBC file of the project.

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

BS_:

BU_: DBG MASTER GPS MOTOR SENSOR APP

BO_ 1 APP_START_STOP: 8 APP
 SG_ APP_START_STOP_cmd : 0|1@1+ (1,0) [0|0] "COMMAND" MASTER
 SG_ APP_ROUTE_latitude : 1|28@1+ (0.000001,-90.000000) [-90|90] "" MASTER
 SG_ APP_ROUTE_longitude : 29|29@1+ (0.000001,-180.000000) [-180|180] "" MASTER
 SG_ APP_FINAL_COORDINATE : 58|1@1+ (1,0) [0|0] "" MASTER
 SG_ APP_COORDINATE_READY : 59|1@1+ (1,0) [0|0] "" MASTER

BO_ 80 APP_ROUTE_DATA: 8 APP
 SG_ APP_READOUT_latitude : 0|28@1+ (0.000001,-90.000000) [-90|90] "" MASTER
 SG_ APP_READOUT_longitude : 28|29@1+ (0.000001,-180.000000) [-180|180] "" MASTER

BO_ 16 SENSOR_DATA: 3 SENSOR 
 SG_ SENSOR_left_sensor : 0|8@1+ (1,0) [0|0] "Inches" MASTER,APP,MOTOR
 SG_ SENSOR_middle_sensor : 8|8@1+ (1,0) [0|0] "Inches" MASTER,APP,MOTOR
 SG_ SENSOR_right_sensor : 16|8@1+ (1,0) [0|0] "Inches" MASTER,APP,MOTOR

BO_ 32 MASTER_HB: 8 MASTER 
 SG_ MASTER_SPEED_cmd : 0|3@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS,APP
 SG_ MASTER_STEER_cmd : 3|3@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS,APP
 SG_ MASTER_LAT_cmd : 6|28@1+ (0.000001,-90.000000) [-90|90] "" SENSOR,MOTOR,GPS,APP
 SG_ MASTER_LONG_cmd : 34|29@1+ (0.000001,-180.000000) [-180|180] "" SENSOR,MOTOR,GPS,APP
 SG_ MASTER_START_COORD : 63|1@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS,APP

BO_ 65 GPS_Data: 8 GPS
 SG_ GPS_READOUT_valid_bit : 0|1@1+ (1,0) [0|1] "" MASTER,MOTOR,APP
 SG_ GPS_READOUT_read_counter : 1|6@1+ (1,0) [0|60] "" MASTER,MOTOR,APP
 SG_ GPS_READOUT_latitude : 7|28@1+ (0.000001,-90.000000) [-90|90] "" MASTER,MOTOR,APP
 SG_ GPS_READOUT_longitude : 35|29@1+ (0.000001,-180.000000) [-180|180] "" MASTER,MOTOR,APP

BO_ 66 COMPASS_Data: 2 GPS
 SG_ COMPASS_Heading : 0|9@1+ (1,0) [0|0] "DEGREE" MASTER,APP,MOTOR 

BO_ 67 GEO_Header: 3 GPS
 SG_ GPS_ANGLE_degree : 0|12@1+ (0.1,-180) [-180.0|180.0] "Degree" MASTER,MOTOR,APP
 SG_ GPS_DISTANCE_meter : 12|12@1+ (0.1,0) [0.0|400.0] "Meters" MASTER,MOTOR,APP

BO_ 48 MOTOR_STATUS: 2 MOTOR
 SG_ MOTOR_STATUS_speed_mph : 0|16@1+ (0.001,0) [0|0] "mph" MASTER,APP

CM_ BU_ MASTER "The master controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BU_ APP "The communication bridge controller of car";
CM_ BU_ GPS "GPS and compass controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";

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

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

BA_ "GenMsgCycleTime" BO_ 32 100;
BA_ "GenMsgCycleTime" BO_ 16 100;
BA_ "GenMsgCycleTime" BO_ 48 100;
BA_ "GenMsgCycleTime" BO_ 65 100;
BA_ "GenMsgCycleTime" BO_ 66 100;

Sensor Controller

Design & Implementation

The main purpose of the sensor controller is Obstacle avoidance and one of the straight forward way to achieve the goal is to use an Ultrasonic sensor.

Sensor controller being the “eye” of the project, lot of thoughts were put into deciding the right sensor to serve the purpose of obstacle avoidance. Considering the factors of reliability and cost, Maxbotix EZ0 ultrasonic sensor is chosen to be left and right sensors. EZ ‘0’ model is selected because it has the widest beam coverage of all the Maxbotix EZ series sensor models. Devantech SF05 ultrasonic sensor is selected for the middle sensor. A different model is used for middle sensor because of its different frequency, which avoids interference between sensors.

The sensors are mounted and tested at different angles so that the front three sensors cover a wide area, without leaving any dead or uncovered region.

Hardware Design

The sensors are interfaced using Port 2 GPIO pins of the microcontroller. The sensors require 5V power supply, which was provided from the main board’s supply. The trigger input to the sensors and the PWM output are interfaced to the GPIO pins as shown below in table. The pins for each sensor are chosen in such a way that it would not tangle each other while physically connecting them on the main board. CAN 1 of the SJOne board is connected to the CAN bus of the car which is also shown in the table below.

Sensor Pin layout

Pin Name	Function
P2_0	Trigger for left sensor
P2_1	Echo for left sensor
P2_2	Trigger for middle sensor
P2_3	Echo for middle sensor
P2_4	Trigger for right sensor
P2_5	Echo for right sensor
P0_1	CAN Tx
P0_2	CAN Rx

3D Printing Design

Sensors are required to be placed at a minimum height of 18 cm from the ground and at a tilt of 5 degrees to avoid ground reflections. A proper mount is required to place them at adjustable angles and heights. Hence the mounts are 3D printed using the below 3D deigns. The heights are adjustable by adding mode standoffs and the angle is adjustable by using the bottom screws.

3D Design for Middle Sensor mount

3D Design for Middle Sensor mount

Hardware Interface

The sensors are interfaced using GPIO pins. CAN 1 of the sensor controller is interfaced to the CAN bus of the car. Below diagram shows the hardware interface between the micro controller, sensors and the CAN bus.

Sensors pin connections

Devantech(middle) sensor pinout

Maxbotix EZ0 sensor pinout

Software Design

Software is designed such that the no two sensors of same type/model close by will be triggered simultaneously, so as to avoid interference with each other. Since the left and right sensor are of the same model, they are triggered sequentially, every 50 ms. The Maxbotix sensors cannot be triggered faster than 49 ms because it takes the sensors a maximum of 49 ms to pull down the PWN pin low when there is no obstacle for 6 meters or 254 inches. If triggered sooner, the reflected waves from the sensor will interfere with the next sensor, giving unpredictable values. The middle sensor and the back sensor are triggered every 50 ms. Hence we get all 4 sensor readings in 100 ms. The triggering of sensors is handled in 1 ms task, but with the check to trigger only every 50 ms. Refer the below datasheets for timing information for triggering and detailed working of both sensor models.

Maxbotix EZ0: http://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf
Devantech SF05:https://www.robot-electronics.co.uk/htm/srf05tech.htm

Sensor triggering sequence

Implementation

Algorithm

1. Initialize the trigger pins as output and PWM pins as input
2. Configure the PWM pins for falling edge interrupt
3. Trigger left and middle and back sensor and start the timer for all three
4. Wait for echo from all of them
5. When echo is received, calculate the distance in inches using the below formula

                   Distance = (stop time – start time)/147

6. Trigger right and middle sensor and start the timer for both & repeat from step 4
7. Broadcast the sensor values on CAN bus

Below is the sample interrupt callback function(ISR) to calculate the distance of obstacle.

Sensor ISR Code Snippet

The flowcharts shown describes in detail on how each sensor is triggered and broadcasted over CAN every 100 ms.

Left Right sensor trigger flowchart

Middle sensor trigger flowchart

Back sensor trigger flowchart

CAN message broadcast in 100 ms task

Testing & Technical Challenges

Motor & I/O Controller

Motor and I/O controller is one of the five controller in the autonomous car. It is responsible for car's steering, movement, input commands and to display critical information regarding the car. The controller is connected to different hardware modules that take care of the mentioned features. These modules comprise of servo motor which is used for steering, electronic speed controller for controlling the DC motor which in turn controls the movements of the car and a touch-screen LCD display for data input and to display critical information. These modules are explained in further detail in hardware interface section of the Motor & I/O Controller below.

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

The motor and I/O controller hardware design consists of SJOne microcontroller board connected to servo motor, electronics speed control, LCD module and LED lights. Servo motor and electronics speed control are connected to the microcontroller using PWM signal. The touch screen LCD is connected to the microcontroller board using UART interface. The LED lights are connected to the board using GPIO interface. The electronic speed controller is powered using the 6v power supply from the car battery pack. The servo motor for steering control is power on using 5V from the power bank. The touch screen LCD module is also powered on using the 5V using the power bank.

Block Diagram of Motor/IO Controller and Connected Modules

Hardware Interface

Electronic Speed Controller (ESC)

ESC: Waterproof XL-5 ESC with low-voltage detection (#TRA3018)

The Electronic Speed Controller is a component used for feeding PWM signal to a DC motor to control the speed at which it rotates. In addition to the speed it also controls the direction in which the motor rotates. These features help the car move forward and reverse and do these in different speeds. From the diagram below you can see the ESC has three color coded wires that are used for PWM signal(WHITE Color), VCC(RED Color) and GND(BLACK Color). These three color coded wires connect to the SJOne micro-controller board and power bank used in the car. There are also two wires coded red and black that have wire adapter at the end connect to the battery pack. The other two red and black wire connect directly to the DC Motor. The ESC also has a EZ Set button to switch between different speed modes, calibrate the speed and steering, and most important of all switch on the ESC itself. Please refer to the documentation provided by TRAXXAS for using the ESC.

• Switch Between Speed Modes (Training/Race/Sport)
• Calibrate Speed and Steering

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	PWM Signal From SJOne	WHITE
6.	NC	NC	RED
7.	(-)ve	Negetive terminal	BLACK

DC Motor

DC Motor: Titan® 12T 550 (12-turn) (#TRA3785)

The DC motor is the primary component that controls the rotation of the car wheel. Based on the direction of the current flow to the motor it rotates the wheel in forward or backward direction. Also, based on the amount of current flow to the motor, it controls the speed at which the wheels rotate. In the figure below you can see the DC motor has to two wire, red and black for (+)ve and (-)ve connection respectively. For forward movement of the wheels the current flows from (+)ve to (-)ve. For reverse movement the current flows from (-)ve and (+)ve. For controlling the speed of the wheel the motor is fed with different amount of current from the ESC, which is controlled based on the duty cycle fed to ESC.

DC Motor Pin Connection

S.No	Wires on (ESC)	Description	Wire Color Code
1.	(+)ve	Positive Terminal	RED
2.	(-)ve	Negetive terminal	BLACK

Servo Motor

SERVO MOTOR: Traxxas Waterproof Digital Ball Bearing Servo (#TRA2075)

The servo motor is the component responsible for the steering of the car. The servo motor is controller directly from the SJOne micro-controller board. It has three color coded wire white, red and black which are used for PWM signal, 5 Volts and GND respectively. Based on the duty cycle of the signal sent to the servo, it rotates in left/right direction.

Servo Motor Pin Connection

S.No	Pin No. (SJOne Board)	Function	Wire Color Code
1.	P2.4	PWM Signal	WHITE
2.	VCC	5 Volts	RED
3.	GND	0 volts	BLACK

Speed Sensor

The speed sensor is one of the hardware component used in the autonomous car for sensing the speed of the car and feeding the information to SJOne microcontroller. The sensor is installed in the gear compartment of the Traxxas car along with the magnet trigger. When the magnet attached to the spur gear rotates along with the gear it passes the hall-effect RPM sensor after every revolution. As soon as the magnet comes in front of the sensor the sensor sends a pulse on the signal line which is color coded as white. The other color coded wires red and black are used for VCC and GND to power the sensor. The sensor is powered using the 5 volts power supply from the power bank.

Speed Sensor Pin Connection

S.No	Pin No. (SJOne Board)	Function	Wire Color Code
1.	P2.4	PWM Signal	WHITE
2.	VCC	5 Volts	RED
3.	GND	0 volts	BLACK

RPM TRIGGER MAGNET: Traxxas Trigger Magnet Holders/Spur Gear (#TRA6538)

RPM SENSOR: Traxxas Sensor RPM Short 3x4mm BCS (#TRA6522)

IO module

IO module consists of touch LCD for displaying critical information, head lights, brake lights and running lights. The LCD is interfaced to UART3 of the micro controller. The lights are interfaced via the GPIO pins. The below figure shows how data from different nodes get to the LCD via CAN bus. It also shows how configurations done via LCD touch screen get to all other nodes via CAN bus.

LCD data flow

Software Design

Motor Controller

Software design for the motor controller consist of different software modules that control speed, steering, inputs and outputs interface using touch screen LCD, and sensing the speed of the car. Controlling speed, steering and sensing speed is done using 10Hz periodic loop. On the other hand the code for LCD input and output run as a task that get scheduled in between the 10Hz periodic scheduler.

The second phase of the motor controlling is maintaining a constant speed i,e., to find out the speed at which it is running and control the car based on the speed at which it is traveling. This comes in handy when the car has a destination that goes uphill. This operation can be called as speed controlling. This operation is done with the help of a speed sensor that can be fixed either on to the wheel or on to the transmission box of the car.

DC Motor and Servo Motor

Software design for the speed control and steering control is done using 10Hz periodic loop. The periodic loop consists of two switch cases, one switch case for speed control and another one for steering control. For speed control, switch cases are for stop, 'slow' speed, 'medium' speed, 'fast' speed, and reverse. For steering control, the switch cases are for the positions of the wheel that are 'hard' left, 'slight' left, center, 'slight' right and 'hard' right.

Steering Position Code

IO module

Since motor's functional information is critical, the LCD uses UART as a communication medium to transmit messages. The LCD and lights working in the software is designed as low priority tasks running at 500 ms. Even though UART takes a long time to process, it will not clog the periodic tasks.

The LCD is interfaced early in the project since it aids in debugging while the car is on the move. Critical information such as sensor readings, motor speed, compass direction, GPS coordinates, the degree to turn and distance to the destination are displayed on the LCD. The below screens show the information displayed on the LCD.
There is also a Settings menu through which the motor speed and sensor thresholds can be configured without having to re-build and re-flash the software.

Implementation

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

IO module algorithm

The critical data is received from different nodes via CAN and packed into packets and sent to the LCD via UART. The LCD used requires a specific format of data from the micro controller for it to display the data.Refer the below datasheet for information on the packet format for 4D systems uLCD-32PTU.
Datasheet: http://www.4dsystems.com.au/productpages/uLCD-32PTU/downloads/uLCD-32PTU_datasheet_R_2_0.pdf
User manual: http://www.4dsystems.com.au/productpages/PICASO/downloads/PICASO_serialcmdmanual_R_1_20.pdf

The below flowchart explains how the tasks work in order to transmit and receive data from the LCD.

LCD Rx task

LCD Tx task

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Geographical Controller

Design & Implementation

Geo Node's sole purpose is to provide the heading error angle and distance to checkpoint/destination to the Master Node. To be able to achieve this, the Geo Node requires gathering of current GEO data and computing them to come up with what Master Node needs. The two required GEO data are current GPS coordinates and compass heading angle. Once these are gathered, Geo Node has to calculate the bearing angle which is the angle between two locations in respect to north. Using both bearing and compass heading angles, the heading error angle can be calculated. For calculating the distance, it requires two GPS coordinates and a little bit of math.

Bearing Angle Calculation

The idea to calculate bearing angle is very basic and fundamental. Since we will be using an RC car and running it on the ground, we'll only be dealing with latitude and longitude coordinates. In another word, positioning can be calculated on a 2D plane using X & Y coordinates, longitude and latitude coordinates respectively. Yes, the earth is not flat, but spherical and that must be accounted for when making calculations but since we making calculations on such a minute scale and short distance, in the tens of meters only, spherical impact can be negated. Imperfection on the pavement would probably make more impact than the earth's spherical shape at this scale. With all that being said, our method to calculate the bearing angle is shown in the image below.

Geo Bearing Calculation Diagram

To calculate the bearing angle, two GPS coordinates are required. One being the current GPS coordinates and the other is the checkpoint location provided by Master Node. Since we want to calculate the bearing angle in respect to north, we project a 3rd point to north using the current GPS coordinates. Now that we have three coordinates, we can calculate vector A (Current location to Checkpoint location) and vector B (Current location to Projection location). Once we calculated both vectors, we use the following equation to calculate the bearing angle:

Angle between two vectors:

    cos α = (vector_A * vector_B) / (│vector_A│ * │vector_B│), where α is the bearing angle

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

    Heading Error = α - ß
  

The heading error will dictate whether the car need to keep left or keep right to reach the checkpoint. For our implementation, whenever the heading error is positive, the cars needs to keep right and whenever heading error is negative, it keeps right.

It is important to normalize both bearing angle and compass angle prior to calculating the heading error. Both bearing and compass angles had to be mapped to have their values range from -180° to 180° as shown in the images below.

Bearing Angle Map

Compass Angle Map

Computation Result

Distance Calculation

To calculate the distance between any two GPS coordinate on a 2D plane, the first step is to calculate the magnitude of both points. The magnitude will yield the distance between both points in decimal degree. Also, since the coordinates are measured in decimal degrees having a precision point of up to 6 decimal points, e.g. 37.123456, we have to first know how long in meters does 0.000001 decimal degree equates to. Also, since the earth is spherical, the ratio of 0.0000001 decimal degree to meters will change depending on where you are on the latitude axis. For example, on the equator where latitude is 0.0 decimal degree, the ratio of meters to 0.000001 decimal degree to will be the highest at 111.32mm compared to 78.71mm at latitude 45.0 decimal degree.

Referencing Wikipedia table below, we get a couple reference points of how long 0.000001 decimal degree equates to in millimeters.

https://en.wikipedia.org/wiki/Decimal_degrees

Using these reference points we can plot them and generate a polynomial equation to calculate the ratio between 0.000001 decimal degrees to meter (or millimeter per the chart). We get the following chart and equation from it:

Milimeters per 0.000001 Decimal Degree at differ Latitude

In the program, it would be written as:

    #define meterPerDecimalDegree(latitude) ((0.00005*pow(latitude,3) - 0.01912*pow(latitude,2) + 0.02642*latitude + 111.32)*0.001), plotting in the current latitude would yield Meter per 0.000001 decimal degrees

After implementing both these bearing and distance calculation into our project, they proved to be accurate computation in guiding our autonomous car to its destination. Of course although implementing our own Geo calculation method was fun and exciting to see it work in real time application, it is worth mentioning that there are plenty of other methods of Geo computation out there. A popular and quick method would be the Haversine formula. Google has plenty of resources about it.

Hardware Design

• Below figure represents the block diagram of Geo Controller. Geo-controller consist of GPS module and IMU module. GPS module is responsible for providing the GPS coordinates and IMU module is responsible for providing Current compass heading with respect to north. IMU and GPS module is interfaced to the SJSU One board via Uart3 and Uart2 respectively.

H/W Interface of GeoController

• Below table shows the Pins connection of IMU module with SJ One Board. Module is interfaced with SJSU One Controller via UART3 interface. The operating volatge of IMU module is 3.3v.

S.R.	IMU Module Pins	SJOne Board Pins
1	Vin	3.3v
2	GND	GND
3	TX	P4.29 (RXD3)
4	RX	P4.28 (TXD3)

• Below table shows the Pins connection of GPS module with SJ One Board. Module is interfaced with SJSU One Controller via UART2 interface. The operating volatge of GPS module is 3.3v.

S.R.	GPS Module Pins	SJOne Board Pins
1	Vin	3.3v
2	GND	GND
3	TX	P2.9 (RXD2)
4	RX	P2.8 (TXD2)

Hardware Interface

GPS Module

GPS Module: Readytosky Ublox NEO-M8N GPS Module

This GPS module uses UART serial communication interface. The refresh rate ranges from 1Hz up to 18Hz with a default baud rate of 9600bps. To achieve the desired refresh rate of 10Hz for our design, the baud rate had to be increased to 115200bps to accommodate for the demanded bandwidth from 10Hz refresh rate.

Specifications & Documentation: www.u-blox.com

GPS Connector Definition:

• GND,
• TX,data output
• RX,data intput
• VCC,2.7V-3.6V

Why choose u-blox GPS module?

There are several reasons to select this GPS module oppose to other types such as Sparkfun's popular Venus GPS. First, is the price. The u-blox GPS module can be purchased off amazon for about $35 with integrated antenna compared to the Venus for $50 with an additional ~$10-15 for the required external antenna. This brings up the next point and that has to do with the external antenna. Since the antenna's coaxial cable can range between 10 to 15 feet, it becomes a hassle trying to tuck it away on once GPS module is mounted on the RC car. Second point is the accuracy. The u-blox's data sheet claims have an accuracy of about 2 meters (Amazon.com seller claims 0.6 to 0.9 meter) compared to 2.5 meters on the Venus. Although these different GPS modules uses their own software to configure its settings, they all are identically configurable. This means it is a no-brainer to go for the u-blox GPS module.

Module Calibration

Setting up u-blox GPS module:

To be able to use u-blox center software to configure the GPS module, either u-blox's developer kit can be purchased or a cheaper alternative choice would be to purchase a FTDI USB to Serial adapter module for about $5 from any convenient online retailer. The u-blox software can be downloaded free from u-blox's website. Once connection is establish between the GPS module and computer, the software provides great number of configurations to change and also a wide GPS map tools to play with. Despite all the fun features the software provides, there are a few important settings that needed to be changed to fit our design.

On default, the refresh rate is set at 1000ms, or 1Hz. This had to be changed to 100ms to be able to get a refresh rate of 10Hz. Next, for the best accuracy possible from this GPS, Navigation Mode needs to be changed to "Pedestrian". This settings ensure best accuracy below speed of 30 meters/second which our RC car is well under. Lastly, since we are only interested in GPRMC messages from our GPS module, u-blox software provided option to turn off all messages except for GPRMC. This helps tremendously when trying to capture reliable messages.

The Readytosky GPS module has a soldered-on little super capacitor that charges up once power is provided and then acts as a battery once power is removed. Although this super capacitor helps by providing power to the memory to keep GSP configuration settings saved as well as provide a warm or hot start (faster to acquire accurate GPS data), it was only able to power for a few hours after power is removed. Although the datasheet says the memory is flash, it kept resetting back to default once battery power is gone. This meant configuration settings had to be redone often. To remedy this problem, the super capacitor had to be removed and in its place, a 3.3V coin battery soldered on.

Interfacing with SJ-One Board:

Interfacing this GPS module to the SJ-One board was straight forward. Since the communication type is UART, TX from GPS is tied to RXD2 pin on SJ-One and RX from GPS is tied to TXD2 pin utilizing UART2 port. Since the refresh rate was configured to 10hz, the default 9600 baud rate was not sufficient enough. Baud rate on both GPS module and SJ-One board both had to be changed to 115200 baud rate. Although baud could have lower and worked just fine, 115200 posed no issue so it was ideally better to get the message sooner and have a longer time in between the next message to avoid cascading messages in the UART read buffer.

**See Hardware Design for wire diagram.**

Razor IMU - 9 Degrees of Freedom

IMU Module

In Geographical node, IMU module is used to obtain the compass heading with respect to north. The compass heading is used in conjunction with Bearing angle provided by the GPS module to calculate Error angle. Error angle is used to steer car in the direction of the destination coordinate.

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

Features:

• 9 Degrees of Freedom on a single, flat board:
  • ITG-3200 - triple-axis digital-output gyroscope
  • ADXL345 - 13-bit resolution, ±16g, triple-axis accelerometer
  • HMC5883L - triple-axis, digital magnetometer
• Autorun feature and help menu integrated into the example firmware
• Output pins match up with FTDI Basic Breakout
• 3.5-16VDC input
• ON-OFF control switch and reset switch

• 9 Degrees of Freedom - Razor IMU

Module Calibration

IMU using on board Arduino Controller for processing data coming from the accelerometer, Magnetometer and Gyroscope. We are using Arduino firmware for IMU calibration. Arduino firmware is flashed with the help of the FTDI connector.

FTDI connector

• FTDI pin connection with IMU module

S.R.	FTDI connector	Razor
1	GND	GND
2	CTS	CTS
3	3.3v	3.3v
4	TX	RX
5	RX	TX
6	DTR	DTR

• Razor IMU Calibration Tutorial

Extended Calibration

• Accelerometer calibration

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

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

• Gyroscope Calibration

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

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

• Magnetometer Calibration

Magnetometer calibration is done using processing software which gives the metrics for offset values, given below. It is also extended calibration which is done by the software. There are two type of calibration for magnetometer, one being the hard calibration and soft calibration being the other.

1. standard calibration: Calibrating the compass with the earth's magnetic field.

 magn x,y,z (min/max) = -564.00/656.00  -585.00/635.00  -550.00/564.00

2. Extended calibration: Calibration the compass with the surrounding magnetic fields.

The standard magnetometer calibration only compensates for hard iron errors, whereas the extended calibration compensates for hard and soft iron errors. Still, in both cases the source of distortion has to be fixed in the sensor coordinate system, i.e. moving and rotating with the sensor. Processing software is used to collect magnetic field samples, which is used to develop the magnetometer calibration values by itself. Magnetometer calibration equation generated by the processing.pde on the basis of the samples collected is given below.

 #define CALIBRATION__MAGN_USE_EXTENDED true
 const float magn_ellipsoid_center[3] = {260.000, -125.844, -113.709};
 const float magn_ellipsoid_transform[3][3] = {{0.604193, 0.0917934, -0.0122780}, {0.0917934, 0.884838, 0.0590891}, {-0.0122780, 0.0590891, 0.965924}};

Software Design

The approach to the software design was to try to write modular code. Utilizing OOP concepts, a few objects were created. At the very top, there is the Geo_Manager. The Geo_Manager's role is to call out to GPS_Module and Compass_Module objects to gather raw data and provide it back to the Manager. Next, it sends these raw geo data to the Geo_Calculation_Engine to perform all necessary calculations before sending the calculated data back to the Manager.

UML Diagram

Control Flow

Software control flow is very simple. The flow diagram below shows exactly how the code works. Best explanation without creating confusion is to follow the flow diagram:

Software Flow Design

Implementations

On-Board Debugging Tool Interface

To be able to provide accurate heading error to Master Node, it is very important before subtracting compass angle from bearing angle (see Design & Implementation section) that they both need to be normalize. Since bearing angle uses projection point to North, its angle calculation is in respect to North. The compass on the other hand was giving magnetic heading which is about 12 degrees off. Often, the compass will also drift some X amount so a "Compass Offset" of 12 degree + X drift amount would have to be added to compass heading angle to normalize it to North. This meant whenever the compass drifted, we would have to either recalibrate it or compensate the offset or most of the time do both which were all very time consuming.

To help drastically reduce time wasted recalibrating the compass offset, we utilized the I/O on SJ-One board to quickly adjust compass offset on the fly as well as display important information for us to monitor as the car was being tested.

Utilizing all four push buttons, all LEDs and the 7-segment display on Geo Node board, we implemented three different modes for the user to interface with the Geo Node. The implementation is shown below:

On-Board Debugging Tool Interface Design

Operation and Controls:

 @ Any Mode
   Input:  Button #4 - Cycles to the next mode.

 @ Mode 1
   Output: 7-Segment Display - Shows distance of current location to checkpoint in meters

 @ Mode 2
   Output: 7-Segment Display - Shows current heading angle error in degrees
   Input:  Button #1 - Decreases Compass Offset therefore affecting current Heading Angle Error
   Input:  Button #2 - Increases Compass offset therefore affecting current Heading Angle Error
   Input:  Button #3 - Zeros out the Heading Angle Error by applying needed Compass Offset Value

 @ Mode 3
   Output: 7-Segment Display - Shows current Compass Offset Value (This mode is better use to take note of the current Compass Offset Value)
   Input:  Button #1 - Decreases Compass Offset therefore affecting current heading angle error
   Input:  Button #2 - Increases Compass offset therefore affecting current heading angle error

Testing & Technical Challenges

GPS Module

Capturing NEMA Messages from GPS Module

One frustrating problem was trying to read GPS NEMA sentences from the GPS module. Since on default the module provides several types of NEMA messages, it was very difficult to try to capture the one you wanted. Increase the GPS module to 10Hz refresh rate and it becomes a mess. Attempting to filter and only accept the NEMA message type you need was very inconsistent. At times, due to the high refresh rate, many GPS refresh cycles would have gone by before being able to filter the correct NEMA message. Couple this with the fact that often the correctly captured NEMA message with either incomplete or mixed with another message regardless of trying to detect the new-line character. Playing with buffer sizes only helped so much.

The solution to this was to disable all unwanted NEMA messages and only have GPS module send out the 1 or 2 type of messages that are required. This meant filtering for current NEMA messages may not be necessary (we still filter just in case) and it also reduces the traffic allowing UART read buffer to capture from start to finish the full NEMA messages.

IMU Module

Communication Bridge Controller

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Here is the hardware block diagram of Communication Bridge Controller.

Hardware block diagram for Communication Bridge Module

Here is the hardware block diagram of Communication Bridge Controller. Here is the hardware block diagram of Communication Bridge Controller. Here is the hardware block diagram of Communication Bridge Controller.

Hardware Interface

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

Software Design

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

Implementation

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

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Master Controller

Design & Implementation

The master controller acts as the brain of the car and coordinates between the other 4 nodes to achieve smooth navigation of the car.

Hardware Design

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

Hardware Interface

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

Software Design

We will discuss the software design of the master in this section. The architecture of the master node is vast and hence we decided to make extensive use of classes and inheritance in C++.

Software Architecture

Structure The software is architectured in a layered fashion with two main layers: application layer and hardware control layer. There are two classes in the application layer (Coordinator and TrajectoryEngine). They are responsible for high level, application specific tasks. The Coordinator has a simple ‘use’ association with the TrajectoryEngine, and it associates via composition to a less abstract layer (Node Control) responsible for hardware specific activities.

Software Abstraction Architecture

The UML class association diagram for the Master Node software is shown below:

UML Class Diagram

As seen in the diagram, Node Control layer is composed of 4 classes, while the application layer is composed of 2 classes.

Components

Application Layer CRC

Class: Coordinator Responsibility: The coordinator orchestrates periodic status requests and order generation to drive the car. It gathers status from all nodes, process the information and then uses it as an input to the trajectory engine as to generate the next order.
Collaboration: The coordinator uses facilities in SensorControl to update sensor states according to the sensor readings from the CAN bus. It uses GeoControl to store and sequence GPS coordinates, as well as to update heading error bases on compass readings coming in from the CAN bus. It uses the TrajectoryEngine to generate the next motor speed and steering order bases on outputs from Sensor and Geo Control.
Class: TrajectoryEngine Responsibility: To decide where to turn next and how fast to drive based on current state of sensors and heading error.
Collaboration: It returns the current motor order (steering and speed) to the Coordinator

Node Control Layer CRC

Class: SensorControl Responsibility: To transform raw sensor numerical readings into meaningful sensor states.
Collaboration:It gets raw readings from Coordinator and returns it the sensor states.
Class: GeoControl Responsibility:To store and sequence through the vector of trajectory coordinates as well as to turn raw numeric heading readings into meaningful steering states.
Collaboration:It gets raw readings from Coordinator and returns it the steering states. It also gets the coordinate inputs and sequence requests from Coordinator and returns it the current appropriate coordinate vector element.

Behavior

The Heartbeat The system works with a periodic 10Hz heartbeat. At every period, the Master node sends out an order in the CAN buss, and it receives a status from each node. The nodes only put messages on the buss upon reception of the heartbeat from the Master node.

Implementation

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

Testing & Technical Challenges

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.

My Issue #1

Discuss the issue and resolution.

Conclusion

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

Project Video

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

Project Source Code

• GitLab Source Code Link

References

Acknowledgement

We, Team Titans, would like to thank Preet for the class of Industrial Applications using CAN bus as CMPE 243 at SJSU. It helped in with the implementation and testing of our project self-navigating car. We also want to thank our Student Assistants for their guidance during the project their feedback helped us get through some obstacles. This project helped us get the knowledge of CAN bus and also helped us practice the skills we have. This course and the project will be a major benefit in our career.

References Used

[1] CMPE 243 Lecture notes from Preetpal Kang, Computer Engineering, San Jose State University. Aug-Dec 2015.
[2] Fall_2014 and Fall_2015 Project Reports
[3] CAN Transceiver
[4] Razor IMU
[5] Google maps API
[6] Activity development