Difference between revisions of "F17: Optimus"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Geographical Controller)
(→‎Hardware Specifications)
 
(428 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
== '''Optimus''' ==
 
−
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.
 
  
−
== Abstract ==
+
{|
 +
|
 +
|
 +
|[[File:CMPE243_F17_Optimus_car_2.png|300px|thumb|left|Optimus left view]]
 +
|
 +
|
 +
|
 +
|
 +
|[[File:CMPE243_F17_Optimus_car_1.png|600px|thumb|center|Optimus front view]]
 +
|
 +
|
 +
|
 +
|
 +
|[[File:CMPE243_F17_Optimus_car_3.png|300px|thumb|right|Optimus right view]]
 +
|
 +
|}
 +
 
 +
'''Optimus''' - An Android app controlled Self Navigating Car powered by SJOne(LPC1758) microcontroller. Optimus manuevers through the selected Routes using LIDAR and GPS Sensors. This wiki page covers the detailed report on how Optimus is built by Team Optimus.
 +
 
 +
== '''Abstract''' ==
 +
 
 +
Embedded Systems are omnipresent and one of its unique, yet powerful application is  Self Driving Car. In this project we to build a Self-Navigating Car named Optimus, that navigates from a source location to a selected destination by avoiding obstacles in its path.
 +
 
 +
The key features the system supports are
 +
 
 +
1. Android Application with Customized map and Dashboard Information.
 +
 
 +
2. LIDAR powered obstacle avoidance.
 +
 
 +
3. Route Calculation and Manuvering to the selected destination
 +
 
 +
4. Self- Adjusting the speed of the car on Ramp.
 +
 
 +
The system is built on FreeRTOS running on LPC1758 SJOne controller and Android application.
 +
The building block of Optimus are the five controllers communicating through High Speed CAN network designed to handle dedicated tasks. The controllers integrates various sensors that is used for navigation of the car.
 +
 
 +
      '''1. Master Controller''' -  handles the Route Manuevering and Obstacle Avoidance
 +
      '''2. Sensor Controller''' -  detects the surrounding objects
 +
      '''3. Geo Controller''' - provides current location
 +
      '''4. Drive Controller''' - controls the ESC
 +
      '''5. Bridge controller''' - Interfaces the system to Android app
 +
{|
 +
|[[ File: CMPE243_F17_Optimus_SystemArchitecture.png|650px|thumb|left|System Architecture]]
 +
|
 +
|[[ File: CMPE243_F17_Optimus_Application.png |400px|thumb|right|Android  Application]]
 +
|
 +
|}
 +
 
 +
== '''Objectives & Introduction''' ==
 +
 
 +
Our Objective is to build and integrate the functionality of these five controllers to develop fully functioning self-driving system.
 +
 
 +
''' Sensor Controller: '''
 +
Sensor controller uses RPLIDAR to scan its 360-degree environment within 6-meter range. It sends the scanned obstacle data to master controller and bridge controller.
 +
 
 +
''' Geo Controller: '''
 +
Geo controller uses NAZA GPS module that provides car current GPS location and compass angle. It calculates heading and bearing angle that helps the car to turn with respect to destination direction.
 +
 
 +
''' Drive Controller: '''
 +
Drive controller drives the motor based on the commands it receives from the Master.
 +
 
 +
''' Bridge Controller: '''
 +
Bridge controller works as a gateway between the Android application and Self-driving car and passes information to/from between them.
 +
 
 +
''' Master Controller: '''
 +
Master controller controls all other controllers and takes decision of drive.
 +
 
 +
''' Android Application: '''
 +
Android application communicates with the car through Bridge controller. It sends the destination location to be reached to the Geo controller and also provides  all the Debugging information  of the Car like
  
−
<br clear= all>
+
1. Obstacles information around the car
  
 +
2. Car's turning angle
  
 +
3. Compass value
  
−
[[|thumb|centre|700px|System Diagram]]
+
4. Bearing angle
  
−
== Objectives & Introduction ==
+
5. Car's GPS location
  
−
== Team Members & Responsibilities ==
+
6. Destination reached status
−
*  Android and Communication Bridge:[[|233px|right]]
 
−
** [ Parimal]<br>
 
−
*  Geographical Controller:
 
−
** [ Sneha]<br>
 
−
** [ Sarvesh]<br>
 
−
*  Master Controller:
 
−
** [ Unnikrishnan]
 
−
** [ Revathy]<br>
 
−
** [ Kripanand]
 
−
*  Motor Controller
 
−
** [ Unnikrishnan]<br>
 
−
** [ Rajul]<br>
 
−
*  Sensor and I/O Controller:
 
−
** [ Sushma]<br>
 
−
** [ Supradeep]<br>
 
−
** [ Harshitha]<br>
 
  
−
== Schedule ==
+
7. Total checkpoints in the route
 +
 
 +
8. Current checkpoint indication
 +
 
 +
== '''Team Members & Responsibilities''' ==
 +
 
 +
*  '''Master Controller''':
 +
** Revathy
 +
 
 +
*  '''Motor Controller''':
 +
** [https://www.linkedin.com/in/unnikrishnan-sreekumar-4a3b8922/ Unnikrishnan]<br>
 +
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul]<br>
 +
 
 +
*  '''Sensor and I/O Controller''':
 +
** [https://www.linkedin.com/in/sushma-nagaraj Sushma]<br>
 +
** [https://www.linkedin.com/in/supradeepk/ Supradeep]<br>
 +
** [https://www.linkedin.com/in/harshitha-bura-4926727a/ Harshitha]
 +
 
 +
*  '''Android and Communication Bridge''':
 +
** [https://www.linkedin.com/in/parimal-basu-67b92430 Parimal]<br>
 +
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha]<br>
 +
** [https://www.linkedin.com/in/unnikrishnan-sreekumar-4a3b8922/ Unnikrishnan]<br>
 +
 
 +
*  '''Geographical Controller''':
 +
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha]<br>
 +
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare]<br>
 +
 
 +
* '''Integration Testing''':
 +
** Revathy
 +
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha]<br>
 +
**[https://www.linkedin.com/in/unnikrishnan-sreekumar-4a3b8922/ Unnikrishnan]
 +
 
 +
* '''PCB Design''':
 +
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul]<br>
 +
 
 +
== '''Project Schedule''' ==
 
Legend:
 
Legend:
  
Line 247: Line 334:
 
** <font color="purple">[Geo:] Advertised distance to the next checkpoint (again using Haversine's algorithm)<br></font>
 
** <font color="purple">[Geo:] Advertised distance to the next checkpoint (again using Haversine's algorithm)<br></font>
 
** <font color="purple">[Geo:] Saving the checkpoints in SDCARD on GEO Controller<br></font>
 
** <font color="purple">[Geo:] Saving the checkpoints in SDCARD on GEO Controller<br></font>
 +
** <font color="blue"> Implemented start-stop triggers from android and auto start on start of route navigation <br></font>
 +
** <font color="blue">Turning angle from geo is handled with offset <br></font>
 
** <font color="clouds"> battery-status is optional feature. Planning for later <br></font>
 
** <font color="clouds"> battery-status is optional feature. Planning for later <br></font>
 
** <font color="clouds"> Indicate checkpoint proximity using backlight indicators<br></font>
 
** <font color="clouds"> Indicate checkpoint proximity using backlight indicators<br></font>
Line 307: Line 396:
 
|
 
|
 
* <font color="orange"> Major Feature: Full feature integration test <br></font>
 
* <font color="orange"> Major Feature: Full feature integration test <br></font>
−
| On Track
+
| complete
 
|}
 
|}
  
−
== Parts List & Cost ==
+
== '''Parts List & Cost''' ==
 
The Project bill of materials is as listed in the table below.
 
The Project bill of materials is as listed in the table below.
 +
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| Item#
+
! scope="col"| SNo.
−
! scope="col"| Part Description
+
! scope="col"| Component
−
! scope="col"| Vendor
+
! scope="col"| Units
−
! scope="col"| Qty
+
! scope="col"| Total Cost
−
! scope="col"| Cost
 
 
|-
 
|-
−
! scope="row"| 1
+
|-
 +
! colspan="4"| General System Components
 +
|-
 +
|-
 +
| 1
 
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
 
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
−
| From Preet
+
| 5
−
| 6
+
| $400
−
| $480
 
 
|-
 
|-
−
! scope="row"| 2
 
−
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview]
 
−
| Prof. Kaikai Liu provided
 
−
| 1
 
−
| $0
 
 
|-
 
|-
−
! scope="row"| 3
 
−
| [https://www.adafruit.com/products/1120 Accelerometer/Magnetometer LSM303]
 
−
| Adafruit
 
 
| 2
 
| 2
−
| $40.00
+
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
 +
| 1
 +
| From Prof. Kaikai Liu
 
|-
 
|-
−
! scope="row"| 4
 
−
| [https://www.sparkfun.com/products/12582 Bluetooth Module]
 
−
| Sparkfun
 
−
| 1
 
−
| $34.95
 
 
|-
 
|-
−
! scope="row"| 5
+
| 3
 
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
 
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
−
| From ebay.
 
 
| 15
 
| 15
−
| $51
+
| $55
 
|-
 
|-
−
! scope="row"| 6
+
|-
−
| [https://traxxas.com/products/parts/batteries/idpowercellbatteries/nimh/2926X-7C-hump-SubC-3000mAh Battery Pack]
+
|-
−
| From Sheldon Hobbist
+
| 4
 +
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
 
| 1
 
| 1
−
| $49.99
+
| From Preet
 
|-
 
|-
−
! scope="row"| 7
+
|-
−
| RP Lidar
+
| 5
−
|  
+
| [https://www.pcbway.com PCB Manufacturing]
 
| 5
 
| 5
−
| $400
+
| $70
 +
|-
 +
|-
 +
| 6
 +
| 3D printing
 +
| 2
 +
| From Marvin
 +
|-
 +
|-
 +
| 6
 +
| General Hardware components( Connectors,standoffs,Soldering Kits)
 +
| 1
 +
| $40
 +
|-
 
|-
 
|-
−
! scope="row"| 8
+
| 7
−
| LED $ Digit Display
+
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
−
| From Preet
 
 
| 1
 
| 1
−
| $0
+
| $41.50
 
|-
 
|-
−
! scope="row"| 9
+
|-
−
| [https://www.adafruit.com/products/746 GPS Module]
+
| 8
−
| From Adafruit
+
| LED Digital Display
 
| 1
 
| 1
−
| $43.34
+
| From Preet
 
|-
 
|-
−
! scope="row"| 10
 
−
| General Components
 
−
| From Amazon
 
−
| -
 
−
| $
 
 
|-
 
|-
−
! scope="row"| 11
+
| 9
−
|[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
+
| [https://www.amazon.com/AdirOffice-Acrylic-Plexiglass-Sheet-Weatherproof/dp/B072BY9L5B/ref=sr_1_1?ie=UTF8&qid=1513524920&sr=8-1&keywords=acrylic+board+clear Acrylic Board]
−
| From traxxas
 
 
| 1
 
| 1
−
| $20
+
| $12.53
 +
|-
 +
|-
 +
! colspan="4"| Sensor/IO Controller Components
 +
|-
 
|-
 
|-
−
! scope="row"| 12
+
| 10
−
| PCB
+
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
−
|  
 
 
| 1
 
| 1
−
| $10.66
+
| $449
 +
|-
 +
|-
 +
! colspan="4"| Geo Controller Components
 +
|-
 
|-
 
|-
−
! scope="row"| 13
+
| 11
−
| Acrylic Board
+
| [https://www.amazon.com/DJI-NAZA-M-V2-GPS-Module/dp/B00O11YQXQ/ref=sr_1_5?ie=UTF8&qid=1513760869&sr=8-5&keywords=naza+gps GPS Module]
−
| From Amazon
 
 
| 1
 
| 1
−
| $12.53
+
| $69
 +
|-
 +
|-
 +
! colspan="4"| Bluetooth Bridge Controller Component
 +
|-
 
|-
 
|-
−
! scope="row"| 14
+
| 12
−
|[http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
+
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
−
| From Preet
 
 
| 1
 
| 1
−
| $0
+
| $34.95
 
|-
 
|-
−
! scope="row"| 15
+
|-
−
|[https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
+
! colspan="4"| Drive Controller Component
−
| From Amazon
+
|-
 +
|-
 +
| 13
 +
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
 
| 1
 
| 1
−
| $41.50
+
| $20
 
|-
 
|-
−
! scope="row"| 16
 
−
|[https://www.pcbway.com PCB Manufacturing]
 
−
| From PCB Way
 
−
| 5
 
−
| $70
 
 
|-
 
|-
 
|}
 
|}
  
 
== '''CAN Communication''' ==
 
== '''CAN Communication''' ==
−
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO
+
The controllers are connected in a CAN bus at 100K baudrate.
 +
System Nodes: MASTER, MOTOR, BLE, SENSOR, GEO
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 434: Line 529:
 
| 1
 
| 1
 
| 2
 
| 2
−
| System Start command to start motor
+
| System Stop command to stop motor
 
| Motor
 
| Motor
 
|-
 
|-
Line 471: Line 566:
 
|-
 
|-
 
|-
 
|-
−
| 4
+
| 6
 
| 195
 
| 195
 
| Compass, Destination Reached flag, Checkpoint id signals
 
| Compass, Destination Reached flag, Checkpoint id signals
Line 477: Line 572:
 
|-
 
|-
 
|-
 
|-
−
| 5
+
| 7
 +
| 196
 +
| GPS Lock
 +
| Master,BLE
 +
|-
 +
|-
 +
| 8
 
| 4
 
| 4
 
| Turning Angle
 
| Turning Angle
Line 483: Line 584:
 
|-
 
|-
 
|-
 
|-
−
| 5
+
| 9
−
| 4
+
| 214
 +
| Current Coordinate
 +
| Master,BLE
 +
|-
 +
|-
 +
| 10
 +
| 37
 
| Heartbeat
 
| Heartbeat
 
| Master
 
| Master
Line 493: Line 600:
 
|-
 
|-
 
|-
 
|-
−
| 4
+
| 11
 +
| 1
 +
| System start/stop command
 +
| Master
 +
|-
 +
|-
 +
|-
 +
|-
 +
| 12
 
| 38
 
| 38
 
| Heartbeat
 
| Heartbeat
Line 499: Line 614:
 
|-
 
|-
 
|-
 
|-
−
| 5
+
| 13
 
| 213
 
| 213
 
| Checkpoint Count from AndroidApp  
 
| Checkpoint Count from AndroidApp  
Line 505: Line 620:
 
|-
 
|-
 
|-
 
|-
−
| 5
+
| 14
−
| 214
+
| 212
−
| Checkpoints(Lat,Long) from Android App
+
| Checkpoints (Lat, Long) from Android App
 
| Geo
 
| Geo
 
|-
 
|-
 
|-
 
|-
−
|}
+
! colspan="4"| Drive Controller Message
−
 
 
−
== '''DBC File''' ==
 
−
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc <br>
 
−
 
 
−
== Android and Communication Bridge ==
 
−
==== Group Members ====
 
−
*'''''[http://www.linkedin.com/in/manali-deshmukh-a8a33994 Manali Deshmukh]<br> '''''
 
−
 
 
−
=== Design & Implementation ===
 
−
The Android and communication bridge controller is responsible for establishing communication between the car and the Android app using BlueSMiRF RN41 bluetooth module.  The Android app sends the check points to the car helping it to make its way to the destination and also receives the data from various modules to be displayed on the app. The data is transferred and recieved from other controllers via CAN bus. The bluetooth module communicates with the SJOne board using UART communication at 115200 bps.  The SJOne and bluetooth module connections are as follows: <br>
 
−
 
 
−
[[File:CMPE_243_F16_SnF_BLE_Block_Diagram.gif|thumb|centre|1200px|BLE Block Diagram]]
 
−
 
 
−
=====Pin Configuration: =====
 
−
{| class="wikitable"
 
 
|-
 
|-
−
! scope="col"| Sl. No
 
−
! scope="col"| Pin on SJOne Board
 
−
! scope="col"| Pin on BlueSMiRF RN41 Bluetooth module
 
−
! scope="col"| Purpose
 
 
|-
 
|-
 +
| 15
 +
| 193
 +
| Telemetry Message
 +
| BLE
 
|-
 
|-
−
|1
 
−
|TXD2
 
−
|RXD
 
−
|Transmit using UART2(TXD2) to RN41
 
 
|-
 
|-
 +
| 16
 +
| 35
 +
| Heartbeat
 +
| Master
 
|-
 
|-
−
|2
 
−
|RXD2
 
−
|TXD
 
−
|Receive using UART2(RXD2) from RN41
 
 
|-
 
|-
−
|-
 
−
|3
 
−
|3V3
 
−
|VCC
 
−
|3.3V voltage supply
 
−
|-
 
−
|-
 
−
|4
 
−
|GND
 
−
|GND
 
−
|Ground
 
 
|}
 
|}
  
−
=== Hardware Design ===
+
=== '''DBC File''' ===
  
−
[[File:CMPE243 F16 SnF Bluetooth Modem.jpg|thumb|right|250px|Bluetooth Modem]]
+
The CAN message id's transmitted and received from all the controllers are designed based on the priority of the CAN messages.  
 +
The priority is as follows
  
−
Bluetooth Module BleSMiRF Gold
+
Priority Level 1 - User Commands
−
Features:
 
−
*v6.15 Firmware
 
−
*FCC Approved Class 1 Bluetooth****Radio Modem
 
−
*Extremely small radio - 0.15x0.6x1.9"
 
−
*Very robust link both in integrity and transmission distance (100m) - no more buffer overruns!
 
−
*Low power consumption : 25mA avg
 
−
*Hardy frequency hopping scheme - operates in harsh RF environments like WiFi, 802.11g, and Zigbee
 
−
*Encrypted connection
 
−
*Frequency: 2.402~2.480 GHz
 
−
*Operating Voltage: 3.3V-6V
 
−
*Serial communications: 2400-115200bps
 
−
*Operating Temperature: -40 ~ +70C
 
−
*Built-in antenna
 
  
−
=== Software Design and Implementation===
+
Priority Level 2 - Sensor data
  
−
The Software design for the app is as follows:
+
Priority Level 3 - Status Signals
  
−
1. The current location of the car is extracted through the GPS of the mobile.
+
Priority Level 4 - Heartbeat
  
−
2. As per location, a route is calculated by the app and checkpoints is sent to the BLE module(SJ-one board)
+
Priority Level 5 - Telemetry signals to display in I/O
  
−
3. The Decoding of the received messages is implemented in 10Hz task.
+
BU_: DBG DRIVER IO MOTOR SENSOR MASTER GEO BLE
  
−
4. Due to challenges faced to parse data in 10Hz, decision was made to shift parsing of data to 1Hz task.
+
BO_ 1 BLE_START_STOP_CMD: 1 BLE
 +
SG_ BLE_START_STOP_CMD_start : 0|4@1+ (1,0) [0|1] "" MASTER
 +
SG_ BLE_START_STOP_CMD_reset : 4|4@1+ (1,0) [0|1] "" MASTER
  
−
5. After parsing the data, the checkpoints are then send over the CAN bus to Geo module for processing.
+
BO_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
−
   
+
  SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR
−
[[File:CMPE243 F16 SnF BLE Software Implement.png|thumb|left|500px|BLE Module Software Implementation]]
 
−
<br clear=all>
 
  
−
===== Android App =====
+
BO_ 212 BLE_GPS_DATA: 8 BLE
 +
SG_ BLE_GPS_long : 0|32@1- (0.000001,0) [0|0] "" GEO
 +
SG_ BLE_GPS_lat : 32|32@1- (0.000001,0) [0|0] "" GEO
  
−
A bluetooth connection is established between android app and bluetooth module. The android app sends a start bit on UART to the master controller to indicate the start of the app and it acts as the start button for the car. The app starts listening to the incoming data and fetches the current location of the car. The distance is calculated between the start and destination location. The JSON is generated from the google map API from where we fetch the check points to be sent to the geo controller. The app also displays the relevant car information for the user.
+
BO_ 213 BLE_GPS_DATA_CNT: 1 BLE
 +
SG_ BLE_GPS_COUNT : 0|8@1+ (1,0) [0|0] "" GEO,SENSOR
  
−
[[File:CMPE 243 F16 SnF BLE Flowchart.jpg|thumb|center|700px|Android App Flow Chart]]<br>
+
BO_ 214 GEO_CURRENT_COORD: 8 GEO
−
[[File:CMPE243_F16_SnF_AppScreen1.jpeg|thumb|left|200px|App Screen 1]]
+
SG_ GEO_CURRENT_COORD_LONG : 0|32@1- (0.000001,0) [0|0] "" MASTER,BLE
−
[[File:CMPE243_F16_SnF_AppScreen2.jpeg|thumb|center|200px|App Screen 2]]
+
SG_ GEO_CURRENT_COORD_LAT : 32|32@1- (0.000001,0) [0|0] "" MASTER,BLE
  
−
[[File:CMPE243_F16_SnF_AppScreen3.jpeg|thumb|left|200px|App Screen 3]]
+
BO_ 195 GEO_TELECOMPASS: 6 GEO
−
[[File:CMPE243_F16_SnF_AppScreen4.jpeg|thumb|center|200px|App Screen 4]]
+
SG_ GEO_TELECOMPASS_compass : 0|12@1+ (0.1,0) [0|360.0] "" MASTER,BLE
 +
SG_ GEO_TELECOMPASS_bearing_angle : 12|12@1+ (0.1,0) [0|360.0] "" MASTER,BLE
 +
SG_ GEO_TELECOMPASS_distance : 24|12@1+ (0.1,0) [0|0] "" MASTER,BLE
 +
SG_ GEO_TELECOMPASS_destination_reached : 36|1@1+ (1,0) [0|1] "" MASTER,BLE
 +
SG_ GEO_TELECOMPASS_checkpoint_id : 37|8@1+ (1,0) [0|0] "" MASTER,BLE
  
−
<br clear=all>
+
BO_ 194 MASTER_TELEMETRY: 3 MASTER
 +
SG_ MASTER_TELEMETRY_gps_mia : 0|1@1+ (1,0) [0|1] "" BLE
 +
SG_ MASTER_TELEMETRY_sensor_mia : 1|1@1+ (1,0) [0|1] "" BLE
 +
SG_ MASTER_TELEMETRY_sensor_heartbeat : 2|1@1+ (1,0) [0|1] "" BLE
 +
SG_ MASTER_TELEMETRY_ble_heartbeat : 3|1@1+ (1,0) [0|1] "" BLE
 +
SG_ MASTER_TELEMETRY_motor_heartbeat : 4|1@1+ (1,0) [0|1] "" BLE
 +
SG_ MASTER_TELEMETRY_geo_heartbeat : 5|1@1+ (1,0) [0|1] "" BLE
 +
SG_ MASTER_TELEMETRY_sys_status : 6|2@1+ (1,0) [0|3] "" BLE
 +
SG_ MASTER_TELEMETRY_gps_tele_mia : 8|1@1+ (1,0) [0|1] "" BLE
  
−
===== BLE Controller =====
+
BO_ 196 GEO_TELEMETRY_LOCK: 1 GEO
 +
SG_ GEO_TELEMETRY_lock : 0|8@1+ (1,0) [0|0] "" MASTER,SENSOR,BLE
 +
 +
BO_ 3 SENSOR_LIDAR_OBSTACLE_INFO: 6 SENSOR
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR0 : 0|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR1 : 4|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR2 : 8|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR3 : 12|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR4 : 16|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR5 : 20|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR6 : 24|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR7 : 28|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR8 : 32|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR9 : 36|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR10 : 40|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR11 : 44|4@1+ (1,0) [0|12] "" MASTER,BLE
  
−
The BLE controller initially enables the uart2 and CAN bus to establish communication between the app and other modules on the CAN bus. The car starts with the command from the app which is received in the 10Hz task and is sent to master module to notify other modules on the CAN bus. After generating route on the app, the app sends the check points to the BLE controller which parses the latitude and longitude values and sends it to the Geo module through the CAN bus.
+
BO_ 4 GEO_TURNING_ANGLE: 2 GEO
 +
SG_ GEO_TURNING_ANGLE_degree : 0|9@1- (1,0) [-180|180] "" MASTER,BLE
  
−
[[File:CMPE243 F16 SnF BLE.jpg|thumb|left|700px|Communication Bridge Flow Chart]]
 
−
<br clear=all>
 
  
−
=== Testing & Technical Challenges ===
+
The CAN DBC is available at the Gitlab link below
−
While receiving data from android app, it was observed that there was loss of information due to the buffer size and the receive queue size. It was solved by increasing the buffer and queue size and also due to baudrate, decision was made to receive data in 10Hz and use the same in 1 Hz task. Thus, by adjusting the transfer rates the data loss was reduced.
 
  
−
In the android application, bluetooth connectivity was limited to the main activity only and it was difficult to pass it to multiple activities. Therefore, the app was built on only one main activity by processing the data in the background to avoiding crashing. This was done because there are chances of crashing since the UI cannot handle too much on processing.
+
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc <br>
  
−
Due to data loss on the app side, it was decided to take the current location from the app and generate the check points. Therefore, to reduce data loss the data was transmitted and received in a thread.
+
=== CAN Bus Debugging ===
 +
We used PCAN Dongle to connect to the host pc to monitor the CAN Bus traffic using BusMaster tool. The screenshot of the Bus Master log is shown below
  
−
==Geographical Controller==
+
[[ File:CMPE243_F17_Optimus_Busmaster.png|600px|thumb|center|| BusMaster CAN Signal Log]]
−
==== Group Members ====
 
−
*'''''[https://www.linkedin.com/in/sneha-shahi-8b1636152/ Sneha Shahi]<br> '''''
 
−
*'''''[https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare]<br> '''''
 
  
−
=== Hardware Design ===
+
== '''Hardware & Software Architecture'''  ==
  
−
'''GPS Module and Compass:'''
+
== '''Master Controller''' ==
  
−
We are using DJI’s NAZA GPS/COMPASS to get the GPS coordinates and Heading angle
+
=== Software Architecture Design ===
  
−
[[ File: CMPE243_F17_Optimus_Gps|600px|thumb|center|| Hardware Schematic]]
+
The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the Self Navigating car. Two of the major functionalities handled by Master Controller is Obstacle avoidance and Route Maneuvering.
  
−
The message structure of the GPS and Compass module is as follows:
+
The overview of Master Controller Software Architecture is as show in the figure below.
 +
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]
  
−
Message Structure:
+
As an analogy to Human driving, it receives the inputs from sensors to determine the surrounding of the Self Navigating car and take decisions based on the environment and current location of the car. The input received and output sent by the Master are as mentioned below:
−
The 0x10 message contains GPS data. The message structure is as follows:
 
−
55 AA 10 3A DT DT DT DT LO LO LO LO LA LA LA LA
 
−
The payload is XORed with a mask that changes over time.
 
−
Values in the message are stored in little endian.
 
  
−
HEADER
+
Input to Master:
−
-------------
 
−
BYTE 1-2: message header - always 55 AA
 
−
BYTE 3: message id (0x10 for GPS message)
 
−
BYTE 4: length of the payload (0x3A or 58 decimal for 0x10 message)
 
  
−
PAYLOAD
+
1. Lidar Object Detection information - To determine if there is an obstacle in the path of navigation
−
--------------
 
−
BYTE 5-8 (DT): date and time
 
−
BYTE 9-12 (LO): longitude (x10^7, degree decimal)
 
−
BYTE 13-16 (LA): latitude (x10^7, degree decimal)
 
  
−
CHECKSUM
+
2. GPS and Compass Reading - To understand the Heading and Bearing angle to decide the direction of movement
−
-----------------
 
−
BYTE 63-64 (CS): checksum
 
  
−
XOR mask
+
3. User command from Android - To stop or Navigate to the Destination
−
---------------
 
−
All bytes of the payload except 53rd (NS), 54th, 61st (SN LSB) and 62nd (SN MSB) are XORed with a mask. Mask is calculated based on the value of byte 53rd (NS) and 61st (SN LSB).
 
  
−
=== Software Design ===
+
Output from Master:
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_System_Flowchart.jpg|1200px|thumb|center|| Geo-Controller Flowchart]]
+
1. Motor control information - sends the target Speed and Steering direction to the Motor.
  
−
'''Flow of Geo Algorithm:'''
+
=== Software Implementation ===
 +
The Master controller runs 2 major algorithms, Route Maneuvering and Obstacle Avoidance. The System start/stop is handled by master based on the Specific commands.
 +
The implicit requirement is that When the user selects the destination, route is calculated and the checkpoints of the route are sent from Android through bridge controller to the Geo. Once Geo Controller receives a complete set of checkpoints, the master controller starts the system based on the "Checkpoint ID". If the ID is a non-zero value, the route has started and Master controller runs the Route Maneuvering Algorithm.
  
−
1. Receive System start command from master
+
The Overall control flow of master controller is shown in the below figure.  
 +
[[ File: CMPE243_F17_Optimus_MasterControlFlow.png|700px|thumb|center|| Process Flowchart]]
  
−
2. Check for GPS Fix.
+
==== Unit Testing ====
  
−
3. If Fix available, send current vehicle geographical coordinates(Latitude and Longitude) to Android via Bluetooth.
+
Using Cgreen Unit Testing framework, the Obstacle avoidance algorithm is unit tested.The complete code for unit test is added in git project.
  
−
4. Android receives the current vehicle location, identifies vehicle destination point along with the checkpoints and sends the checkpoints to Geo Controller via CAN.
+
Ensure(test_obstacle_avoidance)
 +
{
 +
    //Obstacle Avoidance Algorithm
 +
    pmaster->set_target_steer(MC::steer_right);
 +
    mock_obstacle_detections(MC::steer_right,MC::steer_right,false,false,false,false,false,false,true);
 +
    assert_that(pmaster->RunObstacleAvoidanceAlgo(obs_status),is_equal_to(expected_steer));
 +
    assert_that(pmaster->get_forward(),is_equal_to(true));
 +
    assert_that(pmaster->get_target_speed(),is_equal_to(MC::speed_slow));
 +
}
 +
Ensure(test_obstacle_detection)
 +
{
 +
    //Obstacle Detection Algorithm
 +
    mock_CAN_Rx_Lidar_Info(2,2,6,0,2,2,4,0,2,0,5,0);
 +
    set_expected_detection(true,false,true,false,true,false,false);
 +
    actual_detections = psensor->RunObstacleDetectionAlgo();
 +
    assert_that(compare_detections(actual_detections) , is_equal_to(7));
 +
}
 +
TestSuite* master_controller_suite()
 +
{
 +
    TestSuite* master_suite = create_test_suite();
 +
    add_test(master_suite,test_obstacle_avoidance);
 +
    add_test(master_suite,test_obstacle_detection);
 +
    return master_suite;
 +
}
  
−
5.    When fix is available and last checkpoint received from Android, Geo-Controller puts all the received checkpoints into a vector one after the other.
+
==== On board debug indications ====
  
−
6.    Geo-Controller checks whether the destination point is reached. If not, Geo-Controller takes one checkpoint at a time and calculates the compass heading, GPS bearing angle and distance from the starting point to first checkpoint (using Haversine formula).
+
{| class="wikitable"
 +
|-
 +
! scope="col"| Sr.No
 +
! scope="col"| LED Number
 +
! scope="col"| Debug Signal
 +
|-
 +
! scope="row"| 1
 +
| LED 1
 +
| Sensor Heartbeat, Sensor Data Mia
  
−
7.    After calculating the heading, bearing angles, Geo-Controller decides on which direction the vehicle should move by using the steering control algorithm and gives the direction command to master.
+
|-
 +
! scope="row"| 2
 +
| LED 2
 +
| Geo Heartbeat, Turning Angle Signal  Mia
  
−
8.    Master controls the motor to move in that direction. Once the vehicle reaches the first checkpoint, the same flow continues for the remaining checkpoints.
+
|-
 +
! scope="row"| 3
 +
| LED 3
 +
| Bridge Heartbeat mia
  
−
9.    As soon as the last destination checkpoint is popped, we check for the checkpoint vector size. If the vector size is zero and when the vehicle reaches the destination point, we turn a destination reached flag and commands the master to stop the vehicle.
+
|-
 +
! scope="row"| 4
 +
| LED 4
 +
| Motor Heartbeat mia
 +
|-
 +
|}
  
−
We can calculate the bearing angle and distance between the source and destination points using the below mentioned Haversine Formulae.
+
=== Design  Challenges ===
 +
The critical part in Obstacle Avoidance Algorithm is designing, 1. Obstacle detcetion 2. Obstacle avoidance. Since we get 360-degree view of obstacles, we need to group the zones into sectors and tracks to process the 360-degree detection and take decision accordingly.
 +
[[ File: CMPE243_F17_Optimus_ObstacleAvoidanceAlgo.png|700px|thumb|center|| Obstacle Avoidance Design]]
  
−
'''Haversine Formula:'''
+
== '''Motor Controller''' ==
  
−
                  a = sin²(Δφ /2) + (cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2))
+
=== Design & Implementation ===
 +
The Motor Controller is responsible for the Movement and Steering action of the Car. It includes two types of motors, DC motor for movement and DC Servo motor for Steering. The Motor has an inbuilt driver called ESC (Electronic Speed Control) Circuit used the manipulate the speed and steering of the Car. It has a PWM input for both Servo Motor and DC Motor. We are using RPM sensor to take the feedback from the motor to monitor the speed.
  
−
                  c = 2 x atan2( √a, √(1−a) )
+
=== Hardware Design ===
 +
[[File:CmpE243_F17_Motor_Schematic.JPG |thumb|left|300px| Motor Hardware Schematics]]
  
−
                  Distance, d = R x c
+
{| class="wikitable"
 +
|-
 +
! scope="col"|
 +
! scope="col"| SJOne Pin Diagram
 +
! scope="col"|
 +
|-
 +
! scope="col"| Sr.No
 +
! scope="col"| Pin Number
 +
! scope="col"| Pin Function
  
−
                  Where,
+
|-
 +
! scope="row"| 1
 +
| P0.1
 +
| HEADlIGHTS
  
−
                                Φ is latitude
+
|-
 +
! scope="row"| 2
 +
| P1.19
 +
| BRAKELIGHTS
  
−
                                λ is longitude
+
|-
 +
! scope="row"| 3
 +
| P1.20
 +
| LEFT INDICATORS
  
−
                                R is Earth’s radius i.e., 20,902,231 Feet/6371 Km
+
|-
 +
! scope="row"| 4
 +
| P1.22
 +
| RIGHT INDICATORS
 +
|-
 +
! scope="row"| 5
 +
| P0.26
 +
| RPM SENSOR
 +
|-
 +
! scope="row"| 6
 +
| P2.0
 +
| SERVO PWM
 +
|-
 +
! scope="row"| 7
 +
| P2.1
 +
| MOTOR PWM
  
−
                                Δφ = latitude2 – latitude1
+
|}
  
−
                                Δλ = longitude2 – longitude1
 
  
−
=== Implementation ===
 
  
  
−
'''1. Usage of Vectors:''' We used vectors to store and process the checkpoints from Android application. The main reason for using vectors is that the size will grow and shrink with every addition and deletion of checkpoints. So, we can simply check the number of checkpoints left from the vector. We also turned a flag when the vector is empty which means when the flag is on, we have reached the destination.
 
  
−
'''2. Steer Command:''' Direction command to master is given based on the different ranges mentioned in the below picture:
 
  
 +
====Hardware Specifications====
 +
* 1. DC Motor, Servo and ESC
 +
This is a Traxxas Titan 380 18-turn brushed motor. The DC motor comes with the Electronic Speed Control(ESC) module. The ESC module can control both servo and DC motor using Pulse Width Modulation (PWM) control. ESC also requires an initial calibration:
 +
ESC is operated using PWM Signals. The DC motor PWM is converted in the range of -100% to 100% where -100% means "reverse with full speed", 100% means "forward with full speed" and 0 means "Stop or Neutral".
 +
Also, the servo can also be operated in a Safe manner using PWM.
 +
<br> <br>
 +
As we need a locked 0 –> 180 degrees motion in certain applications like robot arm, Humanoids etc. We use these Servo motors. These are Normal motors only with a potentiometer connected to its shaft which gives us the feedback of analog value and adjusts its angle according to its given input signal.
  
−
Deflection = Compass Heading - Bearing Angle
+
So… How to Operate it?
 +
A servo usually requires 5V->6V As VCC. (Industrial servos requires more.) and Ground and a signal to adjust its position.
 +
The signal is a PWM waveform. For a servo, we need to provide a PWM of frequency about 50Hz-200Hz (Refer the datasheet). So the time duration of a clock cycle goes to 20ms. From this 20ms if the On time is 1ms and off time is 19ms we generally get the 0 degrees position. And when we increase the duty cycle from 1ms to 2ms the angle changes from 0–> 180 degrees.
 +
So where can it go wrong-
 +
[[File:CmpE243_F17_Servo_Motor_operation.png|thumb|center|300px|Servo Motor Operation]]
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Steer_Command_Range.jpg|600px|thumb|center|| Steer Command Range]]
+
Power->> The power we provide. Generally we tend to give a higher volt batteries for our applications by pulling the voltage down through regulators to 5Vs. But we surely can-not give supply to the servo through our uC as the servo eats up a hell lot of current.
  
−
Ex: Consider the vehicle is at 90 degrees (Compass heading) with respect to North, and if the angle between the source and destination is 20 degrees with respect to North(Bearing Angle), which direction the vehicle should turn?
+
Another way to burn the servo is at certain times the supply is given directly through the battery so the uC will not blow up. But if you Give a supply say 12Volts then boom. Your servo will go on for ever.
  
−
A. We know Compass Heading = 90 deg, Bearing Angle = 20 deg. So, the difference is 90 - 20 = 70 deg. deflection, so the vehicle has to turn RIGHT since as per our algorithm, the vehicle has to turn right for 60-180 deg. deflection range(deflection = compass heading - bearing angle).
+
PWM–> PWM should strictly be in the range between 1ms–> 2ms (refer datasheets) If by any mistakes the PWM goes out then boom the servo will start jittering and will heat up and heat up and will burn itself down. But this problem is easily identifiable as there is a jitter sound which if you have got enough experience with servos, you will totally notice the noise. So if the noise is there when you turn on the servo, turn it off right away and change the code ASAP.
  
−
The offset value and the steer angular range is calibrated after rigorous testing. For example: If the compass heading at 60 degree angle from bearing angle (clockwise), we have checked which direction the vehicle is attaining the optimum smooth movement, Half Left or Left? Based on these factors, the calibration is done for steer range.
+
Load— Hobby servos don’t have high load bearing capacities and as it is designed that way it always tries to adjust its angle according to signal. But here is the catch. As there is too much off load the servo cannot go further and the signal is forcing it to. So again.. heat… heat and boom. How to avoid this. Give load to the servo only in the figure of safety.
  
−
'''3. Dummy Coordinates:''' We are using the dummy coordinates at the start point and at the end point as delimiters. For example, we are sending (1,1) point initially to check for the first checkpoint. Similarly, we are sending (0,0) at the end after receiving the destination point. We implemented an algorithm to check these conditions and send corresponding  commands to the master to inform that the vehicle has reached the destination.
+
* 2. RPM Sensor
 +
The RPM sensor above requires a specific kind of Installation. '''STEPS ARE:'''
  
−
=== Testing & Technical Challenges ===
+
{|
 +
|
 +
|
 +
|[[File:CmpE243_F17_RPM_install1.JPG ‎|thumb|left|300px]]
 +
|
 +
|
 +
|[[File:CmpE243_F17_RPM_install2.JPG ‎|thumb|center|200px]]
 +
|
 +
|}
  
−
'''Magnetometer Calibration:'''
 
  
−
Reason for calibration:
 
  
−
As mentioned in the below picture, the LSM303 compass range is not concentric with actual compass range. There will be a deflection due to this. For example; we have observed the deflection of LSM303 compass is very minimal with respect to ideal compass readings for a range of 90 – 180 degrees. However, the LSM303 deflection increases as the LSM303 compass angle deflection will slowly increases from 180 to 360 and 0 to 90 degrees.  
+
Once the installation is done, the RPM can be read using the above magnetic RPM sensor. It gives a high pulse at every rotation of the wheel. Hence, to calculate the RPM, the output of the above sensor is fed to a gpio pin of SJOne board.
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Reason_For_Calibration.jpg|600px|thumb|center|| Reason For Calibration]]
+
=== Motor Module Hardware Interface ===
 +
