Latest revision as of 12:24, 20 January 2016

ThunderBird : Self Driving Car

Abstract

ThunderBird is a 1/10 2 WD electric short self-driving truck. The truck is equipped with sensors to detect obstacles, GPS for getting directions, Compass for the truck's orientation, Bluetooth for communicating with the android device and LCD for displaying the sensor values, velocity of the truck and current heading on screen. The modules are interfaced using 5 SJ One boards which features a Cortex-M3 LPC1758. CAN bus is used for communicating between the modules. Android device is used to send start message and enter the destination coordinates through Bluetooth. Based on the GPS co-ordinates master directs the motor in respective direction and if the sensors detect obstacles, it signals the motors to drive the car accordingly. Based on GPS co-ordinates and sensor values Master directs the truck until destination is reached.

Objectives & Introduction

Objective

Objective of this project is to be able to work as a team of ten members to develop an Autonomous self driving Car. which gives us the real time work experience as the team of ten members has to be divided into subteams and work on individual modules(Sensors controller, Motor and I/O controller, GPS controller, Android controller and Master controller ) by collaborating with other sub team members for communication between the modules.

Main goal of this project is to understand how CAN protocol works and its architecture in detail, as all controllers of the system communicate through CAN bus.

Team Members & Responsibilities

• Master Controller and Android application
  • Sravani Aitha
    
  • Vishnu Vardhana Reddy Mandalapu
  • James Sushanth Anandraj
  • Athavan Kanagasabapathy
• Motors and I/O
  • Dheeraj Dake
    
  • Akhil Bhargav Josyabhatla
• Sensors
  • Nitesh Jain
    
  • Rajashree Kambli
    
• GPS
  • Rishit Borad
    
  • Ravi Vanjara
    
• Bridge/Android Controller
  • James Sushanth Anandraj
    
  • Athavan Kanagasabapathy
    

Introduction

Our Autonoumous self-driving car is designed in a way that it has five controllers to deal with different functions of the car and these controllers communicate through CAN bus, below is the description for various controllers.

• Bridge Controller : Bridge controller receives the start, stop messages and check points from the android application and it sends the start and stop messages over CAN bus in order to start and stop the car.
• Motors and I/O Controller : Motor controller receives the steer and direction information from the master controller and navigates the car in required direction.
• Sensors Controller : There are four sensors mounted on the car, three in front and one on rear, sensor controller update the motor with obstacle information by sending the updates from the sensors.
• GPS Controller : GPS controller sends the updated direction and the distance to the destination.
• Master Controller : Master controller collaborate the messages from Brdidge, sensor and GPS controllers and directs the motor in required direction.

Overall Algorithm

   1. Android/Bridge controller sends the start command to master controller as soon it receives start from android app.
   2. GPS controller sends the current location to Bridge and Bridge relays the current co-ordinates to android app.
   3. Android application sends the required destination to the Bridge controller and Bridge controller sends the information to GPS controller.
   4. Based on the current location and destination, GPS+Compass controller decides the required direction for the car to navigate and sends it to Master 
       controller.
   5. Master starts listening to sensor data from sensor controller, required direction from GPS+compass controller and it also keeps listening to android       
      controller for any stop message. 
   6. As soon as Master receives GPS start command, Master controller starts calculating the right direction for the car to navigate.
   7. Sensor Controller keeps sending sensor values on the bus and  Motor+IO controller, Bridge controller. 
   8. Bridge controller sends the sensor values to android app for the displays, android app keeps updating its sensor values as soon as receives an 
      update from bridge controller.  
   9. Motor+IO controller keeps listening to the data from GPS+Compass controller for the heading direction and updates the LCD display accordingly.
   10. Motor+IO controller updates all the sensor values on the LCD display as soon as it receives the update from sensor controller.
   11. Master decides the right direction for the car based on sensor values and GPS-co ordinates, sends the message to Motor to move the vehicle in decided 
       direction. 
   12. Motor listens to the direction from Master controller and directs the car accordingly. .
   13. Step 4 to 12 continue until the Master receives stop command from Android controller or destination reached message from GPS Controller.
   14. As soon as Master receives stop message or destination reached command, Master sends stop message to Motor Controller. 
   15. Motor controller stops the car as soon as it receives stop command from Master controller.

Controllers

Schedule

Team Schedule

Motor and I/O Schedule

Geographical Position Controller Schedule

Sensor Controller Schedule

Master controller and android controller Schedule

Parts List & Cost

Design & Implementation

CAN 11-bit ID Format

Controller ID Table

This DBC File has used to communicate between all controllers in RC Car.

VERSION ""

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

BS_:

BU_: NOONE SENSOR DRIVER MOTOR GPS IO

BO_ 0xA0 HEARTBEAT: 1 DRIVER

SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS 

BO_ 0xA1 sensorback: 1 SENSOR

SG_ SENSOR_BACK_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,GPS,IO 

BO_ 0x02 IOSTART: 1 IO

SG_ IOSTART_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER 

BO_ 0x01 IOSTOP: 1 IO

SG_ IOSTOP_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER 

BO_ 0x03 IOCHECKPOINTCOUNT: 1 IO

SG_ IOCOUNT_cmd : 0|8@1+ (1,0) [0|0] "" GPS,DRIVER 

BO_ 0x05 GPSCHECKPOINTCOUNT: 1 GPS

SG_ GPSCOUNT_cmd : 0|8@1+ (1,0) [0|0] "" IO,DRIVER 

BO_ 0x04 IOGPSCHECKPOINT: 8 IO

