F15: Undergrads++

From Embedded Systems Learning Academy
Revision as of 07:19, 18 December 2015 by 243 user2 (talk | contribs) (→‎Software Design)

Jump to: navigation, search

Undergrads++

Abstract

The project is an autonomous car that shall avoid obstacles. The car will consist of five SJ One controllers connected and communicating via one operational CAN bus. Each controller shall be handled by teams of two people per component and integrated to 1 working autonomous car. The Master Controller team shall be responsible for collecting data from the other controllers and guiding the car using high-level logic. The Motor I/O Controller team shall be responsible for the operation of the motors and operation of the LCD display, which will display debugging or current status messages. The Sensor Controller team shall be responsible for collecting data from the sonar sensor and sending the appropriate data. The Geographical Controller team shall be responsible for calculating the orientation of the car. The Bluetooth/Bridge Controller team shall be responsible for the interface to the end user and sending the way-points. All of these five devices shall operate simultaneously and reach the requested destination.

Objectives & Introduction

  • The user shall be able to set a longitude/latitude using an Android app
  • The user shall be able to send a Start command to start the navigation routine
  • The car shall avoid obstacles and navigate appropriately around them
  • The car shall contain sensors in the front and back to go forward and backward without intervention
  • The car shall reach the destination before the battery dies
  • The car shall contain a GPS and compass to calculate the heading, longitude, and latitude
  • The car shall contain a Bluetooth device to receive information from the Android App
  • The car shall contain appropriate sensors to internally calculate the speed of the car
  • The car shall be able to adjust it's speed appropriately when commanded by the Master controller
  • The car shall display appropriate information on the LCD display
System Communication Overview

Team Members & Responsibilities

Master Controller

  • Marvin Flores
  • Hassan Naveed

Sensor Controller & Finances

  • Arlen Eskandari
  • Onyema Ude

GPS Controller

  • Calvin Lai
  • Jonathon Hongpananon

Motor/LCD Controller

  • Hector Prado-Guerrero
  • Jashan Singh

Bridge/Android Controller

  • Phil Tran
  • Shangming Wang

Parts List & Cost

This section goes over the parts that we ordered and the cost of each item.

Item# Part Desciption Vendor Part Number Qty Cost
1 RC Car Traxxas Traxxas Slash 2WD VXL 58076 Brushless 1 $339.94
2 GPS Module Adafruit Ultimate GPS Adafruit 1 $39.99
3 CAN Transceiver breakout board Anchor Anchor 4 $3.89
4 Assembly Components Amazon, ebay, Halted (High Quality Jumpers, nuts, screws, standoffs) NA $50
5 Arduino compatible Tracking Sensor (For controlling the speed) Phantom YoYo! Amazon 2 $10.12
6 Sonar sensor Maxbotix EZ MB1010 Amazon 4 $29.95
7 3000mAh 2S1P 20~40C LiFePo4 Battery Turnigy Hobbyking 1 $23.82
8 Tripleaxis accelerometer+Magnetometer(Compass) Board Adafruit LSM303 1 $20.97
9 LCD Display 1 given by Preet
10 Brushed Motor Traxxas 3785 Titan 12 Turn 550 1 $19
11 7Segment Display 1 given by Preet

Design & Implementation

The section goes over our top-level designs of our project.

CAN Message ID Table

Sl. No Module ID Type/Bits xxxxx Source bits SSS Destination bits DDD Hex value Source Destination
1 Android 001 CRITICAL_ERROR_BUS_OFF 0 0 0 0 0 x x x 0 0 0 0x008 Android

0x010 Master

0x018 Sensor

0x020 GPS

0x028 Motor-LCD

ANY ALL
2 Master 010 ANDROID->MASTER 0 0 0 0 1 0 0 1 0 1 0 0x04A


Android Master
3 Sensor 011 RC_PARAMS 0 0 0 1 0 0 0 1 0 1 0 0x08A


Android Master
4 GPS 100 SET_DEST 0 0 0 1 1 0 0 1 0 1 0 0x0CA