The Hardware connections of Motor Module is shown in above Schematic. The motor receive signals through CAN bus from the Master and feedback is sent via RPM sensor to the Master as current speed of the Car. The speed sent from a RPM sensor over a CAN bus is also utilized by I/O Module and BLE module to print the values on LED display and Android App.
  
−
Few observations are mentioned in table below. So, we used linear equations to calibrate by finding the slope and the addition factors. Since, the deflection is not linear, we have divided the range of 0-360 angle in three different ranges and applied the linear equations respectively.
+
=== Software Design ===
 +
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Observed_Magnetometer_Deflection.jpg|600px|thumb|center|| Observed Magnetometer Deflection]]
+
[[ File: CMPE243_F17_Optimus_MotorFlowchart.png|600px|thumb|center|| Motor controller flowchart]]
  
−
'''Calibration Before Mounting on the Car:'''
+
=== Motor Module Implementation ===
 +
The motor controller is operated based on the CAN messages received from the Master. The CAN messages for Drive and Steer commands are sent from the Master Controller. Motor controller converts the value received from Master (+100 to -100 for Drive Speed percent and +100 to -100 for Steer angle in the range of 1 to 180 degrees turn) into specific PWM value as required by DC motor and Servo. 
 +
*Speed Regulation:
 +
Upon detection of uphill the pulse frequency from RPM Sensor reduces, that means car is slowing down. Hence, in that scenario, car is accelerated (increase PWM) further to maintain the required speed. Similarly in case of Downhill pulse frequency increases, which means car is speeding up. Hence, brakes (reduced PWM) are applied to compensate the increased speed.
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_Before_Mounting_on_Car.jpg|600px|thumb|center|| Compass Calibration Before Mounting On Car]]
+
== '''Sensor Controller''' ==
 +