SG_ IOLATITUDE : 0|32@1+ (0.1,0) [0|0] "DEGREE" DRIVER,GPS 
SG_ IOLONGTITUDE : 32|32@1+ (0.1,0) [0|0] "DEGREE" DRIVER,GPS

BO_ 0xB0 COMPASS: 4 GPS

SG_ COMPASS_direction : 0|8@1+ (1,0) [0|0] "DIRECTION" DRIVER,GPS,MOTOR 
SG_ COMPASS_angle : 8|16@1- (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB1 GPS_longitude: 8 GPS

SG_ GPS_longitude_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR 
SG_ GPS_longitude_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB2 GPS_latitude: 8 GPS

SG_ GPS_latitude_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR 
SG_ GPS_latitude_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB3 GPS_heading: 8 GPS

SG_ GPS_heading_cur : 0|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR 
SG_ GPS_heading_dst : 32|32@1+ (1,0) [0|0] "DEGREE" DRIVER,GPS,MOTOR

BO_ 0xB4 GPS_dest_reached: 4 GPS

SG_ GPS_dest_reached : 0|32@1+ (1,0) [0|0] "" DRIVER,GPS,MOTOR 

BO_ 200 SONARS: 6 SENSOR

SG_ SENSOR_SONARS_mux M : 0|4@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR 
SG_ SENSOR_SONARS_s1_fault : 4|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_s2_fault : 5|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_s3_fault : 6|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_s4_fault : 7|1@1+ (1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_left m0 : 8|12@1+ (0.1,0) [0|400] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_middle m0 : 20|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_right m0 : 32|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_rear m0 : 44|12@1+ (0.1,0) [0|0] "" DRIVER,IO,MOTOR
SG_ SENSOR_SONARS_no_filt_left m1 : 8|12@1+ (0.1,0) [0|400] "" NOONE
SG_ SENSOR_SONARS_no_filt_middle m1 : 20|12@1+ (0.1,0) [0|400] "" NOONE
SG_ SENSOR_SONARS_no_filt_right m1 : 32|12@1+ (0.1,0) [0|400] "" NOONE
SG_ SENSOR_SONARS_no_filt_rear m1 : 44|12@1+ (0.1,0) [0|400] "" NOONE

BO_ 0X020 MOTOR_CMD: 3 DRIVER

SG_ MOTOR_CMD_steer : 0|8@1- (1,0) [0|0] "" MOTOR 
SG_ MOTOR_CMD_drive : 8|8@1+ (1,0) [0|0] "" MOTOR 
SG_ MOTOR_CMD_angle : 16|8@1+ (1,0) [0|0] "" MOTOR 

CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one"; CM_ BU_ DRIVER "The DRIVER controller driving the car"; CM_ BU_ SENSOR "The sensor controller of the car"; CM_ BU_ MOTOR "The motor controller of the car"; CM_ BO_ 0xA0 "Sync message used to synchronize the controllers";

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

BA_DEF_DEF_ "BusType" "CAN"; BA_DEF_DEF_ "FieldType" "";

BA_ "GenMsgCycleTime" BO_ 0xA0 1000; BA_ "GenMsgCycleTime" BO_ 0x01 100; BA_ "GenMsgCycleTime" BO_ 0X020 100; BA_ "FieldType" SG_ 0xA0 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

VAL_ 0xA0 DRIVER_HEARTBEAT_cmd 1 "DRIVER_HEARTBEAT_cmd_NOOP" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 2 "DRIVER_HEARTBEAT_cmd_REBOOT";

Hardware Design

The hardware was designed in a very clean and neat design with the help of 17 pin jumper cables matching the SJ-One board in order to save the space and avoid the multiple layers of wiring. Every hardware parts were built upon after careful consideration.

The CAN Controller used is MCP2551. It is a high speed transceiver which serves as boundary for all the SJ-One controllers which helps to communicate with each other. The operating speed of the bus is upto 1 megabits per second. The high and low signal acting as the output are protected internally against any short-circuits and sudden transitions in voltage level. The connection to SJ-One board is shown s per below diagram,

Pin Connections

Software Design

Implementation

Working Mechanism

Fig 2.ThunderBird System Flow Diagram

Sensor Controller

Fig 1. LV-EZ Ultrasonic Range Finder

Fig 2. sonarback

We have used four Maxbotix LV-EZ Ultrasonic Range Finder sensors (MB1010), three for front (left, right, mid) and one for the rear. These ultrasonic sensors are used to detect the obstacle which our car can encounter on its route. These sensors are connected to the SJOne board and the CAN bus and can work on 3.3V-5.0V.

The pin configuration for the sensor is as follows:
1) Pin 2-PW: This pin outputs a pulse width representation of range. The distance can be calculated using the scale factor of 147uS per inch.
2) Pin 4-RX: This pin is internally pulled high. The LV-MaxSonar-EZ will continually measure range and output if RX data is left unconnected or held high. If held low the sensor will stop ranging. Bring high for 20uS or more to command a range reading.
3) Pin 6-+5V: Vcc – Operates on 2.5V - 5.5V. Recommended current capability of 3mA for 5V, and 2mA for 3V.
4) Pin 7-GND: Return for the DC power supply. GND (& Vcc) must be ripple and noise free for best operation.

Sensor Hardware Design

Fig 3. Board-Block-Diagram

Fig 3. sensor mount

250mS after power-up, the LV-MaxSonar-EZ is ready to accept the RX command. If the RX pin is left open or held high, the sensor will first run a calibration cycle (49mS), and then it will take a range reading (49mS). After the power up delay, the first reading will take an additional ~100mS. Subsequent readings will take 49mS. The LV-MaxSonar-EZ checks the RX pin at the end of every cycle. Range data can be acquired once every 49mS.