Android Master
5 MOTOR_LCD 101 COORDINATES ANDROID->MASTER 0 0 1 0 0 0 0 1 0 1 0 0x10A


Android Master
6 X X SENSOR_MASTER_REG 0 0 1 0 1 0 1 1 0 1 0 0x14A


Sensor Master
7 X X MASTER_ANDROID_REG 0 0 1 1 0 0 1 0 0 0 1 0x14A


Master Android
8 X X COORDINATES MASTER->ANDROID 0 0 1 1 1 0 1 0 0 0 1 0x1D1


Master Android
9 X X MASTER_COMMANDS-> Motor 0 1 0 0 0 0 1 0 1 0 1 0x215


Master IO_Motor
10 X X MASTER_COMMANDS->SENSOR 0 1 0 0 1 0 1 0 0 1 1 0x253


Master Sensor
11 X X MASTER_COMMANDS_READ-> IO 0 1 0 1 0 0 1 0 1 0 1 0x295


Master IO_Motor
12 X X IO_MOTOR_MASTER_REG 0 1 0 1 1 1 0 1 0 1 0 0x2D5


IO_Motor Master
13 X X MASTER_COMMANDS->GPS 0 1 1 0 0 0 1 0 1 0 0 0x314


Master GPS
14 X X GPS_MASTER_REG 0 1 1 0 1 1 0 0 0 1 0 0x362


GPS Master
15 X X MASTER_COMMANDS_WRITE-> IO 0 1 1 1 0 0 1 0 1 0 1 0x395


Master IO_Motor

DBC File Implementation