The Sensor is for detecting and avoiding obstacles. For this purpose we have used RPLIDAR by SLAMTEC.
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_Before_Mounting_On_Car_ActualVsObserved.jpg|600px|thumb|center|| Compass Calibration Before Mounting On Car - Actual Vs Observed]]
+
===Introduction===
 +
The RPLIDAR A2 is a 360 degree 2D laser scanner (LIDAR) solution developed by SLAMTEC. It can take up to 4000 samples of laser ranging per second with high rotation speed. And equipped with SLAMTEC patented OPTMAG technology, it breakouts the life limitation of traditional LIDAR system so as to work stably for a long time. The system can perform 2D 360-degree scan within a 6-meter range. The generated 2D point cloud data can be used in mapping, localization and object/environment modeling. The typical scanning frequency of the RPLIDAR A2 is 10hz (600rpm). [[File:CmpE243_F17_Optimus_LidarSystemComposition.PNG|350px|thumb|right||LIDAR System Composition]]
 +
Under this condition, the resolution will be 0.9°. And the actual scanning frequency can be freely adjusted within the 5-15hz range according to the requirements of users. The RPLIDAR A2 adopts the low cost laser triangulation measurement system developed by SLAMTEC, which makes the RPLIDAR A2 has excellent performance in all kinds of indoor environment and outdoor environment without direct sunlight exposure.
  
 +
This LIDAR consists of a range scanner core and the mechanical powering part which makes the core rotate at a high speed. When it functions normally, the scanner will rotate and scan clockwise. And users can get the range scan data via the communication interface of the RPLIDAR (UART) and control the start, stop and rotating speed of the rotate motor via PWM.
  
−
However, after mounting the LSM303 compass on the vehicle, the LSM303 compass range from 130 – 220 degrees instead of 90 - 180. So, we have divided the angle into three different ranges i.e., 0 – 185, 185 – 340 and 340 – 360 and applied linear equations as showed below.
+
A laser beam is sent out by the transmitter and the reflected laser beam is received back. Depending on the time taken to receive the beam back, the distance of the obstacle is calculated. If there is no obstacle, the beam will not be reflected back.
  
 +
===Hardware Implementation===
 +
====Specifications of the LIDAR====
  
 +
The specifications of the LIDAR as mentioned in the datasheet are as follows:<br>
 +
Power Supply: 5V <br>
 +
Serial Communication interface: UART <br>
 +
Baud Rate for the UART: 115200 <br>
 +
Working mode of the UART: 8N1 <br>
 +
PWM Maximum Voltage: 5V (Typical 3.3V)
 +
PWM frequency: 25KHz <br>
 +
Duty Cycle of the PWM wave: 60% - 100% <br>
  
−
                  Y = a X + b;
+
====Connections to the SJOne Board====
−
                 
+
The LIDAR works with a UART interface and hence has been connected to the UART3 pins of of the SJOne board i.e. P4.28 and P4.29. As the LIDAR needs a 5V supply, it is provided from the PCB (which is powered through a power bank) instead of the SJOne board which can supply only 3.3V. The connections can be seen in the figure below.
−
                  Where,
 
  
−
                                Y is actual reading
+
[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|LIDAR Connections to SJOne Board]]
  
−
                                X is raw magnetometer readings
+
=== Software Implementation ===
  
−
                                a is multiplication factor
+
====Approach for obtaining the data from the LIDAR====
 +
The LIDAR senses all the obstacles around it (360 degrees upto a range of 6000cm) one degree at a time. This means that for one rotation of the LIDAR WE GET 360 values i.e. 360 angles with their corresponding obstacle information. It takes 180ms for the LIDAR to complete one 360 degree scan. Since we do not need obstacle information for each and every angle, we group a few angles together into "sectors" and consider the nearest object present in a sector as an obstacle. To identify how far an obstacle is located, the distance values are grouped into "tracks" i.e 0cm to 25cm is track 1 and 25cm to 50cm is track 2 and so on. The motor will take action depending on the track in which an obstacle is present.
  
−
                                b is additional factor
+
[[File:CmpE243_F17_Optimus_LidarSectors.jpg|700px|thumb|center|LIDAR readings divided into sectors and tracks]]
  
 +
====Algorithm for interfacing LIDAR to SJOne board and obtaining the obstacle info====
 +
Step 1: Send a GET_HEALTH (0XA5 0X52) Request. If the receive times out it is a communication error.<br>
 +
[[File:CmpE243_F17_Optimus_GetHealthRequestResponse.PNG|500px|thumb|center|The GET_HEALTH request and response packets]]
 +
Step 2: Check if a ‘protection stop’ is happening. If it is happening then send a RESET (0XA5 0X40). Again check for ‘protection stop’ and if it it still set, send a RESET again. If ‘protection stop’ is set even after sending RESET multiple times it means there is a hardware defect. If there is no hardware defect, proceed to the next step.<br>
 +
[[File:CmpE243_F17_Optimus_ResetRequest.PNG|500px|thumb|center|The RESET request packet]]
 +
Step 3: Send a START_SCAN (0XA5 0X20) request. Wait for the response header. If there is no timeout, read the measurement sample. Otherwise check HEALTH_STATUS and MOTOR_STATUS again. Send START_SCAN again.<br>
 +
[[File:CmpE243_F17_Optimus_StartScanRequestResponse.PNG|500px|thumb|center|The START_SCAN request and response packets]]
 +
Step 4: Continuously read the measurement samples.The data sent from the LIDAR will contain the start bit, angle, distance and quality. The start bit is set to 1 after every single 360 degree scan. The angle and distance represent to the motor angle and the obstacle in that corresponding angle. The quality represents the strength of the reflected beam. If the quality is zero it means that there is no obstacle in that direction. This data is processed to be group the information into sectors and tracks.<br>
 +
[[File:CmpE243_F17_Optimus_DistanceMeasurements.PNG|500px|thumb|center|The measurement response packet]]
 +
Step 5: If we wish to stop the readings, send a STOP (0XA5 0X25) request. This is the end of operation.<br>
  
−
'''Calibration After Mounting on the Car:'''
+
====Flowchart for Communicating with the LIDAR and receiving obstacle information====
 +
The entire flowchart for communicating with the LIDAR and receiving data from it is shown in the figure below:
 +
[[File:CmpE243_F17_Optimus_LIDARflowchart.png|700px|thumb|center|Flowchart for communicating with the LIDAR and receiving obstacle information from it]]
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_After_Mounting_On_Car.jpg|600px|thumb|center|| Compass Calibration After Mounting On Car]]
+
====Testing the data obtained from the LIDAR====
 +
To perform the initial testing of the LIDAR and to check if we are getting the correct obstacle info, we have made a setup enclosing the LIDAR on all four sides. So, by plotting the distance info given by the LIDAR in Microsoft Excel we can visualize a map of the obstacles as detected by the LIDAR. The map plotted in Excel after closing almost all four sides of the LIDAR can be shown in the figure shown below.
  
−
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_After_Mounting_On_Car_ActualVsObserved.jpg|600px|thumb|center|| Compass Calibration After Mounting On Car - Actual Vs Observed]]
+
[[File:CmpE243_F17_Optimus_LIDARobstacleMap.PNG|700px|thumb|center||Data Obtained from the LIDAR plotted on an Excel sheet]]
  
−
==Sensor and  I/O ==
+
====CAN DBC messages sent from the Sensor Controller====
−
==== Group Members ====
+
The data received from the LIDAR is grouped into sectors and tracks and is sent over the CAN bus. The CAN DBC messages in the DBC file will be as follows<br>
−
*'''''[http://www.linkedin.com/in/bhushanmuthiyan Bhushan Muthiyan]<br> '''''
+
BO_ 3 SENSOR_LIDAR_OBSTACLE_INFO: 6 SENSOR
−
*'''''[http://www.linkedin.com/in/kparameswaran Karthik Parameswaran]<br>'''''
+
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR0 : 0|4@1+ (1,0) [0|12] "" MASTER,BLE
−
===SENSOR===
+
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR1 : 4|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR2 : 8|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR3 : 12|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR4 : 16|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR5 : 20|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR6 : 24|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR7 : 28|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR8 : 32|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR9 : 36|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR10 : 40|4@1+ (1,0) [0|12] "" MASTER,BLE
 +
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR11 : 44|4@1+ (1,0) [0|12] "" MASTER,BLE
  
−
----
+
== '''Android Application''' ==
  
−
==== Design & Implementation ====
+
=== Description ===
−
We are using Maxbotix LV-EZ Ultrasonic sensors (MB1000). The configuration of the sensor is 3:1 that is three sensors in the front separated by 60 degrees apart and one in the rear. The ultrasonic sensors mounted on the car are used to detect the obstacle on its route. These sensors are connected to the SJOne board and work with a 5.0V power supply. The SJ One board then sends the sensors message with the help of CAN bus.
+
'''A'''n Android Mobile Device Application to Navigate and trigger power to the Self Driving Car "OPTIMUS".<br><br>
 +
Optimus App serves an important role in the SDLC as it integrates the UI alongwith RC Controls like "Power", "Navigation" over Bluetooth channel with the Self navigating CAR.<br>
 +
The App uses RF-Comm Bluetooth Communication protocol and a BLE Transceiver to communicate with CAR and exchange several useful information over a Baud-rate of 9600bps.<br>
 +
Optimus mobile Platform needs to be connected with a specific Device Address based on the BLE Chip type in use.
  
−
The pin description of Maxbotix LV-EZ Ultrasonic sensors is as follows:
+
* OPTIMUS HOME
 +
[[ File: CmpE243_F17_Optimus_Optimus App.gif|700px|thumb|center||Optimus App: OPTIMUS HOME]]<br>
  
−
Pin 1-BW- Unused, leave disconnected or connect to circuit common ground.
+
=== Features ===
  
−
Pin 2-PW- Digital Proximity Logic, outputs a High/Low logic voltage level depending on proximity detection. High means an object has been detected in the
+
'''1. BLUETOOTH'''<br>
−
detection zone. Low means no object is present. There is a ~2.5 second delay on acquiring targets and a ~1.5 second delay for releasing a target once detected. This hysteresis improves sensor reliability.
 
  
−
Pin 3-AN- Unused, leave disconnected or connect to circuit common ground.  
+
The Android mobile application includes support for the Bluetooth network stack, which allows a device to wirelessly exchange data with the HC-05 Bluetooth device.<br>
 +
The Android application framework provides access to the Bluetooth functionality through the Android Bluetooth APIs. These APIs let applications wirelessly connect to other Bluetooth device, enabling point-to-point wireless features.<br>
  
−
Pin 4-RX- This pin is internally pulled high. The LV-ProxSonar-EZ will continually measure proximity information and output send to data. Leave the pin disconnected or hold the pin high for proximity information. Hold low to stop all sensor activity and reset acquire timers. Upon returning to a high state, the sensor will initiate a calibration sequence.
+
Using the Bluetooth APIs, Android application performs the following:<br>
  
−
Pin 5-TX- The TX output delivers asynchronous serial with an RS232 format, except voltages are 0-Vcc
+
* Scan for other Bluetooth device HC-05 on RC Car [00:**:91:D9:14:**]<br>
 +
* Query the local Bluetooth adapter for paired Bluetooth devices<br>
 +
* Establish RFCOMM channels<br>
 +
* Connect to other devices through service discovery<br>
 +
* Transfer data to and from other devices<br>
 +
* Manage multiple connections<br>
  
−
Pin 6-+5V- Vcc – Operates on 2.5V - 5.5V. Recommended current capability of 3mA for 5V, and 2mA for 3V.
+
'''2. MAPS'''<br>
  
−
Pin 7-GND- Return for the DC power supply. GND (& Vcc) must be ripple and noise free for best operation.
+
OPTIMUS App uses Google Maps for setting up the Routing Map information and to decide on the next checkpoint for the Car and the appropriate shortest route by computing the checkpoints using "Adjacency Matrix" and certain algorithms.<br>
 +
Google Maps are used along with other promising features to improve the navigation experience as the Route plot and Checkpoint mapping on groovy paths around campus are difficult to plan and route using Google Api(s).<br>
  
−
==== Hardware Design ====
+
* '''MAPS :: ANDROID - BLE COMMUNICATION JSON SCHEMA'''<br>
−
The ultrasonic sensor is interfaced through GPIO, each sensor requires 2 pins, PW and RX, in addition to the two pins required for powering up the sensor. The PW pins for each sensor is configured as an interrupt.
 
−
The following table and figure shows the pin connections for all the sensors to the SJOne board.
 
−
[[File:SNF_Sensor_schematic.png|400px|Sensor Schematic|frame|center]]
 
−
<br clear=all>
 