Each 49mS period starts by the RX being high or open, after which the LV-MaxSonar-EZ sends the transmit burst, after which the pulse width pin (PW) is set high. When a target is detected the PW pin is pulled low. The PW pin is high for up to 37.5mS if no target is detected. The remainder of the 49mS time (less 4.7mS) is spent adjusting the analog voltage to the correct level. When a long distance is measured immediately after a short distance reading, the analog voltage may not reach the exact level within one read cycle. During the last 4.7mS, the serial data is sent.

Sensor Software Design and Algorithm

The following steps are for initializing, getting readings and calculating distance in inches for one sensor- Main init function: 1) Configure the PW pin of sensor as input.

2) Configure RX pin of the sensor as output and set it high.

3) Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.

4) Note down the sys_get_uptime_us() at the rising interrupt. Let this time be T1.

5) Note down the sys_get_uptime_us() again when the falling edge is encountered. Let this time be T2.

6) To calculate the distance in inches, do - (T2-T1)/147.

7) Send this value to the Master controller via the CAN bus.

Periodic Callback Functions:

We are using the periodic callback functions.Hence we implemented the algorithm around those tasks.We used static variables in order to preserve the values incase functions are completed and the desired tasks are not completed yet. We used only the 1000Hz and 100Hz tasks.

--1000Hz task:

Start 1st sensor.

Get fall edge and calculate value.

Stop sensor and start next.

--100Hz task:

Get all 4 sensor values and send to Master and Motor via Can.

This is the snippet of our Interrupt function callbacks.

eint3_enable_port2(RightSensorPW_Pin, eint_rising_edge, eintCallbackright_Rise);
eint3_enable_port2(RightSensorPW_Pin, eint_falling_edge, eintCallbackright_Fall);

void eintCallbackright_Rise()
{
  //Note down the system start time for right sensor ( start_right_time)
}

void eintCallbackright_Fall()
{
 //Note down the current system time 
 //Subtract the start_right_time from the current system time and divide the result by 147 to get the distance in inches.
}

Fig 4.Sensor workflow

Fig 5. Sensor Timing Diagram

Fig 6. Sensor State Diagram

Fig 7. Sensor Flow chart

Sensor: Technical Challenges

Issue #1 - Fluctuating sensor values: We observed random/fluctuation in the sensor values. Sometimes, the value was even zero.The primary reason was that we were using the ADC mode. ADC mode converts analog to digital values received from the sensors. The values were unstable and unreliable.We could have used an arbitration to get accurate values. But the SJSU one board has only 3 ADC pins and we have 4 sensors to mount. So,either way we could not use ADC mode.
Solution: Switched from ADC mode to PWM mode to get more reliable values,with minimum spikes.PWM mode is a more reliable mode. We got accurate spikes on an oscilloscope and hence we used the PWM mode on the sensors.

Issue #2 - The beams from two adjacent sensors collided with one another.The waves from the sensors travel in a V shape.This caused inter sensor value collision.
Solution: Increased the distance between the sensors and made sure sensors working serially and not in parallel.We increased the distance between the sensors to avoid inter sensor collisions.Also we turned one sensor on at a time. Hence we turned one sensor,got the values and then turned it off before moving on to the next one.The reliability increased considerably.

Issue #3 - The sensor when mounted on the car detected ground as obstacle.During the 1st demo, we mounted the sensors on the main board itself. This caused us getting values from the ground. This situation can be tricky when the car is on a slope.
Solution: Increased the height of sensors placed on the car.We mounted the sensors on custom PCB's and made sure no ground reflections were encountered.

Issue #4 - The sensors did not work on independent 5V supply.We provided a common 5V power to all the sensors. This caused fluctuations and hence unreliable values.
Solution: Switched the power supply to a more reliable and constant SJSU one board VCC.To reduce the spikes, we could have used a stable 5V power source. But we opted for stable power from the SJSU board. This reduced spikes.

Issue #5 - The sensors (Left and Right sensor) gave faulty values when placed at 45 degrees on the corner of the base board i.e. fall edge missed sometimes.The waves from the sensors got reflected from white or oil based painted objects if the sensors were placed at 45 degrees.
Solution: Increased the angle to cover wider area and avoid reflections.Finally we tested out many permutations and combinations to find the accurate angles at which the sensors reflected properly and waves didn't just pass on. Hence increasing the angles to more than 45 degrees helped get us accurate values.

Fig 5. Sensor before

Fig 6. Sensor after

HEAD/TAIL LIGHTS

Based on the Light Sensor mounted on the SJSU one board, we are turning on the LED placed on the Head Light position.The threshold taken for Light is 20.Also for Back lights,if the car halts or moves in the reverse direction, the tail lights will turn on. The encoder values from the motor are used to achieve this.

Sensor Test Video

• Sensor Test Video

Motor and I/O Controllers

ThunderBird is a 2 WD truck. It is equipped with a ARRMA BLX brushless DC motor connected to an BLX80 ESC(Electronic Speed Control). The ESC drives the DC motor according to the PWM(Pulse Width Modulation) signal. The truck's front wheels are connected to a waterproof ADS-7M Metal Geared Steering Servo. The servo and the DC motor are controlled using the PWM pins of the SJOne board.

Motors

Pulse Width Modulation - Controlling DC motor

Fig 1. Initializing pwm signal

Fig 2. Initializing pwm signal

Fig 3. Forward pwm signal