Throughout the development and life-cycle of our project we used a DBC file and a python parser to generate C-code for the five controllers. The DBC file contained CAN messages organized in a particular format, which the python parser generated appropriate code for each CAN node. The C-code generated contained inline functions to convert messages to and from raw CAN messages using marshal and unmarshal operations. This provided a centralized CAN message base for all of the teams to use so that there was consistency throughout the project.

  • The DBC file :
 VERSION ""
  
 
 NS_ : 
 	NS_DESC_
 	CM_
 	BA_DEF_
 	BA_
 	VAL_
 	CAT_DEF_
 	CAT_
 	FILTER
 	BA_DEF_DEF_
 	EV_DATA_
 	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 MASTER MOTOR GPS ANDROID
 
 BO_ 100 HEARTBEAT: 1 MASTER
  SG_ MASTER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR
 
 BO_ 600 INFO_SONARS: 4 SENSOR
  SG_ SENSOR_INFO_SONARS_left : 0|8@1+ (1,0) [0|255] "inch" MASTER
  SG_ SENSOR_INFO_SONARS_middle : 8|8@1+ (1,0) [0|255] "inch" MASTER
  SG_ SENSOR_INFO_SONARS_right : 16|8@1+ (1,0) [0|255] "inch" MASTER
  SG_ SENSOR_INFO_SONARS_rear : 24|8@1+ (1,0) [0|255] "inch" MASTER
 
 BO_ 604 MOTOR_CMD: 2 MASTER
  SG_ MASTER_MOTOR_CMD_steer : 0|8@1+ (1,0) [0|20] "" MOTOR
  SG_ MASTER_MOTOR_CMD_drive : 8|8@1+ (1,0) [0|20] "" MOTOR
 
 BO_ 700 STOP_GO_CMD: 1 ANDROID
  SG_ ANDROID_STOP_CMD_signal : 0|8@1+ (1,0) [0|0] "" MASTER,GPS
 
 BO_ 708 INFO_CHECKPOINTS: 1 ANDROID
  SG_ ANDROID_INFO_CHECKPOINTS_count : 0|8@1+ (1,0) [0|255] "" MASTER,GPS 
 
 BO_ 712 INFO_COORDINATES: 8 ANDROID
  SG_ GPS_INFO_COORDINATES_lat : 0|32@1+ (0.00001,0) [0|0] "" MASTER,GPS
  SG_ GPS_INFO_COORDINATES_long : 32|32@1+ (0.00001,0) [0|0] "" MASTER,GPS
 
 BO_ 716 INFO_HEADING: 4 GPS
  SG_ GPS_INFO_HEADING_current : 0|16@1- (1,0) [0|0] "" MASTER
  SG_ GPS_INFO_HEADING_dst : 16|16@1- (1,0) [0|0] "" MASTER
 
 BO_ 720 DESTINATION_REACHED: 1 GPS
  SG_ GPS_DESTINATION_REACHED_signal : 0|8@1+ (1,0) [0|0] "" MASTER,ANDROID
 
 CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one";
 CM_ BU_ MASTER "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_ BU_ ANDROID "The android controller of the car";
 CM_ BO_ 100 "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_ 100 1000;
 BA_ "GenMsgCycleTime" BO_ 200 100;
 BA_ "GenMsgCycleTime" BO_ 300 100;
 BA_ "FieldType" SG_ 100 MASTER_HEARTBEAT_cmd "MASTER_HEARTBEAT_cmd" 
 BA_ "FieldType" SG_ 604 MASTER_MOTOR_CMD_drive "MASTER_MOTOR_CMD_drive"
 BA_ "FieldType" SG_ 604 MASTER_MOTOR_CMD_steer "MASTER_MOTOR_CMD_steer"
 
 VAL_ 100 MASTER_HEARTBEAT_cmd 0 "MASTER_HEARTBEAT_cmd_NOOP" 1 "MASTER_HEARTBEAT_cmd_SYNC" 2 "MASTER_HEARTBEAT_cmd_REBOOT" ;
 VAL_ 604 MASTER_MOTOR_CMD_drive 4 "MASTER_MOTOR_CMD_drive_FAST" 3 "MASTER_MOTOR_CMD_drive_MEDIUM" 2 "MASTER_MOTOR_CMD_drive_SLOW" 1 "MASTER_MOTOR_CMD_drive_REVERSE" 0 "MASTER_MOTOR_CMD_drive_STOP" ;
 VAL_ 604 MASTER_MOTOR_CMD_steer 4 "MASTER_MOTOR_CMD_steer_HARD_RIGHT" 3 "MASTER_MOTOR_CMD_steer_SOFT_RIGHT" 2 "MASTER_MOTOR_CMD_steer_STRAIGHT" 1 "MASTER_MOTOR_CMD_steer_SOFT_LEFT" 0 "MASTER_MOTOR_CMD_steer_HARD_LEFT"   ;

Git Submodule Add-on

To increase productivity and be more organized through the life-cycle of this project our team implemented and used a git submodule. A git submodule is a separate Git repository, which is a subdirectory of our entire main Git repository. What this does is lets us clone another repository within our project and keep commit history of this submodule separate from the separated projects. The Git submodule allowed a central repository to be used for common code such as the DBC file, python parser, and other source/header files we shared. Every team had a separate branch they were working off of the master branch so there was no way for us to share common code. The submodule made code portable to all teams instead of manually making chances when necessary. For example, if 1 team made a change to a file, then the other 4 teams already have the recent change without having to manually update. The update is automatic to everyone who has the Git submodule set up.

  • To set up a git submodule you can perform the following instructions:
    • Create your separate repository on GitLab.com or GitHub.com, whichever Git repository you prefer to use.
    • Execute : git submodule add ssh_url relative_path_to_new_dir
    • Execute : git status
    • Notice a new change to be commited. There should be a .gitmodule created. This contains details supplied about the new submodule.
    • Execute : git submodule init
    • Execute : git submodule update
  • To use the git submodule you just 'cd' into the directory where the git submodule repo is located, and treat it as an independent Git project. There is a master branch you can checkout and pull from to pull-in the most recent changes. Make commits and push like you would to any other Git project. When there are changes made to this Git submodule then there will be new changes shown in the top project directory. You will want to add this change to your next commit so that your top project points to the correct Git submodule commit number.

