Difference between revisions of "F16: Kasper"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Schedule)
(Undo revision 40909 by Proj user5 (talk))
 
(917 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
The project aims at developing a self driving car using the CAN protocol.<br>
 +
This report discusses in detail the various tasks involved in the development of the car and challenges faced.
  
−
== Project Title ==
+
[[File:CmpE243 F16 Kasper Sensor Frontview.jpeg|center|700px|thumb|Kasper]]
−
=== Self Driving Car ===
 
  
 
== Abstract ==
 
== Abstract ==
−
This project implements a self-driving car.
+
 
 +
We are in an era of smart machines. With the self driving cars taking
 +
over the roads these days, it is an interesting challenge to build our
 +
own version of it.<br>
 +
This project aims at the implementation of such a self-driving car.<br>
 +
 
 +
This self-driving RC car is based on CAN communication protocol which has been proven to be robust and deterministic
 +
by the automotive industry. The controller used is the SJ-One Board.<br>
 +
 
 +
The overall driving of the car is divided across five modules:<br>
 +
'''Sensor:''' The sensor module essentially checks for obstacles in the driving path.<br>
 +
'''MotorIO:''' MotorIO drives the car using the underlying DC motor and Servo. LCD displays important information such sensor readings and GPS coordinates.<br>
 +
'''Geo:''' Geo controller is responsible for obtaining the location details and aid navigation.<br>
 +
'''Bridge:''' Bridge controller interfaces with the Android application where the path to be traversed is selected.<br>
 +
'''Master:''' Master co-ordinates the data from each of the modules and drives the MotorIO.<br>
 +
 
 +
With all these implementations in place, the car will be able to drive itself to the destination.
 +
 
 +
[[File:CmpE243 F16 Kasper Sensor Sideview.jpeg|left|400px|thumb|Car Sideview]]
 +
[[File:CmpE243 F16 Kasper Car top123.jpeg|center|400px|thumb|Car Topview]]
 +
[[File:CmpE243 F16 Kasper Sensor Backview.jpeg|left| 400px|thumb|Car Backview]]
 +
[[File:CmpE243 F16 Kasper Car Covered.jpeg|center|400px|thumb|Kasper Car]]
 +
<br>
  
 
== Objectives & Introduction ==
 
== Objectives & Introduction ==
−
Objective of this project is to create a self driving car
 
  
−
=== Team Members & Responsibilities ===
+
The objective of this project is to build a self-driving car based on CAN protocol.
 +
 
 +
The self-driving car is intended to accomplish the following:
 +
* The car is controlled via the Bluetooth application which is responsible for providing commands related to Start, Stop and Navigation Path of the car.
 +
* The destination to be reached and the route to take in order to reach the destination are selected on the map using the Application.
 +
* The checkpoints selected on the map are sent to the Bluetooth controller which is in turn sent to the Master Controller.
 +
* The Master Controller is responsible for updating Geo Controller with the checkpoints as and when the car navigates.
 +
* The Geo Controller provides the direction data which is useful for navigating from the current location to the nearest checkpoint.
 +
* The Sensor Controller is responsible for detecting all the obstacles and providing the relevant obstacle data.
 +
* Based on the Obstacle Avoidance data received from the sensors and the Navigation data received from the Geo Controller, the Master Controller needs provide commands to the Motor Controller to drive the motor towards the intended destination.
 +
 
 +
 
 +
=== System Block Diagram ===
 +
[[File:cmpe243_F16_kasper_system_block_diagram_1.png‎|centre|700px|thumb|System block diagram]]
  
 +
== Team Members & Responsibilities ==
 +
*  Communication Bridge Controller (Application logo):[[File:CmpE243_F16_Kasper_Logo.png|thumb|300px|right|App Logo]]
 
We have used five controllers
 
We have used five controllers
  
−
* [[#Sensor Controller|''Sensor Controller'']]
+
* [[#Sensor Controller|''Sensor Controller'']]  
−
**Shruthi Narayan
+
**[https://www.linkedin.com/in/shruthi-narayan-76824a28 Shruthi Narayan]
−
**Rimjhim Ghosh
+
**[https://www.linkedin.com/in/rimjhim-ghosh-01793560 Rimjhim Ghosh]
 +
**Color coding: <span style="background:#FF00FF"> Text
 
* [[#Motor & I/O Controller|''Motor & I/O Controller'']]
 
* [[#Motor & I/O Controller|''Motor & I/O Controller'']]
−
**Prashant Aithal
+
**[https://www.linkedin.com/in/prashant-aithal-701086a7 Prashant Aithal]
−
**Chethan Keshava
+
**[https://www.linkedin.com/in/chethankeshava Chethan Keshava]
 +
**Color coding: <span style="background:#FFA500"> Text
 
* [[#Geographical Controller|''Geographical Controller'']]
 
* [[#Geographical Controller|''Geographical Controller'']]
−
**Ankit Gandhi
+
**[https://www.linkedin.com/in/ankit-gandhi-a52a981b Ankit Gandhi]
−
**Bharat Khanna
+
**Color coding: <span style="background:#00BFFF"> Text
−
* [[#Central Controller|''Central Controller'']]
+
* [[#Master Controller|''Master Controller'']]
−
**Aajna Karki
+
**[https://www.linkedin.com/in/aajna Aajna Karki]
−
**Spoorthi Shivakumar
+
**[https://www.linkedin.com/in/spoorthims Spoorthi Mysore Shivakumar]
 +
**Color coding: <span style="background:#FFFF00"> Text
 
* [[#Communication Bridge Controller|''Communication Bridge Controller'']]   
 
* [[#Communication Bridge Controller|''Communication Bridge Controller'']]   
−
**Bharat Khanna
+
**[https://www.linkedin.com/in/bharatkhanna1 Bharat Khanna]
−
**Shantanu Vasishtha
+
**[https://www.linkedin.com/in/shantanuvashishtha Shantanu Vasishtha]
 +
**Color coding: <span style="background:#00FF00"> Text
  
−
== Schedule ==
+
== Team Schedule ==
−
Show a simple table or figures that show your scheduled as planned before you started working on the project.  Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals.  The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.
 
−
 
 
−
'''Team Schedule'''
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| SI No.
+
! scope="col"| Sl No.
 
! scope="col"| Start Date  
 
! scope="col"| Start Date  
 
! scope="col"| End Date
 
! scope="col"| End Date
Line 46: Line 84:
 
| 09/27/2016
 
| 09/27/2016
 
|  
 
|  
−
*Dividing the project into smaller tasks.
+
* Divide the project into smaller tasks
−
*Based on the number of tasks allocating each task to a team of two.
+
* Allocate each module to a team of two
 
| Completed
 
| Completed
 
| 09/27/2016
 
| 09/27/2016
Line 53: Line 91:
 
! scope="row"| 2
 
! scope="row"| 2
 
| 09/28/2016
 
| 09/28/2016
−
| 10/4/2016
+
| 10/04/2016
−
|Reading previous reports and plan accordingly for each task.Ordering components based on
 
−
*The power requirement, Preferable if the input voltage is in the range of SJOne output voltage level.
 
−
*Review of the components that give few or no hardware errors.
 
−
*Placement of modules in the car.
 
−
| In Progress
 
 
|  
 
|  
 +
* Study previous reports to get an overall understanding of the project
 +
* Plan the stages of the project so that tasks across modules can be synchronised
 +
* Research on the components and order the same
 +
* Understand the placement of modules in the car
 +
| Complete
 +
| 10/04/2016
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
−
| 10/5/2016
+
| 10/05/2016
 +
| 10/11/2016
 +
|
 +
* Study the hardware specifications of each module and review them for hardware errors
 +
* Study the datasheet for the components and come up with pin diagrams
 +
* Understand the hardware interfacing of each of the modules and test compatibility
 +
* Analyse power requirements
 +
| Completed
 
| 10/11/2016
 
| 10/11/2016
−
|Understanding Hardware design and requirements of each task.
 
−
|In Progress
 
−
|
 
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
 
| 10/12/2016
 
| 10/12/2016
 
| 10/18/2016
 
| 10/18/2016
−
|*Designing project architecture based on the protocol for communication, power requirement and the number of special purpose GPIO on the SjOne board.
+
|
−
*CAN message ID's, priorities, data size and format proposals for all the possible CAN messages on the bus
+
* Analyse the communication required across the controllers.
−
|Upcoming Task
+
* <span style="background:#FFFF00">Design Message IDs based on the priority of the messages and the data to be sent across. </span>
−
|  
+
* <span style="background:#FFFF00">Implement the DBC file compatible with all the controllers. </span>
 +
* <span style="background:#00BFFF"> Interface GPS module with SJOne board. Firmware development and NMEA sentence parsing.</span>
 +
| Completed
 +
| 10/18/2016
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
 
| 10/19/2016
 
| 10/19/2016
−
| 10/25/2016
+
| 11/01/2016
−
| Planning methods of testing individual modules based on communication protocols used.
 
−
| Upcoming Task
 
 
|  
 
|  
 +
* Establish communication across all the CAN controllers over CAN bus based on the DBC file.
 +
* Verify the power-up interactions between Master and the other controllers
 +
* <span style="background:#FF00FF">Check the sensor functionality stand-alone with a minimal driver. </span>
 +
* <span style="background:#FFA500">Interface motor to the SJOne board and check for basic functionality. </span>
 +
* <span style="background:#00BFFF">Interface Compass module with SJOne board. Firmware development and stand-alone testing. </span>
 +
* <span style="background:#00FF00">Work on Bluetooth firmware development to integrate with SJ one board. </span>
 +
| Completed
 +
| 11/01/2016
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
−
| 10/26/2016
+
| style="text-align:center;" colspan="2"|11/01/2016
 +
|
 +
CAN COMMUNICATION DEMO
 +
| Completed
 +
| 11/01/2016
 +
|-
 +
! scope="row"| 7
 +
| 11/01/2016
 +
| 11/07/2016
 +
|
 +
* <span style="background:#FF00FF">Read sensor values and filter the readings. Prepare sensor values to be sent over the CAN bus to the Master controller. </span>
 +
* <span style="background:#FFA500">Integrate LCD and motor. Implement code for all the transactions of motor and LCD over CAN. </span>
 +
* <span style="background:#00BFFF">Calibrate GPS and Compass Module.Develop complete code for GPS and Compass module communication over CAN </span>
 +
* <span style="background:#00FF00">Develop basic Android application to work with the Bluetooth module. Test the communication between SJOne board and Android application over Bluetooth protocol. </span>
 +
* <span style="background:#FFFF00">Design the Obstacle avoidance and start with basic implementation. </span>
 +
| Completed
 +
| 11/01/2016
 +
|-
 +
! scope="row"| 8
 +
| style="text-align:center;" colspan="2"|11/08/2016
 +
|
 +
PROJECT PROTOTYPE DEMO
 +
| Completed
 +
| 11/07/2016
 +
|-
 +
! scope="row"| 9
 
| 11/08/2016
 
| 11/08/2016
−
|*Integrating Sensor modules with SJone board
+
| 11/15/2016
−
*Development of obstacle avoidance algorithm with sensor integration
 
−
*Developing Master for CAN communication
 
−
*Integrating Mobile app with the Controller
 
−
| Upcoming Task
 
 
|  
 
|  
 +
* Test each module individually for accurate functionality based on communication with the Master
 +
* <span style="background:#00FF00">Verify the stringent requirement of Start-up Sync, Periodic heart-beat messages, Stop car through Bluetooth command. </span>
 +
* Integrate all modules with the Master to test the data flow
 +
* <span style="background:#00FF00">Design the way-point algorithm and start with the implementation. </span>
 +
* <span style="background:#FFFF00">Design the Navigation Algorithm and start with the implementation. </span>
 +
| Completed
 +
| 11/08/2016
 
|-
 
|-
−
! scope="row"| 7
+
! scope="row"| 10
−
| 11/9/2016
+
| 11/16/2016
−
| 11/20/2016
+
| 11/29/2016
−
| Testing Individual sensor with Master controller using CAN communication
+
|  
−
| Upcoming Task
+
* <span style="background:#FFA500">Implement motor feedback and IO display. </span>
 +
* <span style="background:#00FF00">Complete the implementation of Android application. </span>
 +
* Interface all the controllers each with additional implemented features
 +
* Verify the rest of the communication over the CAN bus across the five controllers
 +
| Completed
 +
| 11/15/2016
 +
|-
 +
! scope="row"| 11
 +
| style="text-align:center;" colspan="2"| 11/29/2016
 +
|
 +
PROJECT PROTOTYPE DEMO 2
 +
| Completed
 +
| 11/29/2016
 +
|-
 +
! scope="row"| 12
 +
| 11/29/2016
 +
| 12/06/2016
 
|  
 
|  
 +
* Test the accuracy of the data sent from the sensor and the settings to the Motor based on the Obstacle Avoidance Algorithm
 +
* Test the accuracy of check-points from the Bluetooth controller, location data from the Geocontroller sensor and Navigation Algorithm
 +
* Verify the correct response of each module
 +
| Completed
 +
| 12/06/2016
 
|-
 
|-
−
! scope="row"| 8
+
! scope="row"| 13
−
| 11/21/2016
+
| 12/07/2016
−
| 12/05/2016
+
| 12/15/2016
−
| Integrating & Testing after connecting all sensors to the controller
 
−
| Upcoming Task
 
 
|  
 
|  
 +
* Check for tuning or calibration of components if required
 +
* Brainstorm on the test cases
 +
* Complete end-to-end testing for various scenarios and conditions
 +
| Completed
 +
| 12/15/2016
 
|-
 
|-
 +
! scope="row"| 14
 +
| style="text-align:center;" colspan="2"| 12/21/2016
 +
|
 +
FINAL PROJECT DEMO
 +
| Completed
 +
| 12/21/2016 
 +
|-
 +
! scope="row"| 15
 +
|style="text-align:center;" colspan="2"| 12/20/2016
 +
|
 +
PROJECT REPORT SUBMISSION
 +
| Completed
 +
| 12/20/2016 
 
|}
 
|}
  
Line 132: Line 249:
 
! scope="row"| 3
 
! scope="row"| 3
 
| GPS Module
 
| GPS Module
−
| [http://www.rchobbyexplosion.com/DHK_Hunter_4WD_Short_Course_Truck_with_2_4Ghz_p/dhk8135.htm From Preet]
+
| [https://www.adafruit.com/product/746 Adafruit]
 
| 1
 
| 1
 
| 40
 
| 40
Line 147: Line 264:
 
| 1
 
| 1
 
| 24.95
 
| 24.95
 +
|-
 +
! scope="row"| 6
 +
| LCD screen
 +
| [https://www.adafruit.com/product/499 Adafruit]
 +
| 1
 +
| 24.95
 +
|-
 +
! scope="row"| 7
 +
| Ultrasonic sensor
 +
| [https://www.sparkfun.com/products/8504 Sparkfun]
 +
| 1
 +
| 27.95
 +
|-
 +
! scope="row"| 8
 +
| Jumper cable
 +
| [https://www.amazon.com/Kalevel%C2%AE-120pcs-Multicolored-Female-Breadboard/dp/B00M5WLZDW/ Amazon]
 +
| 1
 +
| 9.99
 +
|-
 +
! scope="row"| 9
 +
| DB9 Connector
 +
| [http://www.halted.com/commerce/catalog/product.jsp?product_id=16322&czuid=1477806005100 HSC]
 +
| 1
 +
| 1
 +
|-
 +
! scope="row"| 10
 +
| CAN Transceiver
 +
| [http://www.microchip.com/wwwproducts/en/en010405 Microchip]
 +
| 10
 +
| 10
 +
|}
 +
 +
 +
==CAN Communication==
 +
CAN '''(Controller Area Network)''' also known as '''CAN bus''' is a vehicle bus that is designed to communicate with microcontrollers and other devices to achieve a specific application. It finds great application in the automotive industry. Shown below is CAN frame along with logical and electrical values.
 +
 +
[[File:CmpE243_F16_Kasper_CANFrame.png|center|700px|thumb|CAN Frame]]
 +
<br>
 +
 +
{|
 +
|[[File:CmpE243_F16_Kasper_CAN_2.png|left|280px|thumb|Start-of-frame]]
 +
|[[File:CmpE243_F16_Kasper_CAN_3.png|left|280px|thumb|Arbitration Field]]
 +
|[[File:CmpE243_F16_Kasper_CAN_4.png|center|280px|thumb|Remote Transmission Request (RTR)]]
 +
|[[File:CmpE243_F16_Kasper_CAN_5.png|right|280px|thumb|Data Length Code (DLC)]]
 +
|}
 +
 +
{|
 +
|[[File:CmpE243_F16_Kasper_CAN_6.png|left|280px|thumb|Data Field]]
 +
|[[File:CmpE243_F16_Kasper_CAN_7.png|left|280px|thumb|CRC]]
 +
|[[File:CmpE243_F16_Kasper_CAN_8.png|center|280px|thumb|Acknowledgement]]
 +
|[[File:CmpE243_F16_Kasper_CAN_9.png|right|280px|thumb|End-of-frame (EOF)]]
 +
|}
 +
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Figure No..
 +
! scope="col"| Field Name
 +
! scope="col"| Length (bits)
 +
! scope="col"| Description
 +
|-
 +
! scope="row"| 1
 +
| CAN frame
 +
| -
 +
| CAN frame with 11 identifier bits.
 +
|-
 +
! scope="row"| 2
 +
| Start-of-frame
 +
| 1
 +
| Denotes the start of frame transmission and indicates beginning of message. It starts with dominant logic 0 bit.
 +
|-
 +
! scope="row"| 3
 +
| Arbitration Field
 +
| 11
 +
| This identifies the messages and indicates the message priority.
 +
|-
 +
! scope="row"| 4
 +
| Remote Transmission Request (RTR)
 +
| 1
 +
| Differentiates remote frame from a data frame. Must be dominant (0) for data frames and recessive (1) for remote request frames.
 +
|-
 +
! scope="row"| 5
 +
| Data Length Code (DLC)
 +
| 4
 +
| Number of bytes of data. This field indicates how much data is stored inside.
 +
|-
 +
! scope="row"| 6
 +
| Data Field
 +
| 0-64 (0-8 Bytes)
 +
| Data to be transmitted.
 +
|-
 +
! scope="row"| 7
 +
| CRC
 +
| 16
 +
| This is a 16-bit cyclic redundancy check code along with CRC delimiter.
 +
|-
 +
! scope="row"| 8
 +
| Acknowledgement
 +
| 2
 +
| Acknowledge bits.
 +
|-
 +
! scope="row"| 9
 +
| End-of-frame (EOF)
 +
| 7
 +
| End of frame bits. Msut be all recessive.
 +
|}
 +
 +
=== DBC File Implementation ===
 +
 +
The DBC file used for the project is as below:
 +
 +
VERSION ""
 +
 +
NS_ :
 +
  BA_
 +
  BA_DEF_
 +
  BA_DEF_DEF_
 +
  BA_DEF_DEF_REL_
 +
  BA_DEF_REL_
 +
  BA_DEF_SGTYPE_
 +
  BA_REL_
 +
  BA_SGTYPE_
 +
  BO_TX_BU_
 +
  BU_BO_REL_
 +
  BU_EV_REL_
 +
  BU_SG_REL_
 +
  CAT_
 +
  CAT_DEF_
 +
  CM_
 +
  ENVVAR_DATA_
 +
  EV_DATA_
 +
  FILTER
 +
  NS_DESC_
 +
  SGTYPE_
 +
  SGTYPE_VAL_
 +
  SG_MUL_VAL_
 +
  SIGTYPE_VALTYPE_
 +
  SIG_GROUP_
 +
  SIG_TYPE_REF_
 +
  SIG_VALTYPE_
 +
  VAL_
 +
  VAL_TABLE_
 +
 +
BS_:
 +
 +
BU_: MASTER GEO SENSOR MOTORIO BRIDGE
 +
 +
BO_ 100 STOP_CAR: 1 MASTER
 +
  SG_ STOP_CAR_data : 0|8@1+ (1,0) [0|0] "" BRIDGE,GEO,SENSOR,MOTORIO
 +
 +
BO_ 110 RESET: 1 MASTER
 +
  SG_ RESET_data : 0|8@1+ (1,0) [0|0] "" BRIDGE,GEO,SENSOR,MOTORIO
 +
 +
BO_ 130 STOP_CMD_APP: 1 BRIDGE
 +
  SG_ STOP_CMD_APP_data : 0|8@1+ (1,0) [0|0] "" MASTER
 +
 +
BO_ 140 START_CMD_APP: 1 BRIDGE
 +
  SG_ START_CMD_APP_data : 0|8@1+ (1,0) [0|0] "" MASTER
 +
 +
BO_ 400 SENSOR_SONIC: 4 SENSOR
 +
  SG_ SENSORS_SONIC_front_left : 0|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 +
  SG_ SENSORS_SONIC_front_right : 16|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 +
  SG_ SENSORS_SONIC_front_center : 32|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 +
  SG_ SENSORS_SONIC_back : 48|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 +
 +
BO_ 410 MOTORIO_DIRECTION: 3 MASTER
 +
  SG_ MOTORIO_DIRECTION_speed : 0|8@1+ (1,0) [0|10] "" MOTORIO
 +
  SG_ MOTORIO_DIRECTION_turn : 8|8@1+ (1,-4) [-3|3] "" MOTORIO
 +
  SG_ MOTORIO_DIRECTION_direction : 16|8@1+ (1,0) [0|2] "" MOTORIO
 +
 +
BO_ 420 BRIDGE_TOTAL_CHECKPOINT: 1 BRIDGE
 +
  SG_ BRIDGE_TOTAL_CHECKPOINT_NUMBER : 0|8@1+ (1,0) [0|0] "" MASTER,MOTORIO
 +
 +
BO_ 430 RECEIVE_START_ACK: 1 MASTER
 +
  SG_ RECEIVE_START_ACK_ack : 0|8@1+ (0,0) [0|0] "" BRIDGE
 +
 +
BO_ 440 BLUETOOTH_DATA: 8 BRIDGE
 +
  SG_ BLUETOOTH_DATA_LAT : 0|32@1+ (0.000001,0) [0|0] "" MASTER
 +
  SG_ BLUETOOTH_DATA_LON : 32|32@1+ (0.000001,-127) [0|0] "" MASTER
 +
 +
BO_ 450 NEXT_CHECKPOINT_DATA: 8 MASTER
 +
  SG_ NEXT_CHECKPOINT_DATA_latitude : 0|32@1+ (0.000001,0) [0|0] "" GEO
 +
  SG_ NEXT_CHECKPOINT_DATA_longitude : 32|32@1+ (0.000001,0) [0|0] "" GEO
 +
 +
BO_ 460 COMPASS_DATA: 5 GEO
 +
  SG_ COMPASS_DATA_speed : 0|8@1+ (1,0) [0|0] "" MASTER
 +
  SG_ COMPASS_DATA_heading : 8|16@1+ (1,0) [0|0] "" MASTER
 +
  SG_ COMPASS_DATA_bearing : 24|16@1+ (1,0) [0|0] "" MASTER
 +
 +
BO_ 470 CURRENT_LOCATION_ACK: 1 BRIDGE
 +
  SG_ CURRENT_LOCATION_ACK_ack : 0|8@1+ (1,0) [0|0] "" MASTER,GEO
 +
 +
BO_ 480 GPS_LOCATION: 8 GEO
 +
  SG_ GPS_LOCATION_latitude : 0|32@1+ (0.000001,0) [0|0] "" MASTER,BRIDGE
 +
  SG_ GPS_LOCATION_longitude : 32|32@1+ (0.000001,0) [0|-127] "" MASTER,BRIDGE
 +
 +
BO_ 490 DISTANCE_TO_DESTINATION: 1 GEO
 +
  SG_ DISTANCE_TO_DESTINATION_data : 0|8@1+ (0,0) [0|0] "" MASTER, MOTORIO
 +
 +
BO_ 500 BATTERY_STATUS: 1 SENSOR
 +
  SG_ DISTANCE_TO_DESTINATION_status : 0|8@1+ (0,0) [0|0] "" MASTER, MOTORIO
 +
 +
CM_ BU_ DRIVER "Master Controller";
 +
CM_ BU_ SENSOR "Sensor Controller";
 +
CM_ BU_ MOTORIO "Motor I/O controller";
 +
CM_ BU_ BRIDGE "BRIDGE Controller";
 +
CM_ BU_ GEO "Geo Controller";
 +
CM_ BO_ 2 "Sync message used to synchronize the controllers";
 +
 +
BA_DEF_ "BusType" STRING ;
 +
BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
 +
BA_DEF_ SG_ "FieldType" STRING;
 +
 +
BA_DEF_DEF_ "BusType" "CAN";
 +
BA_DEF_DEF_ "FieldType" "";
 +
BA_DEF_DEF_ "GenMsgCycleTime" 0;
 +
 +
BA_ "GenMsgCycleTime" BO_ 400           10;
 +
BA_ "GenMsgCycleTime" BO_ 410            10;       
 +
BA_ "GenMsgCycleTime" BO_ 450            10;
 +
BA_ "GenMsgCycleTime" BO_ 460            10;
 +
BA_ "GenMsgCycleTime" BO_ 470            10;
 +
BA_ "GenMsgCycleTime" BO_ 480            10;
 +
 +
=== PCAN Dongle and BUS Master ===
 +
[[File:CmpE243 F16 Kasper PCAN Dongle.jpeg‎|centre|400px|thumb|PCAN Dongle]]
 +
[[File:CmpE243 F16 Kasper BUS Master.jpeg‎|centre|800px|thumb|BUS MASTER]]
 +
 +
The DB9 connector is interfaced to the CAN bus. Using this interface, we can monitor the CAN bus through a tool called ''BusMaster''. ''PCAN Dongle'' is used to view the CAN messages on the CAN Bus on the GUI. This has helped us in debugging CAN related errors on all the 5 controllers.
 +
 +
=== Can Transceiver ===
 +
 +
{|
 +
|[[File:CmpE243 F16 Kasper CAN2551.jpg|left|200px|thumb|CAN Transceiver]]
 +
|[[File:CmpE243 F16 Kasper CAN Trans.jpg|right|200px|thumb|CAN Transceiver Pins]]
 +
|}
 +
<br>
 +
{|
 +
|[[File:CmpE243 F16 Kasper Mcp2551 pinout.PNG|left|500px|thumb|MCP2551 Pinout]]
 
|}
 
|}
  
Line 155: Line 510:
  
 
=== Schedule ===
 
=== Schedule ===
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SI No.
 +
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 +
|-
 +
! scope="row"| 1
 +
| 10/5/2016
 +
| 10/11/2016
 +
|
 +
* Research and order the sensors
 +
| Completed
 +
| 10/9/2016
 +
|-
 +
! scope="row"| 2
 +
| 10/12/2016
 +
| 10/18/2016
 +
|
 +
* Study data sheets and identify pins
 +
* Prepare hardware connection diagram with SJOne Board
 +
| Completed
 +
| 10/18/2016
 +
|-
 +
! scope="row"| 3
 +
| 10/19/2016
 +
| 10/25/2016
 +
|
 +
* Wire the sensors and check with the sample code
 +
* Prepare the sensor DBC file
 +
| Completed
 +
| 10/25/2016
 +
|-
 +
! scope="row"| 4
 +
| 10/26/2016
 +
| 11/1/2016
 +
|
 +
* Interface sensor to SJOne board. Read sensor values and filter the readings
 +
* Prepare sensor values to be sent over CAN bus and test the correctness of sensor CAN messages
 +
| Completed
 +
| 11/1/2016
 +
|-
 +
! scope="row"| 5
 +
| 11/2/2016
 +
| 11/8/2016
 +
|
 +
* Collaborate to achieve basic obstacle avoidance for Project Prototype Demo
 +
| Completed
 +
| 11/8/2016
 +
|-
 +
! scope="row"| 6
 +
| 11/9/2016
 +
| 11/15/2016
 +
|
 +
* Implement and integrate code with multiple sensors
 +
| Completed
 +
| 11/15/2016 
 +
|-
 +
! scope="row"| 7
 +
| 11/16/2016
 +
| 11/22/2016
 +
|
 +
* Test and debug the integrated module
 +
| Completed
 +
| 11/22/2016 
 +
|-
 +
! scope="row"| 8
 +
| 11/23/2016
 +
| 11/29/2016
 +
|
 +
* Collaborate with the other module teams to make sure that the sensors are in working condition for Project Prototype Demo-2
 +
| Completed
 +
| 11/29/2016 
 +
|-
 +
! scope="row"| 9
 +
| 11/30/2016
 +
| 12/6/2016
 +
|
 +
* Test for stability of sensors
 +
| Completed
 +
| 12/5/2016
 +
|-
 +
! scope="row"| 10
 +
| 12/7/2016
 +
| 12/17/2016
 +
|
 +
* Code testing during final phases. Modify code in cooperation with other teams for Final Project Demo
 +
| Completed
 +
| 12/16/2016
 +
|-
 +
|}
 +
 +
=== Hardware Design ===
 +
 +
 +
 +
Four Parallax Ping ultrasonic distance sensors are used in this project for obstacle detection and avoidance.
 +
 +
Non-contact obstacle distance can be measured from about 2 cm (0.8 inches) to 3 meters (3.3 yards).
 +
 +
The PING))) sensor works by transmitting an ultrasonic burst and providing an output pulse that corresponds to the time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.
 +
 +
Four Sensors are mounted on the car.<br>
 +
Three in the front: front_left, front_center, front_right<br>
 +
One at the back: back
 +
 +
This data related to obstacle detection from each of the four sensors is communicated to the Master Controller over the CAN bus.
 +
 +
 +
 +
[[File:CmpE243 F16 Kasper Sensor Ping Blink2.gif|center]]
 +
'''In the above picture, Burst indicator LED blinking shows measurement in progress.'''
 +
 +
 +
 +
The image below shows the wired connections between sensors and SJOne board.
  
−
=== Design & Implementation ===
 
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
−
=== Hardware Design ===
+
[[File:CmpE243 F16 Kasper SensorHardwareFinal.JPEG|center|700px|thumb|Sensor Hardware Interface block diagram]]
−
Discuss your hardware design here.  Show detailed schematics, and the interface here.
 
  
−
=== Hardware Interface ===
+
[[File:CmpE243 F16 Kasper Sensor Mounted.jpeg|center|400px|thumb|Sensors mounted on car]]
−
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 ===
 
=== 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.
+
 
 +
'''Operation Squence:'''
 +
 
 +
[[File:CmpE243 F16 Kasper Sensor flowchart.png|center|700px|thumb|Sensor Operation Flowchart]]
 +
[[File:CmpE243 F16 Kasper Sensor Sequential Ranging.gif|center|900px|thumb|Sensor Sequential Ranging]]
 +
 
 +
'''Software timer for triggering sensor:'''
 +
 
 +
All sensors are triggered using software timers. A soft timer is declared for each sensor which keeps track of the time between trigger and echo for that particular sensor.
 +
 
 +
<pre>
 +
#define Echo_Return_Pulse 18.5
 +
SoftTimer ping_duration_left;
 +
ping_duration_left.reset(Echo_Return_Pulse);
 +
ping_duration_left.restart();
 +
</pre>
 +
 
 +
'''Hardware timer for calculating distance:'''
 +
 
 +
The declaration of hardware timer is as shown below:
 +
 
 +
<pre>
 +
lpc_timer_enable(lpc_timer0,1); /*enable timer0*/
 +
lpc_timer_set_value(lpc_timer0,0); /*set timer0 value=0*/
 +
</pre>
 +
 
 +
'''Distance Calculation:'''
 +
 
 +
Distance=Speed * Time
 +
 
 +
The distance covered by the sound wave is twice the actual distance.
 +
 
 +
Therefore, Distance= (Speed * Time)/2
 +
 
 +
Speed of sound=340m/s, 1m=100cm, 1us=0.000001 s
 +
 
 +
Distance covered in 1us= (340*100*0.000001)/2 = 0.017cm
 +
 
 +
<pre>
 +
#define Distance_Scale 0.017
 +
time_left = lpc_timer_get_value(lpc_timer0);
 +
distance_left = (Distance_Scale)*time_left;
 +
</pre>
 +
 
 +
 
 +
'''Ranging:'''
 +
 
 +
<pre>
 +
LeftSIG.setAsOutput(); /*make SIGpin output*/
 +
LeftSIG.setLow(); /*set low for 2us and then high for clean high*/
 +
delay_us(2);
 +
LeftSIG.setHigh(); /* enable Ranging (enable left sonar). trigger/set high for 2 µs (min), 5 µs typical. Ultrasonic burst*/
 +
delay_us(5);
 +
LeftSIG.setLow(); /*set low*/
 +
LeftSIG.setAsInput(); /*make SIGpin input*/
 +
</pre>
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
+
 
 +
'''Sensor Testing: LV-MaxSonar-EZ(MB1010):'''
 +
 
 +
• This sensor gives a range of 0 inches to 254 inches with a voltage supply of 5V.
 +
 
 +
• Using multiple ultrasonic sensors in a single system caused interference (crosstalk) so the sensors were triggered sequentially which reduced the              fluctuating values
 +
 
 +
• The range reading time of Maxbotix LV-MaxSonar-EZ1 is 49 ms for a range of 254 inches (6.54 m) requirement was to send all sensor values in 10 Hz. Only 2 sensor values could be sent.
 +
 
 +
• Having the requirement to send the sensor readings in 10Hz, we reduced the delay between the sensors to 15ms covering a range of 101 inches. Send values of all the four sensors (left, center, right, back) in 10Hz using chaining process.
 +
 
 +
• Even after this there were frequent abrupt values encountered in the readings so considering the fluctuations and requirement we switched to parallax ping sensors.
 +
 
 +
 
 +
'''Sensor Testing: Parallax Ping '''
 +
 
 +
[[File:CmpE243 F16 Kasper Ping Sensor.jpg|center|300px|thumb|Parallax Ping Sensor-Front View]]
 +
[[File:CmpE243 F16 Kasper Sensor Parallax back.png|center|300px|thumb|Parallax Ping Sensor- Back View]]
 +
 
 +
'''Pin Configuration'''
 +
 
 +
'''Pin1:''' GND- Ground pin
 +
 
 +
'''Pin2:''' 5V- Voltage Supply pin
 +
 
 +
'''Pin3:''' SIG- Signal Pin- This emits a short 40Khz burst acting as a trigger pin then the same pin starts listening the echo.
 +
 
 +
 
 +
'''Ping Sensor Features'''
 +
 
 +
•  Provides precise, non-contact distance measurements within a 2 cm to 3 m range
 +
 
 +
•  Simple pulse in/pulse out communication requires just one I/O pin
 +
 
 +
•  Burst indicator LED shows measurement in progress
 +
 
 +
•  3-pin header makes it easy to connect to a development board, directly or with an extension cable, no soldering required
 +
 
 +
•  The PING))) sensor works by transmitting an ultrasonic (well above human hearing range) burst and providing an output pulse that corresponds to the    time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.
 +
 
 +
[[File:CmpE243 F16 Kasper Sensor Ping Communication.png|center|500px|thumb|Parallax Ping Sensor Coomunication Protocol]]
 +
 
 +
The PING))) sensor detects objects by emitting a short ultrasonic burst and then "listening" for the echo. Under control of a host microcontroller (trigger pulse), the sensor emits a short 40 kHz (ultrasonic) burst. This burst travels through the air, hits an object and then bounces back to the sensor. The PING))) sensor provides an output pulse to the host that will terminate when the echo is detected, hence the width of this pulse corresponds to the distance to the target.
 +
 
 +
[[File:CmpE243 F16 Kasper Ping working.jpg|center|500px|thumb|Working of Parallax Ping Sensor]]
 +
 
 +
'''Ping Sensor Considerations for use:'''
 +
 
 +
The PING))) sensor cannot accurately measure the distance to an object that:
 +
 
 +
* is more than 3 meters away
 +
* that has its reflective surface at a shallow angle so that sound will not be reflected back towards the sensor
 +
* is too small to reflect enough sound back to the sensor
 +
* if the sensor is mounted low on the device, it will detect sound reflecting off of the floor.
 +
 
 +
[[File:CmpE243 F16 Kasper Sensor Ping Ray.jpg|center|500px|thumb|Ping Sensor Object Positioning]]
  
 
=== Testing & Technical Challenges ===
 
=== 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.
+
'''Issue 1:''' '''Triggering of Sensors in Parallel'''
 +
 
 +
Triggering all the sensors in parallel causes interference between adjacent sensors, which in turn causes mis-firing of echo. This results in incorrect distance values from all the sensors.
 +
 
 +
'''Solution:''' '''Sequential triggering of Sensors
 +
'''
 +
Each sensor is triggered only when the previous sensor receives an echo or exceeds the maximum echo reception wait time which is 18.5ms.
 +
 
 +
 
 +
'''Issue 2:''' '''Sensor Angle'''
 +
 
 +
The Left and Right sensors gave faulty values when placed at an acute angle on the corner of the base board.
 +
 
 +
'''Solution:''' '''angle>45'''
 +
 
 +
Increased the angle to cover wider area and avoid reflections. Increasing the angle to more than 45 degrees helped us get accurate values.
  
 
== Motor & I/O Controller ==
 
== Motor & I/O Controller ==
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
−
*''''' Chethan Keshava'''''   
+
*'''''[https://www.linkedin.com/in/chethankeshava Chethan Keshava]'''''   
−
*''''' Prashant Aithal '''''
+
*'''''[https://www.linkedin.com/in/prashant-aithal-701086a7 Prashant Aithal] '''''
  
 
=== Schedule ===
 
=== Schedule ===
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SI No.
 +
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 +
|-
 +
! scope="row"| 1
 +
| 09/27/2016
 +
| 10/04/2016
 +
|
 +
* Finalize project and team schedule and update project wiki
 +
| Completed
 +
| 10/04/2016
 +
|-
 +
! scope="row"| 2
 +
| 10/04/2016
 +
| 10/11/2016
 +
|
 +
* LCD module selection and purchase
 +
| Completed
 +
| 10/07/2016
 +
|-
 +
! scope="row"| 3
 +
| 10/11/2016
 +
| 10/18/2016
 +
|
 +
* Understanding DC and Servo motor and testing the basic functionality
 +
| Completed
 +
| 10/15/2016
 +
|-
 +
! scope="row"| 4
 +
| 10/18/2016
 +
| 10/25/2016
 +
|
 +
* Interfacing motors and test control of motors from the SJOne board
 +
| Completed
 +
| 10/24/2016
 +
|-
 +
! scope="row"| 5
 +
| 10/25/2016
 +
| 11/1/2016
 +
|
 +
* Control the motors using received CAN messages
 +
| Completed
 +
| 11/1/2016
 +
|-
 +
! scope="row"| 6
 +
| 11/1/2016
 +
| 11/15/2016
 +
|
 +
* Discuss with other teams to get simulated inputs from GPS and sensor module and test car control with those inputs. (Testing of obstacle avoidance)
 +
| Completed
 +
| 11/15/2016
 +
|-
 +
! scope="row"| 7
 +
| 11/15/2016
 +
| 11/28/2016
 +
|
 +
* Collaborate with other teams to establish CAN communication between all the modules
 +
| Completed
 +
| 11/28/2016
 +
|-
 +
! scope="row"| 8
 +
| 11/28/2016
 +
| 12/05/2016
 +
|
 +
* Product testing and trial runs
 +
| Completed
 +
| 12/20/2016
 +
|-
 +
|}
 +
 +
 +
 +
=== Pulse Width Modulation ===
 +
[[File:CmpE243 F16 Kasper PWMSignal.png|450px|thumb|Pulse Width Modulation|right]]
 +
Pulse-width modulation (PWM), is a modulation technique which encodes a message into a pulsing signal. Pulse width modulation is a type of digital signal. It is mainly used to control the power supplied to electrical devices such as motors. Pulse width modulation is used in a variety of applications including sophisticated control circuitry. PWM pulse are supplied to the DC and Servo motors in our project. They help in rotating and turning the wheels of the RC car, respectively.
 +
 +
'''Duty Cycle'''
 +
<br>
 +
When the signal is high this is the “ON time”. To describe the amount of “on time” the concept of duty cycle is introduced. Duty cycle is measured in percentages. The percentage duty cycle specifically describes the percentage of time a digital signal is ON over an interval or period of time. This period is the inverse of the frequency of the waveform.
 +
 +
If a digital signal spends half of the time ON and the other half OFF, we would say the digital signal has a duty cycle of 50% and resembles an ideal square wave. If the percentage is higher than 50%, the digital signal spends more time in the high state than the low state and vice versa if the duty cycle is less than 50%.
 +
 +
===Electronic Speed Controller ===
 +
 +
[[File:CmpE243 F16 Kasper P-DHKH111.jpg|thumb|Electronic Speed Controller|right]]
 +
An electronic speed control or ESC is an electronic circuit which is used to vary the electric motor's speed.It also behaves as a dynamic brake. ESCs are used on electrically powered radio controlled cars, essentially providing an electronically generated three-phase electric power low voltage source of energy for the motor.
 +
 +
There are two different types of RC motors, brushed and brushless. Each motor type has its own kind of ESC (Electronic Speed Controller). Without an ESC, the DC motor of the RC car would either not move or it will go at full throttle when the car is driven. Brushed motors are cheap but very ineffecient and lack power. Brushless motors are efficient, powerful, fast, and last much longer. The main visual difference between the two is that the brushless is sealed completely and has three wires, while the brushed has ventilation holes and two wires.
 +
 +
=== Servo Motor ===
 +
[[File:CmpE243 F16 Kasper Battery.jpeg|thumb|right|100px|Battery]]
 +
[[File:CmpE243_F16_Kasper_Servo_PWM.PNG|450px|thumb|Servo PWM Signals|right]]
 +
The RC car came with a digital servo motor. The motor works without ESC. The motor is controlled by giving PWM signal from the SJOne board.
 +
RC Servos are used to convert electrical signal into polar or linear movement. When signal is transmitted from the control to the car, this signal is decoded and sent to a servo. According to this signal, the servo will rotate it's drive shaft by some degrees, and this rotation is translated into wheel steering. The power supply of servos is usually from 3 to 5 volts.
 +
 +
The RC servos are controlled with a PWM signal driven to their signal wire. A PWM signal has three parameters that characterizes it: The first is the amplitude (or peak to peak voltage) of the signal which is around 3 to 5 volts according to it's specifications. The second is the frequency. In PWM, the frequency is usually fixed to a value.The third and most critical value is the positive pulse width of the PWM, i.e. the "duty cycle". The width of the pulse will have a direct result into the drive shaft position.
 +
 +
==== Servo Motor Connections ====
 +
 +
{| class="wikitable"
 +
|-
 +
! align="center"|ESC Wire Pins
 +
! align="center"|SJOne Board Pins
 +
|-
 +
| scope="row" align="center"|Vcc
 +
| scope="row" align="center"|3V3
 +
|-
 +
| scope="row" align="center"|GND
 +
| scope="row" align="center"|GND
 +
|-
 +
| scope="row" align="center"|Turn Control
 +
| scope="row" align="center"|P2.0
 +
|-
 +
|}
 +
 +
Servo motor is controlled with the help of three wires coming out of the servo motor. The wires are VCC, GND and Direction control. The VCC is connected to the 3.3v. GND and direction control are connected to the ground and pwm pins of SJOne board.
 +
<br>
 +
 +
=== DC Motor ===
 +
{|
 +
|[[File:CmpE243 F16 Kasper Hunter motor.jpg|300px|right|top|DC Motor|thumb]]
 +
|}
 +
 +
A DC motor converts direct current electrical power into mechanical power. The most common types rely on the forces produced by magnetic fields.
 +
 +
Pulse width modulation (PWM) is used to  control the motor. One advantage is that the power loss in the switching transistor is small because the transistor is either fully “ON” or fully “OFF”. The RC Car came with the motor that needed 7.4V of power supply to work. The motor has the power to run the car at a maximum speed of 35mph. DC motor is controlled with the help of three wires coming out of the ESC. These wires are VCC, GND and Speed control.
 +
 +
Place the car on a raised platform in such a way that the wheels of the car are not touching any surface. Given below is the code snippet for testing out the dc motors using the on-board switches of the SJ One circuit.
 +
 +
<syntaxhighlight lang="C">
 +
       
 +
        if(SW.getSwitch(1))
 +
{
 +
dc_stop();
 +
}
 +
else if(SW.getSwitch(2))
 +
{
 +
dc_accelerate(6.4);
 +
}
 +
else if(SW.getSwitch(3))
 +
{
 +
dc_accelerate(6.2);
 +
}
 +
else if(SW.getSwitch(4))
 +
{
 +
dc_accelerate(7.6);
 +
}
 +
</syntaxhighlight>
 +
 +
On pressing the on-board switches the wheels of the car would rotate at different speeds.Pressing switch 2 and 3 would make the wheels rotate in he forward direction. The value of the PWM duty cycle can be varied to try out different speeds. Pressing Switch 1 would stop the rotation of the wheel. Switch 4 allows the reversing of the rotation of the wheel. On pressing these switches, either of two functions, shown below are called.
 +
 +
<syntaxhighlight lang="C">
 +
void dc_accelerate(float pwmValue)
 +
{
 +
MotorControl.setDC(pwmValue);
 +
stop_flag = true;
 +
}
 +
 +
void dc_stop(void)
 +
{
 +
if(stop_flag)
 +
{
 +
MotorControl.setDC(DC_STOP);
 +
stop_flag = false;
 +
}
 +
}
 +
</syntaxhighlight>
 +
MotorControl is an object from the MotorController singleton class. The Motorcontroller class has 2 functions-setDC() and setServo(). setDC() is used to drive the car while setServo() is used to control the turning of the car.
 +
 +
[[File:CmpE243_F16_Kasper_DC_PWM.PNG|thumb|right|400px|DC PWM Signals]]
 +
 +
 +
==== DC Motor Connections ====
 +
 +
{| class="wikitable"
 +
|-
 +
! align="center"|ESC Wire Pins
 +
! align="center"|SJOne Board Pins
 +
|-
 +
| scope="row" align="center"|Vcc
 +
| scope="row" align="center"|-
 +
|-
 +
| scope="row" align="center"|GND
 +
| scope="row" align="center"|GND
 +
|-
 +
| scope="row" align="center"|Speed Control
 +
| scope="row" align="center"|P2.1
 +
|-
 +
|}
 +
 +
The VCC line is not used as the required voltage is directly given to the motor through a battery, via ESC. The GND line and Speed control lines are connected to the ground and PWM pin of SJOne board.The DC motor was driven using PWM2 i.e. pin P2.1 of the SJOne board. In-built PWM generation function was used. It requires two parameters, one is pin being used and the other being the frequency.<br>
 +
<br>
 +
 +
 +
 +
<br>
 +
 +
=== Motor/IO Controller Software Design===
 +
 +
==== Tasks ====
 +
{| class="wikitable"
 +
|+ Motor/IO Controller Tasks
 +
|-
 +
! align="center"|Task Name
 +
! align="center"|Purpose
 +
|-
 +
| Period Init
 +
| CAN Bus Initialization, Reset CAN Bus
 +
|-
 +
| Periodic 1Hz Callback
 +
| Check if CAN bus off and Reset bus. Reset the RPM counter. Send data to LCD.
 +
|-
 +
| Periodic 10Hz Callback
 +
| Drive car according to the commands received from Master controller
 +
|-
 +
|}
 +
 +
==== Motor Pin Connections ====
 +
 +
The car runs on Ni-MH batteries. The battery powers the ESC unit, which in turn drives the motor and also powers the steering servo. The  SJ One board, ESC unit and steering servo should share a common ground in order for the PWM signals to have the same reference voltage.
 +
The CAN transceiver uses the 5V power supply and GND, along with the P0.0 (CAN RX) and P0.1 (CAN TX) of the SJ One Board.
 +
P2.0 (PWM1) and P2.1 (PWM2) controls the steering and motor respectively. This is done by sending out PWM signals from the SJ One board  that change the width of a 20ms period waveform. 1ms width represents a 0% duty cycle, 1.5ms width represents a 50% duty cycle, and 2ms width represents a 100% duty cycle.
 +
 +
 +
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Node A Source
 +
! scope="col"| Node A Pin
 +
! scope="col"| Node B Source
 +
! scope="col"| Node B Pin
 +
! scope="col"| Description
 +
|-
 +
| scope="row"| 3.3V Power Supply
 +
| 3.3V
 +
| SJOne Board
 +
| 3V3
 +
| SJOne Power
 +
|-
 +
|-
 +
| scope=row| 3.3V Power Supply
 +
| GND
 +
| SJOne Board
 +
| GND
 +
| SJOne Ground
 +
|-
 +
|-
 +
| scope="row"| CAN Transceiver
 +
| CAN Tx
 +
| SJOne Board
 +
| P0.1 (Tx)
 +
| SJOne - CAN Tx
 +
|-
 +
|-
 +
| scope="row"| CAN Transceiver
 +
| CAN Rx
 +
| SJOne Board
 +
| P0.0 (Rx)
 +
| SJOne - CAN Rx
 +
|-
 +
|-
 +
| scope="row"| CAN Transceiver
 +
| 5V
 +
| 5V Power Supply
 +
| 5V
 +
| SJOne - CAN Power
 +
|-
 +
|-
 +
| scope="row"| CAN Transceiver
 +
| Ground
 +
| 5V Power Supply
 +
| GND
 +
| SJOne - CAN Ground
 +
|-
 +
|-
 +
| scope="row"| CAN Transceiver
 +
| CANL
 +
| CAN BUS
 +
| CANL
 +
| CANL to CAN BUS
 +
|-
 +
|-
 +
| scope="row"| CAN Transceiver
 +
| CANR
 +
| CAN BUS
 +
| CANR
 +
| CANR to CAN BUS
 +
|-
 +
| scope="row"| Steering Servo
 +
| PWM Port
 +
| SJOne Board
 +
| P2.0 PWM
 +
| Steering Control
 +
|-
 +
|-
 +
| scope="row"| Steering Servo
 +
| Ground
 +
| SJOne Board
 +
| GND
 +
| Common ground for reference voltage
 +
|-
 +
|-
 +
| scope="row"| ESC/Motor
 +
| PWM Port
 +
| SJOne Board
 +
| P2.1 PWM
 +
| Motor Control
 +
|-
 +
|-
 +
| scope="row"| ESC/Motor
 +
| Ground
 +
| SJOne Board
 +
| GND
 +
| Common ground for reference voltage
 +
|-
 +
|}
 +
 +
==== Hardware Design ====
 +
[[File:CmpE243 F16 Kasper Motor Block Diagram.jpeg|centre|800px|thumb|Motor Controller Block Diagram]]
 +
 +
==== Software Flow Diagram ====
 +
[[File:CmpE243_F16_Kasper_Motorflowchart.jpg|700px|centre]]<br>
 +
 +
=== Speed Feedback Encoder ===
 +
[[File:CmpE243 F16 Kasper Magnetic_Sensor.jpg|300px|thumb|right|Hall effect Sensor]]<br> 
 +
The speed feedback is simply an RPM meter. It consists of a Hall Effect Magnetic sensor with a set of magnets. The magnets are attached to the inner surface of the wheels and the sensor is connected to the end of the shaft connecting the wheel. Whenever the magnet comes near the sensor, a high signal is generated from the sensor and given to the GPIO port of the SJOne board, which is made as positive edge triggered. The interrupt handler would then increment a count which would give us revolutions per second if the above mentioned count is measured over one second (1Hz periodic callback function).<br>
 +
 +
 +
[[File:CmpE243_F16_Kasper_Hall_sensor_tach.gif|thumb|center]]<br>
 +
[[File:CmpE243 F16 Kasper RPMReal.PNG|800px|centre]]<br>
 +
 +
The next step is to control the speed with this calculated rpm. There are two conditions that need to be checked. One is the speed that the MASTER controller is sending (stop, slow, normal or fast) and another is the rpm. Each of the speeds would have a desired rpm and the calculated rpm is compared to the desired rpm and the final PWM signal to the DC motor is incremented or decremented depending on that. A scenario for this usage would be when the car encounters an upward ramp and the car would slow down while climbing to that. The algorithm would check and sense that the rpm has reduced and would modify PWM for DC to increase power and hence the RPM of car is kept at the desired range.<br>
 +
 +
=== Liquid Crystal Display ===
 +
[[File:CmpE243_F16_Kasper_LCD.PNG|thumb|right|500px]]<br>
 +
 +
IO is the mode of interaction between user and car peripherals. LCD displays the car status while the touch screen allows the user to shift between the various modes.
 +
The touch screen GLCD uLCD32PTU has the following features
 +
Low-cost 3.2" LCD-TFT display graphics user interface solution.
 +
240 x 320 VGA resolution, RGB 65K true to life colours, TFT screen with Integrated 4-Wire Resistive Touch Panel.
 +
Easy 5 pin interface to any host device: VCC, TX, RX, GND, RESET
 +
Powered by 4D-Labs PICASO processor.
 +
2 x Asynchronous hardware serial ports (COM0, COM1), TTL interface, with 300 to 600K baud.
 +
On-board micro-SD memory card adaptor for multimedia storage and data logging purposes. HC memory card support is also available for cards larger than 4GB.
 +
4.0V to 5.5V range operation (single supply).
 +
  
−
=== Design & Implementation ===
+
The LCD is used to display vital parameters such as
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
+
* Speed
 +
*      Sensor Readings
 +
* Obstacle proximity
 +
* GPS co-ordinates
 +
* Current and heading compass zone
  
−
=== Hardware Design ===
+
Shown below are some of the LCD screens created.
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
[[File:CmpE243 F16 Kasper LCD1.jpg|thumb|235px|First words on LCD|left]]
 +
[[File:CmpE243 F16 Kasper LCD3.PNG|thumb|300px|KAPSER Teammates|center]]
 +
[[File:CmpE243 F16 Kasper LCD4.jpg|thumb|300px|Sensor and GPS readings 1|left]]
 +
[[File:CmpE243 F16 Kasper LCD7.jpg|thumb|300px|Sensor and GPS readings 2|center]]
  
−
=== Hardware Interface ===
 
−
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
 
  
−
=== Software Design ===
 
−
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it. 
 
  
−
=== Implementation ===
+
<br>
−
This section includes implementation, but again, not the details, just the high level.  For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
 
  
 
=== Testing & Technical Challenges ===
 
=== 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?
+
'''Issue 1:''' DC motor not responding to PWM signals given to ESC
−
Make a smooth transition to testing section and described what it took to test your project.
+
 
 +
Even though the PWM signals that were generated from the SJOne board were identical to those generated by the company issued remote control of the car (simulated and checked using the CRO), the DC motor was still not responding to the signals.  
 +
 
 +
'''Solution:''' Create the PWM objects just once and never destroy them
 +
 
 +
This solution, obtained after much research online, was implemented using a singleton class which would be used to declare the PWM objects to pass the signal values and would hence declare the PWM objects only one and never be destroyed or re-initialized. It is essential to understand Pulse width Modulation.
 +
 
 +
'''Issue 2:''' Car Reversing on giving Forward Pulse.
 +
 
 +
We observed that initially after turning on the ESC, sometimes the car would go reverse on providing the forward pulse.
 +
 
 +
'''Solution:'''Provide the car a STOP pulse for around 20ms in the Init function of the Periodic scheduler.
 +
 
 +
This solution helps in the calibration of the ESC. Based on the initial pulse received, the ESC is calibrated. Any delay in switching on the ESC and resetting the SJ ONE board, may lead to the Reverse issue. Hence, the ESC had to be switched on simultaneously while resetting the SJ ONE board. This eliminated the unwanted reverse.
 +
 
 +
'''Issue 3:''' Erratic readings while using the Light Sensor for Motor feedback.
 +
 
 +
Initially we used the Light sensor to measure the RPM of the car. This was done by taping a white patch on to the front wheel of the car and the sensor was placed just above the wheel. Light sensor should not be used for Motor Feedback purpose since the Light readings were erratic.
 +
 
 +
'''Solution:'''Use Magnetic Hall Effect sensors.
 +
 
 +
Using the magnetic sensors eliminated the erratic readings. One tricky part is that the sensors need to be mounted really close to the magnets. It is essential to test the car on different terrains and observe if the car is able to move without any difficulty.
  
 
== Geographical Controller ==
 
== Geographical Controller ==
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
−
*''''' Ankit Gandhi '''''
+
*''''' Ankit Gandhi '''''
−
*''''' Bharat Khanna '''''
+
 
 +
GPS, Compass firmware and Hardware Interfacing.
  
 
=== Schedule ===
 
=== Schedule ===
 +
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SI No.
 +
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 +
|-
 +
! scope="row"| 1
 +
| 09/28/2016
 +
| 10/4/2016
 +
|
 +
* Study previous project reports and order GPS and Compass modules
 +
| Complete
 +
| 10/6/2016
 +
|-
 +
! scope="row"| 3
 +
| 10/5/2016
 +
| 10/11/2016
 +
|
 +
* Pin Identification for GPS module on SJOne and connection diagram
 +
* Pin Identification for Compass module on SJOne and connection diagram
 +
| Complete
 +
| 10/10/2016
 +
|-
 +
! scope="row"| 4
 +
| 10/12/2016
 +
| 10/18/2016
 +
|
 +
* Identify power requirements for the GPS module
 +
* Interfacing GPS module with SJone, Firmware Development and NMEA sentence parsing
 +
* Individual testing of GPS module with SJOne Board
 +
| Complete
 +
| 10/18/2016
 +
|-
 +
! scope="row"| 5
 +
| 10/19/2016
 +
| 10/25/2016
 +
|
 +
* Identify power requirements for the GPS module
 +
* Interfacing Compass Module with SJOne Board and Firmware Development
 +
* Individual testing of Compass module with SJOne Board
 +
| Complete
 +
| 10/26/2016
 +
|-
 +
! scope="row"| 6
 +
| 10/26/2016
 +
| 11/01/2016
 +
|
 +
* Calibrating GPS and Compass Module
 +
* Interfacing the GPS and compass module to Android application.
 +
| Complete
 +
| 11/02/2016
 +
|-
 +
! scope="row"| 7
 +
| 11/02/2016
 +
| 11/08/2016
 +
|
 +
* Integrate GPS and Compass module with Master using CAN
 +
| Complete
 +
| 11/09/2016
 +
|-
 +
! scope="row"| 8
 +
| 11/09/2016
 +
| 12/05/2016
 +
|
 +
* Testing and debugging with whole system
 +
| Complete
 +
| 12/11/2016
 +
|-
 +
|}
  
 
=== Design & Implementation ===
 
=== Design & Implementation ===
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
−
=== Hardware Design ===
+
==== Hardware Design ====
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
 
 +
''' <u>Components</u> '''
 +
 
 +
''' SJOne Board '''
 +
----
 +
[[File:devtutorial_SjOneBoardOverlay.png|left|180px|thumb|Ultimate GPS]]
 +
 
 +
The breakout is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels
 +
 
 +
 
 +
*512K ROM, 64K(96K) RAM, 1M(2M) SPI Flash, and Micro-SD for storage.
 +
*Arm Cortex-M4 variant contains 96K RAM, and 2Mb SPI flash
 +
*2-Digit 7-Segment Display
 +
*Power from USB or External Power
 +
*Many GPIOs with two SPI, Multiple UARTs, and I2C and CAN availability
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
<br />
 +
''' GPS Module '''
 +
----
 +
[[File:cmpe243_F16_kasper_ultimate_gps.jpg‎|right|180px|thumb|Ultimate GPS]]
 +
 
 +
The breakout is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels
 +
 
 +
 
 +
*-165 dBm sensitivity, 10 Hz updates, 66 channels
 +
*5V friendly design and only 20mA current draw
 +
*RTC battery-compatible
 +
*Internal patch antenna + u.FL connector for external active antenna
 +
 
 +
''' The Compass Module - LSM303DLHC '''
 +
----
 +
[[File:CmpE243_F16_Kasper_geo_lsm303.jpg ‎|left|180px|thumb|Compass]]
 +
Compass module is based on ST Micros LSM303.
 +
When current flows through a wire, a magnetic field is created. This is the basic principle behind electromagnets. This is also the principle used to measure magnetic fields with a magnetometer. The direction of Earth's magnetic fields affects the flow of electrons in the sensor, and those changes in current can be measured and calculated to derive a compass heading.
 +
 
 +
The features of LSM303DLHCare:
 +
 
 +
*Simple I2C interface
 +
*3 magnetic field channels and 3 acceleration channels
 +
*±2g/±4g/±8g/±16g linear acceleration full scale
 +
*From ±1.3 to ±8.1 gauss magnetic field full scale
 +
 
 +
 
 +
 
 +
<br/>
 +
 
 +
 
 +
<u>Following is the Geo Controller system diagram</u>
 +
 
 +
[[File:Cmpe243_F16_kasper_geo_block_diagram.jpg]]
  
 
=== Hardware Interface ===
 
=== 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.
+
 
 +
Below table lists all the hardware pins used in Geo Controller
 +
 
 +
{| class="wikitable"
 +
|+ Geographical Controller Pin Connection Table
 +
|-
 +
! scope="col"| '''Device Description'''
 +
! scope="col"| '''Bus'''
 +
! scope="col"| '''Device Pins'''
 +
! scope="col"| '''SJOne Board Pins'''
 +
|-
 +
| MCP2551 CAN Transceiver
 +
| CAN1
 +
|
 +
RD
 +
TD
 +
Vcc
 +
GND
 +
|
 +
RD1 P0.0
 +
TD1 P0.1
 +
5V
 +
GND
 +
|-
 +
| GPS Module
 +
| UART2
 +
|
 +
Rx
 +
Tx
 +
Vcc
 +
GND
 +
|
 +
TXD2 P2.8
 +
RXD2 P2.9
 +
5V
 +
GND
 +
|-
 +
| Compass
 +
| I2C2
 +
|
 +
SDA
 +
SCL
 +
Vcc
 +
GND
 +
|
 +
SDA2 P0.10
 +
SCL2 P0.11
 +
Vcc
 +
GND
 +
|-
 +
|}
  
 
=== Software Design ===
 
=== Software Design ===
−
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it. 
 
  
−
=== Implementation ===
+
* <u>Initialization</u>
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
+
 
 +
:GPS module is interfaced using UART. UART is initialized using the most common configuration 9600/8-N-1(9600 baudrate, 8 databits, no (N) parity bit, and          :one (1) stop bit. 
 +
:We are using LSM303DLHC compass module. Both GPS and Compass modules are initialized as below.
 +
 
 +
  void geotaskInit()
 +
  {
 +
      gpsUart.init(GPS_BAUD_RATE,rx_q,tx_q);  // Initialize UART for GPS
 +
      LSM_MAG.init();                          // Initialize LSM303 Magnetometer
 +
      LSM_ACCL.init();                        // Initialize LSM303 Accelerometer
 +
  }
 +
 
 +
* <u>Data Communication with GPS and Compass</u>
 +
'''GPS'''
 +
:GPS module is programmed to send GPS data at 10Hz. Interrupt Handler continuously receives these data and stores in the queue.
 +
:Periodically (10Hz) calling the getChar function gives a complete NMEA string.
 +
 
 +
:Following string is used to set NMEA output sentence, we are using GPRMC for this project(Done in initialization)
 +
char gpsRMConlyCommand[] = "$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n";
 +
char gpsOutputFrequency[] = "$PMTK220,100*2F\r\n";
 +
 
 +
:After sending this, we will be getting GPS string after every 10Hz, which is read by interrupt handler.
 +
 
 +
[[File:CmpE243_F16_Kasper_geo_lat_lon.png|right|220px|thumb|Angle between two coordinates]] 
 +
'''Compass'''
 +
 
 +
:Compass data is read and send every 10Hz. Compass data consists of Bearing, Distance and Heading
 +
 
 +
::Bearing Calculation:
 +
::Bearing angle between two GEO coordinates is calculated using following formula
 +
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
 +
  where, φ1,λ1 is the start point
 +
  φ2,λ2 the end point
 +
  (Δλ is the difference in longitude)
 +
 
 +
[[File:CmpE243_F16_Kasper_geo_bearing_heading.png|left|220px|thumb|Bearing Angle]]
 +
 
 +
 
 +
<BR/>
 +
::Distance Calculation:
 +
::Distance between two GEO coordinates is calculated using following formula
 +
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
 +
c = 2 ⋅ atan2( √a, √(1−a) )
 +
d = R ⋅ c
 +
  where φ is latitude, λ is longitude,
 +
  R is earth’s radius (mean radius = 6,371km);
 +
 
 +
 
 +
 
 +
<BR/>
 +
*<u>CAN Communication</u>
 +
:In GeoController, we are using can1 for transmitting and receiving can messages. Latitude and longitude values are getting updated periodically.
 +
 
 +
 
 +
  void geoTask::sendGpsData()
 +
  {
 +
      if(recvdTrueGPSData == true)
 +
      {
 +
          GPS_LOCATION_t geoGpsData = { 0 };
 +
          geoGpsData.GPS_LOCATION_latitude = curLatitude;
 +
          geoGpsData.GPS_LOCATION_longitude = curLongitude;
 +
          u0_dbg_printf("lat : %f lon: %f\n",curLatitude,curLongitude);
 +
          // This function will encode the CAN data bytes, and send the CAN msg using dbc_app_send_can_msg()
 +
          dbc_encode_and_send_GPS_LOCATION(&geoGpsData);
 +
          recvdTrueGPSData = false;
 +
      }
 +
    }
 +
 
 +
  void geoTask::sendCompassData()
 +
  {
 +
      COMPASS_DATA_t geoCompassData = { 0 };
 +
      calculateDistance();
 +
      if(newChkPointRecvd)
 +
      {
 +
          calculateBearing();
 +
          newChkPointRecvd = false;
 +
      }
 +
      LSM_MAG.getHeading(&heading);
 +
      geoCompassData.COMPASS_DATA_bearing = bearing;
 +
      geoCompassData.COMPASS_DATA_heading = heading;
 +
      geoCompassData.COMPASS_DATA_speed = speed;
 +
      geoCompassData.COMPASS_DATA_distance = distance;
 +
      u0_dbg_printf("head: %f,bearing:%f,Dis:%.2f\n",heading,bearing,distance);
 +
      // This function will encode the CAN data bytes, and send the CAN msg using dbc_app_send_can_msg()
 +
      dbc_encode_and_send_COMPASS_DATA(&geoCompassData);
 +
    }
 +
 
 +
''' Geo Software Flow Diagram '''
 +
 
 +
[[File:CmpE243_F16_Kasper_geo_software_flow.png|center|700px|thumb|Geo Software Flowdiagram]]
  
 
=== Testing & Technical Challenges ===
 
=== 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.
+
'''1. <u>Compass Calibration</u>'''
 +
 
 +
Initially compass doesn't give correct readings,compass needs to be calibrated before it can be used.
 +
-->Used following Arduino sketch to get the minimum and maximum readings of the compass on all three axes.
 +
void loop()
 +
{ 
 +
    compass.read();
 +
    running_min.x = min(running_min.x, compass.m.x);
 +
    running_min.y = min(running_min.y, compass.m.y);
 +
    running_min.z = min(running_min.z, compass.m.z);
 +
    running_max.x = max(running_max.x, compass.m.x);
 +
    running_max.y = max(running_max.y, compass.m.y);
 +
    running_max.z = max(running_max.z, compass.m.z);
 +
    snprintf(report, sizeof(report), "min: {%+6d, %+6d, %+6d}    max: {%+6d, %+6d, %+6d}",
 +
    running_min.x, running_min.y, running_min.z,
 +
    running_max.x, running_max.y, running_max.z);
 +
    Serial.println(report);
 +
    delay(100);
 +
}
 +
 
 +
Use of these Minimum and Maximum Values in the calculation gives better readings
 +
 
 +
Another issue with compass is tilt compensation.
 +
If compass is tilted it gives wrong readings. Tilt needs to be compensated using Accelerometer readings.
 +
pitch = asin(-accxnorm);
 +
roll = asin(accynorm/cos(pitch));
 +
where accxnorm and accynorm are normalized x and y acceleration vector respectively.
  
 
== Communication Bridge Controller ==
 
== Communication Bridge Controller ==
Line 231: Line 1,489:
 
*''''' Bharat Khanna'''''   
 
*''''' Bharat Khanna'''''   
 
*''''' Shantanu Vashishtha '''''
 
*''''' Shantanu Vashishtha '''''
 +
  
 
=== Schedule ===
 
=== Schedule ===
 +
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SI No.
 +
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 +
|-
 +
! scope="row"| 1
 +
| 09/20/2016
 +
| 09/27/2016
 +
|
 +
*Dividing the project into smaller tasks.
 +
*Based on the number of tasks allocating each task to a team of two.
 +
| Complete
 +
| 09/27/2016
 +
|-
 +
! scope="row"| 2
 +
| 09/28/2016
 +
| 10/4/2016
 +
|
 +
*Study previous project reports and order Bluetooth module and other components based on the following factors:
 +
*Power requirement, preferably with input voltage within SJOne board output voltage range.
 +
*Review of the components that give few or no hardware errors.
 +
*Ease of integration with SJOne board.
 +
| Complete
 +
| 10/9/2016
 +
|-
 +
! scope="row"| 3
 +
| 10/5/2016
 +
| 10/11/2016
 +
|
 +
*Understanding Bluetooth module hardware design and protocol requirement for communication.
 +
*Figuring out the pins on SJOne board required for communication with Bluetooth module.
 +
|Complete
 +
| 10/11/2016
 +
|-
 +
! scope="row"| 4
 +
| 10/12/2016
 +
| 10/18/2016
 +
|
 +
<!-- Purchase an apt Bluetooth module after thoroughly studying the previous year project reports. (This is a comment)-->
 +
*CAN message ID's, priorities, data size and format proposals for all the possible CAN messages on the bus.
 +
* Planning methods for testing Bluetooth module.
 +
|Complete
 +
| 10/18/2016
 +
|-
 +
! scope="row"| 5
 +
| 10/19/2016
 +
| 10/25/2016
 +
|
 +
* Work on Bluetooth firmware development to integrate with SJ one board.
 +
| Complete
 +
| 10/25/2016
 +
|-
 +
! scope="row"| 6
 +
| 10/26/2016
 +
| 11/08/2016
 +
|
 +
*Develop basic Android application to work with the Bluetooth module.
 +
*Test the communication between SJ one board and Android application over Bluetooth protocol.
 +
<!-- Integrating Sensor modules with SJone board-->
 +
<!-- Development of obstacle avoidance algorithm with sensor integration-->
 +
<!-- Developing Master for CAN communication-->
 +
<!-- Integrating Mobile app with the Controller-->
 +
| Complete
 +
| 11/08/2016
 +
|-
 +
! scope="row"| 7
 +
| 11/9/2016
 +
| 11/20/2016
 +
|
 +
* Interface Bluetooth module with CAN.
 +
* Integration of geolocation API with mobile APP.
 +
* Testing the Bluetooth module with Mobile application by incorporating filter.
 +
| Complete
 +
| 11/20/2016
 +
|-
 +
! scope="row"| 8
 +
| 11/21/2016
 +
| 12/05/2016
 +
|
 +
* Testing the Bluetooth module with Master controller using CAN communication
 +
* Testing and debugging of the complete system.
 +
| Complete
 +
|  12/18/2016
 +
|-
 +
|}
  
 
=== Design & Implementation ===
 
=== 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.
 
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 +
 +
=== Bluetooth Module ===
 +
----
 +
[[File:CmpE243_F16_kasper_RN42XV_Bluetooth_Module.jpg‎|left|180px|thumb|Bluetooth Module]]
 +
 +
RN42XV is built around Microchip's RN42 low power Bluetooth module. Some features of this module are as follows
 +
 +
 +
*Based on the popular 2 x 10 (2mm) socket footprint.
 +
*Voltage range: (3-3.6)Volts
 +
*Current range: 26 μA sleep, 3 mA connected, 30 mA transmit.
 +
*UART data connection interface.
 +
*Sustained data rates: 240 Kbps (slave), 300 Kbps (master)
 +
*Transmission range up to 60 feet (20 m) distance, +4 dBm output transmitter, -80 dBm typical receive sensitivity.
 +
*FHSS/GFSK modulation, 79 channels at 1-MHz intervals.
  
 
=== Hardware Design ===
 
=== Hardware Design ===
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
The interface between Bluetooth module and controller is as shown in fig [[File:CmpE243_F16_kasper_Interface_between_bluetooth_module_and_controller.jpg‎|centre|700px|thumb|Interface between Bluetooth module and controller]]
  
 
=== Hardware Interface ===
 
=== 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.
+
The interface between Bluetooth module and controller is as shown in fig [[File:CmpE243_F16_kasper_connection_bluetooth_controller_canTransceiver.jpeg|centre|700px|thumb|Pinout Bridge Controller]]
  
−
=== Software Design ===
+
The interface between Bluetooth module and controller is as shown in fig [[File:CmpE243_F16_kasper_CAN_message_and_message_ID.jpeg|centre|700px|thumb|Table CAN Message and_Message ID]]
−
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 Software Design ===
 +
 
 +
The main functions that are used for communication are as follows.
 +
  void Check_Start_STOP__CheckPoint_Condition()
 +
{
 +
if(strcmp(stored_Bluetooth_data,START) == 0)
 +
{
 +
START_CONDITION.START_CMD_APP_data = 1;
 +
dbc_encode_and_send_START_CMD_APP(&START_CONDITION);
 +
memset(stored_Bluetooth_data, 0, sizeof(stored_Bluetooth_data));
 +
}
 +
else if(strcmp(stored_Bluetooth_data,STOP) == 0)
 +
{
 +
STOP_CONDITION.STOP_CMD_APP_data = 1;
 +
dbc_encode_and_send_STOP_CMD_APP(&STOP_CONDITION);
 +
memset(stored_Bluetooth_data, 0, sizeof(stored_Bluetooth_data));
 +
}
 +
else if(check_received == true)
 +
{
 +
int loop =0;
 +
BRIDGE_TOTAL_CHECKPOINT.BRIDGE_TOTAL_CHECKPOINT_NUMBER = check_point_total;
 +
dbc_encode_and_send_BRIDGE_TOTAL_CHECKPOINT(&BRIDGE_TOTAL_CHECKPOINT);
 +
for(loop = 0; loop < (check_point_total*2) ;loop=loop+2)
 +
  {
 +
BLUETOOTH_DATA_Location.BLUETOOTH_DATA_LAT = store_cor[loop];
 +
BLUETOOTH_DATA_Location.BLUETOOTH_DATA_LON = store_cor[loop+1];
 +
dbc_encode_and_send_BLUETOOTH_DATA(&BLUETOOTH_DATA_Location);
 +
}
 +
check_received = false;
 +
}
 +
  }
 +
 +
 
 +
 
 +
  void Can_Receive_ID_Task()
 +
{
 +
if (CAN_rx(can1, &can_msg_Info, 0))
 +
{
 +
LE.off(1);
 +
dbc_msg_hdr_t can_msg_hdr;
 +
can_msg_hdr.dlc = can_msg_Info.frame_fields.data_len;
 +
can_msg_hdr.mid = can_msg_Info.msg_id;
 +
if(can_msg_Info.msg_id == RESET_HDR.mid)
 +
dbc_decode_RESET(&REST_Info, can_msg_Info.data.bytes, &can_msg_hdr);
 +
if(can_msg_Info.msg_id == RECEIVE_START_ACK_HDR.mid)
 +
printf("Case_RECEIVE_START_ACKt\n");
 +
if(can_msg_Info.msg_id == BRIDGE_POWER_SYNC_HDR.mid)
 +
printf("BRIDGE_POWER_SYNC_data\n");
 +
if(can_msg_Info.msg_id == GPS_LOCATION_HDR.mid)
 +
{
 +
dbc_decode_GPS_LOCATION(&GPS_LOCATION_RECEIVE, can_msg_Info.data.bytes, &can_msg_hdr);
 +
sprintf(lat,"%f",GPS_LOCATION_RECEIVE.GPS_LOCATION_latitude);
 +
sprintf(lon,"%f",GPS_LOCATION_RECEIVE.GPS_LOCATION_longitude);
 +
        Send_App_curr_loc(lat,lon);
 +
}
 +
if(dbc_handle_mia_RESET(&REST_Info, 1))
 +
{
 +
REST_Info.RESET_data=RESET__MIA_MSG.RESET_data;
 +
LD.setNumber(REST_Info.RESET_data);
 +
LE.on(1);
 +
}
 +
}
 +
  }
 +
 
 +
The interface between Bluetooth module and controller is as shown in fig [[File:CmpE243_F16_kasper_Bluetooth_Software_FLow_Chart.jpeg‎|centre|700px|thumb|Bluettoh Software FLow Chart]]
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
+
The aim of the project is the design and development of an autonomous vehicle which should be able to traverse from its current location to the destination provided by the user. The destination is provided by the user via Android mobile application. The bridge controller refers to communication between the master controller and the mobile application which is established using RN42XV Bluetooth module. The data that is received via mobile application is start command, stop command, total number of checkpoints and checkpoints itself. The SJOne boards establishes communication with Bluetooth module using UART communication protocol. Once the data is received by the Bluetooth controller it is then sent to the master controller using CAN communication protocol.
 +
 
 +
===Android Application Design===
 +
====Problem statement====
 +
In present day, what is that one thing, which has become an essential part of a human life? Yes, that's correct, the answer is smartphone. It is almost impossible to imagine a single day without a mobile phone. So whether it is for a bank transaction or daily grocery shopping or travel, we need all the updated information in our hand. Keeping in mind this technological need, an application to control and track our self driving car prototype makes total sense. With universality of android platform, we decide to make an adnroid application to control our self driving car prototype "Kasper".
 +
 
 +
====Implementation====
 +
The objective of the Android application is to allow the user to communicate with the self driving car using a smartphone. The application is built using Android Studio. It is the official IDE for Android platform development.  The project uses .java file to design the logic of the app. To integrate maps within your application, an API key from Google's developer console is required. This API helps Google in tracking the statistics related to the app. When a device is clicked, map pops up which means that map fragment has been successfully implemented. Application uses Android Application framework (API level 25). There are four activities responsible for complete functionality of the application, namely FirstActivity.java, MapActivity.java and LatLong.java. <br>
 +
 
 +
1. FirstActivity.java is responsible for screen 1 and has some basic buttons to "Turn ON" bluetooth for the device, find available bluetooth devices, make the smartphone discoverable to other devices, list paired devices and "Turn OFF" bluetooth on the device. After selecting an appropriate bluetooth module listed in the paired devices/available devices list, application makes a transition to screen 2. <br>
  
−
=== Testing & Technical Challenges ===
+
2. The most basic information that a user must be able to control in a self-driving car is the source and the destination. The source in the application is designed to set with the current location sent by GPS module to bluetooth controller.
−
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
+
Screen 2 is controlled by MapActivity.java that opens a map. This file is responsible for creating a bluetooth socket that allows communication between the app and the actual hardware. After the map is visible, destination is marked manually by the user, by selecting a point on the integrated Google map API. The format of the point selection is such that the application will consider the final/last checkpoint as destination while the rest markers will be considered as intermediate checkpoints. Once the user is done marking the check points, the information is sent to Bluetooth controller in the following format: <br>
−
Make a smooth transition to testing section and described what it took to test your project.
+
n,latitude_1,longitude_1...latitude_n,longitude_n <br>
 +
Here, n is number of checkpoints and (latitude_n,longitude_n) will be considered as the destination points by the Bluetooth controller. Once this information is sent, application waits for an acknowldgement in the form of "ack$" from the Bluetooth controller to ensure that the coordinates have been received. If there is no acknowldgement then the start button will not become active. After receiving acknowledgement, start button becomes active and the car will start moving when the button is asserted. Also, at a time only one of the two start or stop button is active. So, once a start button is pushed it is deactivated and stop is active now. <br>
 +
MapActivity.java also includes a handler for receiving messages like current location and then updating them on the map. It also receives coordinates at regular intervals to track the car location.
 +
 
 +
3. LatLong.java file has a public class with variables and methods that can used anywhere. This is done to set and get the latitude and longitude values.
 +
 
 +
====Bluetooth - Android Interface====
 +
[[File:CmpE243_F16_Kasper_Interface.png|width=300%|center|Bluetooth - Android interface]]
 +
<br>
 +
 
 +
====Command format and functionality====
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SI No.
 +
! scope="col"| Button
 +
! scope="col"| Description
 +
! scope="col"| Screen
 +
! scope="col"| Command format
 +
|-
 +
! scope="row"| 1
 +
| Turn ON
 +
| When this button is pressed it will ask user to turn ON the bluetooth.
 +
If the bluetooth is already on then it will display "Already on" message.
 +
| Screen 1
 +
| --
 +
|-
 +
|-
 +
! scope="row"| 2
 +
| Turn OFF
 +
| When this button is pressed it will send a command to hardware to disable the bluetooth.
 +
| Screen 1
 +
| --
 +
|-
 +
|-
 +
! scope="row"| 3
 +
| Get Visible
 +
| When this button is pressed it will ask user to make bluetooth device visible to other devices for 120 seconds.
 +
| Screen 1
 +
| --
 +
|-
 +
|-
 +
! scope="row"| 4
 +
| List Devices
 +
| When this button is pressed it will display all the previously paired devices in a list view on the screen.
 +
| Screen 1
 +
| --
 +
|-
 +
|-
 +
! scope="row"| 5
 +
| Find Devices
 +
| If the intended device is not in the List Devices list then press this button to search for available devices and then connect.
 +
| Screen 1
 +
| --
 +
|-
 +
|-
 +
! scope="row"| 6
 +
| Connect
 +
| When this button is pressed it will update the map with the current location sent by the GPS module to the Bluetooth controller.
 +
| Screen 2
 +
|
 +
* Sent: connect
 +
* Received: loc,latitude,longitude$
 +
|-
 +
|-
 +
! scope="row"| 7
 +
| Send
 +
| After configuring the checkpoints, this button is used to send the coordinates of the selected points.
 +
| Screen 2
 +
|
 +
*Sent: latitude,longitude
 +
|-
 +
|-
 +
! scope="row"| 8
 +
| Updating car location
 +
| The car location can be tracked depending upon the GPS data.
 +
| Screen 2
 +
|
 +
*Received - ab,latitude,longitude$
 +
|-
 +
|-
 +
! scope="row"| 9
 +
| Start/Stop
 +
| At a time only one of the button is active. Start will run the car while Stop will stop the car.
 +
| Screen 2
 +
|
 +
*For Start - start
 +
*For Stop - stop
 +
|-
 +
|}
 +
 
 +
====Application workflow====
 +
[[File:CmpE243_F16_Kasper_FC.png|width=300%|none|Flowchart]]
 +
<br>
 +
 
 +
====Application features====
 +
Android application has major features that exploit real time data. Once the phone is connected to the bluetooth module application starts sending and receiving data to perform number of operations. Features are listed below: <br>
 +
1. First feature is to get the current location. Application sends a command to request bluetooth module for updating the current location. After receiving the current location coordinates, application updates them on the Google map API used. <br>
 +
2. Second remarkable feature is updating the map with destination along with check points. This feature is highly desirable as it maps real life situation, in which destination is not reached instantly, but going from one checkpoint to another. Once the checkpoint have been marked they are sent to the master controller. <br>
 +
3. Third feature provide a layer of reliability during communication. Once the checkpoints have been sent, start car button will not become active until there is an acknowldgement from the bluetooth controller that it has received the destination coordinates along with checkpoints. This ensures that the car will not go to any random location. <br>
 +
4. The fourth most important feature in the application is that it exploits the real time data sent by the GPS module. As the car starts moving, GPS coordinates change. This new data is received by the application that helps in tracking the current car location. This feature is extremely useful to trace the route that is taken by the car (if there is any obstacle in the initial path). <br>
 +
 
 +
====Android UI design====
 +
{|
 +
|[[File:CmpE243_F16_Kasper_Screen1.jpg|left|220px|thumb|Android App Icon]]
 +
|[[File:CmpE243_F16_Kasper_Screen2.jpg|left|220px|thumb|Application Homepage. RNBT is the Bluetooth module name]]
 +
|[[File:CmpE243_F16_Kasper_Screen3.png|left|220px|thumb|Map with connect button]]
 +
|[[File:CmpE243_F16_Kasper_Screen4.png|center|220px|thumb|App showing current location]]
 +
|[[File:CmpE243_F16_Kasper_Screen5.png|right|220px|thumb|Check points marked]]
 +
|}
 +
<br>
 +
{|
 +
|[[File:CmpE243_F16_Kasper_Screen7.png|220px|thumb|left|Start button visible after sending coordinates]]
 +
|[[File:CmpE243_F16_Kasper_Screen8.png|220px|thumb|left| Route to the destination. Yellow dot is the current car location]]
 +
|}
 +
 
 +
=== Testing ===
 +
* For testing purpose, the code is made modular which means that each functionality in the code is defined in different functions. This approach makes it easier to check the output at different levels, which makes it easier to verify the output at different levels.
 +
* The testing for Bluetooth module is done using "Bluetooth Serial Terminal" Application
 +
 
 +
=== Technical Challenges ===
 +
* Technical challenge faced while communicating between Android app and Bluetooth was sending the current location which is achieved by updating the send_cor_buffer after every 10 milliseconds and sending updated coordinates.
  
−
== Central Controller ==
+
== Master Controller ==
 
=== Team Members & Responsibilities ===
 
=== Team Members & Responsibilities ===
  
 
*''''' Aajna Karki '''''   
 
*''''' Aajna Karki '''''   
−
*''''' Spoorthi Shivakumar '''''
+
*''''' Spoorthi Mysore Shivakumar '''''
  
 
=== Schedule ===
 
=== Schedule ===
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SI No.
 +
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 +
|-
 +
! scope="row"| 1
 +
| 09/26/2016
 +
| 10/05/2016
 +
|
 +
* Understand the tasks involved and the overall scope of the Master Controller
 +
* Finalise on the CAN transceiver to be used and place an order for the same
 +
| Complete
 +
| 10/05/2016
 +
|-
 +
! scope="row"| 2
 +
| 10/06/2016
 +
| 10/18/2016
 +
|
 +
* Finalise on the node addresses and message IDs for each of the CAN controllers
 +
* Implement the DBC file
 +
| Complete
 +
| 10/18/2016
 +
|-
 +
! scope="row"| 3
 +
| 10/19/2016
 +
| 10/25/2016
 +
|
 +
* Understand the overall hardware design and build the car
 +
* Establish CAN communication with the other controllers based on the DBC file
 +
* Test the basic power-up interactions with the controllers
 +
| Complete
 +
| 10/25/2016
 +
|-
 +
! scope="row"| 4
 +
| 10/26/2016
 +
| 11/07/2016
 +
|
 +
* Design and implement the Obstacle avoidance algorithm
 +
| Complete
 +
| 11/07/2016
 +
|-
 +
! scope="row"| 5
 +
| 11/08/2016
 +
| 11/15/2016
 +
|
 +
* Co-ordinate during the integration of the motor and sensor modules from the Master Controller perspective
 +
* Establish complete communication across different CAN controllers interfaced
 +
* Strictly monitor sync and the stop command from bluetooth
 +
* Design and start the implementation of the Navigation Algorithm
 +
| Complete
 +
| 11/20/2016
 +
|-
 +
! scope="row"| 6
 +
| 11/16/2016
 +
| 11/29/2016
 +
|
 +
* Test the full-fledge functionality of Obstacle Avoidance algorithm based on data from all the sensors and commands to the motor controller.
 +
* Verify communication with Bluetooth controller for accurate check-point data
 +
* Test the functionality of Navigation algorithm with the location data from Geocontroller
 +
| Complete
 +
| 11/29/2016
 +
|-
 +
! scope="row"| 7
 +
| 11/29/2016
 +
| 12/06/2016
 +
|
 +
* Test the algorithms for any unaccounted scenarios or issues faced
 +
*  Verify the accuracy of data received from all controllers and the response from the Master Controller
 +
| Complete
 +
| 12/12/2015
 +
|-
 +
! scope="row"| 8
 +
| 12/06/2016
 +
| 12/15/2016
 +
|
 +
* Test extensively and debug issues
 +
| Complete
 +
| 12/18/2016
 +
|-
 +
|}
  
 
=== Design & Implementation ===
 
=== 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.
+
The Master Controller is responsible for driving the car based on the Obstacle Avoidance and Navigation algorithm.
 +
 
 +
Obstacle avoidance algorithm uses the sensor data and drives the motor accordingly. Navigation algorithm uses the data from compass to adjust the direction of the car based on the destination.
  
 
=== Hardware Design ===
 
=== Hardware Design ===
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
Master Controller is interfaced to CAN transceiver as shown below.<br>
 +
CAN messages are transmitted and received over the bus establishing communication with the rest of the controllers.
  
 
=== Hardware Interface ===
 
=== 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.
+
Master Controller is concerned with the implementation of algorithms to drive the car.<br>
 +
The hardware interface is only to the CAN transceiver over which communication with the rest of the controllers happens.
 +
 
 +
[[File:CmpE243_F16_Kasper_MasterCAN_BlockDiagram.png|center|500px|thumb|Master Controller interface to CAN transceiver]]
  
 
=== Software Design ===
 
=== 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.
+
 
 +
Master Controller receives CAN messages in the 100Hz periodic function.<br>
 +
The functionality to drive the car based on Obstacle Avoidance and Navigation Algorithm is implemented in the 10Hz periodic function.<br>
 +
The 1Hz periodic function implements the logic to check if CAN bus is on/off.
 +
<br>
 +
 
 +
 
 +
[[File:CmpE243_F16_Kasper_PeriodicFlowChart.png|center|500px|thumb|Functionality in 1 and 100Hz of Master Controller]]
 +
 
 +
 
 +
<br>
 +
The drive commands to the car are based on the Obstacle Avoidance and the Navigation algorithm.<br>
 +
Obstacle avoidance is given priority over Navigation Algorithm. <br>
 +
If no obstacles are encountered, the control falls to the Navigation algorithm which directs the car to the destination.
 +
 
 +
 
 +
[[File:CmpE243_F16_Kasper_10HzFlowChart.png|center|700px|thumb|Functionality in 10Hz of Master Controller]]
 +
 
 +
 
 +
'''Obstacle Avoidance Algorithm:
 +
 
 +
Three zones are declared based on the distance of the obstacle - NEAR zone, MEDIUM zone and FAR zone.
 +
 
 +
Based on which zone the obstacle is encountered in, appropriate decisions are made to drive the car.
 +
 
 +
 
 +
 
 +
'''Navigation Algorithm:'''
 +
 
 +
The compass readings obtained range from 0 to 360.
 +
Based on the readings, the data is divided into quadrants. Based on each of the value received, appropriate drive decisions are made.
 +
 
 +
Navigation Algorithm has lower priority as compared to Obstacle Avoidance algorithm.
 +
 
 +
Below is the detailed flowchart of Obstacle and Navigation Algorithm
 +
 
 +
[[File:CmpE243_F16_Kasper_ObstacleNavigationAlgorithm.png|center|700px|thumb|Obstacle And Navigation Algorithm]]
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
+
 
 +
The overall function of the Master Controller can be visualized through the following state machines:
 +
 
 +
'''Initial State'''<br>
 +
This is the initial state of the car when no commands are received. The car is dormant at this point.
 +
 
 +
'''Send Checkpoints'''<br>
 +
Once the checkpoint data is received from the Bridge controller, it is saved in an array.<br>
 +
The checkpoints need to be sent to Geo controller sequentially. As and when a particular checkpoint is reached, next checkpoint data needs to be sent.<br>
 +
The state of the controller in which checkpoint data is sent constitutes this state.
 +
 
 +
'''Navigating'''<br>
 +
Navigation is started only after the ''Start'' command is received from the Bridge Controller.<br>
 +
When a CAN message with the ''Start'' command is received, the state of the car is changed to ''Navigating''.  
 +
 
 +
'''Stop Car'''<br>
 +
When ''Stop'' command is received from the Bridge Controller, the state of the car is changed to ''Stop Car''.
 +
Motor commands are sent to stop the car.
 +
 
 +
[[File:CmpE243_F16_Kasper_CarStateDiagramMaster.JPG|center|600px|thumb|State Diagram]]
 +
 
 +
 
 +
 
 +
In terms of coding, they are defined as enum values:
 +
 
 +
<syntaxhighlight lang="c">
 +
enum STATE_CAR{
 +
SEND_CHECKPOINTS,
 +
NAVIGATING,
 +
STOP_CAR,
 +
INITIAL_STATE
 +
};
 +
</syntaxhighlight>
  
 
=== Testing & Technical Challenges ===
 
=== 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?
+
Few challenges faced during the phase of the project are as below:
−
Make a smooth transition to testing section and described what it took to test your project.
+
 
 +
'''CAN Receive function'''<br>
 +
It is advisable that the system has only one CAN Receive. The values can be be populated in 100Hz and used in 1Hz/10Hz based on priority. Having more than one CAN receive can result in messages being missed.<br>When reading messages in 100Hz , an 'if' instead of 'while' could be used so that there is no task overrun.
 +
 
 +
== Conclusion ==
 +
The self driving car project has definitely helped us learn and grow in terms of technical knowledge as well as team management.
 +
Right from choosing the hardware components by considering every aspect of its functionality to programming them,
 +
this project has indeed given us an end-to-end learning of the entire system. There has been a lot of decision making
 +
which has resulted in many brain-storming sessions with the team as a whole.
  
 +
The different phases of the project have been significant in their own terms. Selection of hardware is of utmost importance.
 +
We have had scenarios where we changed the ultrasonic sensors and the RPM sensors for greater accuracy. A major learning is
 +
that component selection needs diligent efforts. Sticking to the demo timelines would help a great deal. Code reviews would be beneficial as well.
  
−
=== My Issue #1 ===
+
We, as a team, have learnt how to build a machine from scratch. We also have learnt how a considerably big team can manage
−
Discuss the issue and resolution.
+
their particular modules and co-ordinate with the other modules as well. Team management has been a good takeaway here.
  
−
== Conclusion ==
+
It has been overall a tremendous learning experience. I hope the further projects benefit from our learning curve documented.
−
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 ===
 
=== Project Video ===
−
Upload a video of your project and post the link here.
+
 
 +
[https://www.youtube.com/watch?v=u5xBqo3Sc8c&feature=youtu.be| Kasper Project video]
 +
 
 +
=== Other video links ===
 +
 
 +
*Obstacle Avoidance
 +
[https://www.youtube.com/watch?v=zHanGKYkF2U&feature=youtu.be| Obstacle avoidance]
 +
 
 +
*Sensor and LED blinking test
 +
[https://www.youtube.com/watch?v=rQezBmLZ7tQ&feature=youtu.be|  Sensor Testing Video]
  
 
=== Project Source Code ===
 
=== Project Source Code ===
−
*  [https://gitlab.com/cmpe243_kepler/self_driving_car/tree/master/ Sourceforge Source Code Link]
+
*  [https://gitlab.com/cmpe243_kasper/self_driving_car Gitlab Source Code Link]
  
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
−
Any acknowledgement that you may wish to provide can be included here.
+
This project has been an amazing learning experience for the whole team. The knowledge we take from here is immense. We are grateful to '''Professor Preetpal Kang''' for his guidance and efforts towards making our learning commendable. Also, we would like to extend our sincere thanks to the '''ISA''' team for their continuous support. Here is a special mention to the '''''Kasper''''' team for all their meticulous and diligent efforts towards making this project a reality.
  
 
=== References Used ===
 
=== References Used ===
−
List any references used in project.
 
  
−
=== Appendix ===
+
[1] Preetpal Kang's lecture notes of CMPE 243, Computer Engineering, San Jose State University, Aug-Dec 2016.
−
You can list the references you used.
+
[2] [http://www.socialledge.com/sjsu/index.php?title=Industrial_Application_using_CAN_Bus#Fall_2015 Fall 2015 Wiki Projects]
 +
[3] [https://www.keil.com/dd/chip/4871.htm LPC1758 User Manual]
 +
[4] [https://www.parallax.com/product/28015 Parallax Ultrasonic Sensor]
 +
[5] [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405 CAN Transceiver]
 +
[6] [https://www.sparkfun.com/products/10736 Razor IMU]
 +
[7] [https://www.pololu.com/file/0J434/LSM303DLH-compass-app-note.pdf LSM303 Application Note]
 +
[8] [https://www.adafruit.com/products/746 Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3]
 +
[9] [http://gis.stackexchange.com/questions/29605/distance-calculation-integrating-incremental-gps-data GPS data calculation accuracy]
 +
[10] [http://www.csgnetwork.com/gpsdistcalc.html GPS Longitude Latitude distance calculator]
 +
[11] [http://stackoverflow.com/questions/365826/calculate-distance-between-2-gps-coordinates Calculate distance between two points]
 +
[12] [http://www.4dsystems.com.au/product/uLCD_32PTU/ GLCD with Touchscreen]
 +
[13] [https://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf GPS Datasheet]
 +
[14] [https://en.wikipedia.org/wiki/CAN_bus CAN Communication]
 +
[15] [https://en.wikipedia.org/wiki/Hall_effect_sensor Hall effect sensor]

Latest revision as of 10:23, 15 December 2017

The project aims at developing a self driving car using the CAN protocol.
This report discusses in detail the various tasks involved in the development of the car and challenges faced.

Kasper

Contents

Abstract

We are in an era of smart machines. With the self driving cars taking over the roads these days, it is an interesting challenge to build our own version of it.
This project aims at the implementation of such a self-driving car.

This self-driving RC car is based on CAN communication protocol which has been proven to be robust and deterministic by the automotive industry. The controller used is the SJ-One Board.

The overall driving of the car is divided across five modules:
Sensor: The sensor module essentially checks for obstacles in the driving path.
MotorIO: MotorIO drives the car using the underlying DC motor and Servo. LCD displays important information such sensor readings and GPS coordinates.
Geo: Geo controller is responsible for obtaining the location details and aid navigation.
Bridge: Bridge controller interfaces with the Android application where the path to be traversed is selected.
Master: Master co-ordinates the data from each of the modules and drives the MotorIO.

With all these implementations in place, the car will be able to drive itself to the destination.

Car Sideview
Car Topview
Car Backview
Kasper Car


Objectives & Introduction

The objective of this project is to build a self-driving car based on CAN protocol.

The self-driving car is intended to accomplish the following:

  • The car is controlled via the Bluetooth application which is responsible for providing commands related to Start, Stop and Navigation Path of the car.
  • The destination to be reached and the route to take in order to reach the destination are selected on the map using the Application.
  • The checkpoints selected on the map are sent to the Bluetooth controller which is in turn sent to the Master Controller.
  • The Master Controller is responsible for updating Geo Controller with the checkpoints as and when the car navigates.
  • The Geo Controller provides the direction data which is useful for navigating from the current location to the nearest checkpoint.
  • The Sensor Controller is responsible for detecting all the obstacles and providing the relevant obstacle data.
  • Based on the Obstacle Avoidance data received from the sensors and the Navigation data received from the Geo Controller, the Master Controller needs provide commands to the Motor Controller to drive the motor towards the intended destination.


System Block Diagram

System block diagram

Team Members & Responsibilities

  • Communication Bridge Controller (Application logo):
    App Logo

We have used five controllers

Team Schedule

Sl No. Start Date End Date Task Status Actual Completion Date
1 09/20/2016 09/27/2016
  • Divide the project into smaller tasks
  • Allocate each module to a team of two
 Completed 09/27/2016
2 09/28/2016 10/04/2016
  • Study previous reports to get an overall understanding of the project
  • Plan the stages of the project so that tasks across modules can be synchronised
  • Research on the components and order the same
  • Understand the placement of modules in the car
 Complete 10/04/2016
3 10/05/2016 10/11/2016
  • Study the hardware specifications of each module and review them for hardware errors
  • Study the datasheet for the components and come up with pin diagrams
  • Understand the hardware interfacing of each of the modules and test compatibility
  • Analyse power requirements
 Completed 10/11/2016
4 10/12/2016 10/18/2016
  • Analyse the communication required across the controllers.
  • Design Message IDs based on the priority of the messages and the data to be sent across.
  • Implement the DBC file compatible with all the controllers.
  • Interface GPS module with SJOne board. Firmware development and NMEA sentence parsing.
 Completed 10/18/2016
5 10/19/2016 11/01/2016
  • Establish communication across all the CAN controllers over CAN bus based on the DBC file.
  • Verify the power-up interactions between Master and the other controllers
  • Check the sensor functionality stand-alone with a minimal driver.
  • Interface motor to the SJOne board and check for basic functionality.
  • Interface Compass module with SJOne board. Firmware development and stand-alone testing.
  • Work on Bluetooth firmware development to integrate with SJ one board.
Completed 11/01/2016
6 11/01/2016

CAN COMMUNICATION DEMO

Completed 11/01/2016
7 11/01/2016 11/07/2016
  • Read sensor values and filter the readings. Prepare sensor values to be sent over the CAN bus to the Master controller.
  • Integrate LCD and motor. Implement code for all the transactions of motor and LCD over CAN.
  • Calibrate GPS and Compass Module.Develop complete code for GPS and Compass module communication over CAN
  • Develop basic Android application to work with the Bluetooth module. Test the communication between SJOne board and Android application over Bluetooth protocol.
  • Design the Obstacle avoidance and start with basic implementation.
Completed 11/01/2016
8 11/08/2016

PROJECT PROTOTYPE DEMO

Completed 11/07/2016
9 11/08/2016 11/15/2016
  • Test each module individually for accurate functionality based on communication with the Master
  • Verify the stringent requirement of Start-up Sync, Periodic heart-beat messages, Stop car through Bluetooth command.
  • Integrate all modules with the Master to test the data flow
  • Design the way-point algorithm and start with the implementation.
  • Design the Navigation Algorithm and start with the implementation.
Completed 11/08/2016
10 11/16/2016 11/29/2016
  • Implement motor feedback and IO display.
  • Complete the implementation of Android application.
  • Interface all the controllers each with additional implemented features
  • Verify the rest of the communication over the CAN bus across the five controllers
 Completed 11/15/2016
11 11/29/2016

PROJECT PROTOTYPE DEMO 2

Completed 11/29/2016
12 11/29/2016 12/06/2016
  • Test the accuracy of the data sent from the sensor and the settings to the Motor based on the Obstacle Avoidance Algorithm
  • Test the accuracy of check-points from the Bluetooth controller, location data from the Geocontroller sensor and Navigation Algorithm
  • Verify the correct response of each module
 Completed 12/06/2016
13 12/07/2016 12/15/2016
  • Check for tuning or calibration of components if required
  • Brainstorm on the test cases
  • Complete end-to-end testing for various scenarios and conditions
 Completed 12/15/2016
14 12/21/2016

FINAL PROJECT DEMO

Completed 12/21/2016
15 12/20/2016

PROJECT REPORT SUBMISSION

Completed 12/20/2016

Parts List & Cost

Item# Part Desciption Vendor Qty Cost $
1 RC Car From Preet 1 0
2 SJOne board Preet 5 80
3 GPS Module Adafruit 1 40
4 Triple Axis Magnetometer (Compass) Sparkfun 1 15
5 Bluetooth Module Sparkfun 1 24.95
6 LCD screen Adafruit 1 24.95
7 Ultrasonic sensor Sparkfun 1 27.95
8 Jumper cable Amazon 1 9.99
9 DB9 Connector HSC 1 1
10 CAN Transceiver Microchip 10 10


CAN Communication

CAN (Controller Area Network) also known as CAN bus is a vehicle bus that is designed to communicate with microcontrollers and other devices to achieve a specific application. It finds great application in the automotive industry. Shown below is CAN frame along with logical and electrical values.

CAN Frame


Start-of-frame
Arbitration Field
Remote Transmission Request (RTR)
Data Length Code (DLC)
Data Field
CRC
Acknowledgement
End-of-frame (EOF)
Figure No.. Field Name Length (bits) Description
1 CAN frame - CAN frame with 11 identifier bits.
2 Start-of-frame 1 Denotes the start of frame transmission and indicates beginning of message. It starts with dominant logic 0 bit.
3 Arbitration Field 11 This identifies the messages and indicates the message priority.
4 Remote Transmission Request (RTR) 1 Differentiates remote frame from a data frame. Must be dominant (0) for data frames and recessive (1) for remote request frames.
5 Data Length Code (DLC) 4 Number of bytes of data. This field indicates how much data is stored inside.
6 Data Field 0-64 (0-8 Bytes) Data to be transmitted.
7 CRC 16 This is a 16-bit cyclic redundancy check code along with CRC delimiter.
8 Acknowledgement 2 Acknowledge bits.
9 End-of-frame (EOF) 7 End of frame bits. Msut be all recessive.

DBC File Implementation

The DBC file used for the project is as below:

VERSION ""

NS_ : 

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

BS_: 

BU_: MASTER GEO SENSOR MOTORIO BRIDGE

BO_ 100 STOP_CAR: 1 MASTER 
 SG_ STOP_CAR_data : 0|8@1+ (1,0) [0|0] "" BRIDGE,GEO,SENSOR,MOTORIO

BO_ 110 RESET: 1 MASTER 
 SG_ RESET_data : 0|8@1+ (1,0) [0|0] "" BRIDGE,GEO,SENSOR,MOTORIO

BO_ 130 STOP_CMD_APP: 1 BRIDGE 
 SG_ STOP_CMD_APP_data : 0|8@1+ (1,0) [0|0] "" MASTER

BO_ 140 START_CMD_APP: 1 BRIDGE 
 SG_ START_CMD_APP_data : 0|8@1+ (1,0) [0|0] "" MASTER

BO_ 400 SENSOR_SONIC: 4 SENSOR 
 SG_ SENSORS_SONIC_front_left : 0|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 SG_ SENSORS_SONIC_front_right : 16|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 SG_ SENSORS_SONIC_front_center : 32|16@1+ (1,0) [0|0] "" MASTER,MOTORIO
 SG_ SENSORS_SONIC_back : 48|16@1+ (1,0) [0|0] "" MASTER,MOTORIO

BO_ 410 MOTORIO_DIRECTION: 3 MASTER
 SG_ MOTORIO_DIRECTION_speed : 0|8@1+ (1,0) [0|10] "" MOTORIO
 SG_ MOTORIO_DIRECTION_turn : 8|8@1+ (1,-4) [-3|3] "" MOTORIO
 SG_ MOTORIO_DIRECTION_direction : 16|8@1+ (1,0) [0|2] "" MOTORIO

BO_ 420 BRIDGE_TOTAL_CHECKPOINT: 1 BRIDGE
 SG_ BRIDGE_TOTAL_CHECKPOINT_NUMBER : 0|8@1+ (1,0) [0|0] "" MASTER,MOTORIO

BO_ 430 RECEIVE_START_ACK: 1 MASTER
 SG_ RECEIVE_START_ACK_ack : 0|8@1+ (0,0) [0|0] "" BRIDGE

BO_ 440 BLUETOOTH_DATA: 8 BRIDGE
 SG_ BLUETOOTH_DATA_LAT : 0|32@1+ (0.000001,0) [0|0] "" MASTER
 SG_ BLUETOOTH_DATA_LON : 32|32@1+ (0.000001,-127) [0|0] "" MASTER

BO_ 450 NEXT_CHECKPOINT_DATA: 8 MASTER
 SG_ NEXT_CHECKPOINT_DATA_latitude : 0|32@1+ (0.000001,0) [0|0] "" GEO
 SG_ NEXT_CHECKPOINT_DATA_longitude : 32|32@1+ (0.000001,0) [0|0] "" GEO

BO_ 460 COMPASS_DATA: 5 GEO
 SG_ COMPASS_DATA_speed : 0|8@1+ (1,0) [0|0] "" MASTER
 SG_ COMPASS_DATA_heading : 8|16@1+ (1,0) [0|0] "" MASTER
 SG_ COMPASS_DATA_bearing : 24|16@1+ (1,0) [0|0] "" MASTER

BO_ 470 CURRENT_LOCATION_ACK: 1 BRIDGE
 SG_ CURRENT_LOCATION_ACK_ack : 0|8@1+ (1,0) [0|0] "" MASTER,GEO

BO_ 480 GPS_LOCATION: 8 GEO
 SG_ GPS_LOCATION_latitude : 0|32@1+ (0.000001,0) [0|0] "" MASTER,BRIDGE
 SG_ GPS_LOCATION_longitude : 32|32@1+ (0.000001,0) [0|-127] "" MASTER,BRIDGE

BO_ 490 DISTANCE_TO_DESTINATION: 1 GEO
 SG_ DISTANCE_TO_DESTINATION_data : 0|8@1+ (0,0) [0|0] "" MASTER, MOTORIO

BO_ 500 BATTERY_STATUS: 1 SENSOR
 SG_ DISTANCE_TO_DESTINATION_status : 0|8@1+ (0,0) [0|0] "" MASTER, MOTORIO 

CM_ BU_ DRIVER "Master Controller";
CM_ BU_ SENSOR "Sensor Controller";
CM_ BU_ MOTORIO "Motor I/O controller";
CM_ BU_ BRIDGE "BRIDGE Controller";
CM_ BU_ GEO "Geo Controller";
CM_ BO_ 2 "Sync message used to synchronize the controllers"; 

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

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

BA_ "GenMsgCycleTime" BO_ 400 	          10;
BA_ "GenMsgCycleTime" BO_ 410             10;        
BA_ "GenMsgCycleTime" BO_ 450             10;
BA_ "GenMsgCycleTime" BO_ 460             10;
BA_ "GenMsgCycleTime" BO_ 470             10;
BA_ "GenMsgCycleTime" BO_ 480             10;

PCAN Dongle and BUS Master

PCAN Dongle
BUS MASTER

The DB9 connector is interfaced to the CAN bus. Using this interface, we can monitor the CAN bus through a tool called BusMaster. PCAN Dongle is used to view the CAN messages on the CAN Bus on the GUI. This has helped us in debugging CAN related errors on all the 5 controllers.

Can Transceiver

CAN Transceiver
CAN Transceiver Pins


MCP2551 Pinout

Sensor Controller

Team Members & Responsibilities

  • Shruthi Narayan
  • Rimjhim Ghosh

Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 10/5/2016 10/11/2016
  • Research and order the sensors
 Completed 10/9/2016
2 10/12/2016 10/18/2016
  • Study data sheets and identify pins
  • Prepare hardware connection diagram with SJOne Board
 Completed 10/18/2016
3 10/19/2016 10/25/2016
  • Wire the sensors and check with the sample code
  • Prepare the sensor DBC file
Completed 10/25/2016
4 10/26/2016 11/1/2016
  • Interface sensor to SJOne board. Read sensor values and filter the readings
  • Prepare sensor values to be sent over CAN bus and test the correctness of sensor CAN messages
 Completed 11/1/2016
5 11/2/2016 11/8/2016
  • Collaborate to achieve basic obstacle avoidance for Project Prototype Demo
Completed 11/8/2016
6 11/9/2016 11/15/2016
  • Implement and integrate code with multiple sensors
 Completed 11/15/2016
7 11/16/2016 11/22/2016
  • Test and debug the integrated module
 Completed 11/22/2016
8 11/23/2016 11/29/2016
  • Collaborate with the other module teams to make sure that the sensors are in working condition for Project Prototype Demo-2
 Completed 11/29/2016
9 11/30/2016 12/6/2016
  • Test for stability of sensors
 Completed 12/5/2016
10 12/7/2016 12/17/2016
  • Code testing during final phases. Modify code in cooperation with other teams for Final Project Demo
 Completed 12/16/2016

Hardware Design

Four Parallax Ping ultrasonic distance sensors are used in this project for obstacle detection and avoidance.

Non-contact obstacle distance can be measured from about 2 cm (0.8 inches) to 3 meters (3.3 yards).

The PING))) sensor works by transmitting an ultrasonic burst and providing an output pulse that corresponds to the time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.

Four Sensors are mounted on the car.
Three in the front: front_left, front_center, front_right
One at the back: back

This data related to obstacle detection from each of the four sensors is communicated to the Master Controller over the CAN bus.


CmpE243 F16 Kasper Sensor Ping Blink2.gif

In the above picture, Burst indicator LED blinking shows measurement in progress.


The image below shows the wired connections between sensors and SJOne board.


Sensor Hardware Interface block diagram
Sensors mounted on car

Software Design

Operation Squence:

Sensor Operation Flowchart
Sensor Sequential Ranging

Software timer for triggering sensor:

All sensors are triggered using software timers. A soft timer is declared for each sensor which keeps track of the time between trigger and echo for that particular sensor. 

#define Echo_Return_Pulse 18.5
SoftTimer ping_duration_left;
ping_duration_left.reset(Echo_Return_Pulse);
ping_duration_left.restart();

Hardware timer for calculating distance:

The declaration of hardware timer is as shown below: 

lpc_timer_enable(lpc_timer0,1); /*enable timer0*/
lpc_timer_set_value(lpc_timer0,0); /*set timer0 value=0*/

Distance Calculation:

Distance=Speed * Time

The distance covered by the sound wave is twice the actual distance.

Therefore, Distance= (Speed * Time)/2

Speed of sound=340m/s, 1m=100cm, 1us=0.000001 s

Distance covered in 1us= (340*100*0.000001)/2 = 0.017cm 

#define Distance_Scale 0.017
time_left = lpc_timer_get_value(lpc_timer0);
distance_left = (Distance_Scale)*time_left;


Ranging: 

LeftSIG.setAsOutput(); /*make SIGpin output*/
LeftSIG.setLow(); /*set low for 2us and then high for clean high*/
delay_us(2);
LeftSIG.setHigh(); /* enable Ranging (enable left sonar). trigger/set high for 2 µs (min), 5 µs typical. Ultrasonic burst*/
delay_us(5);
LeftSIG.setLow(); /*set low*/
LeftSIG.setAsInput(); /*make SIGpin input*/

Implementation

Sensor Testing: LV-MaxSonar-EZ(MB1010):

• This sensor gives a range of 0 inches to 254 inches with a voltage supply of 5V.

• Using multiple ultrasonic sensors in a single system caused interference (crosstalk) so the sensors were triggered sequentially which reduced the fluctuating values

• The range reading time of Maxbotix LV-MaxSonar-EZ1 is 49 ms for a range of 254 inches (6.54 m) requirement was to send all sensor values in 10 Hz. Only 2 sensor values could be sent.

• Having the requirement to send the sensor readings in 10Hz, we reduced the delay between the sensors to 15ms covering a range of 101 inches. Send values of all the four sensors (left, center, right, back) in 10Hz using chaining process.

• Even after this there were frequent abrupt values encountered in the readings so considering the fluctuations and requirement we switched to parallax ping sensors.


Sensor Testing: Parallax Ping

Parallax Ping Sensor-Front View
Parallax Ping Sensor- Back View

Pin Configuration

Pin1: GND- Ground pin

Pin2: 5V- Voltage Supply pin

Pin3: SIG- Signal Pin- This emits a short 40Khz burst acting as a trigger pin then the same pin starts listening the echo.


Ping Sensor Features

• Provides precise, non-contact distance measurements within a 2 cm to 3 m range

• Simple pulse in/pulse out communication requires just one I/O pin

• Burst indicator LED shows measurement in progress

• 3-pin header makes it easy to connect to a development board, directly or with an extension cable, no soldering required

• The PING))) sensor works by transmitting an ultrasonic (well above human hearing range) burst and providing an output pulse that corresponds to the time required for the burst echo to return to the sensor. By measuring the echo pulse width, the distance to target can easily be calculated.

Parallax Ping Sensor Coomunication Protocol

The PING))) sensor detects objects by emitting a short ultrasonic burst and then "listening" for the echo. Under control of a host microcontroller (trigger pulse), the sensor emits a short 40 kHz (ultrasonic) burst. This burst travels through the air, hits an object and then bounces back to the sensor. The PING))) sensor provides an output pulse to the host that will terminate when the echo is detected, hence the width of this pulse corresponds to the distance to the target.

Working of Parallax Ping Sensor

Ping Sensor Considerations for use:

The PING))) sensor cannot accurately measure the distance to an object that:

  • is more than 3 meters away
  • that has its reflective surface at a shallow angle so that sound will not be reflected back towards the sensor
  • is too small to reflect enough sound back to the sensor
  • if the sensor is mounted low on the device, it will detect sound reflecting off of the floor.
Ping Sensor Object Positioning

Testing & Technical Challenges

Issue 1: Triggering of Sensors in Parallel

Triggering all the sensors in parallel causes interference between adjacent sensors, which in turn causes mis-firing of echo. This results in incorrect distance values from all the sensors.

Solution: Sequential triggering of Sensors Each sensor is triggered only when the previous sensor receives an echo or exceeds the maximum echo reception wait time which is 18.5ms.


Issue 2: Sensor Angle

The Left and Right sensors gave faulty values when placed at an acute angle on the corner of the base board.

Solution: angle>45

Increased the angle to cover wider area and avoid reflections. Increasing the angle to more than 45 degrees helped us get accurate values.

Motor & I/O Controller

Team Members & Responsibilities

Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/27/2016 10/04/2016
  • Finalize project and team schedule and update project wiki
 Completed 10/04/2016
2 10/04/2016 10/11/2016
  • LCD module selection and purchase
 Completed 10/07/2016
3 10/11/2016 10/18/2016
  • Understanding DC and Servo motor and testing the basic functionality
 Completed 10/15/2016
4 10/18/2016 10/25/2016
  • Interfacing motors and test control of motors from the SJOne board
 Completed 10/24/2016
5 10/25/2016 11/1/2016
  • Control the motors using received CAN messages
Completed 11/1/2016
6 11/1/2016 11/15/2016
  • Discuss with other teams to get simulated inputs from GPS and sensor module and test car control with those inputs. (Testing of obstacle avoidance)
 Completed 11/15/2016
7 11/15/2016 11/28/2016
  • Collaborate with other teams to establish CAN communication between all the modules
 Completed 11/28/2016
8 11/28/2016 12/05/2016
  • Product testing and trial runs
Completed 12/20/2016


Pulse Width Modulation

Pulse Width Modulation

Pulse-width modulation (PWM), is a modulation technique which encodes a message into a pulsing signal. Pulse width modulation is a type of digital signal. It is mainly used to control the power supplied to electrical devices such as motors. Pulse width modulation is used in a variety of applications including sophisticated control circuitry. PWM pulse are supplied to the DC and Servo motors in our project. They help in rotating and turning the wheels of the RC car, respectively.

Duty Cycle
When the signal is high this is the “ON time”. To describe the amount of “on time” the concept of duty cycle is introduced. Duty cycle is measured in percentages. The percentage duty cycle specifically describes the percentage of time a digital signal is ON over an interval or period of time. This period is the inverse of the frequency of the waveform.

If a digital signal spends half of the time ON and the other half OFF, we would say the digital signal has a duty cycle of 50% and resembles an ideal square wave. If the percentage is higher than 50%, the digital signal spends more time in the high state than the low state and vice versa if the duty cycle is less than 50%.

Electronic Speed Controller

Electronic Speed Controller

An electronic speed control or ESC is an electronic circuit which is used to vary the electric motor's speed.It also behaves as a dynamic brake. ESCs are used on electrically powered radio controlled cars, essentially providing an electronically generated three-phase electric power low voltage source of energy for the motor.

There are two different types of RC motors, brushed and brushless. Each motor type has its own kind of ESC (Electronic Speed Controller). Without an ESC, the DC motor of the RC car would either not move or it will go at full throttle when the car is driven. Brushed motors are cheap but very ineffecient and lack power. Brushless motors are efficient, powerful, fast, and last much longer. The main visual difference between the two is that the brushless is sealed completely and has three wires, while the brushed has ventilation holes and two wires.

Servo Motor

Battery
Servo PWM Signals

The RC car came with a digital servo motor. The motor works without ESC. The motor is controlled by giving PWM signal from the SJOne board. RC Servos are used to convert electrical signal into polar or linear movement. When signal is transmitted from the control to the car, this signal is decoded and sent to a servo. According to this signal, the servo will rotate it's drive shaft by some degrees, and this rotation is translated into wheel steering. The power supply of servos is usually from 3 to 5 volts.

The RC servos are controlled with a PWM signal driven to their signal wire. A PWM signal has three parameters that characterizes it: The first is the amplitude (or peak to peak voltage) of the signal which is around 3 to 5 volts according to it's specifications. The second is the frequency. In PWM, the frequency is usually fixed to a value.The third and most critical value is the positive pulse width of the PWM, i.e. the "duty cycle". The width of the pulse will have a direct result into the drive shaft position.

Servo Motor Connections

ESC Wire Pins SJOne Board Pins
Vcc 3V3
GND GND
Turn Control P2.0

Servo motor is controlled with the help of three wires coming out of the servo motor. The wires are VCC, GND and Direction control. The VCC is connected to the 3.3v. GND and direction control are connected to the ground and pwm pins of SJOne board.

DC Motor

DC Motor

A DC motor converts direct current electrical power into mechanical power. The most common types rely on the forces produced by magnetic fields.

Pulse width modulation (PWM) is used to control the motor. One advantage is that the power loss in the switching transistor is small because the transistor is either fully “ON” or fully “OFF”. The RC Car came with the motor that needed 7.4V of power supply to work. The motor has the power to run the car at a maximum speed of 35mph. DC motor is controlled with the help of three wires coming out of the ESC. These wires are VCC, GND and Speed control.

Place the car on a raised platform in such a way that the wheels of the car are not touching any surface. Given below is the code snippet for testing out the dc motors using the on-board switches of the SJ One circuit. 

        
        if(SW.getSwitch(1))
	{
		dc_stop();
	}
	else if(SW.getSwitch(2))
	{
		dc_accelerate(6.4);
	}
	else if(SW.getSwitch(3))
	{
		dc_accelerate(6.2);
	}
	else if(SW.getSwitch(4))
	{
		dc_accelerate(7.6);
	}

On pressing the on-board switches the wheels of the car would rotate at different speeds.Pressing switch 2 and 3 would make the wheels rotate in he forward direction. The value of the PWM duty cycle can be varied to try out different speeds. Pressing Switch 1 would stop the rotation of the wheel. Switch 4 allows the reversing of the rotation of the wheel. On pressing these switches, either of two functions, shown below are called. 

void dc_accelerate(float pwmValue)
{
	MotorControl.setDC(pwmValue);
	stop_flag = true;
}

void dc_stop(void)
{
	if(stop_flag)
	{
		MotorControl.setDC(DC_STOP);
		stop_flag = false;
	}
}

MotorControl is an object from the MotorController singleton class. The Motorcontroller class has 2 functions-setDC() and setServo(). setDC() is used to drive the car while setServo() is used to control the turning of the car.

DC PWM Signals


DC Motor Connections

ESC Wire Pins SJOne Board Pins
Vcc -
GND GND
Speed Control P2.1

The VCC line is not used as the required voltage is directly given to the motor through a battery, via ESC. The GND line and Speed control lines are connected to the ground and PWM pin of SJOne board.The DC motor was driven using PWM2 i.e. pin P2.1 of the SJOne board. In-built PWM generation function was used. It requires two parameters, one is pin being used and the other being the frequency.



Motor/IO Controller Software Design

Tasks

Motor/IO Controller Tasks
Task Name Purpose
Period Init CAN Bus Initialization, Reset CAN Bus
Periodic 1Hz Callback Check if CAN bus off and Reset bus. Reset the RPM counter. Send data to LCD.
Periodic 10Hz Callback Drive car according to the commands received from Master controller

Motor Pin Connections

The car runs on Ni-MH batteries. The battery powers the ESC unit, which in turn drives the motor and also powers the steering servo. The SJ One board, ESC unit and steering servo should share a common ground in order for the PWM signals to have the same reference voltage. The CAN transceiver uses the 5V power supply and GND, along with the P0.0 (CAN RX) and P0.1 (CAN TX) of the SJ One Board. P2.0 (PWM1) and P2.1 (PWM2) controls the steering and motor respectively. This is done by sending out PWM signals from the SJ One board that change the width of a 20ms period waveform. 1ms width represents a 0% duty cycle, 1.5ms width represents a 50% duty cycle, and 2ms width represents a 100% duty cycle.


Node A Source Node A Pin Node B Source Node B Pin Description
3.3V Power Supply 3.3V SJOne Board 3V3 SJOne Power
3.3V Power Supply GND SJOne Board GND SJOne Ground
CAN Transceiver CAN Tx SJOne Board P0.1 (Tx) SJOne - CAN Tx
CAN Transceiver CAN Rx SJOne Board P0.0 (Rx) SJOne - CAN Rx
CAN Transceiver 5V 5V Power Supply 5V SJOne - CAN Power
CAN Transceiver Ground 5V Power Supply GND SJOne - CAN Ground
CAN Transceiver CANL CAN BUS CANL CANL to CAN BUS
CAN Transceiver CANR CAN BUS CANR CANR to CAN BUS
Steering Servo PWM Port SJOne Board P2.0 PWM Steering Control
Steering Servo Ground SJOne Board GND Common ground for reference voltage
ESC/Motor PWM Port SJOne Board P2.1 PWM Motor Control
ESC/Motor Ground SJOne Board GND Common ground for reference voltage

Hardware Design

Motor Controller Block Diagram

Software Flow Diagram

CmpE243 F16 Kasper Motorflowchart.jpg

Speed Feedback Encoder

Hall effect Sensor

The speed feedback is simply an RPM meter. It consists of a Hall Effect Magnetic sensor with a set of magnets. The magnets are attached to the inner surface of the wheels and the sensor is connected to the end of the shaft connecting the wheel. Whenever the magnet comes near the sensor, a high signal is generated from the sensor and given to the GPIO port of the SJOne board, which is made as positive edge triggered. The interrupt handler would then increment a count which would give us revolutions per second if the above mentioned count is measured over one second (1Hz periodic callback function).


CmpE243 F16 Kasper Hall sensor tach.gif

CmpE243 F16 Kasper RPMReal.PNG

The next step is to control the speed with this calculated rpm. There are two conditions that need to be checked. One is the speed that the MASTER controller is sending (stop, slow, normal or fast) and another is the rpm. Each of the speeds would have a desired rpm and the calculated rpm is compared to the desired rpm and the final PWM signal to the DC motor is incremented or decremented depending on that. A scenario for this usage would be when the car encounters an upward ramp and the car would slow down while climbing to that. The algorithm would check and sense that the rpm has reduced and would modify PWM for DC to increase power and hence the RPM of car is kept at the desired range.

Liquid Crystal Display

CmpE243 F16 Kasper LCD.PNG

IO is the mode of interaction between user and car peripherals. LCD displays the car status while the touch screen allows the user to shift between the various modes. The touch screen GLCD uLCD32PTU has the following features Low-cost 3.2" LCD-TFT display graphics user interface solution. 240 x 320 VGA resolution, RGB 65K true to life colours, TFT screen with Integrated 4-Wire Resistive Touch Panel. Easy 5 pin interface to any host device: VCC, TX, RX, GND, RESET Powered by 4D-Labs PICASO processor. 2 x Asynchronous hardware serial ports (COM0, COM1), TTL interface, with 300 to 600K baud. On-board micro-SD memory card adaptor for multimedia storage and data logging purposes. HC memory card support is also available for cards larger than 4GB. 4.0V to 5.5V range operation (single supply).


The LCD is used to display vital parameters such as

  • Speed
  • Sensor Readings
  • Obstacle proximity
  • GPS co-ordinates
  • Current and heading compass zone

Shown below are some of the LCD screens created.

First words on LCD
KAPSER Teammates
Sensor and GPS readings 1
Sensor and GPS readings 2



Testing & Technical Challenges

Issue 1: DC motor not responding to PWM signals given to ESC

Even though the PWM signals that were generated from the SJOne board were identical to those generated by the company issued remote control of the car (simulated and checked using the CRO), the DC motor was still not responding to the signals.

Solution: Create the PWM objects just once and never destroy them

This solution, obtained after much research online, was implemented using a singleton class which would be used to declare the PWM objects to pass the signal values and would hence declare the PWM objects only one and never be destroyed or re-initialized. It is essential to understand Pulse width Modulation.

Issue 2: Car Reversing on giving Forward Pulse.

We observed that initially after turning on the ESC, sometimes the car would go reverse on providing the forward pulse.

Solution:Provide the car a STOP pulse for around 20ms in the Init function of the Periodic scheduler.

This solution helps in the calibration of the ESC. Based on the initial pulse received, the ESC is calibrated. Any delay in switching on the ESC and resetting the SJ ONE board, may lead to the Reverse issue. Hence, the ESC had to be switched on simultaneously while resetting the SJ ONE board. This eliminated the unwanted reverse.

Issue 3: Erratic readings while using the Light Sensor for Motor feedback.

Initially we used the Light sensor to measure the RPM of the car. This was done by taping a white patch on to the front wheel of the car and the sensor was placed just above the wheel. Light sensor should not be used for Motor Feedback purpose since the Light readings were erratic.

Solution:Use Magnetic Hall Effect sensors.

Using the magnetic sensors eliminated the erratic readings. One tricky part is that the sensors need to be mounted really close to the magnets. It is essential to test the car on different terrains and observe if the car is able to move without any difficulty.

Geographical Controller

Team Members & Responsibilities

  • Ankit Gandhi

GPS, Compass firmware and Hardware Interfacing.

Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/28/2016 10/4/2016
  • Study previous project reports and order GPS and Compass modules
 Complete 10/6/2016
3 10/5/2016 10/11/2016
  • Pin Identification for GPS module on SJOne and connection diagram
  • Pin Identification for Compass module on SJOne and connection diagram
 Complete 10/10/2016
4 10/12/2016 10/18/2016
  • Identify power requirements for the GPS module
  • Interfacing GPS module with SJone, Firmware Development and NMEA sentence parsing
  • Individual testing of GPS module with SJOne Board
 Complete 10/18/2016
5 10/19/2016 10/25/2016
  • Identify power requirements for the GPS module
  • Interfacing Compass Module with SJOne Board and Firmware Development
  • Individual testing of Compass module with SJOne Board
 Complete 10/26/2016
6 10/26/2016 11/01/2016
  • Calibrating GPS and Compass Module
  • Interfacing the GPS and compass module to Android application.
 Complete 11/02/2016
7 11/02/2016 11/08/2016
  • Integrate GPS and Compass module with Master using CAN
 Complete 11/09/2016
8 11/09/2016 12/05/2016
  • Testing and debugging with whole system
Complete 12/11/2016

Design & Implementation

Hardware Design

Components

SJOne Board

Ultimate GPS

The breakout is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels


  • 512K ROM, 64K(96K) RAM, 1M(2M) SPI Flash, and Micro-SD for storage.
  • Arm Cortex-M4 variant contains 96K RAM, and 2Mb SPI flash
  • 2-Digit 7-Segment Display
  • Power from USB or External Power
  • Many GPIOs with two SPI, Multiple UARTs, and I2C and CAN availability





GPS Module

Ultimate GPS

The breakout is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels


  • -165 dBm sensitivity, 10 Hz updates, 66 channels
  • 5V friendly design and only 20mA current draw
  • RTC battery-compatible
  • Internal patch antenna + u.FL connector for external active antenna

The Compass Module - LSM303DLHC

Compass

Compass module is based on ST Micros LSM303. When current flows through a wire, a magnetic field is created. This is the basic principle behind electromagnets. This is also the principle used to measure magnetic fields with a magnetometer. The direction of Earth's magnetic fields affects the flow of electrons in the sensor, and those changes in current can be measured and calculated to derive a compass heading.

The features of LSM303DLHCare:

  • Simple I2C interface
  • 3 magnetic field channels and 3 acceleration channels
  • ±2g/±4g/±8g/±16g linear acceleration full scale
  • From ±1.3 to ±8.1 gauss magnetic field full scale




Following is the Geo Controller system diagram

Cmpe243 F16 kasper geo block diagram.jpg

Hardware Interface

Below table lists all the hardware pins used in Geo Controller

Geographical Controller Pin Connection Table
Device Description Bus Device Pins SJOne Board Pins
MCP2551 CAN Transceiver CAN1 
RD
TD
Vcc
GND 

RD1 P0.0
TD1 P0.1
5V
GND
GPS Module UART2 
Rx
Tx
Vcc
GND 

TXD2 P2.8
RXD2 P2.9
5V
GND
Compass I2C2 
SDA
SCL 
Vcc
GND

SDA2 P0.10
SCL2 P0.11
Vcc
GND

Software Design

  • Initialization
GPS module is interfaced using UART. UART is initialized using the most common configuration 9600/8-N-1(9600 baudrate, 8 databits, no (N) parity bit, and  :one (1) stop bit.
We are using LSM303DLHC compass module. Both GPS and Compass modules are initialized as below.
 void geotaskInit()
 {
     gpsUart.init(GPS_BAUD_RATE,rx_q,tx_q);   // Initialize UART for GPS
     LSM_MAG.init();                          // Initialize LSM303 Magnetometer 
     LSM_ACCL.init();                         // Initialize LSM303 Accelerometer
 }
  • Data Communication with GPS and Compass

GPS

GPS module is programmed to send GPS data at 10Hz. Interrupt Handler continuously receives these data and stores in the queue.
Periodically (10Hz) calling the getChar function gives a complete NMEA string.
Following string is used to set NMEA output sentence, we are using GPRMC for this project(Done in initialization)
char gpsRMConlyCommand[] = "$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n";
char gpsOutputFrequency[] =  "$PMTK220,100*2F\r\n";
After sending this, we will be getting GPS string after every 10Hz, which is read by interrupt handler.
Angle between two coordinates

Compass

Compass data is read and send every 10Hz. Compass data consists of Bearing, Distance and Heading
Bearing Calculation:
Bearing angle between two GEO coordinates is calculated using following formula 
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
  where, φ1,λ1 is the start point
  φ2,λ2 the end point 
  (Δλ is the difference in longitude)
Bearing Angle



Distance Calculation:
Distance between two GEO coordinates is calculated using following formula 
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c
  where φ is latitude, λ is longitude, 
  R is earth’s radius (mean radius = 6,371km);



  • CAN Communication
In GeoController, we are using can1 for transmitting and receiving can messages. Latitude and longitude values are getting updated periodically.


  void geoTask::sendGpsData()
  {
      if(recvdTrueGPSData == true)
      {
          GPS_LOCATION_t geoGpsData = { 0 };
          geoGpsData.GPS_LOCATION_latitude = curLatitude;
          geoGpsData.GPS_LOCATION_longitude = curLongitude;
          u0_dbg_printf("lat : %f lon: %f\n",curLatitude,curLongitude);
          // This function will encode the CAN data bytes, and send the CAN msg using dbc_app_send_can_msg()
          dbc_encode_and_send_GPS_LOCATION(&geoGpsData);
          recvdTrueGPSData = false;
      }
   }

  void geoTask::sendCompassData()
  {
      COMPASS_DATA_t geoCompassData = { 0 };
      calculateDistance();
      if(newChkPointRecvd)
      {
          calculateBearing();
          newChkPointRecvd = false;
      }
      LSM_MAG.getHeading(&heading);
      geoCompassData.COMPASS_DATA_bearing = bearing;
      geoCompassData.COMPASS_DATA_heading = heading;
      geoCompassData.COMPASS_DATA_speed = speed;
      geoCompassData.COMPASS_DATA_distance = distance;
      u0_dbg_printf("head: %f,bearing:%f,Dis:%.2f\n",heading,bearing,distance);
      // This function will encode the CAN data bytes, and send the CAN msg using dbc_app_send_can_msg()
      dbc_encode_and_send_COMPASS_DATA(&geoCompassData);
   }

Geo Software Flow Diagram

Geo Software Flowdiagram

Testing & Technical Challenges

1. Compass Calibration

Initially compass doesn't give correct readings,compass needs to be calibrated before it can be used. -->Used following Arduino sketch to get the minimum and maximum readings of the compass on all three axes. 

void loop() 
{  
   compass.read();
   running_min.x = min(running_min.x, compass.m.x);
   running_min.y = min(running_min.y, compass.m.y);
   running_min.z = min(running_min.z, compass.m.z);
   running_max.x = max(running_max.x, compass.m.x);
   running_max.y = max(running_max.y, compass.m.y);
   running_max.z = max(running_max.z, compass.m.z);
   snprintf(report, sizeof(report), "min: {%+6d, %+6d, %+6d}    max: {%+6d, %+6d, %+6d}",
   running_min.x, running_min.y, running_min.z,
   running_max.x, running_max.y, running_max.z);
   Serial.println(report);
   delay(100);
}

Use of these Minimum and Maximum Values in the calculation gives better readings

Another issue with compass is tilt compensation. If compass is tilted it gives wrong readings. Tilt needs to be compensated using Accelerometer readings. 

pitch = asin(-accxnorm);
roll = asin(accynorm/cos(pitch));
where accxnorm and accynorm are normalized x and y acceleration vector respectively.

Communication Bridge Controller

Team Members & Responsibilities

  • Bharat Khanna
  • Shantanu Vashishtha


Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/20/2016 09/27/2016
  • Dividing the project into smaller tasks.
  • Based on the number of tasks allocating each task to a team of two.
 Complete 09/27/2016
2 09/28/2016 10/4/2016
  • Study previous project reports and order Bluetooth module and other components based on the following factors:
  • Power requirement, preferably with input voltage within SJOne board output voltage range.
  • Review of the components that give few or no hardware errors.
  • Ease of integration with SJOne board.
 Complete 10/9/2016
3 10/5/2016 10/11/2016
  • Understanding Bluetooth module hardware design and protocol requirement for communication.
  • Figuring out the pins on SJOne board required for communication with Bluetooth module.
 Complete 10/11/2016
4 10/12/2016 10/18/2016
  • CAN message ID's, priorities, data size and format proposals for all the possible CAN messages on the bus.
  • Planning methods for testing Bluetooth module.
 Complete 10/18/2016
5 10/19/2016 10/25/2016
  • Work on Bluetooth firmware development to integrate with SJ one board.
 Complete 10/25/2016
6 10/26/2016 11/08/2016
  • Develop basic Android application to work with the Bluetooth module.
  • Test the communication between SJ one board and Android application over Bluetooth protocol.
 Complete 11/08/2016
7 11/9/2016 11/20/2016
  • Interface Bluetooth module with CAN.
  • Integration of geolocation API with mobile APP.
  • Testing the Bluetooth module with Mobile application by incorporating filter.
 Complete 11/20/2016
8 11/21/2016 12/05/2016
  • Testing the Bluetooth module with Master controller using CAN communication
  • Testing and debugging of the complete system.
 Complete 12/18/2016

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.

Bluetooth Module

Bluetooth Module

RN42XV is built around Microchip's RN42 low power Bluetooth module. Some features of this module are as follows


  • Based on the popular 2 x 10 (2mm) socket footprint.
  • Voltage range: (3-3.6)Volts
  • Current range: 26 μA sleep, 3 mA connected, 30 mA transmit.
  • UART data connection interface.
  • Sustained data rates: 240 Kbps (slave), 300 Kbps (master)
  • Transmission range up to 60 feet (20 m) distance, +4 dBm output transmitter, -80 dBm typical receive sensitivity.
  • FHSS/GFSK modulation, 79 channels at 1-MHz intervals.

Hardware Design

The interface between Bluetooth module and controller is as shown in fig
Interface between Bluetooth module and controller

Hardware Interface

The interface between Bluetooth module and controller is as shown in fig
Pinout Bridge Controller
The interface between Bluetooth module and controller is as shown in fig
Table CAN Message and_Message ID

Bluetooth Software Design

The main functions that are used for communication are as follows. 

void Check_Start_STOP__CheckPoint_Condition()
{
	if(strcmp(stored_Bluetooth_data,START) == 0)
	{
		START_CONDITION.START_CMD_APP_data = 1;
		dbc_encode_and_send_START_CMD_APP(&START_CONDITION);
		memset(stored_Bluetooth_data, 0, sizeof(stored_Bluetooth_data));
	}
	else if(strcmp(stored_Bluetooth_data,STOP) == 0)
	{
		STOP_CONDITION.STOP_CMD_APP_data = 1;
		dbc_encode_and_send_STOP_CMD_APP(&STOP_CONDITION);
		memset(stored_Bluetooth_data, 0, sizeof(stored_Bluetooth_data));
	}
	else if(check_received == true)
	{
		int loop =0;
		BRIDGE_TOTAL_CHECKPOINT.BRIDGE_TOTAL_CHECKPOINT_NUMBER = check_point_total;
		dbc_encode_and_send_BRIDGE_TOTAL_CHECKPOINT(&BRIDGE_TOTAL_CHECKPOINT);
		for(loop = 0; loop < (check_point_total*2) ;loop=loop+2)
 		{
			BLUETOOTH_DATA_Location.BLUETOOTH_DATA_LAT = store_cor[loop];
			BLUETOOTH_DATA_Location.BLUETOOTH_DATA_LON = store_cor[loop+1];
			dbc_encode_and_send_BLUETOOTH_DATA(&BLUETOOTH_DATA_Location);
		}
		check_received = false;
	}
 } 




void Can_Receive_ID_Task()
{
	if (CAN_rx(can1, &can_msg_Info, 0))
	{
		LE.off(1);
		dbc_msg_hdr_t can_msg_hdr;
		can_msg_hdr.dlc = can_msg_Info.frame_fields.data_len;
		can_msg_hdr.mid = can_msg_Info.msg_id;
		if(can_msg_Info.msg_id == RESET_HDR.mid)
			dbc_decode_RESET(&REST_Info, can_msg_Info.data.bytes, &can_msg_hdr);
		if(can_msg_Info.msg_id == RECEIVE_START_ACK_HDR.mid)
			printf("Case_RECEIVE_START_ACKt\n");
		if(can_msg_Info.msg_id == BRIDGE_POWER_SYNC_HDR.mid)
			printf("BRIDGE_POWER_SYNC_data\n");
		if(can_msg_Info.msg_id == GPS_LOCATION_HDR.mid)
		{
			dbc_decode_GPS_LOCATION(&GPS_LOCATION_RECEIVE, can_msg_Info.data.bytes, &can_msg_hdr);
			sprintf(lat,"%f",GPS_LOCATION_RECEIVE.GPS_LOCATION_latitude);
			sprintf(lon,"%f",GPS_LOCATION_RECEIVE.GPS_LOCATION_longitude);
		        Send_App_curr_loc(lat,lon);
		}
		if(dbc_handle_mia_RESET(&REST_Info, 1))
		{
			REST_Info.RESET_data=RESET__MIA_MSG.RESET_data;
			LD.setNumber(REST_Info.RESET_data);
			LE.on(1);
		}
	}
}
The interface between Bluetooth module and controller is as shown in fig
Bluettoh Software FLow Chart

Implementation

The aim of the project is the design and development of an autonomous vehicle which should be able to traverse from its current location to the destination provided by the user. The destination is provided by the user via Android mobile application. The bridge controller refers to communication between the master controller and the mobile application which is established using RN42XV Bluetooth module. The data that is received via mobile application is start command, stop command, total number of checkpoints and checkpoints itself. The SJOne boards establishes communication with Bluetooth module using UART communication protocol. Once the data is received by the Bluetooth controller it is then sent to the master controller using CAN communication protocol.

Android Application Design

Problem statement

In present day, what is that one thing, which has become an essential part of a human life? Yes, that's correct, the answer is smartphone. It is almost impossible to imagine a single day without a mobile phone. So whether it is for a bank transaction or daily grocery shopping or travel, we need all the updated information in our hand. Keeping in mind this technological need, an application to control and track our self driving car prototype makes total sense. With universality of android platform, we decide to make an adnroid application to control our self driving car prototype "Kasper".

Implementation

The objective of the Android application is to allow the user to communicate with the self driving car using a smartphone. The application is built using Android Studio. It is the official IDE for Android platform development. The project uses .java file to design the logic of the app. To integrate maps within your application, an API key from Google's developer console is required. This API helps Google in tracking the statistics related to the app. When a device is clicked, map pops up which means that map fragment has been successfully implemented. Application uses Android Application framework (API level 25). There are four activities responsible for complete functionality of the application, namely FirstActivity.java, MapActivity.java and LatLong.java.

1. FirstActivity.java is responsible for screen 1 and has some basic buttons to "Turn ON" bluetooth for the device, find available bluetooth devices, make the smartphone discoverable to other devices, list paired devices and "Turn OFF" bluetooth on the device. After selecting an appropriate bluetooth module listed in the paired devices/available devices list, application makes a transition to screen 2.

2. The most basic information that a user must be able to control in a self-driving car is the source and the destination. The source in the application is designed to set with the current location sent by GPS module to bluetooth controller. Screen 2 is controlled by MapActivity.java that opens a map. This file is responsible for creating a bluetooth socket that allows communication between the app and the actual hardware. After the map is visible, destination is marked manually by the user, by selecting a point on the integrated Google map API. The format of the point selection is such that the application will consider the final/last checkpoint as destination while the rest markers will be considered as intermediate checkpoints. Once the user is done marking the check points, the information is sent to Bluetooth controller in the following format:
n,latitude_1,longitude_1...latitude_n,longitude_n
Here, n is number of checkpoints and (latitude_n,longitude_n) will be considered as the destination points by the Bluetooth controller. Once this information is sent, application waits for an acknowldgement in the form of "ack$" from the Bluetooth controller to ensure that the coordinates have been received. If there is no acknowldgement then the start button will not become active. After receiving acknowledgement, start button becomes active and the car will start moving when the button is asserted. Also, at a time only one of the two start or stop button is active. So, once a start button is pushed it is deactivated and stop is active now.
MapActivity.java also includes a handler for receiving messages like current location and then updating them on the map. It also receives coordinates at regular intervals to track the car location.

3. LatLong.java file has a public class with variables and methods that can used anywhere. This is done to set and get the latitude and longitude values.

Bluetooth - Android Interface

Bluetooth - Android interface


Command format and functionality

SI No. Button Description Screen Command format
1 Turn ON When this button is pressed it will ask user to turn ON the bluetooth.

If the bluetooth is already on then it will display "Already on" message.

Screen 1 --
2 Turn OFF When this button is pressed it will send a command to hardware to disable the bluetooth. Screen 1 --
3 Get Visible When this button is pressed it will ask user to make bluetooth device visible to other devices for 120 seconds. Screen 1 --
4 List Devices When this button is pressed it will display all the previously paired devices in a list view on the screen. Screen 1 --
5 Find Devices If the intended device is not in the List Devices list then press this button to search for available devices and then connect. Screen 1 --
6 Connect When this button is pressed it will update the map with the current location sent by the GPS module to the Bluetooth controller. Screen 2
  • Sent: connect
  • Received: loc,latitude,longitude$
7 Send After configuring the checkpoints, this button is used to send the coordinates of the selected points. Screen 2
  • Sent: latitude,longitude
8 Updating car location The car location can be tracked depending upon the GPS data. Screen 2
  • Received - ab,latitude,longitude$
9 Start/Stop At a time only one of the button is active. Start will run the car while Stop will stop the car. Screen 2
  • For Start - start
  • For Stop - stop

Application workflow

Flowchart


Application features

Android application has major features that exploit real time data. Once the phone is connected to the bluetooth module application starts sending and receiving data to perform number of operations. Features are listed below:
1. First feature is to get the current location. Application sends a command to request bluetooth module for updating the current location. After receiving the current location coordinates, application updates them on the Google map API used.
2. Second remarkable feature is updating the map with destination along with check points. This feature is highly desirable as it maps real life situation, in which destination is not reached instantly, but going from one checkpoint to another. Once the checkpoint have been marked they are sent to the master controller.
3. Third feature provide a layer of reliability during communication. Once the checkpoints have been sent, start car button will not become active until there is an acknowldgement from the bluetooth controller that it has received the destination coordinates along with checkpoints. This ensures that the car will not go to any random location.
4. The fourth most important feature in the application is that it exploits the real time data sent by the GPS module. As the car starts moving, GPS coordinates change. This new data is received by the application that helps in tracking the current car location. This feature is extremely useful to trace the route that is taken by the car (if there is any obstacle in the initial path).

Android UI design

Android App Icon
Application Homepage. RNBT is the Bluetooth module name
Map with connect button
App showing current location
Check points marked


Start button visible after sending coordinates
Route to the destination. Yellow dot is the current car location

Testing

  • For testing purpose, the code is made modular which means that each functionality in the code is defined in different functions. This approach makes it easier to check the output at different levels, which makes it easier to verify the output at different levels.
  • The testing for Bluetooth module is done using "Bluetooth Serial Terminal" Application

Technical Challenges

  • Technical challenge faced while communicating between Android app and Bluetooth was sending the current location which is achieved by updating the send_cor_buffer after every 10 milliseconds and sending updated coordinates.

Master Controller

Team Members & Responsibilities

  • Aajna Karki
  • Spoorthi Mysore Shivakumar

Schedule

SI No. Start Date End Date Task Status Actual Completion Date
1 09/26/2016 10/05/2016
  • Understand the tasks involved and the overall scope of the Master Controller
  • Finalise on the CAN transceiver to be used and place an order for the same
 Complete 10/05/2016
2 10/06/2016 10/18/2016
  • Finalise on the node addresses and message IDs for each of the CAN controllers
  • Implement the DBC file
 Complete 10/18/2016
3 10/19/2016 10/25/2016
  • Understand the overall hardware design and build the car
  • Establish CAN communication with the other controllers based on the DBC file
  • Test the basic power-up interactions with the controllers
 Complete 10/25/2016
4 10/26/2016 11/07/2016
  • Design and implement the Obstacle avoidance algorithm
 Complete 11/07/2016
5 11/08/2016 11/15/2016
  • Co-ordinate during the integration of the motor and sensor modules from the Master Controller perspective
  • Establish complete communication across different CAN controllers interfaced
  • Strictly monitor sync and the stop command from bluetooth
  • Design and start the implementation of the Navigation Algorithm
 Complete 11/20/2016
6 11/16/2016 11/29/2016
  • Test the full-fledge functionality of Obstacle Avoidance algorithm based on data from all the sensors and commands to the motor controller.
  • Verify communication with Bluetooth controller for accurate check-point data
  • Test the functionality of Navigation algorithm with the location data from Geocontroller
 Complete 11/29/2016
7 11/29/2016 12/06/2016
  • Test the algorithms for any unaccounted scenarios or issues faced
  • Verify the accuracy of data received from all controllers and the response from the Master Controller
 Complete 12/12/2015
8 12/06/2016 12/15/2016
  • Test extensively and debug issues
 Complete 12/18/2016

Design & Implementation

The Master Controller is responsible for driving the car based on the Obstacle Avoidance and Navigation algorithm.

Obstacle avoidance algorithm uses the sensor data and drives the motor accordingly. Navigation algorithm uses the data from compass to adjust the direction of the car based on the destination.

Hardware Design

Master Controller is interfaced to CAN transceiver as shown below.
CAN messages are transmitted and received over the bus establishing communication with the rest of the controllers.

Hardware Interface

Master Controller is concerned with the implementation of algorithms to drive the car.
The hardware interface is only to the CAN transceiver over which communication with the rest of the controllers happens.

Master Controller interface to CAN transceiver

Software Design

Master Controller receives CAN messages in the 100Hz periodic function.
The functionality to drive the car based on Obstacle Avoidance and Navigation Algorithm is implemented in the 10Hz periodic function.
The 1Hz periodic function implements the logic to check if CAN bus is on/off.


Functionality in 1 and 100Hz of Master Controller



The drive commands to the car are based on the Obstacle Avoidance and the Navigation algorithm.
Obstacle avoidance is given priority over Navigation Algorithm.
If no obstacles are encountered, the control falls to the Navigation algorithm which directs the car to the destination.


Functionality in 10Hz of Master Controller


Obstacle Avoidance Algorithm:

Three zones are declared based on the distance of the obstacle - NEAR zone, MEDIUM zone and FAR zone.

Based on which zone the obstacle is encountered in, appropriate decisions are made to drive the car.


Navigation Algorithm:

The compass readings obtained range from 0 to 360. Based on the readings, the data is divided into quadrants. Based on each of the value received, appropriate drive decisions are made.

Navigation Algorithm has lower priority as compared to Obstacle Avoidance algorithm.

Below is the detailed flowchart of Obstacle and Navigation Algorithm

Obstacle And Navigation Algorithm

Implementation

The overall function of the Master Controller can be visualized through the following state machines:

Initial State
This is the initial state of the car when no commands are received. The car is dormant at this point.

Send Checkpoints
Once the checkpoint data is received from the Bridge controller, it is saved in an array.
The checkpoints need to be sent to Geo controller sequentially. As and when a particular checkpoint is reached, next checkpoint data needs to be sent.
The state of the controller in which checkpoint data is sent constitutes this state.

Navigating
Navigation is started only after the Start command is received from the Bridge Controller.
When a CAN message with the Start command is received, the state of the car is changed to Navigating.

Stop Car
When Stop command is received from the Bridge Controller, the state of the car is changed to Stop Car. Motor commands are sent to stop the car.

State Diagram


In terms of coding, they are defined as enum values: 

enum STATE_CAR{
	SEND_CHECKPOINTS,
	NAVIGATING,
	STOP_CAR,
	INITIAL_STATE
};

Testing & Technical Challenges

Few challenges faced during the phase of the project are as below:

CAN Receive function
It is advisable that the system has only one CAN Receive. The values can be be populated in 100Hz and used in 1Hz/10Hz based on priority. Having more than one CAN receive can result in messages being missed.
When reading messages in 100Hz , an 'if' instead of 'while' could be used so that there is no task overrun.

Conclusion

The self driving car project has definitely helped us learn and grow in terms of technical knowledge as well as team management. Right from choosing the hardware components by considering every aspect of its functionality to programming them, this project has indeed given us an end-to-end learning of the entire system. There has been a lot of decision making which has resulted in many brain-storming sessions with the team as a whole.

The different phases of the project have been significant in their own terms. Selection of hardware is of utmost importance. We have had scenarios where we changed the ultrasonic sensors and the RPM sensors for greater accuracy. A major learning is that component selection needs diligent efforts. Sticking to the demo timelines would help a great deal. Code reviews would be beneficial as well.

We, as a team, have learnt how to build a machine from scratch. We also have learnt how a considerably big team can manage their particular modules and co-ordinate with the other modules as well. Team management has been a good takeaway here.

It has been overall a tremendous learning experience. I hope the further projects benefit from our learning curve documented.

Project Video

Kasper Project video

Other video links

  • Obstacle Avoidance

Obstacle avoidance

  • Sensor and LED blinking test

Sensor Testing Video

Project Source Code

References

Acknowledgement

This project has been an amazing learning experience for the whole team. The knowledge we take from here is immense. We are grateful to Professor Preetpal Kang for his guidance and efforts towards making our learning commendable. Also, we would like to extend our sincere thanks to the ISA team for their continuous support. Here is a special mention to the Kasper team for all their meticulous and diligent efforts towards making this project a reality.

References Used

[1] Preetpal Kang's lecture notes of CMPE 243, Computer Engineering, San Jose State University, Aug-Dec 2016. 
[2] Fall 2015 Wiki Projects
[3] LPC1758 User Manual
[4] Parallax Ultrasonic Sensor
[5] CAN Transceiver
[6] Razor IMU
[7] LSM303 Application Note
[8] Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3
[9] GPS data calculation accuracy
[10] GPS Longitude Latitude distance calculator
[11] Calculate distance between two points
[12] GLCD with Touchscreen
[13] GPS Datasheet
[14] CAN Communication
[15] Hall effect sensor

Retrieved from "http://socialledge.com/sjsu/index.php?title=F16:_Kasper&oldid=40910"