Fig 4. Reverse pwm signal

Fig 5. Servo pwm signal

Fig 6. Optical Sensor for measuring RPM

Fig 7. Optical sensor secured on the car's back rim

Fig 8. Schematics of Optical sensor interface with SJOne board

Pulse width modulation is a technique which is used to encode the analog signal into a pulsating signal. The signal is represented as a series of pulses. This signal can be easily generated using the pwm pins of the SJOne board. The ESC is initialized upon passing a PWM signal which is sent by the RF module on the truck. The type of signal is observed by hooking the PWM pin to the digital oscilloscope. The initialization signal is shown in figure 1. A resolution of 1ms is set on the oscilloscope. The PWM signal has a width of 1.5 ms. This signal initializes the ESC. Once the ESC's are initialized, the motors require a signal to accelerate and decelerate. The type of signals for moving the motor forward and backward are realized by hooking the output pin of the RF module to the digital oscilloscope. The forward and backward pwm signals at full throttle are shown in figures 2 and 3 respectively. The respective pwm signal pulses for moving the motors forward and backward are shown below.

• Acceleration PWM signal
  • Forward full throttle - 2 ms
  • Forward medium throttle - 1.8 ms
  • Neutral - 1.5 ms

• Reverse PWM signal
  • Reverse full throttle - 1 ms
  • Reverse medium throttle - 1.2 ms
  • Neutral - 1.5 ms

PWM Calculations

The PWM value to be set is determined from these calculations:

• PWM is a percentage of the signal frequency
• The signal is of 50 Hz i.e. 20 ms duration
• A 10% of the signal value gives a duration of 2 ms - 10/100 * 20 = 2 ms

The respective percentages for all the signal were calculated and the PWM signals were generated using the PWM.set function. The generated pulses from the SJOne PWM pin is passed to the ESC for initialization and controlling the DC motor. The ESC has 3 connections - Vcc, GND and PWM. SJOne board's GND and PWM are connected to the ESC. The Vcc is supplied from the battery pack.

A sample code demonstrating the PWM signals is written and the motors were controlled using the on-board SJOne switches.

DC motor demo

Controlling Servo motor

The servo motor channel in the RF module is hooked to the digital oscilloscope to determine the initial sequence. It is observed that when the RF transmitter is switched on, the RC remote sends a pwm signal which resets the servo to its starting position. This PWM signal re-centers the truck's wheels. The signal is realized by hooking the data pin from the first channel of the RF module to the digital oscilloscope. The PWM signal is shown in figure 4. The signal is having a pulse of 1.6 ms. The steering on the RC is moved left and right to determine the PWM signals. The signal values were noted from the oscilloscope. The values are tabulated below.

• Steering PWM signal
  • Steer full right - 2 ms
  • Steer full left - 1 ms
  • Steer center - 1.6 ms

A PWM signal having a pulse width between 1.6 ms to 2 ms is used to control the steering towards right precisely. Similarly, a PWM signal having a pulse width between 1 ms to 1.6 ms is used to control the steering towards left precisely. The servo has 3 connections - Vcc, GND and PWM. The servo motor is not connected to a ESC. It doesn't get any voltage if it is not connected to the RF module. The servo motor operates at 6V. For testing, the Vcc of the servo motor is connected to the RF module. The GND from the RF module is made common with the GND from SJOne board. The PWN signal is given as an input from the SJOne board. The PWM signal values were calculated using the procedure shown above. The respective PWM signals were then sent to the servo motor using the PWM pin on the SJOne board for steering the truck.

The on-board switches on the SJOne board are used to steer the truck left and right. A sample code demonstrating this functionality is written and tested.

Servo motor demo

Speed Feedback Encoder

The car should maintain it's speed at all times. The factors affecting the car's speed include incline surfaces, weight of the car and low battery. During these cases, the car should increase and decrease its speed accordingly. There should be some mechanism to know the speed of the car. If you get a Traxxas car, it has an inbuilt device built into the car for measuring the car's speed. We are using optical sensor to detect the car's revolutions.

Optical Sensor

The optical sensor is shown in the figure 5. The optical sensor has Vcc, GND and data pins. The Tx led lights bright red and the Rx receives the reflected light from the Tx when it encounters a white surface. The optical sensor is mounted on the back rim of the car. A white paper is patched on to the tyre to reflect the light from the Tx into the Rx. The mounted optical sensor is shown in figure 6. The schematics for the optical sensor is shown in figure 7. The sensor's data pin is hooked to the GPIO pin. An ISR is called on that pin which will increment a counter value each time the interrupt is called. The counts are averaged using period functions and is displayed on the LCD for every second. The RPM is controlled according to these revolutions per second value. When the car goes on a slope, the pwm is increased to maintain the RPM and once the car climbs the slope, PWM value is decreased. It adjusts accordingly to maintain the RPM!

Precise Steer

The car should steer precisely according to the compass value and GPS value. The GPS tells the car where to go and the compass will tell the car in which direction it should go. The compass gives the values in degrees which lie in the range 0 to 360. The car's servo motor has a PWM range of 4 to 10 with 4 being the extreme left, 7 being the center and 10 being the extreme right. The compass degrees are divided into 17 sectors. The sectors 0 to 9 have values ranging from 0 to 180 degrees and sectors 10 to 17 have values ranging from 180 to 360 degrees. The sectors 0 to 9 drive the car right and the sectors 10 to 17 drive the car left. Each sector accounts to 20 degrees on the compass value. The entire PWM range is divided into sector value. The respective PWM value is set for the car's servo motor for precise steering control.