Master Controller

Master Controller

  • Marvin Flores
  • Hassan Naveed

Master Controller Team Schedule

Sl. No Start Date End Date Task Status Actual Completion Date
1 10/6/2015 10/13/2015 propose CAN message IDs, data length, and priorities. testing communication between the other boards via CAN bus Complete 10/19/2015
2 10/13/2015 10/20/2015 Process motor and Sensor data. Vehicle should be able to run and stop based on the sensor readings. Complete 11/03/2015
3 10/20/2015 10/27/2015 Process heading data and sends appropriate message to the motor/LCD team. Complete 12/14/2015
4 10/27/2015 11/10/2015 Overall CAN bus system implementation. all boards should be able to communicate properly. Master should be able to send/receive message to/from any module(board.) The master should be able to process the messages accordingly. Complete 12/07/2015
5 11/10/2015 11/17/2015 Testing/debugging part 1. Master should be able to receive commands from the Android team and be able execute these commands properly. The master should be able to send commands to the other boards. The vehicle should be running and avoiding obstacles. Complete 12/16/2015
6 11/17/2015 11/24/2015 Testing/debugging part 2. Master should be able to request GPS coordinates information from the GPS team and be able to make the car move from origin point to the target point. N/A (This task was reassigned to the GPS team) 12/16/2015
7 11/24/2015 12/01/2015 Testing/debugging part 3, Finalizing the project. All messages, commands, and requests are handled accordingly. The vehicle should be avoiding obstacles, and is able to go to the target location. Complete 12/16/2015

Hardware Design

For the master controller, hardware part essentially covers setting up the CAN bus. The master controller communicates with all other controllers on board i.e the motor, android, GPS, compass and sensors. The bus was set up using five SN65HVD233-HT 3.3-V CAN transceiver chips to send and receive CAN messages from the master controller.

File:Cmpe243 F15 Undergrads System--
Sensor minimum block values

Hardware Interface

The RD1 (pin 0.0) and TD1 (pin 0.1) on the SJ ONE board are connected to the CAN RECEIVE data output and CAN TRANSMIT data input pins on the CAN transceiver. A 120 ohm resistor is attached as a termination resistor between CANH and CANL pins of the two transceivers. This ensures that a transmitting node does not get its own reflection. For the software part, we configured the CAN bus using the FULL CAN mode. The main advantage of using the FULL CAN is that the processor does not have to parse the incoming message and messages go inside designated mail boxes. To initialize the CAN bus in FULL CAN mode, we set its baud rate to be 100kbps, the receive and send queue size to be 50 and pass an array of accepted message IDs and its size as parameters to the following function which initializes the CAN BUS.

bool iCAN_init_FULLCAN(uint32_t * std_list_arr, size_t arraySize);

The function returns true if the bus is initialized successfully and all the message IDs are added to the acceptance filter.

These messages can then be read using a pointer to the message mailbox as the first parameter and the dbc decode function as the second parameter to the following function:

iCAN_rx(can_fullcan_msg_t *msg, msg_hdr_t *msg_hdr);

For sending, after the DBC file encodes the message, we can transmit it over the CAN bus using the transmit function. First parameter is a pointer to the can_msg_t message and the second is the pointer to the message header generated by dbc parser.

bool iCAN_tx(can_msg_t *msg, msg_hdr_t *msg_hdr);

Software Design

Motor Control Logic

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.

The software design is based on layered architecture. There are a total of three layers and they are listed below:

  • Communication layer - responsible for receiving CAN messages
  • Data layer - responsible for extracting or encoding the data from CAN messages
  • Control layer - responsible for making decisions based on data processing and controlling the overall behavior of the car.

All layers are being done in the 100Hz task. First, the Communication layer handles all the incoming messages sent to the MASTER CONTROLLER (i.e. Heading values, STOP/GO Signal, Sensor values, and Destination reached signal). All values are saved in their respective global variables.

Next, The data layer parses the values in the following order:

1.) Check whether we have a STOP/GO signal or Destination reached signal.

2.) Parse the sensor values; comparing them to their minimum block values.

3.) Generate motor commands based on the parsed sensor values if the car is about to hit an object.

4.) Parse the destination and current heading sent by the GPS controller and set car steering direction accordingly.

5.) Send motor commands.

The idea is to run everything in one pass (within the 100Hz task) for logic simplicity. The image above shows the high level view of our driving logic based on the sensor and heading values. The Image below shows the minimum block values of the sensors. When one of the sensors reads a value lower than its minimum block value, appropriate action is taken.

Sensor minimum block values

The GPS controller keeps on sending the next checkpoint to the master each time it reaches the current one. After the master receives and reaches the final checkpoint, the GPS controller sets a flag final_destination_reached and the master responds by resetting the GO signal and commanding the motors to stop.

Motor I/O Controller

Motor/LCD Controller

  • Hector Prado-Guerrero
  • Jashan Singh

Motor control/LCD Team Schedule

Sl. No Start Date End Date Task Status Actual Completion Date
1 10/06/15 10/13/15 Write and test drivers for the brushless motor In progress 10/**/15
2 10/13/15 10/20/15 Write and test drivers for the LCD Incomplete 10/**/15
3 10/20/15 10/27/15 Interface motor to the rest of the software and get moving under power Incomplete 10/**/15
4 10/27/15 11/03/15 Interface LCD to accept and display CAN messages Incomplete 11/**/15
5 11/03/15 11/10/15 Debugging week 1 Incomplete 11/**/15

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

The Android program was written with the Android SDK. The program uses one Activity and three fragments under that Activity (as seen in the Visio diagram). The Activity is the base of the program, and it manages the three fragments in it using a FragmentTransaction and FragmentManager class. There is another layout in the Activity's layout that is specifically made as a fragment container. The Activity features three buttons at the bottom of the screen. Each button with show a fragment. All fragments are constantly running, and the Activity simply hides fragments from the user when the user clicks on a button in the bottom menu. Fragments communicate with each other by using the Activity as a middle man. Information from Fragment A can pass its information to Fragment B by first going through Activity.

Google Maps was inserted into the Maps Fragment. An API key was needed in order for Google Maps to work on the phone. An open source API was used to get the directions and and coordinates of the start and end position. A LatLng list array was inserted to the API to get the list of coordinates. After choosing a point, the "SET" button should be pressed, and the array will be transmitted through bluetooth. The Maps Fragment features buttons that allow operation of the vehicle. These buttons will transmit data to the SJOne board through Bluetooth.

The Bluetooth API was used to send data to and from the Android and SJOne board. When transmitting data from Android to SJOne, a terminal command is used on the SJOne board side to receive data. This is done by using the UART2 ports of the board, and connecting it with a Bluetooth transceiver.

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

Sensor Controller

Sensor Controller & Finances

  • Arlen Eskandari
  • Onyema Ude

Sensor Controller Team Schedule

Sl. No Start Date End Date Task Status Actual Completion Date
1 10/7/2015 10/14/2015 Ordering the sensors and studying the sensor's datasheet Complete 10/17/2015
2 10/14/2015 10/30/2015 Reading Sensor's data and preparing it to be sent over the CAN bus Complete 10/17/2015
3 10/30/2015 11/7/2015 Normalizing sensor data values and sending it to the Master through CAN bus Complete 11/09/2015
4 10/24/2015 10/30/2015 Implementation with multiple sensors Complete 11/09/2015
5 10/30/2015 11/24/2015 Sending multiple sensor data to the master through CAN bus Complete 11/09/2015
6 10/24/2015 11/25/2015 Optimizing the code 12/12/2015
7 12/01/2015 12/17/2015 Collaborating with other teams and updating the code as needed 12/16/2015

Hardware Design