−
{| class="wikitable"
 
−
|-
 
−
! scope="col"| Sr.No
 
−
! scope="col"| SJOne Pin Number
 
−
! scope="col"| Sensor Pin Function
 
  
−
|-
+
The App was also upgraded to have live tracking feature of Car's location by indicating the crossed marker with '''YELLOW_HUE''' color to distinguish the original path and the traversed path by the car.<br>
−
! scope="row"| 1
+
As soon as the car crosses a checkpoint marker the marker color will be updated to YELLOW from its original BLUE Color to indicate the checkpoint flag has been crossed.<br>
−
| P1.23
 
−
| Middle Sensor PW
 
  
−
|-
+
[[ File: CmpE243_F17_Optimus_Live_Track.JPG|700px|thumb|center||Optimus App: LIVE CAR TRACKING]]<br>
−
! scope="row"| 2
 
−
|P 2.3
 
−
| Middle Sensor Rx
 
  
−
|-
+
Optimus app uses interpolation schemes to calculate intermediate routes and to set checkpoints using Draggable Marker mechanism to set Destination and plot route path till the same.<br>
−
! scope="row"| 3
+
The Json Format shown has various tags for extracting checkpoint information using Json reader and plotting the points on the Map. Features of the Json Data packet are:<br>
−
| P 1.28
 
−
| Left Sensor PW
 
  
−
|-
+
* '''Feature Properties:'''<br>
−
! scope="row"| 4
+
  * Name                  : Description of the route Start Point<br>
−
| P 2.5
+
  * Description [optional] : Custom Description of the route<br>
−
| Left Sensor Rx
+
  * LineString            : Signifies the route type eg. Line Plot<br>
−
|-
+
  * coordinates            : List of Lat-Long Coordinates till Next major Check point<br>
−
! scope="row"| 5
 
−
| P1.22
 
−
| Right Sensor PW
 
  
−
|-
+
[[ File: CmpE243_F17_Optimus_Routes_Json.JPG|700px|thumb|center||ROUTE INTERPOLATION DATA]]<br>
−
! scope="row"| 6
 
−
| P 1.29
 
−
| Rear Sensor Pw
 
  
−
|-
 
−
! scope="row"| 7
 
−
| P 2.7
 
−
| Rear Sensor Rx
 
−
|-
 
−
|}
 
  
 +
'''3. DASHBOARD'''<br>
  
−
The figure below shows the design for the 3D mount for the front sensors.
+
Dash Board was designed to have an at a glance View and to project a UI similar to a CAR Dashboard on the App wherein we have Compass Values, Bearing and Heading Angles, Lidar Maps to resonate the data obtained from LIDAR which also helps in debugging the features and the values being sent from respective Sensor Modules.<br>
−
<gallery mpde= "packed" widths=500px>
 
−
File:SNF_Ultrasonic_Mount.png|Ultrasonic mount Design
 
−
File:CMPE_243_F16_SNF_Usltrasonic_sensor mount.png|3D design
 
−
</gallery>
 
−
<br clear=all>
 
  
−
====Ultrasonic Sensor====
+
* '''OPTIMUS DASHBOARD'''<br>
 +
[[ File: CmpE243_F17_Optimus_Optimus Dashboard.gif|700px|thumb|center||Optimus App: OPTIMUS DASHBOARD]]<br>
  
−
There are three ultrasonic sensors for the front of the car positioned at different angles to provide a wide ultrasonic "vision" for the car. The mount for the sensors was 3D printed such that we have the flexibility to change the angle of the sensor at a later stage when debugging the sensor.
+
* '''DASHBOARD JSON SCHEMA'''<br>
 +
[[ File: CmpE243_F17_Optimus_Dashboard_Json.JPG|700px|thumb|center||DASHBOARD DATA]]<br>
  
−
=== Hardware Interface ===
+
* '''Dashboard Information:'''<br>
 +
  * JSON_ID_GPS_LOCK_STAT  : Signifies the current Status of GPS LOCK on the car<br>
 +
  * JSON_ID_COMPASS_HEADING : Signifies current Heading Angle from COMPASS<br>
 +
  * JSON_ID_COMPASS_BEARING : Signifies current Bearing Angle from COMPASS<br>
 +
  * JSON_ID_TURNING_ANGLE  : Signifies current TurningAngle from COMPASS<br>
 +
  * JSON_ID_DIST_TO_DEST    : Signifies distance from Current Location to Destination or Absolute Displacement of Car relative to Destination Checkpoint<br>
 +
  * JSON_ID_DEST_REACHED    : Signifies whether the car has reached Destination or not!<br>
 +
 +
* '''LIDAR Information:'''<br>
 +
  * JSON_ID_SENSOR_LIDAR_OBSTACLE_INFO_SEC0  : Signifies Track position of the Obstacles detected on multiple Sectors by LIDAR<br>
 +
For Example: Track 9, Sector 1 means Obstacle is detected at Sector 1 at 450 centimeters or 4.50 meters from the Current position of car at an angle range 20-45 degrees from LIDAR/CAR Front line of vision at that particular time instance<br>
 +
{|
 +
|
 +
|
 +
|[[ File: CmpE243_F17_Optimus_Lidar_angle.GIF|700px|thumb|LiDAR detection of Track 9 Sector 1 i.e. 4.50 mts.||Android: LIDAR PLOT]]
 +
|
 +
|
 +
|[[ File: CmpE243_F17_Optimus_Lidar.GIF|700px|thumb|Optimus App: Lidar Obstacle Detection||Android: LIDAR PLOT]]
 +
|
 +
|}
  
−
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.
+
== ''' Bluetooth Controller ''' ==
 +
===Hardware Implementation ===
 +
''' Bluetooth Module Pin Configuration:’''
 +
 +
We are using HC-05 Bluetooth module to send and receive the data from our android application.
  
−
=== Software Design and Implementation ===
+
[[ File: CmpE243_F17_Optimus_HC-05.jpg|200px|thumb|left|| Bluetooth Module]]
−
The readings from the sensor is taken in the form of PWM signals with the help of interrupts.
+
[[ File: CmpE243_F17_Optimus_bridge_HC-05_pin_conf.jpg|679px|thumb|centre||pin configuration]]
−
The following steps were performed to take readings and calculating distance from the sensor
+
<br>
 +
<br>
 +
The Bridge controller is connected to the bluetooth module through the uart serial interface (Uart3) with 9600 baud rate 8-bit data and 1 stop bit.
  
−
# Configure the PW pin of sensor as input.
+
=== Software Implementation ===
−
# Configure RX pin of the sensor as output and set it high.
+
''' Pseudo code of Bridge controller: '''
−
# Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.
 
−
# Start timer at the rising edge of the interrupt (time T1).
 
−
# At falling Edge of the interrupt stop the timer (time T2).
 
−
# The distance of the obstacle is = (T2-T1)/147 inches.
 
−
#Check for threshold distance. If distance > threshold distance for given sensor, then convey to master that obstacle was found.
 
−
#If middle sensor value has distance <= critical distance then convey then set critical bit, conveying that car must stop to avoid a collision
 
−
#Broadcast data on CAN bus. <br>
 
  
 +
1. Turn on bridge controller.
  
−
[[File:CMPE_243_F16_SNF_Sensor_Flowchart.png|thumb|1000px|centre|Sensor Flowchart]]
+
2. Initialise Bluetooth controller with Uart3 settings.
  
−
===I/O===
+
3. Initialise CAN-BUS with 100 kbps speed.
  
−
----
+
4. Handle Incoming IO messages it received from the Geo and the Sensor over CAN Bus.
−
==== Design & Implementation ====
 
−
The IO section for the car consists of two main components, an LCD screen and LED indicators.
 
  
−
[[File:CMPE_243_F16_SNF_IO.png|thumb|left|500px|LCD Schematic]] [[File:CMPE_243_F16_SNF_IO_LED_Connections.png|thumb|right|500px|frame|LED Schematic]] <br>
+
5. Send the received CAN message to the Android over Bluetooth each second.
−
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
 
−
IO is integral to troubleshooting the working of the car. The team first decided upon the various important indicators that would be needed to troubleshoot  the working of the car and then decided to translate them into either LED indicators or LCD screen elements. The table below summarizes the features for IO and which IO element was used to represent them on the car.
 
  
−
{| class="wikitable"
+
6. Send the heartbeat message every second to the Master controller.
−
|-
 
−
! scope="col"| Sr.No
 
−
! scope="col"|Sensor Pin Function
 
−
! scope="col"| LCD Element
 
−
! scope="col"| LED Element Present
 
  
−
|-
+
7. Read Bluetooth message it received from the Android app.
−
! scope="row"| 1
 
−
| System Command (Start, Stop Resume)
 
−
| An on screen LED that turns off/on for each command
 
−
|Yes
 
  
−
|-
+
8. Forward the Android message to GEO controller if it received checkpoints otherwise forward it to Master.
−
! scope="row"| 2
 
−
|Right Turn
 
−
|An on screen LED that turns off/on
 
−
| Yes
 
  
−
|-
+
[[ File: CMPE243_F17_Optimus_BLEControlFlow.png|700px|thumb|center|| Process Flowchart]]
−
! scope="row"| 3
 
−
| Left Turn
 
−
| An on screen LED that turns off/on
 
−
|Yes
 
−
 
 
−
|-
 
−
! scope="row"| 4
 
−
| Brake
 
−
| An on screen LED that turns off/on
 
−
|Yes
 
−
|-
 
−
! scope="row"| 5
 
−
| Forward
 
−
| An on screen LED that turns off/on
 
−
|Yes
 
−
 
 
−
|-
 
−
! scope="row"| 6
 
−
| Reverse
 
−
| An on screen LED that turns off/on
 
−
|Yes
 
−
 
 
−
|-
 
−
! scope="row"| 7
 
−
| Right Sensor
 
−
| Gauge
 
−
|No
 
−
|-
 
  
−
|-
+
DBC format for  messages sent from Bluetooth controller :
−
! scope="row"| 8
 
−
| Left Sensor
 
−
| Gauge
 
−
|No
 
−
|-
 
  
−
! scope="row"| 9
+
BO_ 1 BLE_START_STOP_CMD: 1 BLE
−
| Middle Sensor
+
SG_ BLE_START_STOP_CMD_start : 0|4@1+ (1,0) [0|1] "" MASTER
−
| Gauge
+
SG_ BLE_START_STOP_CMD_reset : 4|4@1+ (1,0) [0|1] "" MASTER
−
|No
 
−
|-
 
  
−
! scope="row"| 10
+
BO_ 38 BLE_HEARTBEAT: 1 BLE
−
| Rear Sensor
+
SG_ BLE_HEARTBEAT_signal : 0|8@1+ (1,0) [0|255] "" MASTER
−
| An on screen LED that turns off/on
 
−
|Yes
 
−
|-
 
−
! scope="row"| 11
 
−
| System Status (Heatbeat)
 
−
| Gauge
 
−
|No
 
−
|-
 
  
−
! scope="row"| 12
+
BO_ 212 BLE_GPS_DATA: 8 BLE
−
| Speed.
+
SG_ BLE_GPS_long : 0|32@1- (0.000001,0) [0|0] "" GEO
−
| Meter.
+
SG_ BLE_GPS_lat : 32|32@1- (0.000001,0) [0|0] "" GEO
−
|No
 
  
−
|-
+
  BO_ 213 BLE_GPS_DATA_CNT: 1 BLE
−
! scope="row"| 13
+
  SG_ BLE_GPS_COUNT : 0|8@1+ (1,0) [0|0] "" GEO,SENSOR
−
| Battery Indicator
 
−
| Gauge
 
−
|No
 
−
|}
 
−
   
 
−
==== Hardware Interface ====
 
−
The hardware interface for the LCD is through UART for LED it is through GPIO.
 
−
LCD Hardware interface:
 
−
The LCD controller works on UART communication. Uart-2 on SJONE board is used for sending the data and command to uLCD-32PTU.
 
−
We are using uLCD-32PTU to debug and display the important CAN message. We used this LCD because of following features:
 
−
*The uLCD-32PTU is a compact and cost effective Intelligent Display Module packed with plenty of features capable of being an interface controller for a number of applications.
 
−
*Built in extensive 4DGL graphics and system library functions.
 
−
*Simple UART communication at 9600 Baud rate is used to communicate with SJONE board.
 
−
LED hardware interface:
 
−
For the LEDs we connected the the positive end to the VCC and the negative end to the GPIO. This was done to prevent the SJOne port from being the current source for a constantly glowing LED.
 
−
There are 10 LEDs in total on the car. 4 in the front and 6 in the rear.
 
−
<div><ul>
 
−
<li style="display: inline-block;">[[File:CMPE_243_F16_SNF_IO_LCD_Connections.JPG|thumb|350px|left|uLCD32PTU Connections]]
 
−
<li style="display: inline-block;">[[File:CMPE243_F16_SNF_LCD_REAR_VIEW.JPG|thumb|right|450px|uLCD32PTU Rearview]]
 
−
<li style="display: inline-block;">[[File:CMPE_243_F16_LCD_SnF_FRONTVIEW.JPG|thumb|500px|left|uLCD32PTU Frontview]]
 
−
<li style="display: inline-block;">[[File:CMPE_243_F16_SNF_LCD_PROGRAMMING_ADAPTER.JPG|thumb|right|700px|uLCD32PTU Programming Adapter]]
 
−
</ul></div>
 
−
<br clear=all>
 
  
−
==== Software Design ====
+
== '''Geographical Controller''' ==
−
[[File:CMPE 243 F16 SNF Screen Changes.gif|thumb|500px|center|LCD screen changes]]
 
−
<gallery mode ="packed">
 
−
File:CMPE_243_F16_SnF_form_0.JPG|Form 0
 
−
File:CMPE_243_F16_SnF_form_1.JPG|Form 1
 
−
File:CMPE_243_F16_SnF_form_2.JPG|Form 2
 
−
File:CMPE_243_F16_SnF_form_3.JPG|Form 3
 
−
</gallery>
 
−
* Form0: This is the home screen for Spartan and Furious which displays the logo of our team. This screen is displayed when there is no system command from the Master. As soon as the IO receives the master system command the IO displays all the relevant data using periodic callback function.
 
  
−
* Form1: This is the screen which is being displayed after the home screen. This screen shows the sensor data, Speed indication, System command status and the direction in which the car is moving.. There are four different gauges for different sensor Data. Each gauge indicates obstacle proximity detected from ultrasonic sensors which are placed on left (L), centre (M), right (R) and rear sensor at back (B) of the car. The direction of the car is indicated using different LEDs for Front(F), Right(R), Left(L), Back(B) indication. The system command LED indicates that master is in sync with all the modules. 
+
=== Introduction ===
  
−
* Form2: In this screen IO displays the System Status of all the modules and also the System status given by the master module to all the modules. System status consists of start, stop and Resume status. There are six different LED’s indication the Heartbeat of the modules. There is a battery indicator Gauge which displays the battery life.
+
'''GPS and Compass Module:'''
  
−
* Form3: This is the ‘Geo Status’ screen which shows different parameters such as GPS longitude and latitude, current compass direction and different modes of car.
+
'''GPS''':
  
−
The data is sent to the LCD in specified format.
+
[[ File: CMPE243_F17_Optimus_GPS.PNG|200px|thumb|right|| GPS]]
−
For sending Gauge, LED, Speedometer data  we need to send five bytes of data.<br>
 
−
<tt>
 
−
Byte1 - Event byte<br>
 
−
Byte2 - Object type<br>
 
−
Byte3 - Object number<br>
 
−
Byte4 - Data byte 1<br>
 
−
Byte5 - Check sum
 
−
</tt>
 
  
−
For angular meter readings we have six bytes of data to be sent.<br>
+
GPS is a global navigation satellite system that provides geo location and time information to a GPS receiver anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites.
−
<tt>
 
−
Byte1 - Event byte<br>
 
−
Byte2 - Object type<br>
 
−
Byte3 - Object number<br>
 
−
Byte4 - Data byte 1<br>
 
−
Byte5 - Data byte 2<br>
 
−
Byte6 - Check sum<br>
 
−
</tt>
 
  
−
For String to be  passed we need to have 3 bytes + each character as data byte + checksum byte.<br>
+
'''Compass''':
−
<tt>
 
−
Byte1 - Event byte<br>
 
−
Byte2 - Object type<br>
 
−
Byte3 - Object number<br>
 
−
Byte4 - Data byte 1<br>
 
−
Byte5 - Data byte 2<br>
 
−
Byte6 - Data byte 3<br>
 
−
.<br>
 
−
.<br>
 
−
.<br>
 
−
Byte n+3 - Data byte n<br>
 
−
Byte n+4  - Check sum<br>
 
−
</tt>
 
−
The data is sent to the LCD using UART. Following steps should be performed in order to display the readings on LCD.
 
−
#Wait for system command from master.
 
−
#Once master command has been received, collect CAN data for all information that has to be shown on IO.
 
−
#Update the corresponding LCD element, and toggle the LEDs based on data received.
 
−
#Switch LCD form every 5 seconds.
 
−
#If destination reached, show the destination reached form.
 
  
−
<br clear=all>
+
[[ File: CMPE243_F17_Optimus_MagneticCompass.GIF|200px|thumb|right|| Compass]]
−
<gallery widths =500px heights =500px>
 
−
File:CMPE 243 F16 SNF LCD FLOWCHART.png|LCD code Flowchart
 
−
File:CMPE 243 F16 SNF LED flowchart.png|LED code Flowchart
 
−
</gallery>
 
−
<br clear=all>
 
−
=== Testing & Technical Challenges ===
 
−
Sensor Technical Challenges and Testing:
 
  
−
We have used sensor in PW mode. In this mode the major challenge was triggering of the sensor. We had to trigger four sensors in such a way that they do not interfere with each other. In order to tackle this issue we triggered front and rear sensor at same time and after a small delay we triggered right and left sensor at same time.
+
A compass is an instrument used for navigation and orientation that shows direction relative to the geographic cardinal directions (or points). Usually, a diagram called a compass rose shows the directions north, south, east, and west on the compass face as abbreviated initials. When the compass is used, the rose can be aligned with the corresponding geographic directions; for example, the "N" mark on the rose really points northward. Compasses often display markings for angles in degrees in addition to (or sometimes instead of) the rose. North corresponds to 0°, and the angles increase clockwise, so east is 90° degrees, south is 180°, and west is 270°. These numbers allow the compass to show azimuths or bearings, which are commonly stated in this notation.
−
The second major challenge is sensor reflection from ground and sensor mounting design. We had to mount the sensor with an angle of 20 degrees with the horizontal. Still there were some reflections but they were minimal. We designed 3D print for sensor mounting such that the angle between each sensor was exactly 60 degrees. The beam angle of sensor is 30 degrees in each side.  
+
We are using DJI’s NAZA GPS/COMPASS to get the GPS coordinates and Heading angle. The diagram of the module is as follows:
 +
[[ File: CMPE243_F17_Optimus_Naza.JPG|200px|thumb|right|| GPS and Compass Module]]
  
 +
'''Message Structure:'''
  
 +
* GPS':
  
−
IO Technical challenges:
+
The 0x10 message contains GPS data. The message structure is as follows:
  
−
LCD mounting was the main challenge for IO. We were using LCD and LED for debugging purposes. For LED we connected same GPIO pins for front and back signal pins. So, the issue came with different colour LED’s. The LED which has less resistance draws all the power and only that LED was turning ON and OFF. The other LED was not showing any indication. We had to change both LED’s with same color and then it was working fine.
+
[[ File: CMPE243_F17_Optimus_GPS_Message.JPG|600px|thumb|center|| GPS Data]]
−
The second issue was of common ground for LCD. We were sending data using UART and had given a Ground pin connection to LCD from the power source. There was no change in the LCD screens and then we figured out that it was due to no common ground connection.
 
  
−
== Motor Controller ==
 
−
==== Group Members ====
 
−
*'''''[http://www.linkedin.com/in/srinivasanshilpa Shilpa Srinivasan]<br> '''''
 
  
−
=== Design & Implementation ===
+
* Compass:
−
The motor controller is responsible for generating the driving and steering action of the car. For this purpose, we have two types motors viz DC motor for driving and Servo motor which is used for changing directions of the car. The motor controller is also interfaced with a speed encoder for generating a feedback mechanism to automatically control and monitor the speed of the car.
 
−
Our car came equipped with a Servo motor and brushed DC motor which is connected Electronic Speed Control (ESC).
 
  
−
=== Hardware Design ===
+
The 0x20 message contains compass data. The structure of the message is as follows:
−
[[File:CMPE243_F16_SnF_MotorHardwareInterface.png|frame|left|200px|Motor Hardware Schematics]]
 
  
−
{| class="wikitable"
+
[[ File: CMPE243_F17_Optimus_Compass_Message.JPG|600px|thumb|center|| Compass Data]]
−
|-
 
−
! scope="col"|
 
−
! scope="col"| SJOne Pin Diagram
 
−
! scope="col"|  
 
−
|-
 
−
! scope="col"| Sr.No
 
−
! scope="col"| Pin Number
 
−
! scope="col"| Pin Function
 
  
−
|-
+
* Calibration':
−
! scope="row"| 1
 
−
| P0.0
 
−
| CAN RX
 
  
−
|-
+
Why calibrate the compass?
−
! scope="row"| 2
 
−
| P0.1
 
−
| CAN TX
 
  
−
|-
+
Ferromagnetic substances placed on multi-rotor or around its working environment affect the reading of earth’s magnetic field for the digital compass. It also reduces the accuracy of the multi-rotor control, or even reads an incorrect heading. Calibration will eliminate such influences, and ensure MC system performs well in a non-ideal magnetic environment.  
−
! scope="row"| 3
 
−
| P2.0
 
−
| Servo motor
 
  
−
|-
+
When to do it?
−
! scope="row"| 4
+
 
−
| P2.1
+
• The first time you install Naza compass.
−
| DC motor
 
−
|-
 
−
! scope="row"| 5
 
−
| P2.5
 
−
| Speed Encoder
 
  
−
|}
+
• When the multi-rotor mechanical setup has changed.
  
 +
• If the GPS/Compass module is re-positioned.
  
−
<br clear=all>
+
• If electronic devices are added/removed/re-positioned.
  
−
*'''Hardware Specifications'''
+
'''Hardware Connection'''
  
−
[[File:CMPE243_F16_SnF_DCMotor.png|thumb|left|200px|DC Motor]]
+
The Pin Configuration is as follows:
−
=====1. DC Motor =====
 
−
Our car came with Titan 12T 550 brushed motor and waterproof ESC. The ESC drives the DC motor based on the Pulse Width modulation (PWM) applied to it. The power supply required for this motor is 8.4 V. Maximum speed of upto 30mph can be achieved. The rotational speed is proportional to the EMF generated in its coil and the torque is proportional to the current.The main connection pins driving the motor are VCC,GND and the Control pin (PWM). The pin P2.1 of SJ-one board is connected to supply the required PWM to the motor.
 
−
The basic working principle of DC motor is illustrated in the following figure :
 
−
Since the preprogrammed controller has to be replaced by using our design ,the DC motor is then tested with Digital Oscilloscope for getting the frequency of operation and equivalent PWM values for full throttle condition in the forward as well as backward condition.
 
−
It was observed from the waveform that the frequency of operation is 100Hz. The range of operational duty cycle is 10% to 20% with 15% being the neutral value or the stop condition.
 
−
In order to accelerate the car a PWM value in the range of 15.6%-20.0% is applied. The 15.6 is the minimum pickup PWM that should be supplied in order to get the car moving at full load. <br> <br>
 
  
−
[[File:CMPE243_F16_SnF_ServoMotor.png|thumb|left|140px|Servo Motor]]
+
[[ File: CMPE243_F17_Pin.JPG|400px|thumb|centre|| Block Diagram]]
−
=====2. Servo Motor =====
 
−
The servomotor used in the car is #2056 a waterproof all weather-action and double the steering power as compared to standard servos. The servo motor is responsible for controlling the steering action of right or left by applying a suitable PWM pulse. The servo motor can be driven with 3.3 V power supply. The pin P2.0 of SJ-one board is connected to supply the required PWM to the motor. After testing the servo motor, we found that the frequency of operation is 100Hz and the operational duty cycle range is 10.0%-20.0% with 15% being the neutral value. For a full right deflection, we provide input PWM pulse ranging from 15.0-20.0% and for full deflection to the left we apply 10.0-15.0% of PWM. <br>
 
  
 +
=== Software Design ===
  
−
<br>
+
'''Algorithm:'''
 +
'''Distance calculation:'''
  
 +
We are using the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface
 +
 +
'''Bearing Angle calculation''':
  
 +
The bearing of a point is the number of degrees in the angle measured in a clockwise direction from the north line to the line joining the centre of the compass with the point. A bearing is used to represent the direction of one point relative to another point. The bearing angle is calculated by using the following formula:
 +
[[ File: CMPE243_F17_Angle.JPG|400px|thumb|right|| Angle Information]]
 +
[[ File: CMPE243_F17_Optimus_DBC_Message.JPG|400px|thumb|right|| DBC Messages]]
 +
[[ File: CMPE243_F17_Optimus_geoflowchart.png|700px|thumb|centre|| Flowchart]]
  
 +
== '''Package Design''' ==
  
−
[[File:CMPE243_F16_SnF_DSO.png|thumb|centre|700px|Digital Oscilloscope readings for the motors]]<br>
+
=== PCB Design ===
 +
[[ File: CmpE243_F17_T1_HWDesign_Schematic.png|800px|thumb|center|| PCB Complete Schematic for All 5 Control Interfaces]] <br>
 +
[[ File: CmpE243_F17_T1_HWDesign_Board.png|800px|thumb|center|| PCB Complete Board design for All 5 Control Interfaces]]
  
−
[[File:CMPE243_F16_SnF_HallEffectSensor.png|thumb|left|300px|Hall-Effect Principle.]]
+
=== 3D Printed Sensor Mounts ===
−
=====3. Speed Sensor =====
+
We designed 3D printing Models for holding the Sensor LiDAR and GPS using OpenScad Software.
−
The speed feedback is monitored through the speed encoder which works on the Hall-effect principle.
 
−
The Hall-effect speed sensor works as a transducer whose output voltage varies in response to the magnetic field.
 
−
The sensor is mounted on the Spur gear instead of the wheel. The sensor would detect the rotation of axle. The motor controller would detect whenever the magnet is aligned with the sensor. This would generate a pulse. The pulse is detected in the form of rising-edge interrupt.
 
−
This gives the wheel rotation count. The wheel rotates for every 1/4th rotation of the spur gear. The rotation count can then be converted to rpm to calculate the speed of the car. <br><br><br><br><br>
 
  
 +
[[ File: CMPE243_F17_Optimus_3DMount.png|700px|thumb|center|| LiDAR Mount]] <br>
 +
[[ File: CMPE243_F17_Optimus_3DGPS.png|700px|thumb|center|| GPS Mount]]
  
 +
== '''Git Project Management''' ==
  
 +
The Gitlab project is managed using working on different branches for different controllers and restricting access to all users to merge the branch to master branch.
 +
To get easy notification of all git activity, we created a webhook for git notifications in CMPE243 Slack Channel.
 +
The useful features of git such as Issues List, Milestone tracks are used for easy management
  
 +
[[ File: CMPE243_F17_Optimus_Webhook.png|500px|thumb|center|| GitLab WebHooks]]
  
 +
The project git repository is below.
  
 +
https://gitlab.com/optimus_prime/optimus/tree/master
  
−
=== Hardware Interface ===
+
== '''Technical Challenges''' ==
−
The CAN bus is used to send and receive messages to and from the Master Controller. The motor controller receives driving and steering signals from the master. The speed calculation is performed using the speed sensor and is sent on the bus, which will be received by the IO controller for display purposes.
 
  
−
=== Software Design ===
+
=== Motor Technical Challenges ===
−
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
+
1) ESC Calibration <br>
−
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
+
We messed up the calibration on the ESC.<br>
−
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]
+
XL 5 had a long press option to calibrate the ESC, where the ESC shall:<br>
 +