When the car encounters an obstacle, the precise control is stopped and the car steers to avoid the obstacle. Once the obstacles are avoided, the precise control is activated back.

Periodic Callback Functions:

The periodic callback functions are called periodically. The initialization is done in periodic init which is done at the start. The periodic callback functions 1Hz, 10 Hz, 100 Hz and 1000 Hz are called every 1000 ms, 100ms, 10 ms and 1 ms respectively. The following tasks were performed in the periodic functions.

--1Hz task:

Reset the number of interrupts received from the optical sensor

--10Hz task:

Update the LCD

--100Hz task:

The motor code

--1000Hz task:

Not used

Common Problems and troubleshooting

Issue #1 - The PWM signal width i see on the Oscilloscope is not correct!
Solution: I observed this while using PWM.set() in periodic functions. I did observe a correct pulse width on the oscilloscope when i did pwm.set in main(). But when i did pwm.set() in the periodic functions, i observed that the PWM signal is giving an incorrect pulse width. The reason is the PWM object is getting destructed. PWM object doesn't get destructed when used in a while(1) loop. When used in the periodic functions, it gets destroyed as soon as the function exits. The solution for this is to make a PWM Singleton Class that doesn't destruct. You can use methods such as motorcontrol.drive() and motorcontrol.steer() to set the PWM's for driving and steering the car. This is a better approach than making the PWM class global.

Issue #2 - The car's ESC initializes but the motor doesn't move irrespective of the PWM value!
Solution: Make sure that the battery is charged. Simple as that.

Issue #3 - How do i find the car's ESC initialization sequence?
Solution: You can use an Oscilloscope for this. As soon as the car is switched on the car's RC module sends a PWM signal to the ESC. The signal's width can be observed by hooking that PWM pin to the oscilloscope. The PWM value can be calculated according to the procedure described above. Give the respective PWM values and the ESC will be initialized.

I/O

Liquid Crystal Display

Fig 9.LCD, Driver and SJOne interface

Fig 10.LCD displaying the values

A 20x4 LCD(CM 204-1) is used for displaying the speed, sensor values and the start and end coordinates. A LCD driver by SJValley Engineering is used for accessing the LCD through UART. The driver and LCD are soldered on to the prototype board. A USB jack is soldered on-board to power the LCD using the 5V supply from the external battery. The connections between the driver and SJOne board is shown in figure 5. As soon as the LCD is powered on, it displays to enter 0xF0 which is the command for detecting the baud rate. After 0xF0 is sent, the data can be transmitted using UART. A baud rate of 38400 is used for displaying information on the LCD. If you are getting some junk values, make sure that the baud rate is set correct and check the soldering.

The LCD with displaying the values is shown in figure 6. The following helps you to organize information on your LCD.

• Commands for displaying information on LCD
  • urt.put displays a character on the LCD
  • urt.putlin displays a character on the LCD and moves the cursor to the next line
  • $CLR_SCR is used to clear the screen

Fig 9.Flowchart for LCD

Common Problems and troubleshooting

Issue #1 - LCD is displaying only 2 lines, line 1 and line 3 when i power it on.

Solution: Check the connections. Make sure that the LCD is properly soldered to the driver.

Issue #2 - I am getting garbage values printed on the screen when i try to transfer information over UART

Solution: LCD is not initialized properly. Make sure you get the detecting baudrate information displayed on screen when the LCD is powered on.

Issue #3 - Is it okay to program the LCD while being connected to the SJOne board?

Solution: I didn't find any issues while programming the SJOne board with the LCD connected to it. However, some teams had issues with it.

Issue #4 - How do i update a single field on the LCD keeping the rest static?

Solution: I cleared the entire screen every 100 ms and it looked like only the values are being updated!

GPS Controller

Geographical controller module plays an important role in heading and positioning of autonomous car.It consists of 20GHZ GPS module and 9-DOF RAZOR IMU interfaced to SJ-one board.

The GPS module provides Latitude and Longitude co-ordinates for current position of car.The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to give you nine degrees of inertial measurement.

Hardware Interface

SPARKFUN VENUS GPS with SMA CONNECTOR

Sparkfun Venus GPS is interfaced to SJone Board using UART communication protocol. As shown in above figure ; we have used UART-2 on SJone board to interface with GPS module at 38400 bps. GPS module needs a 2-3 mins of startup time to lock satellites and receive gps co-ordinates.It is recommended to use a coin cell battery or a alternative power source to boot up and lock satellites.

Sparkfun Venus GPS provides GPS information basically the current latitude and longitude in different NMEA standard messages such as

 $GPBOD - Bearing, origin to destination
  $GPBWC - Bearing and distance to waypoint, great circle
  $GPGGA - Global Positioning System Fix Data
  $GPGLL - Geographic position, latitude / longitude
  $GPGSA - GPS DOP and active satellites 
  $GPGSV - GPS Satellites in view
  $GPHDT - Heading, True
  $GPR00 - List of waypoints in currently active route
  $GPRMA - Recommended minimum specific Loran-C data
  $GPRMB - Recommended minimum navigation info
  $GPRMC - Recommended minimum specific GPS/Transit data
  $GPRTE - Routes
  $GPTRF - Transit Fix Data
  $GPSTN - Multiple Data ID
  $GPVBW - Dual Ground / Water Speed
  $GPVTG - Track made good and ground speed
  $GPWPL - Waypoint location
  $GPXTE - Cross-track error, Measured
  $GPZDA - Date & Time

We use $GPGGA - Global Positioning System Fix Data

Time, position and fix related data for a GPS receiver.