4 LV-MaxSonar sensors are used for the project, they are used for obstacle detection and avoidance. These sensors are able to detect obstacles 0 – 254 inches, though objects 6 inches or closer are simply registered as 6 inches. Sensors are powered with 5Volts (3.3Volts option is also available). Each reading takes 50ms, and each sensor is enabled at a time using the RX pin on the sensor to avoid crosstalk. Three sensors are placed in front of the car (Left , Middle, Right) and one at the back. The image below shows the wired connections between sensors and SJOne board.

Sensor Hardware Design

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

In this project the PWM option of the sonar sensor is used to measure the distance. To have the sensor to range, 250ms after the power up the sensors are ready to take their first measurement, the very first measurement take 98ms (49ms for initial calibration) and the consecutive measurements take 49ms each.

The software start measuring from in order of Left, middle, right, and rear sensors. To measure the PW pin of the sensor (which is connected to a dedicated GPIO pin separately for each sensor) is held high for 50ms (49ms is the minimum), at the moment the software saves the system clock uptime in a variable "trig_time". As soon as sensor is enabled, it sends out an ultrasonic burst, after the burst is bounced back from an obstacle and at the moment when the sensor receives the bounced back burst the "PW" pin of the sensor which is connected to an "interrupt enabled" (falling edge enabled) GPIO pin is pulled low. The moment the Interrupt enabled GPIO pin goes low, the interrupt service routine goes to "calculate_dist" function to calculate the distance by first subtracting the current system uptime from trig_time which was saved before; the dividing it by 174 (given by datasheet) to measure the distance in inches.