a) After long press, glow green and start taking PWM signals for neutral (1.5).<br>
 +
b) Glow green once again where we shall feed in PWM signals for Forward (2ms).<br>
 +
b) Glow green twice again where we shall feed in PWM signals for Reverse (1ms)."<br>
 +
-We wrote code to calibrate using EXT-INT (EINT3) over P0.1 - switch to calibrate the ESC this way!<br>
 +
<br>
  
−
=== Implementation ===
+
2) ESC Reverse<br>
−
The motor controller receives all its signals from Master controller from the CAN bus.
+
The ESC was not activating reverse if we directly - as in the datasheet (no formal datasheet - only XL 5 forums - talked about 1ms pulse width at 50Hz for reverse).<br>
−
The motor controller receives the steer and drive command from the master. The motor controller receives the System start command which boots and decodes further drive signals  to the motor controller. Upon receiving the drive command the motor controller decodes the steering action. Upon receiving suitable data about the obstacle from sensor controller the master controller relays appropriate steering action. To achieve better performance in steering, the turn is categorized as FULL and HALF. This gives better precision in turning.
+
We figured out that Reverse is actually 3 steps:<br>
−
*Speed Regulation:
+
a) goNeutral()<br>
−
Upon detection of uphill the pulse received from the speed encoder reduces. This is detected and the motor feedback is designed such that the speed is increased by providing higher value of PWM value to drive the DC motor. Similarly, for downhill the pulse count received increases which is detected by the speed encoder and the speed is reduced by applying reduced PWM.
+
b) goReverse()<br>
 +
c) goNeutral()<br>
 +
d) goReverse()<br>
  
−
=== Testing & Technical Challenges ===
 
−
*Wheel Alignment Error
 
−
Though the neutral value of PWM is 15% at which the servo is supposed to be aligned straight. In practice, however when we tested the car for straight run slight deflection towards right was observed when the PWM pulse width was set to 15.0 %. Thus, to correct this, we provided correction value of -0.98 giving a resultant PWM pulse width of 14.02%. Thus, we fixed the wheel alignment and obtained the desired straight path traversal.
 
 
<br>
 
<br>
−
*Speed Sensor Assembly
 
−
The speed encoder was assembled on the spur gear of the car. The installation at first was such that outer fitting was large and was avoiding the pulse trigger by the magnet.As a result of which we were unable to modulate speed.Issue was resolved by using the correct outer assembly of the gear which generated the speed feedback.
 
  
−
== Master Controller ==
+
3) RPM Sensor Installation:<br>
−
==== Group Members ====
+
After following the steps to install RPM sensor (as steps above), the RPM sensor was not detecting the Rotation (magnet) of the wheel. <br>
−
*'''''[http://www.linkedin.com/in/ankita151 Ankita Singhal]<br> '''''
+
The reason for that was Machine steeled pinion gear and slipper clutch. The Machine steeled pinion gear and slipper clutch that came with the RC car was big. That increased the distance between Magnet and RPM sensor. That's why we were not able to detect RPM of wheel.<br>
−
*'''''[http://www.linkedin.com/in/sukriti-choudhary-16550b104 Sukriti Choudhary]<br> '''''
+
We even checked the activity using Digital Oscilloscope. <br>
 +
Then we changed the smaller Machine steeled pinion gear and slipper clutch and reinstalled the RPM sensor and it worked. <br><br>
  
−
=== Introduction and Responsibilities ===
+
=== Android  Issues Undergone ===
 +
* '''MAPS: Plotting Routes and Offline Check Points Calculation'''<br>
  
−
Master controller is the brain of the car.<br>
+
With our initial implementation using Google Android API we were able to route maps but sooner during testing of the route navigation we faced a couple of issues as follows:<br>
−
All the decisions are taken by the master module. Some of the major responsibilities of the master module are:<br>
 
  
−
* System command (Initial Start) : Upon successful connection with Android app, master command will send as system start command to all the other modules on the CAN bus. This command advises all the modules to start their processing(similar to wake up).
+
1. For Straight Line Routes, often the intermediate checkpoints were not received, as according to Google Api's checkpoints are only generated at the intersections where the route bends.<br>
−
* Obstacle avoidance : Based on the sensor values, master will decide the direction to be taken by the motor.<br>
+
2. Due to the aforesaid drawback on straight routes it was hard to navigate and interpolation was required to make sure the GEO has enough checkpoints to redefine the heading angle before the car goes too far from its destined straight route path.<br>
−
* GPS data: Depending upon the GPS calculated direction and obstacle data received from sensor module, master controller will decide the steer and drive of the motor.<br>
+
3. Google Route's are calculated from any point on the ground to the nearest offset point on the pre-drawn custom Google poly-line path, as a result the route from certain locations ended up to be on the sharp edge routes rather than smooth curves which also led to little longer routes and our car ended up in side walks or side bushes while correcting its course to follow the main route.<br>
−
* Determine if all the modules on the bus are active or inactive.<br>
 
  
−
The master controller using the data from other modules, drives the car safely to the destination.
+
[[ File: CmpE243_F17_Optimus_Routes.jpg|700px|thumb|center||Optimus App: Navigation and Route Selection]]<br>
 +
* '''Application Compatibility'''<br>
  
−
=== Hardware Design ===
+
During Implementation one of the issues faced were the security features of Android applications and permissions to use Geo Locations and App Storage.<br> Every time after fresh app Installation the permissions had to be revisited and enabled for the app to access them, something which still can be upgraded further. 
 +
 
 +
==== Testing and Procedures to Overcome Challenges ====
  
−
*Interface of CAN Bus with six SJ-One controller boards on PCB was designed.
+
'''MAP DEBUGGING & ROUTE CALCULATION''' <br>
−
*Ribbon Cables were used instead of individual jumper wires to assist in designing less complex circuit.
 
  
 +
For overcoming the problem of placing routes and calculating the shortest path we decided to interpolate routes in the university premises.<br>
 +
Steps involved:<br>
  
−
[[File:CMPE243_F16_SnF_Master_CAN_Interface.jpg|thumb|center|700px|Interface with the CAN Hardware]]
+
* Draw polylines routes over saved checkpoint coordinates by reading and parsing a json file at the app level to get the next checkpoint coordinates.<br>
 +
* Use Dijkstra's Algorithm to calculate shortest path between those routes.<br>
 +
* For longer routes two approaches could be taken to calculate the intermediate checkpoints:<br>
 +
** a. Straightline Approach<br>
 +
** b. Geodesy Engineering Approach.<br>
  