Structure: $GPGGA,hhmmss.sss,ddmm.mmmm,a,dddmm.mmmm,a,x,xx,x.x,x.x,M,,,,xxxx*hh<CR><LF>

1 2 3 4 5 6 7 8 9 10 11

Example:

$GPGGA,111636.932,2447.0949,N,12100.5223,E,1,11,0.8,118.2,M,,,,0000*02<CR><LF>

Gpgca NEMA standard description table

The SparkFun Venus GPS comes with a default baud rate of 9600 bps and update rate of 1 Hz. It does NOT have an antenna, so we had to use Antenna GPS Embedded SMA. From our and experience of our project advisors we would recommend a GPS with refresh/update rate of ATLEAST 10Hz.

These are few commands which have 90% usage for most GPS module setup and troubleshooting.

1. Factory Reset
A0 A1 00 02 04 00 04 0D 0A
2. Configure the position update rate of GPS system(10 Hz).
A0 A1 00 03 0E 0A 01 05 0D 0A
3. Configure serial port. this command will set baud rate to 38400.
A0 A1 00 04 05 00 03 01 07 0D 0A
4. Configure NMEA message interval (this command will block all strings except GPGGA).
A0 A1 00 09 08 01 00 00 00 00 00 00 01 08 0D 0A

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

Compass

Hardware Interface

We are using sparkfun Razor IMU to give 9-degree of internal measurement. It has inbuilt triple axis gyroscope, accelerometer and magnetometer. The 8Mhz factory firmware gives compass heading using UART which is raw value of yaw, pitch and roll. The firmware for the Razor IMU is available on the GIT on various platforms such as Ardiuno, Android, Processing etc.

400

We are using Ardiuno platform to download the firmware on the compass using Aurdino software. The same platform and firmware offers functionality to calibrate the compass. Having compass values is not enough for the project as it may or may not work on in real-time, when it is embedded on the car. Magnetometer is sensitive to magnetic field around, hence, the compass needs to be calibrated in the environment where it has to perform i.e on the car. The firmware is written in a way that it shows the deviation from the original value during calibration and gives a final value after the calibration to put as an offset in respective meter. All the meters, gyroscope, accelerometer and magnetometer, needs to be calibrated individually as the final heading is being calculated using values from all the three meters. [1], calibration methods are given on the link mentioned earlier.

Compass firmware in aurdino

Roll

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

Magnetometer calibration

Magnetometer extended 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. Hard calibration: Calibrating the compass with the earth's magnetic field.
2. Soft calibration: Calibration the compass with the surrounding magnetic fields.

  #define CALIBRATION__MAGN_USE_EXTENDED true
  const float magn_ellipsoid_center[3] = {0, 0, 0};
  const float magn_ellipsoid_transform[3][3] = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}};

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

Calibrating the compass

Heading before calibration

Heading after calibration

Flowchart

Challenges faced

1. Considering cost effectiveness and other projects, we odered HMC5881 compass. There are not so many resources on internet to calibrate the compass right and it gave the heading which differed from the actual north. We tried adding offset in the compass value to ake it work but the offset was fluctuating in all the coordinates also gave different headings after each power cycle.

2. After disappointing results from the HMC5881 compass, we ordered Razor IMU 9DOF compass and unfortunately the compass module turned out to be defective and we learned that after many calibration attampts. The compass was giving different north direction after every power cycle and the heading data was drifting back to same angle after moving the compass. We were able to resolve the drifting issue by removing the error correction code but even after resolving one issue the major issue remained same and not gave the right north direction.

3. For the same Razor IMU 9DOF, the heading was constantly decreasing even for the stagnant position of the compass. The headings were regular and smooth, ie. changed with the movement of the compass but after every power cycle the north pointer was different and in many cases not the right north direction. We were able to get the constant values for the heading by altering the Kp_yaw and Ki_yaw to 0.02f and 0.000045f respectively. to get the north direction, we had to change the Razor IMU module with the new one and it worked as expected after calibration.

4. While receiving GPS checkpoint from IO module, the decoding altered the float data and the data did not match with the data sent from the IO module. We copied the float value to a 4 byte char array to get the right data from IO module.

Master Controller

Master controller is responsible for communication between different controllers and sync each controller's data in directing the car in right direction. It receives ths start or stop command from Android application as soon it receives the command, Master sends motor with the respective message. Master controller listens to the data from sensors and GPS and compass, based on the obstacle avoidance algorithm and GPS co-ordinates, Master decides the right direction for the car and sends it to the Motor.

Software Implementation

Master controller initializes CAN and set the bypass filter on master to accept all incoming CAN messages and in software we process the required data based on the message IDs. as soon as the Controller is up, it initializes the CAN, periodicScehdular task starts executing, where we are using 100Hz function to process all incoming messages and transmitting the CAN messages on to the Bus. if CAN transmission fails, resetcan_bus function is being called to resent the CAN.

Below sections explains the flow in detail.

 main()
  { 
    CAN initialization
    periodicschedular task
  }

Heart Beat mechanism

Hearbeat message flow

The heart beat mechanism is included in order to check for aliveness of each of the controller. There are totally five controllers including the Master Controller. The heart beat algorithm has been included in every of the controllers,

      1) Every controller sends a CAN message with their own respective msessage ID's 

      2) During the reception of the CAN Messages, there is a difference between the tasks between Master and other controller's 

               Master Side:

                      1) Receive the CAN message

                      2) Decode the message id and Update the Counter value associated with that Message ID.

               Other Controllers Side:

                      1) If message is from Master, then toggle their LED

                      2) Ignoring the other messages

      3) The Controllers are checked for aliveness every 10 seconds by comparing the current and old counter values. 

                      1) If both old and current counter values matches, then corresponding controller is considered to be dead and LED is light up.

                      2) If they doesn't match then the status has been received and controller is alive.