After the left sensor finished its measurement, the RX pin on the left sensor is pulled low to disable the sensor, then the RX pin of the middle sensor is pulled high to enable the sensor (at this moment all other sensors are disabled except the middle one to eliminate crosstalk. Then after enabling the middle sensor all the ranging procedure is identical to the one explained above. For the right, and rear sensors the same procedure is repeated all over.

void Range_left(void) { 

   Left_en.setHigh(); // enable Ranging   (enable left sonar)
   delay_us(21); //hold high  >20uS to enable ranging
   Left_trig_time = sys_get_uptime_us(); //get timer at the moment ranging starts
   Left_en.setLow(); // disable ranging of left sonar

} void Range(){ 

   Range_left();
   delay_ms(50);
   Range_middle();
   delay_ms(50);
   Range_right();
   delay_ms(50);
   Range_rear();
   delay_ms(50);
   CAN_send();
   test();

}

Bluetooth/Bridge Controller

Bridge/Android Controller

  • Phil Tran
  • Shangming Wang

Android/Bluetooth Team Schedule

Sl. No Start Date End Date Task Status Actual Completion Date
1 10/6/2015 10/15/2015 Familiarize ourselves with the Android SDK and Java and Google Maps API Complete 10/15/2015
2 10/6/2015 10/30/2015 Have a working menu. Complete 10/30/2015
3 10/10/2015 10/30/2015 Have the phone communicating with the SJOne board using Bluetooth Bee (UART). Complete 11/10/2015
4 10/16/2015 11/10/2015 Relay CAN Bus messages/tasks. Complete 12/10/15
5 10/18/2015 11/15/2015 Be able to input GPS coordinates and have a working map available. Complete 10/30/2015
6 10/25/2015 11/20/2015 Start and stop commands should be up and running. Test with GPS. Complete 11/05/2015
7 11/15/2015 12/01/2015 Extensive testing of the application and its bridge Incomplete

Hardware Design

The Bridge communication hardware design is very simple. A BTBEE Pro Bluetooth XBee socket chip is connected to the SJOne board. UART2 port on the SJOne board is used. UART2 Rx and Tx from the pins on the board are connected to the CAN Bus, which is then connected onto the CAN wires.

Android Hardware Design

Hardware Interface

Overall, the interface between Android and the SJOne board is simple. The Bluetooth module (BTBee Pro) is connected to XBEE port on the SJOne board. The UART2 switch is flipped so that the BTBee could accept UART2 line information. The Android writes to the BTBee at 115200 bps. The BTBee then sends the information to the SJOne board through UART2 through a command line. The data is then encoded to fit the CAN bus. Any other CAN transceiver can listen to the message it sends.

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

The Android program was written with the Android SDK. The program uses one Activity and three fragments under that Activity (as seen in the Visio diagram). The Activity is the base of the program, and it manages the three fragments in it using a FragmentTransaction and FragmentManager class. There is another layout in the Activity's layout that is specifically made as a fragment container. The Activity features three buttons at the bottom of the screen. Each button with show a fragment. All fragments are constantly running, and the Activity simply hides fragments from the user when the user clicks on a button in the bottom menu. Fragments communicate with each other by using the Activity as a middle man. Information from Fragment A can pass its information to Fragment B by first going through Activity.

Fragment Layout under Activity
Fragment Layout under Activity

Google Maps was inserted into the Maps Fragment. An API key was needed in order for Google Maps to work on the phone. An open source API was used to get the directions and and coordinates of the start and end position. A LatLng list array was inserted to the API to get the list of coordinates. After choosing a point, the "SET" button should be pressed, and the array will be transmitted through bluetooth. The Maps Fragment features buttons that allow operation of the vehicle. These buttons will transmit data to the SJOne board through Bluetooth. All data from Android must first be converted to string and then converted to a byte array in order to be sent over Bluetooth

The Bluetooth API was used to send data to and from the Android and SJOne board. When transmitting data from Android to SJOne, a terminal command is used on the SJOne board side to receive data. This is done by using the UART2 ports of the board, and connecting it with a Bluetooth transceiver.

The Bluetooth communication is sent using the write function on Android. Each write function takes a command that the terminal command one the SJOne board will receive. At every command, an action happens. Every command takes a format:

Android Commands to SJOne Board
Command Format Function
bluetooth GO Send go signal to master.
bluetooth STOP Send stop signal to master.
bluetooth RESET Reset all points. Reset coordinates counter and total size of array.
bluetooth read [latitude] [longitude] Read the points in latitude_longitude format where '_' is a space.
bluetooth endread This is a signal that happens after read is done. Sends flag to periodic scheduler to send coordinates.

On the SJOne board side, all the operations on the CAN bus happen on the 100Hz Periodic Callback. The flags dictate the flow of transmission of checkpoints. Only when the flags are true will transmission happen. The GO and STOP commands are also set by flags.

Geographical Controller

The Geographical Controller is responsible for providing the location of the car and heading direction to the master controller. It receives the way-points from the Bridge Controller and calculates the distance to the final destination. The Master Controller is still responsible for controlling the logic of forward, backward, left, and right to reach the final destination.

GPS Controller

  • Calvin Lai
  • Jonathon Hongpananon

GPS Controller Team Schedule

Sl. No Start Date End Date Task Status Actual Completion Date
1 09/29/2015 10/06/2015 Order Adafruit Compass and GPS and solder header pins Complete 10/05/2015
2 10/06/2015 10/13/2015 Connect and get minimum UART connection working and interface compass via I2C Complete 10/20/2015
3 10/13/2015 10/20/2015 Design GPS task to parse data and get compass heading info Complete 10/27/2015
4 10/20/2015 10/27/2015 Integrate GPS, SJSU board, and CAN rx/tx task Complete 11/03/2015
5 10/27/2015 11/3/2015 Test Communication with Master Controller and determine final heading using GPS and compass Complete 11/10/2015
6 11/03/2015 11/10/2015 Test and debug (if there are any errors/corner cases) Complete 11/17/2015
7 11/10/2015 11/17/2015 Optimize the code and testing for stability and report. Complete 11/25/2015


Hardware Design

The figure below illustrates the high-level design for the Geographical Controller. The Geographical controller uses an Adafruit GPS Breakout and an Adafruit 10 Degrees Of Freedom (DOF) IMU Breakout. The Adafruit GPS breakout is a GPS module with a 10Hz update rate with a low current draw, which makes this an excellent device for low power consumption. The Adafruit 10-DOF IMU Breakout contains an accelerometer, gyroscope, magnetometer, barometer, and temperature sensor; however, only the magnetometer was used to calculate the heading direction.

Geographical Hardware Design

Hardware Interface

Geographical Controller Pin Interface Table
Device Port Source Port Destination Device
SJ One 3v3 Vin Adafruit GPS
SJ One GND GND Adafruit GPS
SJ One TXD2 RX Adafruit GPS
SJ One RXD2 TX Adafruit GPS
SJ One 3v3 Vin LSM303DLHC (Adafruit Compass)
SJ One GND GND LSM303DLHC (Adafruit Compass)
SJ One P0[0] (SDA) SDA LSM303DLHC (Adafruit Compass)
SJ One P0[1] (SCL) SCL LSM303DLHC (Adafruit Compass)

Software Design

GPS Data Format

The following table below shows the type of information that is retrieved from the Adafruit GPS chip. When interfaced with the GPS via UART, the string that is received is in the format

$GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh.

The Geographical Controller is responsible for parsing this information and handling the data appropriately.

GPGGA Format
Name Example Data Description
Sentence Identifier $GPGGA Global Positioning System Fix Data
Time 170834 17:08:34 Z
Latitude 4124.8963, N 41d 24.8963' N or 41d 24' 54" N
Longitude 08151.6838, W 81d 51.6838' W or 81d 51' 41" W
Fix Quality 1 Data is from a GPS fix
# of Satellites 05 5 Satellites are in view
Horizontal Dilution of Precision 1.5 Relative accuracy of horizontal position
Altitude 170834 280.2 meters above mean sea level
Height of geoid above WGS84 ellipsoid -34.0, M -34.0 meters
Time since last DGPS update blank No last update
GGPS reference station id blank No station id
Checksum *75 Used by program to check for transmission errors

After parsing the NMEA string, the correct heading must be calculated to help orient the car in the correct direction. When the correct heading is calculated, the current and correct heading are both sent in a single CAN message to the master controller.

Tasks

Geographical Controller Tasks
Task Name Purpose
Periodic 1Hz Callback Periodic heartbeat
Periodic 10Hz Callback Calculate and save current heading (10Hz because the GPS is limited to 10Hz refresh rate)
Periodic 100Hz Callback Receive checkpoints from Android Controller and send current heading to Master Controller

Algorithms Used

Finding the correct heading between two geographical coordinates.
 correctHeading = atan2(dy, dx) * 180 / pi; (where dy and dx are the delta of latitude and longitude)
Finding the distance between two geographical coordinates.
  dist = sin(degreeToRadian(lat1)) * sin(degreeToRadian(lat2)) + cos(degreeToRadian(lat1)) * cos(degreeToRadian(lat2)) * cos(degreeToRadian(theta));
  dist = acos(dist);
  dist = radianToDegree(dist);
  dist = dist * 60 * 1.1515 * 1.609344;

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.

Include sub-sections that list out a problem and solution, such as:

Problems Encountered

# Module Issue Resolution Impact
1 Master data storage/usage (e.g. sensor readings, heading values, etc.) take the simplest approach, use global variables and label them appropriately; make sure to check whether mutex or access protection is needed. Put everything in 100Hz first before optimizing your code. Medium
2 Master Driving logic Draw diagrams on paper first. Choose the simplest implementation and avoid unnecessary if statements; test as soon as possible by creating simulations. Create different 'MODES' to test the sensor logic and gps logic independently, before testing both at the same time. High
3 Master Receiving/Sending CAN messages After testing your logic via simulation, TEST your CAN messages ASAP! structure your messages properly and try to implement DBC parser as soon as possible. High
4 Master Monitor data Use telemetry instead of printf statements. Low

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

References

Acknowledgement

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

References Used

List any references used in project.

Appendix

You can list the references you used.

Retrieved from "http://socialledge.com/sjsu/index.php?title=F15:_Undergrads%2B%2B&oldid=21259"