−
=== Software Design ===
+
[[ File: CmpE243_F17_Optimus_Nearest_Route_Algorithm.gif|700px|thumb|center||Source:wikipedia.org::Dijkstra's algorithm]]<br>
  
−
Master Controller needs to periodically receive and transmit updated data from all the modules in order to make an efficient decision. Based on the priority of the data, corresponding CAN messages are parsed in 100Hz, 10Hz or 1Hz periodic scheduler tasks respectively. Data received can be viewed and traced in real time using PCAN View or BUS Master tool.
+
Geodesy approach is complex and can be implemented using 'Haversine' technique to calculate the intermediate points between two points along the geographic surface of the earth but since the distances for the demo were not so long enough that can be significantly impacted by the curvature we decided to go with the primary approach.<br>
  
−
=== Software Implementation ===
+
We used '''Vincenty''' formula to compute the interpolated points between two checkpoints when the distance between the two exceeded ~(10±5)meters the algorithm will interpolate the route to give intermediate checkpoints which will be marked on the map using BLUE Markers.<br>
−
The diagram below details out the flow of data to and from the Master Controller.<br>
 
  
−
[[File:CMPE243_F16_SnF_Master_Block.gif|thumb|700px|center|Master Controller Execution Flow]]
+
''' For easy user view we added Hybrid TYPE MAP on the app so that user can have a 3D feel of the route.<br>
  
−
==== Heartbeat ====
+
''' MARKERS '''<br>
 +
* We also added colored Markers for denoting following:<br>
  
−
Master Controller is responsible to identify if all the modules are active or inactive. All the modules send the heartbeat messages on the CAN Bus every 1Hz. If the heartbeat message is not received from any module, master marks the system status of the module as inactive. The system status message is update at run time on the I/O and the app. User can then reset the inactive module.
+
  >>> '''START/STOP''' : Custom Markers<br>
 +
  >>> '''CAR LOCATION''' : Yellow Markers<br>
 +
  >>> '''INTERMEDIATE CHECKPOINTS''' : HUE_BLUE Markers<br>
  
−
The code snippet for the receiving heartbeat messages and determining system status is as follows: <br>
+
[[ File: CmpE243_F17_Optimus_Map Markers.png|700px|thumb|center||Optimus App: Map Markers]]<br>
  
−
if(dbc_decode_BLE_HEARTBEAT(&ble_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
+
=== Sensor Controller ===
−
    system_status_message.MASTER_SYSTEM_STATUS_ble = 1;
 
−
if(dbc_decode_SENSOR_HEARTBEAT(&sensor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 
−
    system_status_message.MASTER_SYSTEM_STATUS_sensor = 1;
 
−
if(dbc_decode_GEO_HEARTBEAT(&geo_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 
−
    system_status_message.MASTER_SYSTEM_STATUS_geo = 1;
 
−
if(dbc_decode_IO_HEARTBEAT(&io_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 
−
    system_status_message.MASTER_SYSTEM_STATUS_io = 1;
 
−
if(dbc_decode_MOTOR_HEARTBEAT(&motor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 
−
    system_status_message.MASTER_SYSTEM_STATUS_motor = 1;
 
  
 +
1. LIDAR is not able to detect black colored objects sometimes as the light from the LASER is completely absorbed by black and nothing is reflected back.
  
−
To determine the direction and throttle of the car, master controller needs the data from sensor and Geo module. These data are critical for the system and are parsed in 10Hz periodic tasks.  
+
[https://www.youtube.com/watch?v=xQFsSSVI3TE&feature=youtu.be LIDAR doesn't detect black objects]
−
After the master receives BLE_CMD = START, master will send SYSTEM_CMD= START command to all of the modules, which notifies them that the Bluetooth communication via app has been initiated.  
 
−
The car is capable of reaching a destination or just running while avoiding obstacles with no destination set.
 
−
The software design of the master controller supports two modes for the car:
 
  
−
==== Free Run mode ====
+
2. LIDAR object detection will be the plane where it is mounted. So, if the object height is less than the height the LIDAR is mounted then the object will not be detected.
  
−
* For switching to free run mode, the “FREE RUN” button needs to be selected from the app.
+
[https://www.youtube.com/watch?v=kNBofrklUgs&feature=youtu.be LIDAR doesn't detect objects lower than it's height]
−
* As per the sensor data, the movement of the car is decided by the master controller.
 
−
* By default the motor is commanded to move straight.
 
−
* If there is an obstacle in the middle sensor, then the sensor data for left and right sensor is checked.
 
−
* If there is an obstacle at a very short distance, critical obstacle bit is set and car is first stop.
 
−
* When the car needs to stop due to obstacles, reverse sensor value is checked.
 
−
* The car stops only when there are obstacles in all directions or user sends Stop from the app.
 
−
* The following table depicts the motor command sent by master to the motor controller as per the sensor values.
 
  
−
{| class="wikitable"
+
3. If there is very high ramp then ramp will also come in the plane of the LIDAR and it will be considered as an obstacle.
−
|-
 
−
! scope="col"| Sr no
 
−
! scope="col"| Left sensor value
 
−
! scope="col"| Middle sensor value
 
−
! scope="col"| Right sensor value
 
−
! scope="col"| Critical value
 
−
! scope="col"| Rear sensor value
 
−
! scope="col"| Motor Command
 
  
−
|-
+
4. LIDAR's Exposure to direct sunlight will cause noise creation in the obstacle detection.
−
! scope="row"| 0
 
−
| 0
 
−
| 0
 
−
| 0
 
−
| 0
 
−
| X
 
−
| STRAIGHT
 
  
−
|-
+
=== Geo Technical Challenges ===
−
! scope="row"| 1
 
−
| 0
 
−
| 0
 
−
| 1
 
−
| 0
 
−
| X
 
−
| HALF RIGHT
 
  
−
|-
+
The first and the major issue we faced with the GEO module was selecting the proper hardware for GPS and Compass. We tried with Sparkfun, Adafruit and Ublox GPS modules. We observed a lot of time taken by the GPS to get a lock and also the error was high. Then we switched to DJI Naza GPS and we found that it was pretty accurate and the lock up time was hardly a minute. The software issue which we faced with Naza GPS was that it did not have a proper software documentation. We tried to understand the message packets and went through the forums to understand the message layout. After this we were able to integrate the module successfully.
−
! scope="row"| 2
 
−
| 0
 
−
| 1
 
−
| 0
 
−
| 0
 
−
| X
 
−
| LEFT
 
  
−
|-
+
The Naza gps module comes with a in-built compass and it simplified our setup as we did not have to integrate two separate modules.
−
! scope="row"| 3
 
−
| 0
 
−
| 1
 
−
| 1
 
−
| 0
 
−
| X
 
−
| RIGHT
 
  
−
|-
+
We faced one more hardware issue once the Rx pin of the gps module was accidentaly connected to the ground pin then the gps started to draw a lot of current. So to avoid this kind of mistakes we integrated fuse with the gps so even if extra current is drawn the fuse will take care that this does not hamper the entire system.
−
! scope="row"| 4
+
−
| 1
+
Also, the car was going to the edges even if the path was towards the middle of the road as per google maps. So after developing an app to map the checkpoints we found that the path is actually inside the buildings. So, we had to find a different solution to solve this problem. Afterwards, we created a database of all the routes in campus and then processed the route through the android app.
−
| 0
 
−
| 0
 
−
| 0
 
−
| X
 
−
| HALF LEFT
 
−
|-
 
−
! scope="row"| 5
 
−
| 1
 
−
| 0
 
−
| 1
 
−
| 0
 
−
| X
 
−
| STRAIGHT
 
  
−
|-
 
−
! scope="row"| 6
 
−
| 1
 
−
| 1
 
−
| 0
 
−
| 0
 
−
| X
 
−
| LEFT
 
  
−
|-
+
[[ File: CMPE243_F17_Optimus_App.JPG|300px|thumb|center|| GPS Route]]
−
! scope="row"| 7
 
−
| 1
 
−
| 1
 
−
| 1
 
−
| 0
 
−
| 0
 
−
| REVERSE
 
  
−
|-
+
== '''Project Videos''' ==
−
! scope="row"| 8
 
−
| 1
 
−
| 1
 
−
| 1
 
−
| 0
 
−
| 1
 
−
| STOP
 
−
|-
 
−
! scope="row"| 9
 
−
| X
 
−
| X
 
−
| X
 
−
| 1
 
−
| 0
 
−
| REVERSE
 
−
|-
 
−
! scope="row"| 10
 
−
| X
 
−
| X
 
−
| X
 
−
| 1
 
−
| 1
 
−
| STOP
 
−
|-
 
  
−
|}
+
https://youtu.be/lzW2ASbNfYo
  
−
* When STOP button is selected from the app,the BLE will advise the same to master controller and master will send SYSTEM_CMD= STOP to all the modules. This stop command notifies them that the Bluetooth communication via app has been deactivated. <br>
+
== '''Conclusion''' ==
 +
As a team we were able to achieve the set of goals and requirements within the required time frame. Over the course of this project, we learnt cutting edge industry standards and techniques such as:
 +
*Team Work: Working in a team with so many people gave us a real sense of what happens in the industry when a large number of people work together.
 +
*GIT: Our source code versioning, code review sessions and test management was using GIT.  
 +
*CAN: A simple and robust broadcast bus which works with a pair of differential signals. We were able to use the CAN bus to interconnect five LPC1758 micro controllers powered by FreeRTOS.
  
 +
*Accountability: Dealing with both software and hardware is not an easy task and nothing can be taken for granted, especially the hardware.
 +
*Hardware issues:
 +
** Power Issues: Initially we were using a single port from the Power bank power up everything (all the boards) including the LIDAR. This caused the LIDAR to stop working due to insufficient current. It took a while for us to figure this out. 
 +
** GPS: Calibrating the GPS and getting accurate data from the GPS was a challenging task.
 +
**Android Application: Using google maps to obtain checkpoints did not workout as google maps was giving a single checkpoint. So we created a database of checkpoints for navigating the car across SJSU campus.
 +
**Debugging: Connecting the PCAN dongle to the car and moving around with it is a difficult way to debug. Hence we created a dashboard on the android application to view all the useful information on the tab without any hassles.
  
−
[[File:CMPE243_F16_SnF_Free_Run_Flowchart.png|thumb|center|700px|Free Run Mode Flow Chart]]
+
To the teams that are designing their car:
 +
* If using a LIDAR for obstacle avoidance make sure to test it in all lighting conditions.
 +
* It is better to have  PCB instead of soldering everything on a wire-wrapping board.
 +
* Start with the implementation for the Geo module early.
  
−
==== Navigation mode ====
+
== '''Project Source Code''' ==
 +
The source code is available in the below github link
  
−
* For switching to navigation mode, the “NAVIGATION MODE” button needs to be selected from the app.
+
https://gitlab.com/optimus_prime/optimus
−
* In this mode, Geo module sends the desired direction to the master controller.
 
−
* The master controller will check if there is any obstacle in the desired path.
 
−
* In case of obstacle, car moves as per the obstacle avoidance algorithm (free run mode).
 
−
* Once Destination Reached signal is received from the Geo module, the car stops. <br>
 
  
 +
== '''References''' ==
 +
*[https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control ESC Calibration]
 +
*[http://www.instructables.com/id/ESC-Programming-on-Arduino-Hobbyking-ESC/ ESC PWM information]
 +
*[https://forums.traxxas.com/showthread.php?8923102-PWM-in-XL-5 ESC XL-5 PWM information]
 +
*[https://www.movable-type.co.uk/scripts/latlong.html GEO Bearing information]
 +
*[http://bucket.download.slamtec.com/351a5409ddfba077ad11ec5071e97ba5bf2c5d0a/LR002_SLAMTEC_rplidar_sdk_v1.0_en.pdf LIDAR SDK which helped us in coding for the LIDAR]
 +
*[http://bucket.download.slamtec.com/004eb70efdaba0d30a559d7efc60b4bc6bc257fc/LD204_SLAMTEC_rplidar_datasheet_A2M4_v1.0_en.pdf LIDAR Data Sheet]
 +
*[http://bucket.download.slamtec.com/351a5409ddfba077ad11ec5071e97ba5bf2c5d0a/LR002_SLAMTEC_rplidar_sdk_v1.0_en.pdf LIDAR User Manual]
  
−
[[File:CMPE_243_F16_SnF_Navigation_Mode_Flowchart.png|thumb|center|1000px|Navigation Mode Flow Chart]]
+
== '''Acknowledgement''' ==
 +
We are thankful for the guidance and support by
  
−
== Common Technical Challenges ==
+
Professor
−
=== Issue 1 ===
 
−
One of the most unexpected issue faced during testing, was we were unable to receive data from motor and sensor module during testing for demo1. After debugging, we realized that the ribbon cable we purchased was meant for a special purpose and was shorted internally as shown in the picture because of which we were unable to receive data from the CAN bus. 
 
  
 +
* Preetpal Kang
  
−
[[File: CMPE243_F16_SNF_Ribbon_breakout.PNG|thumb|center|500px|Ribbon Breakout]]
+
ISA
−
[[File: CMPE243_F16_SNF_Ribbon_cable.png|thumb|center|800px|Ribbon Cable]]
 
  
−
== Conclusion ==
+
* Prashant Aithal
 +
 +
* Saurabh Ravindra Deshmukh
 +
 +
* Purvil Kamdar
  
−
This project has helped each one of us grow, not just academically, but professionally as well. This project did achieve the goals it promised, these were:
+
* Shruthi Narayan
−
*CAN: Teaching us to work with the CAN bus and protocol; a simple, robust and noise immune mode of communication and using DBC files as a method of managing CAN messages.
 
−
*GIT: Using GIT as a method of continuous integration and improve productivity. GIT allowed us to work independent of our schedules, boosting our productivity beyond the time the team members met.
 
−
*Team Work: Working in a fairly large group gave us a real sense of team work and collaboration.
 
−
*Professionalism and accountability.
 
  
−
On testing the car we found a lot of practical hurdles that we had to overcome. Debugging issues was a large part of our efforts to improve the working of our car. To mention a few:
+
* Parth Pachchigar
−
*Hardware issues:
 
−
** Ribbon Cable: Issues with ribbon cables, we found the hard way that the ribbon cable we initially used was for a specific purpose making it incompatible with our boards.
 
−
**Voltage fluctuation disrupting the CAN bus: Inconsistent soldering on on of the power rails, caused the CAN bus to fail altogether.
 
−
*Bluetooth bridge: Maintaining a Bluetooth connection between different activities in the app was a problem.
 
−
*Sensor: A section of code was rearranged to solve a problem that prevented the sensor from sending messages to the CAN bus.
 
−
*I/O: The I/O module is receiving a large amount of data, causing a task overrun. This was fixed by re-prioritizing the display and rearranging the code.
 
  
−
To the teams that are designing their car:
+
* Abhishek Singh
−
* Use a faster sensor and apply filters like a median or Gaussian filter to improve sensor performance.
 
−
* Ensure hardware connections are tested thoroughly.
 
−
* Start with the implementation for the Geo module early.
 
−
* Ensure that your Android App can communicate consistently with SJOne board.
 
−
=== Project Videos ===
 
  
−
[https://youtu.be/dsfW-ZqOqjA CMPE243_F16_Spartan_and_Furious]
+
For 3D printing
−
[https://youtu.be/89XIqO05p18 Demo Day Video]
 
  
−
=== Project Source Code ===
+
* Our sincere thanks to Marvin Flores <marvin.flores@sjsu.edu> for printing our 3D print models.
−
*  [https://gitlab.com/ankitas/spartan_and_furious Gitlab Code Link]
 
  
−
== References ==
+
For Sponsoring R/C car
−
=== Acknowledgement ===
 
−
We would like to acknowledge the following people for their help in completing this project:
 
−
*Preet for his invaluable teachings.
 
−
*The ISAs for their great advice and tips.
 
−
*[https://www.linkedin.com/in/gvsiddharth Siddarth] for helping with the design for our 3D mount.
 
−
*Maxbotix for a generous student discount on their product.
 
−
*Microchip for the free CAN ICs.
 
−
*[http://www.cratustech.com/ Cratus Technologies] for letting us use their 3D printer.
 
  
−
=== References Used ===
+
* Professor Kaikai, Liu
−
*[http://www.nxp.com/documents/user_manual/UM10360.pdf LPC_USER_MANUAL]
 
−
*[http://www.microchip.com/wwwproducts/en/en010405 CAN transceiver]
 
−
*[https://en.wikipedia.org/wiki/Haversine_formula Haversine Formula Wikipedia]
 
−
*[https://en.wikipedia.org/wiki/Magnetometer Magnetometer Wikipedia]
 
−
*[http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf MCP2551 Datasheet]
 
−
*[https://en.wikipedia.org/wiki/Hall_effect_sensor Hall Effect Sensor Wikipedia]
 
−
*[https://cdn-shop.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf Ultimate GPS Adafruit]
 
−
*[http://www.4dsystems.com.au/product/uLCD_32PTU/ uLCD-32PTU]
 
−
*[http://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf Maxbotix Ultrasonic Datasheet]
 
−
*[https://learn.adafruit.com/adafruit-ina219-current-sensor-breakout/downloads Adafruit Ina219 current sensor]
 
−
*[https://www.sparkfun.com/products/12582 SparkFun Bluetooth Modem - BlueSMiRF Gold]
 
−
*[https://developer.android.com/guide/topics/connectivity/bluetooth.html Android Bluetooth API Guid]
 
−
*[https://developers.google.com/maps/documentation/android-api/ Maps Android API]
 
−
*[https://traxxas.com/sites/default/files/Slash%204x4%20RPM.pdf RPM sensor 6520 Installation Guide]
 
−
*[https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control Configuration of Electronics Speed Control]
 

Latest revision as of 05:23, 23 December 2017

Optimus left view
Optimus front view
Optimus right view

Optimus - An Android app controlled Self Navigating Car powered by SJOne(LPC1758) microcontroller. Optimus manuevers through the selected Routes using LIDAR and GPS Sensors. This wiki page covers the detailed report on how Optimus is built by Team Optimus.

Contents

Abstract

Embedded Systems are omnipresent and one of its unique, yet powerful application is Self Driving Car. In this project we to build a Self-Navigating Car named Optimus, that navigates from a source location to a selected destination by avoiding obstacles in its path.

The key features the system supports are

1. Android Application with Customized map and Dashboard Information.

2. LIDAR powered obstacle avoidance.

3. Route Calculation and Manuvering to the selected destination

4. Self- Adjusting the speed of the car on Ramp.

The system is built on FreeRTOS running on LPC1758 SJOne controller and Android application. The building block of Optimus are the five controllers communicating through High Speed CAN network designed to handle dedicated tasks. The controllers integrates various sensors that is used for navigation of the car. 

     1. Master Controller -  handles the Route Manuevering and Obstacle Avoidance 
     2. Sensor Controller -  detects the surrounding objects
     3. Geo Controller - provides current location
     4. Drive Controller - controls the ESC
     5. Bridge controller - Interfaces the system to Android app
System Architecture
Android Application

Objectives & Introduction

Our Objective is to build and integrate the functionality of these five controllers to develop fully functioning self-driving system.

Sensor Controller: Sensor controller uses RPLIDAR to scan its 360-degree environment within 6-meter range. It sends the scanned obstacle data to master controller and bridge controller.

Geo Controller: Geo controller uses NAZA GPS module that provides car current GPS location and compass angle. It calculates heading and bearing angle that helps the car to turn with respect to destination direction.

Drive Controller: Drive controller drives the motor based on the commands it receives from the Master.

Bridge Controller: Bridge controller works as a gateway between the Android application and Self-driving car and passes information to/from between them.

Master Controller: Master controller controls all other controllers and takes decision of drive.

Android Application: Android application communicates with the car through Bridge controller. It sends the destination location to be reached to the Geo controller and also provides all the Debugging information of the Car like

1. Obstacles information around the car

2. Car's turning angle

3. Compass value

4. Bearing angle

5. Car's GPS location

6. Destination reached status

7. Total checkpoints in the route

8. Current checkpoint indication

Team Members & Responsibilities

  • Master Controller:
    • Revathy

Project Schedule

Legend:

Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal

Week# Date Planned Task Actual Status
1 9/23/2017
  • Decide roles for each team member
  • Read FY16 project reports and understand requirements
  • Setup Gitlab project readme
  • Ordered CAN Tranceivers and get R/C car
  • Team roles are decided and module owners are assigned
  • Gitlab project is set
  • Ordered CAN tranceivers and got R/C Car
 Complete.
2 9/30/2017
  • Design software architecture for each module and design signal interfaces between modules
  • Setup Wiki Project Report template
  • Design Hardware layout of system components
  • Create component checklist and order required components for individual modules.
  • Setup Gitlab project code for each modules
  • Overall project requirements are understood
  • Wiki Project report setup is done
  • Odered components for Geo controller module
  • Initial commit of project base is done
 Complete
3 10/14/2017
  • Major Feature: Implement Free run mode
    • Implement heartbeat messages and initial system bootup sync between modules
    • Interface the RPLidar to SJOne board via UART
    • Achieve basic communication such as obtaining the device and health info.
    • Study of Android Toolkit for Bluetooth Adapter connections and APIs
    • Study of HC-05 Bluetooth Module
    • Creating APIs for Start/ STOP button requests to write to output-Stream buffers
    • Creating RFComm SPP Connection socket and the rest of UI for basic operation of Pairing, Connection
    • Checking the AT Command sequence for Bluetooth Operation and Pairing
    • Automating the AT Command sequence for Bluetooth HC-05 operation and Android App
    • Run Motors via commands from SJOne Automatically
    • Order the RPM sensor module for the Drive Controller
    • Design and Order PCB
  • Major Feature: Implemented Free run mode
    • Added hearbeat messages from all controllers to master in can_db and implemented the handling functions in master controller
    • Implemented speed steer command CAN msg transmission and handling in Master controller. Master-Drive integration phase-I
    • Interfaced RPLidar to SJOne board and achieved basic communication via UART. Started obtaining data as well.
    • Android:Android API for Bluetooth Adapter connections studied.
    • Android:Learning of AT Command sequence for Bluetooth Operation and Pairing done.
    • Android:Created Start/Stop API's for button requests to be Sent to HC-05 IC.
    • Android:Basic Pairing Operation Working.
    • Motor: ESC Traxxas XL-5 (Electronic Speed Control) interfaced to SJOne board
    • Tested and identified duty cycles for different speeds required; Callibration and testing of ESC is over exteral switch at P0.1
    • Ordered RPM sensor
Complete
4 10/21/2017
  • Major Feature: Implement Basic Obstacle Avoidance in Free-run mode
    • Add all modules CAN messages to DBC file
    • Test steer and speed CAN commands between Master and Motor
    • Implement Obstacle avoidance algorithm
    • Obtain data from the lidar and process the data i.e. decide on the format in which the data has to be sent to the master
    • Write unit test cases for the lidar.
    • Interface compass module to SJOne board and calibrate the errors
    • find the heading and bearing angle based on mocked checkpoint
    • Test and verify GPS module outdoor to receive valid data and check for errors
    • Calibrate the GPS module error
    • Design and implement the DRIVE_CONTROLLER STEER/SPEED interface with Master (TDD)
    • Install the new RPM sensor module for the Drive Controller
    • Operating motors based on the CAN messages from the Master
  • Major Feature: Implemented Free-run mode w/o obstacle avoidance
    • Added all modules basic CAN messages in can_db
    • Implemented interface files in master controller to handle CAN messages from all nodes to master
    • Implemented Master-Drive controller Integration
    • Implemented Master-Bluetooth controller integration
    • Added all modules basic CAN messages in can_db
    • GPS integrated to SJONE board
    • Added all modules basic CAN messages in can_db
    • Wrote unit test cases for the LIDAR.
    • Wrote logic for dividing the information obtained from the lidar into sectors and tracks.
    • MASTER_SPEED_STEER_CMD was defined to use 8-bits for speed control (neutral, forward, and reverse); 9-bits for steer control (straight, left, and right)
    • Designed glue code: DriveManager and hardware interface code: DriveController using TDD (test code in _MOTOR/_cgreen_test/)
    • Got the Traxxas #6520 RPM sensor; installed the same with the slipper clutch; Observed the RPM sensor trigger over an oscilloscope and found the minimum distance of magnet to RPM sensor is not achievable with the stock slipper clutch. Ordered Traxxas #6878 new slipper clutch and ball-bearings
    • Master - Drive Controller Interface implemented and tested over CAN; Check "drive" terminal command on Master controller
complete
5 10/28/2017
  • Major Feature: Implement maneuvering in Master controller
    • Implement maneuvering algorithm to drive steering angle of the servo
    • Implement maneuvering algorithm to control ESC speed
    • Test and validate the information obtained from the sensor.
    • Send the Lidar data and heartbeat over CAN.
    • LIDAR should be fully working.
    • Identify the basic speed(s) at which the car shall move; the min, max and normal forward speeds, and the min and normal reverse speeds
    • Interface the RPM sensor over ADC and validate the readings
    • Writing PID Algorithm for Motor Control
    • Calibrating PID constants according to the Motors
    • Testing the Bluetooth Range and multiple pairing option to establish security of the Master device
    • Testing the accuracy of GPS while moving
    • Made the code modular and added the wrapper function for all the important modules
    • Worked on android app which will dump the lattitude and longitude information for checkpoints
    • Test the accuracy of GPS while moving
    • Get the code review done and do the testing after that
    • Worked on the Android app that will dump the checkpoints into a file
    • Finish PCB design and place order
  • Major Feature: Implemented maneuvering in Master-Geo controller
  • Major Feature: Implemented Basic Obstacle Avoidance in Free-run mode
    • Implement maneuvering algorithm in android app is moved to next week schedule
    • Implemented maneuvering algorithm in Master to drive steering angle of the servo
    • Implement maneuvering algorithm in Master to control ESC speed
    • Unit Testing obstacle avoidance algorithm
    • Tested and validated the sensor data by plotting graphs in an EXCEL sheet.
    • Sending the obstacle information and heartbeat over CAN.
    • LIDAR fully working and sending obstacle information.
    • Identified basic speeds, slow, normal, and turbo for forward and reverse
    • Interfaced the RPM sensor over GPIO and validated; but the clutch gear with magnet was far apart from the RPM Sensor
    • Wrote the PID code keeping future integration in mind; Have pushed the code
    • Failed to use RPM sensor - new clutch gear also did not work (magnet is too far away - validated with Oscilloscope); Have to consider using IR sensor for feedback
    • Android:Tested successfully individual and multiple Device pairing.
    • Android:Android app updated with Navigation and Drawer Modules with Detecting NAV points.
    • Tested the accuracy of GPS while moving
    • Made the GPS and compass code modular and checked the functionaity after the changes
    • Worked on the Android app that will dump the checkpoints into a file
    • Completed PCB Design
 Complete
6 11/07/2017
  • Major Feature: Implement maneuvering with mocked GEO checkpoints
    • Collect mock checkpoints using the Android Data Collector application
    • Collect mock checkpoints using the GEO module and compare for any discrepancies
    • Identify I/O on-board Display information; Currenly identified are documented below:
    • Health status like GPS Lock status, etc.
    • Identify hardware to check battery-status and procure the same; update PCB as well
    • Display bluetooth pairing status
    • Test on-board I/O module for bluetooth pairing status
    • In case RPM installation/usage fail, Identify new mechanism for feedback and order components; Update PCB as well to include new hardware
    • Implement simple feature additions on steer control to handle reverse; basically steering rear-left and rear-right has to be practically implemented on motor/drive controller
    • Receive GEO Controller's Turning-angle message and compute target steer
    • Use GEO Controller's distance to next-checkpoint information to compute target speed
    • Mock checkpoint navigation testing using different possible obstacle heights and forms possible
    • Identify advertisement messages on the DBC file and add documentation in Wiki; Currently identified advertisements: a) current GEO location, b) SENSOR radar map
    • Shall define the BLE Controller to android message structure and message generation-intervals (classify on-demand advertisements and periodic advertisements)
    • Implement marker for current location display - which is an on-demand advertisement
    • Implement feature for the user to enter destination - a Google Map View shall be shown to the user to confirm route from source(current car location) to destination
    • Android app (once on the new device) shall download the entire offline map information of the SJSU campus and store it on a SQLite database
  • Major Feature: Implemented maneuvering with mocked GEO checkpoints
    • Provided Mock checkpoints and used the heading and bearing angle logic to get the turning angle
    • Collected mock checkpoints and check for the error with different places
    • Interfaced the Sparkfun Seven segment display with the SJOne Board.
    • Implemented interface method to receive GEO Controller's Turning-angle message and set target steer
    • Target speed is not changed between checkpoints.So geo feedback for distance to destination is not used in design
    • Destination Reached flag is tracked to stop the car on reaching destination
    • Checkpoint Id CAN signal is processed by Master to start the car once destination is selected
    • Android:Implemented Marker for current position Display.
    • Android:User entry for setting up destination on MAP done.
    • RPM Installation failed, but could get auxiliary hardware (motor pinion) from local shop and get it working
    • Implemented basic motor feedback using hall sensor (RPM sensor); tested working on ramps
    • Steer left and right on reverse now follows natural order; Could not finish literal reverse-left and reverse-right implementation; Moved this task forward; Had to test and implement motor feedback this week
    • Defined the BLE Controller messages to android in JSON message structure and message generation-intervals (classify on-demand advertisements and periodic advertisements)
    • On Demand Advertisement- Current Marker Location
    • Draggable Destination Marker for final destination and intermittent checkpoint transmission to GEO from Android via BLE
    • Marking the checkpoints with HUE_BLUE color to do better tracking of the navigation.
    • Added multi state BT options and Added restrictions on buttons like NAV usage dependency on BT Connection, Powerup button dependency on NAV setup before actually powering the car.
 Complete
7 11/14/2017
  • Major Feature: Implementing maneuvering with Android app supplied GEO checkpoints with on-board I/O
    • Use mock data from file to compute: a) Heading b) Bearing -> use Haversine's algorithm to compute turning angle
    • Advertise distance to the next checkpoint (again using Haversine's algorithm)
    • Save the proper checkpoints for one route (Clark's to SU) to SDCARD on GEO Controller
    • Implement system start/stop triggers from different use cases
    • Turning angle offset of -10,10 is added to take right / left turn
    • Implement the battery-status DBC Message advertisement
    • Indicate checkpoint proximity using backlight indicators
    • Create 2 CAN messages for Disgnostic and I/O data to transmit it to BLE module
    • Receive the diagnostic CAN message and decode to transmit it to Android App
    • [Android I/O:] Design Android app views for visualizing Diagnostic and I/O data
    • Test and validate success/fail cases for on-board I/O display information(as defined above)
    • Update PWM pulses to match MASTER's target speed with proper feedback from the identified feedback-mechanism
    • Identify PID constants kp, ki, kd and evaluate performance against the basic feedback implementation
    • Finalize feedback algorithm and fine-tuning
  • Major Feature: Implemented maneuvering with Android app supplied GEO checkpoints with on-board I/O
    • [Geo:] Implemented mock data from file to compute: a) Heading b) Bearing -> used Haversine's algorithm to compute turning angle
    • [Geo:] Advertised distance to the next checkpoint (again using Haversine's algorithm)
    • [Geo:] Saving the checkpoints in SDCARD on GEO Controller
    • Implemented start-stop triggers from android and auto start on start of route navigation
    • Turning angle from geo is handled with offset
    • battery-status is optional feature. Planning for later
    • Indicate checkpoint proximity using backlight indicators
    • [BLE:] Created CAN messages for Telemetry data from all modules to BLe to send to Android
    • [BLE:] Received Telemetry messages are transmitted to Android App
    • [Android I/O:] Android app views created for visualizing Telemetry data
    • Test and validate success/fail cases for on-board I/O display information
    • Update PWM pulses to match MASTER's target speed with proper feedback from the identified feedback-mechanism
    • Finalize feedback algorithm and fine-tuning
 Complete.
8 11/21/2017
  • Major Feature: Complete maneuvering implementation with Android app and Android I/O
    • [Android I/O:] Implement display of Sensor Obstacle Information on a RADAR map
    • [Android I/O:] Dynamically update car's Current location on the map's route path
    • [Android I/O:] BT Auto Connection and Pairing implemented
    • [Android I/O:] Health information from BLE Controller, namely battery, GPS lock status, and motor speed shall be updated
    • [Android I/O:] BT Auto connect implementation and re-connection on disconnection.
    • Test achievable target speeds with different possible obstacle heights and forms possible, and ground conditions
  • Major Feature: Completed maneuvering implementation with Android app
    • [Android I/O:] Sensor obstacle LIDAR information has been updated on the app
    • [Android I/O:] Dynamic update of Car's current location and intermittent checkpoints implemented.
    • [Android I/O:] Health information from BLE Controller, namely GPS lock status, and motor speed has been updated on the Dashboard of the app.
    • [Android I/O:] Completed BT Auto connect implementation and re-connection on disconnection.
 Complete.
9 11/28/2017
  • Major Feature: Full feature integration test
    • Execute the test plan created above [Planned for 11/14] (check Testing documentation in Wiki)
    • Execute the test plan created above [Planned for 11/14]; Phase 1: Test all identified cases for ground-conditions (grass, inclines, etc)
    • Execute the test plan created above [Planned for 11/14]; Phase 2: Test all identified cases for GPS routes and obstacle forms
  • Major Feature: Full feature integration test
    • Integration testing with all controllers and Android App to select routes and send checkpoints from App to Ble.
 Complete.
10 12/5/2017
  • Major Feature: Full feature integration test
    • Execute the test plan created above [Planned for 11/14]; Phase 3: Test all identified cases for speed levels and on-board I/O validation
    • Execute the test plan created above [Planned for 11/14]; Phase 4: Test all identified cases for [Android I/O] validation
  • Major Feature: Full feature integration test
    • Integration testing with Android App with Debug view/Dash board with sensor and GPS data
 Complete
11 12/12/2017
  • Major Feature: Full feature integration test
    • Execute the test plan created above [Planned for 11/14]; Phase 5: Test all identified cases for desired Turbo mode(s)
  • Update Wiki Complete Report
  • Major Feature: Full feature integration test
complete

Parts List & Cost

The Project bill of materials is as listed in the table below.

SNo. Component Units Total Cost
General System Components
1 SJ One Board (LPC 1758) 5 $400
2 Traxaas RC Car 1 From Prof. Kaikai Liu
3 CAN Transceivers 15 $55
4 PCAN dongle 1 From Preet
5 PCB Manufacturing 5 $70
6 3D printing 2 From Marvin
6 General Hardware components( Connectors,standoffs,Soldering Kits) 1 $40
7 Power Bank 1 $41.50
8 LED Digital Display 1 From Preet
9 Acrylic Board 1 $12.53
Sensor/IO Controller Components
10 RP Lidar 1 $449
Geo Controller Components
11 GPS Module 1 $69
Bluetooth Bridge Controller Component
12 Bluetooth Module 1 $34.95
Drive Controller Component
13 RPM Sensor 1 $20

CAN Communication

The controllers are connected in a CAN bus at 100K baudrate. System Nodes: MASTER, MOTOR, BLE, SENSOR, GEO

SNo. Message ID Message from Source Node Receivers
Master Controller Message
1 2 System Stop command to stop motor Motor
2 17 Target Speed-Steer Signal to Motor Motor
3 194 Telemetry Message to Display it on Android BLE
Sensor Controller Message
4 3 Lidar Detections of obstacles in 360 degree grouped as sectors Master,BLE
5 36 Heartbeat Master
Geo Controller Message
6 195 Compass, Destination Reached flag, Checkpoint id signals Master,BLE
7 196 GPS Lock Master,BLE
8 4 Turning Angle Master,BLE
9 214 Current Coordinate Master,BLE
10 37 Heartbeat Master
Bluetooth Bridge Controller Message
11 1 System start/stop command Master
12 38 Heartbeat Master
13 213 Checkpoint Count from AndroidApp Geo
14 212 Checkpoints (Lat, Long) from Android App Geo
Drive Controller Message
15 193 Telemetry Message BLE
16 35 Heartbeat Master

DBC File

The CAN message id's transmitted and received from all the controllers are designed based on the priority of the CAN messages. The priority is as follows

Priority Level 1 - User Commands

Priority Level 2 - Sensor data

Priority Level 3 - Status Signals

Priority Level 4 - Heartbeat

Priority Level 5 - Telemetry signals to display in I/O 

BU_: DBG DRIVER IO MOTOR SENSOR MASTER GEO BLE

BO_ 1 BLE_START_STOP_CMD: 1 BLE
SG_ BLE_START_STOP_CMD_start : 0|4@1+ (1,0) [0|1] "" MASTER
SG_ BLE_START_STOP_CMD_reset : 4|4@1+ (1,0) [0|1] "" MASTER

BO_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

BO_ 212 BLE_GPS_DATA: 8 BLE
SG_ BLE_GPS_long : 0|32@1- (0.000001,0) [0|0] "" GEO
SG_ BLE_GPS_lat : 32|32@1- (0.000001,0) [0|0] "" GEO

BO_ 213 BLE_GPS_DATA_CNT: 1 BLE 
SG_ BLE_GPS_COUNT : 0|8@1+ (1,0) [0|0] "" GEO,SENSOR

BO_ 214 GEO_CURRENT_COORD: 8 GEO
SG_ GEO_CURRENT_COORD_LONG : 0|32@1- (0.000001,0) [0|0] "" MASTER,BLE
SG_ GEO_CURRENT_COORD_LAT : 32|32@1- (0.000001,0) [0|0] "" MASTER,BLE

BO_ 195 GEO_TELECOMPASS: 6 GEO
SG_ GEO_TELECOMPASS_compass : 0|12@1+ (0.1,0) [0|360.0] "" MASTER,BLE
SG_ GEO_TELECOMPASS_bearing_angle : 12|12@1+ (0.1,0) [0|360.0] "" MASTER,BLE
SG_ GEO_TELECOMPASS_distance : 24|12@1+ (0.1,0) [0|0] "" MASTER,BLE
SG_ GEO_TELECOMPASS_destination_reached : 36|1@1+ (1,0) [0|1] "" MASTER,BLE
SG_ GEO_TELECOMPASS_checkpoint_id : 37|8@1+ (1,0) [0|0] "" MASTER,BLE

BO_ 194 MASTER_TELEMETRY: 3 MASTER
SG_ MASTER_TELEMETRY_gps_mia : 0|1@1+ (1,0) [0|1] "" BLE
SG_ MASTER_TELEMETRY_sensor_mia : 1|1@1+ (1,0) [0|1] "" BLE
SG_ MASTER_TELEMETRY_sensor_heartbeat : 2|1@1+ (1,0) [0|1] "" BLE
SG_ MASTER_TELEMETRY_ble_heartbeat : 3|1@1+ (1,0) [0|1] "" BLE
SG_ MASTER_TELEMETRY_motor_heartbeat : 4|1@1+ (1,0) [0|1] "" BLE
SG_ MASTER_TELEMETRY_geo_heartbeat : 5|1@1+ (1,0) [0|1] "" BLE
SG_ MASTER_TELEMETRY_sys_status : 6|2@1+ (1,0) [0|3] "" BLE
SG_ MASTER_TELEMETRY_gps_tele_mia : 8|1@1+ (1,0) [0|1] "" BLE

BO_ 196 GEO_TELEMETRY_LOCK: 1 GEO
SG_ GEO_TELEMETRY_lock : 0|8@1+ (1,0) [0|0] "" MASTER,SENSOR,BLE

BO_ 3 SENSOR_LIDAR_OBSTACLE_INFO: 6 SENSOR
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR0 : 0|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR1 : 4|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR2 : 8|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR3 : 12|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR4 : 16|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR5 : 20|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR6 : 24|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR7 : 28|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR8 : 32|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR9 : 36|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR10 : 40|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR11 : 44|4@1+ (1,0) [0|12] "" MASTER,BLE

BO_ 4 GEO_TURNING_ANGLE: 2 GEO
SG_ GEO_TURNING_ANGLE_degree : 0|9@1- (1,0) [-180|180] "" MASTER,BLE


The CAN DBC is available at the Gitlab link below

https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc

CAN Bus Debugging

We used PCAN Dongle to connect to the host pc to monitor the CAN Bus traffic using BusMaster tool. The screenshot of the Bus Master log is shown below

BusMaster CAN Signal Log

Hardware & Software Architecture

Master Controller

Software Architecture Design

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the Self Navigating car. Two of the major functionalities handled by Master Controller is Obstacle avoidance and Route Maneuvering.

The overview of Master Controller Software Architecture is as show in the figure below.

SW Architecture

As an analogy to Human driving, it receives the inputs from sensors to determine the surrounding of the Self Navigating car and take decisions based on the environment and current location of the car. The input received and output sent by the Master are as mentioned below:

Input to Master:

1. Lidar Object Detection information - To determine if there is an obstacle in the path of navigation

2. GPS and Compass Reading - To understand the Heading and Bearing angle to decide the direction of movement

3. User command from Android - To stop or Navigate to the Destination

Output from Master:

1. Motor control information - sends the target Speed and Steering direction to the Motor.

Software Implementation

The Master controller runs 2 major algorithms, Route Maneuvering and Obstacle Avoidance. The System start/stop is handled by master based on the Specific commands. The implicit requirement is that When the user selects the destination, route is calculated and the checkpoints of the route are sent from Android through bridge controller to the Geo. Once Geo Controller receives a complete set of checkpoints, the master controller starts the system based on the "Checkpoint ID". If the ID is a non-zero value, the route has started and Master controller runs the Route Maneuvering Algorithm.

The Overall control flow of master controller is shown in the below figure.

Process Flowchart

Unit Testing

Using Cgreen Unit Testing framework, the Obstacle avoidance algorithm is unit tested.The complete code for unit test is added in git project. 

Ensure(test_obstacle_avoidance)
{
   //Obstacle Avoidance Algorithm
   pmaster->set_target_steer(MC::steer_right);
   mock_obstacle_detections(MC::steer_right,MC::steer_right,false,false,false,false,false,false,true);
   assert_that(pmaster->RunObstacleAvoidanceAlgo(obs_status),is_equal_to(expected_steer));
   assert_that(pmaster->get_forward(),is_equal_to(true));
   assert_that(pmaster->get_target_speed(),is_equal_to(MC::speed_slow));
}
Ensure(test_obstacle_detection)
{
   //Obstacle Detection Algorithm
   mock_CAN_Rx_Lidar_Info(2,2,6,0,2,2,4,0,2,0,5,0);
   set_expected_detection(true,false,true,false,true,false,false);
   actual_detections = psensor->RunObstacleDetectionAlgo();
   assert_that(compare_detections(actual_detections) , is_equal_to(7));
}
TestSuite* master_controller_suite()
{
   TestSuite* master_suite = create_test_suite();
   add_test(master_suite,test_obstacle_avoidance);
   add_test(master_suite,test_obstacle_detection);
   return master_suite;
}

On board debug indications

Sr.No LED Number Debug Signal
1 LED 1 Sensor Heartbeat, Sensor Data Mia
2 LED 2 Geo Heartbeat, Turning Angle Signal Mia
3 LED 3 Bridge Heartbeat mia
4 LED 4 Motor Heartbeat mia

Design Challenges

The critical part in Obstacle Avoidance Algorithm is designing, 1. Obstacle detcetion 2. Obstacle avoidance. Since we get 360-degree view of obstacles, we need to group the zones into sectors and tracks to process the 360-degree detection and take decision accordingly.

Obstacle Avoidance Design

Motor Controller

Design & Implementation

The Motor Controller is responsible for the Movement and Steering action of the Car. It includes two types of motors, DC motor for movement and DC Servo motor for Steering. The Motor has an inbuilt driver called ESC (Electronic Speed Control) Circuit used the manipulate the speed and steering of the Car. It has a PWM input for both Servo Motor and DC Motor. We are using RPM sensor to take the feedback from the motor to monitor the speed.

Hardware Design

Motor Hardware Schematics
SJOne Pin Diagram
Sr.No Pin Number Pin Function
1 P0.1 HEADlIGHTS
2 P1.19 BRAKELIGHTS
3 P1.20 LEFT INDICATORS
4 P1.22 RIGHT INDICATORS
5 P0.26 RPM SENSOR
6 P2.0 SERVO PWM
7 P2.1 MOTOR PWM




Hardware Specifications

  • 1. DC Motor, Servo and ESC

This is a Traxxas Titan 380 18-turn brushed motor. The DC motor comes with the Electronic Speed Control(ESC) module. The ESC module can control both servo and DC motor using Pulse Width Modulation (PWM) control. ESC also requires an initial calibration: ESC is operated using PWM Signals. The DC motor PWM is converted in the range of -100% to 100% where -100% means "reverse with full speed", 100% means "forward with full speed" and 0 means "Stop or Neutral". Also, the servo can also be operated in a Safe manner using PWM.

As we need a locked 0 –> 180 degrees motion in certain applications like robot arm, Humanoids etc. We use these Servo motors. These are Normal motors only with a potentiometer connected to its shaft which gives us the feedback of analog value and adjusts its angle according to its given input signal.

So… How to Operate it? A servo usually requires 5V->6V As VCC. (Industrial servos requires more.) and Ground and a signal to adjust its position. The signal is a PWM waveform. For a servo, we need to provide a PWM of frequency about 50Hz-200Hz (Refer the datasheet). So the time duration of a clock cycle goes to 20ms. From this 20ms if the On time is 1ms and off time is 19ms we generally get the 0 degrees position. And when we increase the duty cycle from 1ms to 2ms the angle changes from 0–> 180 degrees. So where can it go wrong-

Servo Motor Operation

Power->> The power we provide. Generally we tend to give a higher volt batteries for our applications by pulling the voltage down through regulators to 5Vs. But we surely can-not give supply to the servo through our uC as the servo eats up a hell lot of current.

Another way to burn the servo is at certain times the supply is given directly through the battery so the uC will not blow up. But if you Give a supply say 12Volts then boom. Your servo will go on for ever.

PWM–> PWM should strictly be in the range between 1ms–> 2ms (refer datasheets) If by any mistakes the PWM goes out then boom the servo will start jittering and will heat up and heat up and will burn itself down. But this problem is easily identifiable as there is a jitter sound which if you have got enough experience with servos, you will totally notice the noise. So if the noise is there when you turn on the servo, turn it off right away and change the code ASAP.

Load— Hobby servos don’t have high load bearing capacities and as it is designed that way it always tries to adjust its angle according to signal. But here is the catch. As there is too much off load the servo cannot go further and the signal is forcing it to. So again.. heat… heat and boom. How to avoid this. Give load to the servo only in the figure of safety.

  • 2. RPM Sensor

The RPM sensor above requires a specific kind of Installation. STEPS ARE:

CmpE243 F17 RPM install1.JPG
CmpE243 F17 RPM install2.JPG


Once the installation is done, the RPM can be read using the above magnetic RPM sensor. It gives a high pulse at every rotation of the wheel. Hence, to calculate the RPM, the output of the above sensor is fed to a gpio pin of SJOne board.

Motor Module Hardware Interface

The Hardware connections of Motor Module is shown in above Schematic. The motor receive signals through CAN bus from the Master and feedback is sent via RPM sensor to the Master as current speed of the Car. The speed sent from a RPM sensor over a CAN bus is also utilized by I/O Module and BLE module to print the values on LED display and Android App.

Software Design

The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.

Motor controller flowchart

Motor Module Implementation

The motor controller is operated based on the CAN messages received from the Master. The CAN messages for Drive and Steer commands are sent from the Master Controller. Motor controller converts the value received from Master (+100 to -100 for Drive Speed percent and +100 to -100 for Steer angle in the range of 1 to 180 degrees turn) into specific PWM value as required by DC motor and Servo.

  • Speed Regulation:

Upon detection of uphill the pulse frequency from RPM Sensor reduces, that means car is slowing down. Hence, in that scenario, car is accelerated (increase PWM) further to maintain the required speed. Similarly in case of Downhill pulse frequency increases, which means car is speeding up. Hence, brakes (reduced PWM) are applied to compensate the increased speed.

Sensor Controller

The Sensor is for detecting and avoiding obstacles. For this purpose we have used RPLIDAR by SLAMTEC.

Introduction

The RPLIDAR A2 is a 360 degree 2D laser scanner (LIDAR) solution developed by SLAMTEC. It can take up to 4000 samples of laser ranging per second with high rotation speed. And equipped with SLAMTEC patented OPTMAG technology, it breakouts the life limitation of traditional LIDAR system so as to work stably for a long time. The system can perform 2D 360-degree scan within a 6-meter range. The generated 2D point cloud data can be used in mapping, localization and object/environment modeling. The typical scanning frequency of the RPLIDAR A2 is 10hz (600rpm).
LIDAR System Composition

Under this condition, the resolution will be 0.9°. And the actual scanning frequency can be freely adjusted within the 5-15hz range according to the requirements of users. The RPLIDAR A2 adopts the low cost laser triangulation measurement system developed by SLAMTEC, which makes the RPLIDAR A2 has excellent performance in all kinds of indoor environment and outdoor environment without direct sunlight exposure.

This LIDAR consists of a range scanner core and the mechanical powering part which makes the core rotate at a high speed. When it functions normally, the scanner will rotate and scan clockwise. And users can get the range scan data via the communication interface of the RPLIDAR (UART) and control the start, stop and rotating speed of the rotate motor via PWM.

A laser beam is sent out by the transmitter and the reflected laser beam is received back. Depending on the time taken to receive the beam back, the distance of the obstacle is calculated. If there is no obstacle, the beam will not be reflected back.

Hardware Implementation

Specifications of the LIDAR

The specifications of the LIDAR as mentioned in the datasheet are as follows:
Power Supply: 5V
Serial Communication interface: UART
Baud Rate for the UART: 115200
Working mode of the UART: 8N1
PWM Maximum Voltage: 5V (Typical 3.3V) PWM frequency: 25KHz
Duty Cycle of the PWM wave: 60% - 100%

Connections to the SJOne Board

The LIDAR works with a UART interface and hence has been connected to the UART3 pins of of the SJOne board i.e. P4.28 and P4.29. As the LIDAR needs a 5V supply, it is provided from the PCB (which is powered through a power bank) instead of the SJOne board which can supply only 3.3V. The connections can be seen in the figure below.

LIDAR Connections to SJOne Board

Software Implementation

Approach for obtaining the data from the LIDAR

The LIDAR senses all the obstacles around it (360 degrees upto a range of 6000cm) one degree at a time. This means that for one rotation of the LIDAR WE GET 360 values i.e. 360 angles with their corresponding obstacle information. It takes 180ms for the LIDAR to complete one 360 degree scan. Since we do not need obstacle information for each and every angle, we group a few angles together into "sectors" and consider the nearest object present in a sector as an obstacle. To identify how far an obstacle is located, the distance values are grouped into "tracks" i.e 0cm to 25cm is track 1 and 25cm to 50cm is track 2 and so on. The motor will take action depending on the track in which an obstacle is present.

LIDAR readings divided into sectors and tracks

Algorithm for interfacing LIDAR to SJOne board and obtaining the obstacle info

Step 1: Send a GET_HEALTH (0XA5 0X52) Request. If the receive times out it is a communication error.

The GET_HEALTH request and response packets

Step 2: Check if a ‘protection stop’ is happening. If it is happening then send a RESET (0XA5 0X40). Again check for ‘protection stop’ and if it it still set, send a RESET again. If ‘protection stop’ is set even after sending RESET multiple times it means there is a hardware defect. If there is no hardware defect, proceed to the next step.

The RESET request packet

Step 3: Send a START_SCAN (0XA5 0X20) request. Wait for the response header. If there is no timeout, read the measurement sample. Otherwise check HEALTH_STATUS and MOTOR_STATUS again. Send START_SCAN again.

The START_SCAN request and response packets

Step 4: Continuously read the measurement samples.The data sent from the LIDAR will contain the start bit, angle, distance and quality. The start bit is set to 1 after every single 360 degree scan. The angle and distance represent to the motor angle and the obstacle in that corresponding angle. The quality represents the strength of the reflected beam. If the quality is zero it means that there is no obstacle in that direction. This data is processed to be group the information into sectors and tracks.

The measurement response packet

Step 5: If we wish to stop the readings, send a STOP (0XA5 0X25) request. This is the end of operation.

Flowchart for Communicating with the LIDAR and receiving obstacle information

The entire flowchart for communicating with the LIDAR and receiving data from it is shown in the figure below:

Flowchart for communicating with the LIDAR and receiving obstacle information from it

Testing the data obtained from the LIDAR

To perform the initial testing of the LIDAR and to check if we are getting the correct obstacle info, we have made a setup enclosing the LIDAR on all four sides. So, by plotting the distance info given by the LIDAR in Microsoft Excel we can visualize a map of the obstacles as detected by the LIDAR. The map plotted in Excel after closing almost all four sides of the LIDAR can be shown in the figure shown below.

Data Obtained from the LIDAR plotted on an Excel sheet

CAN DBC messages sent from the Sensor Controller

The data received from the LIDAR is grouped into sectors and tracks and is sent over the CAN bus. The CAN DBC messages in the DBC file will be as follows
BO_ 3 SENSOR_LIDAR_OBSTACLE_INFO: 6 SENSOR 

SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR0 : 0|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR1 : 4|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR2 : 8|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR3 : 12|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR4 : 16|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR5 : 20|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR6 : 24|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR7 : 28|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR8 : 32|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR9 : 36|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR10 : 40|4@1+ (1,0) [0|12] "" MASTER,BLE
SG_ SENSOR_LIDAR_OBSTACLE_INFO_SECTOR11 : 44|4@1+ (1,0) [0|12] "" MASTER,BLE

Android Application

Description

An Android Mobile Device Application to Navigate and trigger power to the Self Driving Car "OPTIMUS".

Optimus App serves an important role in the SDLC as it integrates the UI alongwith RC Controls like "Power", "Navigation" over Bluetooth channel with the Self navigating CAR.
The App uses RF-Comm Bluetooth Communication protocol and a BLE Transceiver to communicate with CAR and exchange several useful information over a Baud-rate of 9600bps.
Optimus mobile Platform needs to be connected with a specific Device Address based on the BLE Chip type in use.

  • OPTIMUS HOME
Optimus App: OPTIMUS HOME

Features

1. BLUETOOTH

The Android mobile application includes support for the Bluetooth network stack, which allows a device to wirelessly exchange data with the HC-05 Bluetooth device.
The Android application framework provides access to the Bluetooth functionality through the Android Bluetooth APIs. These APIs let applications wirelessly connect to other Bluetooth device, enabling point-to-point wireless features.

Using the Bluetooth APIs, Android application performs the following:

  • Scan for other Bluetooth device HC-05 on RC Car [00:**:91:D9:14:**]
  • Query the local Bluetooth adapter for paired Bluetooth devices
  • Establish RFCOMM channels
  • Connect to other devices through service discovery
  • Transfer data to and from other devices
  • Manage multiple connections

2. MAPS

OPTIMUS App uses Google Maps for setting up the Routing Map information and to decide on the next checkpoint for the Car and the appropriate shortest route by computing the checkpoints using "Adjacency Matrix" and certain algorithms.
Google Maps are used along with other promising features to improve the navigation experience as the Route plot and Checkpoint mapping on groovy paths around campus are difficult to plan and route using Google Api(s).

  • MAPS :: ANDROID - BLE COMMUNICATION JSON SCHEMA

The App was also upgraded to have live tracking feature of Car's location by indicating the crossed marker with YELLOW_HUE color to distinguish the original path and the traversed path by the car.
As soon as the car crosses a checkpoint marker the marker color will be updated to YELLOW from its original BLUE Color to indicate the checkpoint flag has been crossed.

Optimus App: LIVE CAR TRACKING

Optimus app uses interpolation schemes to calculate intermediate routes and to set checkpoints using Draggable Marker mechanism to set Destination and plot route path till the same.
The Json Format shown has various tags for extracting checkpoint information using Json reader and plotting the points on the Map. Features of the Json Data packet are:

  • Feature Properties:
 * Name                   : Description of the route Start Point

 * Description [optional] : Custom Description of the route

 * LineString             : Signifies the route type eg. Line Plot

 * coordinates            : List of Lat-Long Coordinates till Next major Check point
ROUTE INTERPOLATION DATA


3. DASHBOARD

Dash Board was designed to have an at a glance View and to project a UI similar to a CAR Dashboard on the App wherein we have Compass Values, Bearing and Heading Angles, Lidar Maps to resonate the data obtained from LIDAR which also helps in debugging the features and the values being sent from respective Sensor Modules.

  • OPTIMUS DASHBOARD
Optimus App: OPTIMUS DASHBOARD

  • DASHBOARD JSON SCHEMA
DASHBOARD DATA

  • Dashboard Information:
 * JSON_ID_GPS_LOCK_STAT   : Signifies the current Status of GPS LOCK on the car

 * JSON_ID_COMPASS_HEADING : Signifies current Heading Angle from COMPASS

 * JSON_ID_COMPASS_BEARING : Signifies current Bearing Angle from COMPASS

 * JSON_ID_TURNING_ANGLE   : Signifies current TurningAngle from COMPASS

 * JSON_ID_DIST_TO_DEST    : Signifies distance from Current Location to Destination or Absolute Displacement of Car relative to Destination Checkpoint

 * JSON_ID_DEST_REACHED    : Signifies whether the car has reached Destination or not!
  • LIDAR Information:
 * JSON_ID_SENSOR_LIDAR_OBSTACLE_INFO_SEC0   : Signifies Track position of the Obstacles detected on multiple Sectors by LIDAR

For Example: Track 9, Sector 1 means Obstacle is detected at Sector 1 at 450 centimeters or 4.50 meters from the Current position of car at an angle range 20-45 degrees from LIDAR/CAR Front line of vision at that particular time instance

LiDAR detection of Track 9 Sector 1 i.e. 4.50 mts.
 Android: LIDAR PLOT
Optimus App: Lidar Obstacle Detection
 Android: LIDAR PLOT

Bluetooth Controller

Hardware Implementation

' Bluetooth Module Pin Configuration:’

We are using HC-05 Bluetooth module to send and receive the data from our android application.

Bluetooth Module
pin configuration



The Bridge controller is connected to the bluetooth module through the uart serial interface (Uart3) with 9600 baud rate 8-bit data and 1 stop bit.

Software Implementation

Pseudo code of Bridge controller:

1. Turn on bridge controller.

2. Initialise Bluetooth controller with Uart3 settings.

3. Initialise CAN-BUS with 100 kbps speed.

4. Handle Incoming IO messages it received from the Geo and the Sensor over CAN Bus.

5. Send the received CAN message to the Android over Bluetooth each second.

6. Send the heartbeat message every second to the Master controller.

7. Read Bluetooth message it received from the Android app.

8. Forward the Android message to GEO controller if it received checkpoints otherwise forward it to Master.

Process Flowchart

DBC format for messages sent from Bluetooth controller : 

BO_ 1 BLE_START_STOP_CMD: 1 BLE
SG_ BLE_START_STOP_CMD_start : 0|4@1+ (1,0) [0|1] "" MASTER
SG_ BLE_START_STOP_CMD_reset : 4|4@1+ (1,0) [0|1] "" MASTER

BO_ 38 BLE_HEARTBEAT: 1 BLE
SG_ BLE_HEARTBEAT_signal : 0|8@1+ (1,0) [0|255] "" MASTER

BO_ 212 BLE_GPS_DATA: 8 BLE
SG_ BLE_GPS_long : 0|32@1- (0.000001,0) [0|0] "" GEO
SG_ BLE_GPS_lat : 32|32@1- (0.000001,0) [0|0] "" GEO

BO_ 213 BLE_GPS_DATA_CNT: 1 BLE 
SG_ BLE_GPS_COUNT : 0|8@1+ (1,0) [0|0] "" GEO,SENSOR

Geographical Controller

Introduction

GPS and Compass Module:

GPS:

GPS

GPS is a global navigation satellite system that provides geo location and time information to a GPS receiver anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites.

Compass:

Compass

A compass is an instrument used for navigation and orientation that shows direction relative to the geographic cardinal directions (or points). Usually, a diagram called a compass rose shows the directions north, south, east, and west on the compass face as abbreviated initials. When the compass is used, the rose can be aligned with the corresponding geographic directions; for example, the "N" mark on the rose really points northward. Compasses often display markings for angles in degrees in addition to (or sometimes instead of) the rose. North corresponds to 0°, and the angles increase clockwise, so east is 90° degrees, south is 180°, and west is 270°. These numbers allow the compass to show azimuths or bearings, which are commonly stated in this notation. We are using DJI’s NAZA GPS/COMPASS to get the GPS coordinates and Heading angle. The diagram of the module is as follows:

GPS and Compass Module

Message Structure:

  • GPS':

The 0x10 message contains GPS data. The message structure is as follows:

GPS Data


  • Compass:

The 0x20 message contains compass data. The structure of the message is as follows:

Compass Data
  • Calibration':

Why calibrate the compass?

Ferromagnetic substances placed on multi-rotor or around its working environment affect the reading of earth’s magnetic field for the digital compass. It also reduces the accuracy of the multi-rotor control, or even reads an incorrect heading. Calibration will eliminate such influences, and ensure MC system performs well in a non-ideal magnetic environment.

When to do it?

• The first time you install Naza compass.

• When the multi-rotor mechanical setup has changed.

• If the GPS/Compass module is re-positioned.

• If electronic devices are added/removed/re-positioned.

Hardware Connection

The Pin Configuration is as follows:

Block Diagram

Software Design

Algorithm: Distance calculation:

We are using the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface

Bearing Angle calculation:

The bearing of a point is the number of degrees in the angle measured in a clockwise direction from the north line to the line joining the centre of the compass with the point. A bearing is used to represent the direction of one point relative to another point. The bearing angle is calculated by using the following formula:

Angle Information
DBC Messages
Flowchart

Package Design

PCB Design

PCB Complete Schematic for All 5 Control Interfaces

PCB Complete Board design for All 5 Control Interfaces

3D Printed Sensor Mounts

We designed 3D printing Models for holding the Sensor LiDAR and GPS using OpenScad Software.

LiDAR Mount

GPS Mount

Git Project Management

The Gitlab project is managed using working on different branches for different controllers and restricting access to all users to merge the branch to master branch. To get easy notification of all git activity, we created a webhook for git notifications in CMPE243 Slack Channel. The useful features of git such as Issues List, Milestone tracks are used for easy management

GitLab WebHooks

The project git repository is below.

https://gitlab.com/optimus_prime/optimus/tree/master

Technical Challenges

Motor Technical Challenges

1) ESC Calibration
We messed up the calibration on the ESC.
XL 5 had a long press option to calibrate the ESC, where the ESC shall:
a) After long press, glow green and start taking PWM signals for neutral (1.5).
b) Glow green once again where we shall feed in PWM signals for Forward (2ms).
b) Glow green twice again where we shall feed in PWM signals for Reverse (1ms)."
-We wrote code to calibrate using EXT-INT (EINT3) over P0.1 - switch to calibrate the ESC this way!

2) ESC Reverse
The ESC was not activating reverse if we directly - as in the datasheet (no formal datasheet - only XL 5 forums - talked about 1ms pulse width at 50Hz for reverse).
We figured out that Reverse is actually 3 steps:
a) goNeutral()
b) goReverse()
c) goNeutral()
d) goReverse()


3) RPM Sensor Installation:
After following the steps to install RPM sensor (as steps above), the RPM sensor was not detecting the Rotation (magnet) of the wheel.
The reason for that was Machine steeled pinion gear and slipper clutch. The Machine steeled pinion gear and slipper clutch that came with the RC car was big. That increased the distance between Magnet and RPM sensor. That's why we were not able to detect RPM of wheel.
We even checked the activity using Digital Oscilloscope.
Then we changed the smaller Machine steeled pinion gear and slipper clutch and reinstalled the RPM sensor and it worked.

Android Issues Undergone

  • MAPS: Plotting Routes and Offline Check Points Calculation

With our initial implementation using Google Android API we were able to route maps but sooner during testing of the route navigation we faced a couple of issues as follows:

1. For Straight Line Routes, often the intermediate checkpoints were not received, as according to Google Api's checkpoints are only generated at the intersections where the route bends.
2. Due to the aforesaid drawback on straight routes it was hard to navigate and interpolation was required to make sure the GEO has enough checkpoints to redefine the heading angle before the car goes too far from its destined straight route path.
3. Google Route's are calculated from any point on the ground to the nearest offset point on the pre-drawn custom Google poly-line path, as a result the route from certain locations ended up to be on the sharp edge routes rather than smooth curves which also led to little longer routes and our car ended up in side walks or side bushes while correcting its course to follow the main route.

Optimus App: Navigation and Route Selection

  • Application Compatibility

During Implementation one of the issues faced were the security features of Android applications and permissions to use Geo Locations and App Storage.
Every time after fresh app Installation the permissions had to be revisited and enabled for the app to access them, something which still can be upgraded further.

Testing and Procedures to Overcome Challenges

MAP DEBUGGING & ROUTE CALCULATION

For overcoming the problem of placing routes and calculating the shortest path we decided to interpolate routes in the university premises.
Steps involved:

  • Draw polylines routes over saved checkpoint coordinates by reading and parsing a json file at the app level to get the next checkpoint coordinates.
  • Use Dijkstra's Algorithm to calculate shortest path between those routes.
  • For longer routes two approaches could be taken to calculate the intermediate checkpoints:
    • a. Straightline Approach
    • b. Geodesy Engineering Approach.
Source:wikipedia.org::Dijkstra's algorithm

Geodesy approach is complex and can be implemented using 'Haversine' technique to calculate the intermediate points between two points along the geographic surface of the earth but since the distances for the demo were not so long enough that can be significantly impacted by the curvature we decided to go with the primary approach.

We used Vincenty formula to compute the interpolated points between two checkpoints when the distance between the two exceeded ~(10±5)meters the algorithm will interpolate the route to give intermediate checkpoints which will be marked on the map using BLUE Markers.

For easy user view we added Hybrid TYPE MAP on the app so that user can have a 3D feel of the route.

MARKERS

  • We also added colored Markers for denoting following:
  >>> START/STOP : Custom Markers

  >>> CAR LOCATION : Yellow Markers

  >>> INTERMEDIATE CHECKPOINTS : HUE_BLUE Markers
Optimus App: Map Markers

Sensor Controller

1. LIDAR is not able to detect black colored objects sometimes as the light from the LASER is completely absorbed by black and nothing is reflected back.

LIDAR doesn't detect black objects

2. LIDAR object detection will be the plane where it is mounted. So, if the object height is less than the height the LIDAR is mounted then the object will not be detected.

LIDAR doesn't detect objects lower than it's height

3. If there is very high ramp then ramp will also come in the plane of the LIDAR and it will be considered as an obstacle.

4. LIDAR's Exposure to direct sunlight will cause noise creation in the obstacle detection.

Geo Technical Challenges

The first and the major issue we faced with the GEO module was selecting the proper hardware for GPS and Compass. We tried with Sparkfun, Adafruit and Ublox GPS modules. We observed a lot of time taken by the GPS to get a lock and also the error was high. Then we switched to DJI Naza GPS and we found that it was pretty accurate and the lock up time was hardly a minute. The software issue which we faced with Naza GPS was that it did not have a proper software documentation. We tried to understand the message packets and went through the forums to understand the message layout. After this we were able to integrate the module successfully.

The Naza gps module comes with a in-built compass and it simplified our setup as we did not have to integrate two separate modules.

We faced one more hardware issue once the Rx pin of the gps module was accidentaly connected to the ground pin then the gps started to draw a lot of current. So to avoid this kind of mistakes we integrated fuse with the gps so even if extra current is drawn the fuse will take care that this does not hamper the entire system.

Also, the car was going to the edges even if the path was towards the middle of the road as per google maps. So after developing an app to map the checkpoints we found that the path is actually inside the buildings. So, we had to find a different solution to solve this problem. Afterwards, we created a database of all the routes in campus and then processed the route through the android app.


GPS Route

Project Videos

https://youtu.be/lzW2ASbNfYo

Conclusion

As a team we were able to achieve the set of goals and requirements within the required time frame. Over the course of this project, we learnt cutting edge industry standards and techniques such as:

  • Team Work: Working in a team with so many people gave us a real sense of what happens in the industry when a large number of people work together.
  • GIT: Our source code versioning, code review sessions and test management was using GIT.
  • CAN: A simple and robust broadcast bus which works with a pair of differential signals. We were able to use the CAN bus to interconnect five LPC1758 micro controllers powered by FreeRTOS.
  • Accountability: Dealing with both software and hardware is not an easy task and nothing can be taken for granted, especially the hardware.
  • Hardware issues:
    • Power Issues: Initially we were using a single port from the Power bank power up everything (all the boards) including the LIDAR. This caused the LIDAR to stop working due to insufficient current. It took a while for us to figure this out.
    • GPS: Calibrating the GPS and getting accurate data from the GPS was a challenging task.
    • Android Application: Using google maps to obtain checkpoints did not workout as google maps was giving a single checkpoint. So we created a database of checkpoints for navigating the car across SJSU campus.
    • Debugging: Connecting the PCAN dongle to the car and moving around with it is a difficult way to debug. Hence we created a dashboard on the android application to view all the useful information on the tab without any hassles.

To the teams that are designing their car:

  • If using a LIDAR for obstacle avoidance make sure to test it in all lighting conditions.
  • It is better to have PCB instead of soldering everything on a wire-wrapping board.
  • Start with the implementation for the Geo module early.

Project Source Code

The source code is available in the below github link

https://gitlab.com/optimus_prime/optimus

References

Acknowledgement

We are thankful for the guidance and support by

Professor

  • Preetpal Kang

ISA

  • Prashant Aithal
  • Saurabh Ravindra Deshmukh
  • Purvil Kamdar
  • Shruthi Narayan
  • Parth Pachchigar
  • Abhishek Singh

For 3D printing

  • Our sincere thanks to Marvin Flores <marvin.flores@sjsu.edu> for printing our 3D print models.

For Sponsoring R/C car

  • Professor Kaikai, Liu

Retrieved from "http://socialledge.com/sjsu/index.php?title=F17:_Optimus&oldid=44105"