Obstacle avoidance and car navigation Algorithm

Based on the data received from GPS Controller and sensor values, Master would decide the direction and steer values for the car and update the motor with the required direction and steer data. Direction and steer value computation is based on the below algorithm.

Obstacle avoidence and car navigation algorithm

PSEUDOCODE:

   if (Start command from android or Switch)
       if (GPS starts sending the valid data)
        {
           if Destination_Reached == TRUE
             return STOP command          
           else (Listen to the Sensor first and if no obstacle listen to GPS Direction)
              if NO OBSTACLE detected
                 return GPS DIRECTION
             
               if RIGHT OBSTACLE detected
                if GPS_DIRECTION == RIGHT
                  RETURN STRAIGHT
                 else
                  RETURN GPS_DIRECTION

               if STRAIGHT OBSTACLE detected
                  (Compare RIGHT and LEFT SENSOR)
                  if RIGHT OBSTACLE is NEAR than LEFT SENSOR:
 		      RETURN RIGHT
		    else
                     RETURN LEFT
      
               if STRAIGHT and RIGHT OBSTACLE detected
                  RETURN SLIGHT_LEFT
		
               if LEFT OBSTACLE detected:
                  if GPS_DIRECTION == LEFT
                    RETURN STRAIGHT
                  else
                    RETURN GPS_DIRECTION

               if LEFT and RIGHT OBSTACLE detected
                  RETURN STRAIGHT

               if STRAIGHT and LEFT OBSTACLE detected
                  RETURN SLIGHT_RIGHT
	
               if STRAIGHT, LEFT and RIGHT OBSTACLE detected 
                  if REAR SENSOR detected
                    RETURN STOP
                  else 
                    RETURN REVERSE

GPS Direction:

               if COMPASS_Angle == 0
                 return STRAIGHT Command                
               else if COMPASS_DIRECTION = 1
                 return RIGHT command              
               else
                 return LEFT command

Periodic Callback Functions :

We used periodic callback functions in implementing CAN communication between controllers to make the communication deterministic and real-time. We used 100Hz in implementing the CAN communication for transmitting and receiving CAN messages.

100Hz function is used to process CAN messages received by Master controller, compute the required direction and to transmit the CAN message to Motor controller, It processes up to five messages in one function call and it also completes executing obstacle avoidance algorithm and based on GPS data, required direction is computed and CAN message is transmitted with required direction details and steer data to Motor Controller.

Periodic Schedular task

100Hz Function:

{
     Receive and process sensor controller data
     Receive and process GPS+Compass controller data
     Receive and process Birdge controller data
     Compute the direction of the car based on Sensor and GPS data
     Transmit CAN message to Motor with required direction or stop condition. 
}

Bluetooth Control and Android application

Hardware Design

A BTBEE Pro Bluetooth XBee socket chip connected to the SJOne board is the main hardware component used in Bridge communication.It is interfaced to the SJONE board over UART2. The SJONE board is in turn interfaced with the CAN Bus using a MCP2551 CAN Transceiver.

Hardware Interface

The BTBEE Pro is placed on the XBee socket of the SJOne board. This design was chosen over using I2C/SPI interface as SJONE board has a XBEE socket which can be used directly.The BT module communicates with the SJOne board using a UART interface. Uart2 on the SJONE board is used for this purpose. In order to enable the communication over UART, the switch on the SJONE board needs to set to UART2 position.

Bluetooth Hardware Interface

Software Design

The Software design of the Bluetooth and android Bridge control system consists of two main parts
1) Bluetooth to CAN Bridge Software on SJONE board 2) Thunderbird Android Application

Bluetooth to CAN Bridge

The Bluetooth chip is initialized by passing the following commands over bluetooth.

Bluetooth initialization commands

Once the chip the initialized data is sent and received from the android app to the SJONE board by treating the Bluetooth connection as a UART bus using uart api's like uart2.getChar and uart2.printf.

In our bridge controller we have written the algorithm to parse input characters from uart and take action based on the sequence of characters that make up a command. The bridge controller responds to the following commands.
a) Hello - Hello message from android. The SJONE board responds with the current GPS coordinates.
b) Start - Start message from android. The SJONE board responds with HI to begin exchange of one GPS checkpoint value.
c) Stop - Stop message from android. The SJONE board responds with the number of GPS coordinates it received from Android.
d) Good - Car start message from android. The SJONE board transmits a start message to Master controller to start transmitting commands on can bus to control the car.
e) Bad - Emergency start message from android. The SJONE board transmits a stop message to the Master controller to send stop command on the can bus to all controllers.

Bluetooth Commands Parsing

Parsing float information from android

We have used a state machine approach to receive latitude and longitude float values from android app. The state machine is explained as a flowchart below.

Bluetooth Float Parsing

Updating analytics values to android

Updating analytics value to the android app is an important functionality of bluetooth controller. We read all messages on the can bus and store the values in dbc defined global variables. At 1 hz we send this out to the Android app. The analytics values that are sent to android are as follows
a) Induvidual sensor readings
b) Last command issued by Master
c) Speed of the car from Motor
d) Latitude, Longitude and Heading values from GPS.

Android Application Software Design

In our project android application is used to perform the following tasks around which we have designed the application. a) Connect to the truck over bluetooth
b) Get its current location
c) Set the destination for the truck to reach
d) View analytics information broadcasted over bluetooth

