Difference between revisions of "F15: Undergrads++"

Revision as of 05:17, 6 December 2015

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

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 Wong

Parts List & Cost

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.

CAN Message ID Table

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

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

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.

Motor I/O Controller

Motor/LCD Controller

• Hector Prado-Guerrero
• Jashan Singh

Motor control/LCD Team Schedule

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

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

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

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.

Bluetooth/Bridge Controller

Bridge/Android Controller

• Phil Tran
• Shangming Wong

Android/Bluetooth Team Schedule

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

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.

Geographical Controller

GPS Controller

• Calvin Lai
• Jonathon Hongpananon

GPS Controller Team Schedule

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

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.

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

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

• Sourceforge Source Code Link
• GitLab Source Code Link
• Git Submodule Source Code Link

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.