The above structure is clearly reflected in the activites used in the android application. We have 4 activities that makes up our android application. Intents and Bundled data is used to transmit information from one activity to another.

a) Welcome activity
The welcome activity is the first activity that is shown to the user. In this activity the user is presented with options to connect to the device. When the user clicks on the connect button a list of bluetooth devices are shown to the user and the user selects the truck and connects to it. Once connected we show the options activity.

b) Options activity
The options activity is the second activity shown to the user after he connects to the truck. In this activity we show options to obtain the current gps location from the device. This activity also serves as the analytics page where the different values obtained from bridge. The values are obtained from the bluetooth activity using intents.

c) Map activity
The Map activity is the activity where the user can select a destination. We have used Android-GoogleDirectionLibrary by akexorcist to show the map interface and set destination. We also used the library to get checkpoint data from Google directions API. A server key is used for authentication by the Google server before obtaining checkpoints .The checkpoints data is transmitted to bridge controller using the bluetooth activity.

d) Bluetooth Activity
The bluetooth activity forms the crux of the application. It receives intents with data to be transmitted to the SJONE board from all other activities. We have used Android-BluetoothSPPLibrary by akexorcist to establish and negotiate bluetooth connection and send and receive data. This activity also periodically receives analytics data and sends it to the options activity where it is displayed

Use Case Flow Chart

We expect the user to follow this flow chart to use the app to interact with the truck.

User Interaction Flow Chart

Android UI design

The UI was designed with simplicity and quick development time in mind. It was designed in the UI editor of Android Studio. The following are screenshots from application.

Periodic Scheduler Design

One Hertz Task

In One hertz task. We send analytics values to android app by UART over bluetooth. The analytics values sent are sensor values,motor directions sent by master, speed of car from motor, heading and location of the truck.

Ten Hertz Task

In 10 hertz task we read and write to the CAN bus to update DBC generated structures which represent the latest values received on the BUS.

Hundred Hertz Task

In 100 hertz task we read characters from the Bluetooth Uart connection and parse and execute appropriate commands.

Challenges Faced

a) Could not interface the UART connection with Terminal code of SJONE board to use existing command handler code
Solution: Develop custom code to parse data to and from the uart connection treating it as a char driver.

b) Bridge controller crashes when both CAN and Bluetooth communication are done in 100 hz task
Solution: Move Can communication to 10 hertz task

c) Bridge and Android app developed before other subsystems were fully functional
Solution: Create a Test section in Android app that uses hard coded values from sjsu board and goes through the user process.

d) GPS values sent and received are -1 times the ones used by GPS system
Solution: Multiply by -1 in all places when reading and writing values to the SJONE board.

Testing & Technical Challenges

CAN_DBC

Problem : The introduction of CAN DBC in the middle of the project was not well orchestrated and derailed the project from the schedule
Solution : If a major change such as CAN DBC needs to be made special efforts need to be taken to ensure proper coordination between the sender and receiver for every message added on the bus. Do not use experimental features like message multiplexer as it added to 2 extra days of debugging to figure out a software issue that mux is poorly implemented.

Project Manangement

Problem : Lack of proper time and project management led to schedules being missed.
Solution : At the begining of the project nominate a person as Project manager. This person should ensure proper communication between team members and review individual team status and high level algorithms for induvidual components frequently and look for quick methods to solve high level problems. Do not depend on team members physical presence. Use skype calls and other team collab tools to ensure weekly meeting and team progress.

Code Review

Problem : Lack of proper code review led to small software bugs which cause major delay due to debug time and effort
Solution : Assign a person for every person to review the other person's contribution from another team. This could help reduce small small bugs which have big time and effort impact.

Figuring out team strengths

Problem : People chose new domains different from their comfort zone to contribute to the project
Solution : People should choose subsystems based on their strengths. Even if you want to learn something new, you can learn after project, not during project. The project should proceed according to schedule which is already very difficult to follow. There should be no delay due to experimental work. All experiments can be done after the project is done. In all actions and decisions taken during project ask only one question. Will this help the project to work in the demo? do not worry about individual learning goals.

Conclusion

This was a very interesting and challenging team project. We gained good technical embedded application knowledge and it also helped us gaining team organization and management skills. This project gave us good exposure to different modules such as sensors, MOTOR, GPS, Android application and CAN bus, which made us comfortable to work on any new module by exploring its features. We would suggest the future teams working on this project to set individual goals and divide the major tasks into several small tasks and work towards them to be more productive. Overall experience of this project was very good, and we call it one of the best projects we worked on.

Project Video

Here is our demo.

THUNDERBIRD

Project Source Code

• GitLab Source Code Link

References

Acknowledgement

We would like to thank Preet for guiding us throughout the semester and for giving us such the wonderful opportunity to work on this project. We would also like to thank Mr.Mitesh Sanghvi and the entire ISA team for their constant support and encouragement. Finally, it would not have been possible to work on the project without the entire team's support for each other. The team worked really hard to achieve the final goal of making the Self Driving RC Car work!

References Used

[1]Kang, P.(2015).CMPE243: Embedded system Application, notes [Power point slides and lecture notes]
[2]LPC1758 User Manual
[3]Real time OS on embedded system
[4]Razor IMU
[5]Razor IMU tutorial 1
[6]Razor IMU tutorial 2 
[7]Sparkfun GPS info
[8]Maxbotix Sonar Sensor
[9]LCD
[10]Android Google Direction Library
[11]Bluetooth SPP Library