== '''Optimus''' ==
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.

== Abstract ==
== Objectives & Introduction ==
== Team Members & Responsibilities ==

* Motor Controller
** Unnikrishnan
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

* Android and Communication Bridge
** Parimal
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 
** Unnikrishnan

* Geographical Controller:
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare] 

* Master Controller:
** Revathy

* Sensor and I/O Controller:
** Sushma
** Supradeep
** Harshitha

* Integration Testing
** Unnikrishnan
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 

* PCB Design
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

== Project Schedule ==
Legend:

 Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal 
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Planned Task
! scope="col"| Actual
! scope="col"| Status
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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 
| On Track
|}

== Parts List & Cost ==
The Project bill of materials is as listed in the table below.

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Component
! scope="col"| Units
! scope="col"| Total Cost
|-
|-
! colspan="4"| General System Components
|-
|-
| 1
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
| 5
| $400
|-
|-
| 2
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
| 1
| From Prof. Kaikai Liu
|-
|-
| 3
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
| 15
| $55
|-
|-
|-
| 4
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
| 1
| From Preet
|-
|-
| 5
| [https://www.pcbway.com PCB Manufacturing]
| 5
| $70
|-
|-
| 6
| 3D printing
| 2
| From Marvin
|-
|-
| 6
| General Hardware components( Connectors,standoffs,Soldering Kits)
| 1
| $40
|-
|-
| 7
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
| 1
| $41.50
|-
|-
| 8
| LED Digital Display
| 1
| From Preet
|-
|-
| 9
| [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]
| 1
| $12.53
|-
|-
! colspan="4"| Sensor/IO Controller Components
|-
|-
| 10
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
| 1
| $449
|-
|-
! colspan="4"| Geo Controller Components
|-
|-
| 11
| [https://www.amazon.com/DJI-Naza-M-LITE-GPS-Module/dp/B017K2RMCO/ref=sr_1_1?ie=UTF8&qid=1513524634&sr=8-1&keywords=Naza+GPS GPS Module]
| 1
| $50
|-
|-
! colspan="4"| Bluetooth Bridge Controller Component
|-
|-
| 12
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
| 1
| $34.95
|-
|-
! colspan="4"| Drive Controller Component
|-
|-
| 13
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
| 1
| $20
|-
|-
|}

== '''CAN Communication''' ==
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Message ID
! scope="col"| Message from Source Node
! scope="col"| Receivers
|-
|-
! colspan="4"| Master Controller Message
|-
|-
| 1
| 2
| System Start command to start motor
| Motor
|-
|-
| 2
| 17
| Target Speed-Steer Signal to Motor
| Motor
|-
|-
| 3
| 194
| Telemetry Message to Display it on Android
| BLE
|-
|-
|-
! colspan="4"| Sensor Controller Message
|-
|-
| 4
| 3
| Lidar Detections of obstacles in 360 degree grouped as sectors
| Master,BLE
|-
|-
|-
| 5
| 36
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Geo Controller Message
|-
|-
| 6
| 195
| Compass, Destination Reached flag, Checkpoint id signals
| Master,BLE
|-
|-
| 7
| 4
| Turning Angle
| Master,BLE
|-
|-
| 8
| 4
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Bluetooth Bridge Controller Message
|-
|-
| 9
| 1
| Send start command received from Android app to master
| Master
|-
|-
|-
|-
| 10
| 38
| Heartbeat
| Master
|-
|-
| 11
| 213
| Checkpoint Count from AndroidApp
| Geo
|-
|-
| 12
| 212
| Checkpoints (Lat, Long) from Android App
| Geo
|-
|-
|}

== '''DBC File''' ==
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc 

== '''Hardware & Software Architecture''' ==

=== '''Master Controller Design & Implementation''' ===

==== '''Software Architecture Design''' ====

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the R/C car. Two of the major functionalities handled by Mater Controller is Obstacle avoidance and Route Manuevering.

The overview of Master Controller Software Architecture is to shown in the below figure.
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]

As an analogy to Human driving, it receives the imputs from sensors to determine the surrounding of the R/C car and take decisions based on the environments and commands from the user. The input data it receives includes the following. The output of the Master controller is to direct the Motor with target Speed and Steering direction.

1. Lidar Object Detections - To determine if there is any 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

==== '''Software Implementation''' ====
To Add:

Obstacle Detection design

Obstacle Avoidance Algorithm

Overall Control Flow

Debug Leds map

GPIO interface to led, CAN txrx

Description of control flow(periodic tasks)

Handling of Can messages

Unit testing

Issues

== 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 ===
[[File:CmpE243_F17_Motor_Schematic.JPG |frame|left|500px| Motor Hardware Schematics]]

{| class="wikitable"
|-
! scope="col"|
! scope="col"| SJOne Pin Diagram
! scope="col"|
|-
! scope="col"| Sr.No
! scope="col"| Pin Number
! scope="col"| Pin Function

|-
! scope="row"| 1
| P0.1
| HEADlIGHTS

|-
! scope="row"| 2
| P1.19
| BRAKELIGHTS

|-
! scope="row"| 3
| P1.20
| LEFT INDICATORS

|-
! 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

|}

 

*'''Hardware Specifications'''

===== 1. DC Motor, Servo and ESC =====
[[File:CmpE243_F17_Motor_Traxxas.jpg |thumb|left|200px|DC Motor]]

[[File:CmpE243_F17_Servo_Motor.jpg|thumb|left|200px|Servo Motor]]

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:

[[File:CmpE243_F17_ESC_Cali(A).png|thumb|center|200px|ESC Calibration Step 2 and 3]]
[[File:CmpE243_F17_ESC_Cali(B).png|thumb|center|200px|ESC Calibration Step 4 and 5]]
[[File:CmpE243_F17_ESC_Cali(D).png|thumb|center|200px|ESC Calibration Step 6]]

1. Connect a fully charged battery pack to the ESC. 
2. Turn on the transmitter (with the throttle at neutral). 
3. Press and hold the EZ-Set button (A). The LED will first turn green and then red. Release the EZ-Set button. 
4. When the LED blinks RED ONCE, pull the throttle trigger to the full throttle position and hold it there (B). 
5. When the LED blinks RED TWICE, push the throttle trigger to the full reverse and hold it there (C). 
6. When the LED blinks GREEN ONCE, programming is complete. The LED will then shine green or red (depending on low-voltage detection setting) indicating the ESC is on and at neutral (D). 
 
Once, the Calibration is done, ESC is ready to be operated with 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, servo can also be operated in Safe manner using PWM. Here are some notes on '''how not to blow a servo motor''':
 
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. (As i am Talking about hobby servos that all the other hobbyists use.. 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|500px|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 and the one which i use i.e. Atmega16 can mostly source only up to 200mA so it will totally burn it.

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 own 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 =====
 
[[File:CmpE243_F17_RPM_Sensor.jpg ‎|thumb|center|400px|Servo Motor Operation]]
 

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

[[File:CmpE243_F17_RPM_install1.JPG ‎|thumb|center|1000px]]

 
[[File:CmpE243_F17_RPM_install2.JPG ‎|thumb|center|1000px]]

 

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.
[[File:CmpE243_F17_Motor_Software_Flow.JPG|frame|centre|1000px|Flowchart.]]

=== Implementation ===
The motor controller receives all its signals from Master controller from the CAN bus.
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.
*Speed Regulation:
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.

=== 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.
 
*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.

=== 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). [[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.

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.

[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|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.

[[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. 
[[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. 
[[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. 
[[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. 
[[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. 

=====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]]

=====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.

[Figure of a plot of the LIDAR readings (done in Excel) will be added]

=====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 ===

=== Bluetooth Controller ===
==== Hardware Implementation ====
''' Bluetooth Module:'''
We are using HC-05 Bluetooth module to send and receive the data from our android application.
[[ File: HC-05.jpg|200px|thumb|center|| Bluetooth Module]]
''' Pin Configuration:'''
[[ File: bridge_hc_pin.jpg|679px|thumb|center||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.

''' Periodic Task implementation: '''

''' 1 Hz task '''

1. Send Heartbeat message to Master.

2. Send IO messages which are already received from Geo and Sensor controller to the Android app.

3. Read Data from the Bluetooth module.

''' 100 Hz task '''

1. Read CAN messages.

''' DBC messages: '''

''' 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_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

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

''' Messages received By Bluetooth controller: '''

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_ 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_ 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,SENSOR

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

=== Geographical Controller ===

==== Design & Implementation ====

'''GPS and Compass Module:'''

'''GPS''':

[[ File: CMPE243_F17_Gps.JPG|600px|thumb|center|| GPS ]]

The Global Positioning System (GPS), originally Navstar GPS, is a space-based radio navigation system owned by the United States government and operated by the United States Air Force. It 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''':

[[ File: CMPE243_F17_Compass.JPG|600px|thumb|center|| 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:
[[ File: CMPE243_F17_Optimus_Gps.JPG|600px|thumb|center|| GPS and Compass Module]]

'''Message Structure:'''

'''GPS''':

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
-------------

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
--------------

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
-----------------

BYTE 63-64 (CS): checksum

XOR mask
---------------

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).

'''Compass''':

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

55 AA 20 06 CX CX CY CY CZ CZ CS CS

Values in the message are stored in little endian format.

HEADER
-------------

BYTE 1-2: message header - always 55 AA
BYTE 3 : message id (0x20 for compass message)
BYTE 4 : length of the payload (0x06 or 6 decimal for 0x20 message)

PAYLOAD
--------------

BYTE 5-6 (CX): compass X axis data (signed)
BYTE 7-8 (CY): compass Y axis data (signed)
BYTE 9-10 (CZ): compass Z axis data (signed)

XOR
-----------------

All the bytes of the payload except 9th are XORed with a mask. Mask is calculated based on the value of the 9th byte.

If we index bits from LSB to MSB as 0-7 we have:

mask[0] = 9thByte[0] xor 9thByte[4]

mask[1] = 9thByte[1] xor 9thByte[5]

mask[2] = 9thByte[2] xor 9thByte[6]

mask[3] = 9thByte[3] xor 9thByte[7] xor 9thByte[0];

mask[4] = 9thByte[1];

mask[5] = 9thByte[2];

mask[6] = 9thByte[3];

mask[7] = 9thByte[4] xor 9thByte[0];

'''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.

'''Pin Configuration:'''

The Pin Configuration is as follows:

[[ File: CMPE243_F17_Pin.JPG|600px|thumb|center|| 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

'''Haversine formula:'''

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)

'''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.

'''Formula:'''

θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )

where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.

'''DBC Messages:'''

[[ File: CMPE243_F17_Dbc.JPG|600px|thumb|center|| DBC Messages]]

=== Implementation ===

'''Periodic callback function description:'''

'''1 Hz Function:'''

a. Check CAN bus

b. Send Heartbeat to Master module

c. Send GPS lock to Master and Sensor modules

'''100 Hz Function:'''

a. Get GPS coordinates

b. Get Heading angle

c. Get Checkpoints count

d. Calculate Bearing angle

e. Calculate Turning angle

f. Calculate Distance remaining

g. Send Heading angle

h. Send Bearing angle

i. Send Turning angle

j. Send Distance remaining

k. Check Destination reached

=== Testing & Technical Challenges ===

[[ File: CMPE243_F17_Route.JPG|600px|thumb|center|| GPS Route]]

=== Git Project Management ===

== Common Technical Challenges ==
== Project Videos ==
== Conclusion ==
== Project Source Code ==
== References ==
== Acknowledgement ==

== References Used ==

File:CmpE243 F17 Motor Software Flow.JPG

2017-12-18T09:20:53Z

Rgdrumer:

F17: Optimus

2017-12-18T09:07:37Z

Rgdrumer: /* Hardware Design */

== '''Optimus''' ==
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.

== Abstract ==
== Objectives & Introduction ==
== Team Members & Responsibilities ==

* Motor Controller
** Unnikrishnan
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

* Android and Communication Bridge
** Parimal
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 
** Unnikrishnan

* Geographical Controller:
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare] 

* Master Controller:
** Revathy

* Sensor and I/O Controller:
** Sushma
** Supradeep
** Harshitha

* Integration Testing
** Unnikrishnan
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 

* PCB Design
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

== Project Schedule ==
Legend:

 Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal 
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Planned Task
! scope="col"| Actual
! scope="col"| Status
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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 
| On Track
|}

== Parts List & Cost ==
The Project bill of materials is as listed in the table below.

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Component
! scope="col"| Units
! scope="col"| Total Cost
|-
|-
! colspan="4"| General System Components
|-
|-
| 1
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
| 5
| $400
|-
|-
| 2
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
| 1
| From Prof. Kaikai Liu
|-
|-
| 3
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
| 15
| $55
|-
|-
|-
| 4
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
| 1
| From Preet
|-
|-
| 5
| [https://www.pcbway.com PCB Manufacturing]
| 5
| $70
|-
|-
| 6
| 3D printing
| 2
| From Marvin
|-
|-
| 6
| General Hardware components( Connectors,standoffs,Soldering Kits)
| 1
| $40
|-
|-
| 7
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
| 1
| $41.50
|-
|-
| 8
| LED Digital Display
| 1
| From Preet
|-
|-
| 9
| [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]
| 1
| $12.53
|-
|-
! colspan="4"| Sensor/IO Controller Components
|-
|-
| 10
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
| 1
| $449
|-
|-
! colspan="4"| Geo Controller Components
|-
|-
| 11
| [https://www.amazon.com/DJI-Naza-M-LITE-GPS-Module/dp/B017K2RMCO/ref=sr_1_1?ie=UTF8&qid=1513524634&sr=8-1&keywords=Naza+GPS GPS Module]
| 1
| $50
|-
|-
! colspan="4"| Bluetooth Bridge Controller Component
|-
|-
| 12
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
| 1
| $34.95
|-
|-
! colspan="4"| Drive Controller Component
|-
|-
| 13
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
| 1
| $20
|-
|-
|}

== '''CAN Communication''' ==
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Message ID
! scope="col"| Message from Source Node
! scope="col"| Receivers
|-
|-
! colspan="4"| Master Controller Message
|-
|-
| 1
| 2
| System Start command to start motor
| Motor
|-
|-
| 2
| 17
| Target Speed-Steer Signal to Motor
| Motor
|-
|-
| 3
| 194
| Telemetry Message to Display it on Android
| BLE
|-
|-
|-
! colspan="4"| Sensor Controller Message
|-
|-
| 4
| 3
| Lidar Detections of obstacles in 360 degree grouped as sectors
| Master,BLE
|-
|-
|-
| 5
| 36
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Geo Controller Message
|-
|-
| 6
| 195
| Compass, Destination Reached flag, Checkpoint id signals
| Master,BLE
|-
|-
| 7
| 4
| Turning Angle
| Master,BLE
|-
|-
| 8
| 4
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Bluetooth Bridge Controller Message
|-
|-
| 9
| 1
| Send start command received from Android app to master
| Master
|-
|-
|-
|-
| 10
| 38
| Heartbeat
| Master
|-
|-
| 11
| 213
| Checkpoint Count from AndroidApp
| Geo
|-
|-
| 12
| 212
| Checkpoints (Lat, Long) from Android App
| Geo
|-
|-
|}

== '''DBC File''' ==
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc 

== '''Hardware & Software Architecture''' ==

=== '''Master Controller Design & Implementation''' ===

==== '''Software Architecture Design''' ====

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the R/C car. Two of the major functionalities handled by Mater Controller is Obstacle avoidance and Route Manuevering.

The overview of Master Controller Software Architecture is to shown in the below figure.
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]

As an analogy to Human driving, it receives the imputs from sensors to determine the surrounding of the R/C car and take decisions based on the environments and commands from the user. The input data it receives includes the following. The output of the Master controller is to direct the Motor with target Speed and Steering direction.

1. Lidar Object Detections - To determine if there is any 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

==== '''Software Implementation''' ====
To Add:

Obstacle Detection design

Obstacle Avoidance Algorithm

Overall Control Flow

Debug Leds map

GPIO interface to led, CAN txrx

Description of control flow(periodic tasks)

Handling of Can messages

Unit testing

Issues

== 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 ===
[[File:CmpE243_F17_Motor_Schematic.JPG |frame|left|500px| Motor Hardware Schematics]]

{| class="wikitable"
|-
! scope="col"|
! scope="col"| SJOne Pin Diagram
! scope="col"|
|-
! scope="col"| Sr.No
! scope="col"| Pin Number
! scope="col"| Pin Function

|-
! scope="row"| 1
| P0.1
| HEADlIGHTS

|-
! scope="row"| 2
| P1.19
| BRAKELIGHTS

|-
! scope="row"| 3
| P1.20
| LEFT INDICATORS

|-
! 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

|}

 

*'''Hardware Specifications'''

===== 1. DC Motor, Servo and ESC =====
[[File:CmpE243_F17_Motor_Traxxas.jpg |thumb|left|200px|DC Motor]]

[[File:CmpE243_F17_Servo_Motor.jpg|thumb|left|200px|Servo Motor]]

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:

[[File:CmpE243_F17_ESC_Cali(A).png|thumb|center|200px|ESC Calibration Step 2 and 3]]
[[File:CmpE243_F17_ESC_Cali(B).png|thumb|center|200px|ESC Calibration Step 4 and 5]]
[[File:CmpE243_F17_ESC_Cali(D).png|thumb|center|200px|ESC Calibration Step 6]]

1. Connect a fully charged battery pack to the ESC. 
2. Turn on the transmitter (with the throttle at neutral). 
3. Press and hold the EZ-Set button (A). The LED will first turn green and then red. Release the EZ-Set button. 
4. When the LED blinks RED ONCE, pull the throttle trigger to the full throttle position and hold it there (B). 
5. When the LED blinks RED TWICE, push the throttle trigger to the full reverse and hold it there (C). 
6. When the LED blinks GREEN ONCE, programming is complete. The LED will then shine green or red (depending on low-voltage detection setting) indicating the ESC is on and at neutral (D). 
 
Once, the Calibration is done, ESC is ready to be operated with 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, servo can also be operated in Safe manner using PWM. Here are some notes on '''how not to blow a servo motor''':
 
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. (As i am Talking about hobby servos that all the other hobbyists use.. 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|500px|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 and the one which i use i.e. Atmega16 can mostly source only up to 200mA so it will totally burn it.

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 own 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 =====
 
[[File:CmpE243_F17_RPM_Sensor.jpg ‎|thumb|center|400px|Servo Motor Operation]]
 

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

[[File:CmpE243_F17_RPM_install1.JPG ‎|thumb|center|1000px]]

 
[[File:CmpE243_F17_RPM_install2.JPG ‎|thumb|center|1000px]]

 

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.
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]

=== Implementation ===
The motor controller receives all its signals from Master controller from the CAN bus.
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.
*Speed Regulation:
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.

=== 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.
 
*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.

=== 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). [[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.

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.

[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|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.

[[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. 
[[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. 
[[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. 
[[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. 
[[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. 

=====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]]

=====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.

[Figure of a plot of the LIDAR readings (done in Excel) will be added]

=====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 ===

=== Bluetooth Controller ===
==== Hardware Implementation ====
''' Bluetooth Module:'''
We are using HC-05 Bluetooth module to send and receive the data from our android application.
[[ File: HC-05.jpg|200px|thumb|center|| Bluetooth Module]]
''' Pin Configuration:'''
[[ File: bridge_hc_pin.jpg|679px|thumb|center||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.

''' Periodic Task implementation: '''

''' 1 Hz task '''

1. Send Heartbeat message to Master.

2. Send IO messages which are already received from Geo and Sensor controller to the Android app.

3. Read Data from the Bluetooth module.

''' 100 Hz task '''

1. Read CAN messages.

''' DBC messages: '''

''' 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_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

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

''' Messages received By Bluetooth controller: '''

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_ 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_ 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,SENSOR

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

=== Geographical Controller ===

==== Design & Implementation ====

'''GPS and Compass Module:'''

'''GPS''':

[[ File: CMPE243_F17_Gps.JPG|600px|thumb|center|| GPS ]]

The Global Positioning System (GPS), originally Navstar GPS, is a space-based radio navigation system owned by the United States government and operated by the United States Air Force. It 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''':

[[ File: CMPE243_F17_Compass.JPG|600px|thumb|center|| 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:
[[ File: CMPE243_F17_Optimus_Gps.JPG|600px|thumb|center|| GPS and Compass Module]]

'''Message Structure:'''

'''GPS''':

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
-------------

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
--------------

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
-----------------

BYTE 63-64 (CS): checksum

XOR mask
---------------

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).

'''Compass''':

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

55 AA 20 06 CX CX CY CY CZ CZ CS CS

Values in the message are stored in little endian format.

HEADER
-------------

BYTE 1-2: message header - always 55 AA
BYTE 3 : message id (0x20 for compass message)
BYTE 4 : length of the payload (0x06 or 6 decimal for 0x20 message)

PAYLOAD
--------------

BYTE 5-6 (CX): compass X axis data (signed)
BYTE 7-8 (CY): compass Y axis data (signed)
BYTE 9-10 (CZ): compass Z axis data (signed)

XOR
-----------------

All the bytes of the payload except 9th are XORed with a mask. Mask is calculated based on the value of the 9th byte.

If we index bits from LSB to MSB as 0-7 we have:

mask[0] = 9thByte[0] xor 9thByte[4]

mask[1] = 9thByte[1] xor 9thByte[5]

mask[2] = 9thByte[2] xor 9thByte[6]

mask[3] = 9thByte[3] xor 9thByte[7] xor 9thByte[0];

mask[4] = 9thByte[1];

mask[5] = 9thByte[2];

mask[6] = 9thByte[3];

mask[7] = 9thByte[4] xor 9thByte[0];

'''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.

'''Pin Configuration:'''

The Pin Configuration is as follows:

[[ File: CMPE243_F17_Pin.JPG|600px|thumb|center|| 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

'''Haversine formula:'''

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)

'''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.

'''Formula:'''

θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )

where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.

'''DBC Messages:'''

[[ File: CMPE243_F17_Dbc.JPG|600px|thumb|center|| DBC Messages]]

=== Implementation ===

'''Periodic callback function description:'''

'''1 Hz Function:'''

a. Check CAN bus

b. Send Heartbeat to Master module

c. Send GPS lock to Master and Sensor modules

'''100 Hz Function:'''

a. Get GPS coordinates

b. Get Heading angle

c. Get Checkpoints count

d. Calculate Bearing angle

e. Calculate Turning angle

f. Calculate Distance remaining

g. Send Heading angle

h. Send Bearing angle

i. Send Turning angle

j. Send Distance remaining

k. Check Destination reached

=== Testing & Technical Challenges ===

[[ File: CMPE243_F17_Route.JPG|600px|thumb|center|| GPS Route]]

=== Git Project Management ===

== Common Technical Challenges ==
== Project Videos ==
== Conclusion ==
== Project Source Code ==
== References ==
== Acknowledgement ==

== References Used ==

F17: Optimus

2017-12-18T09:07:06Z

Rgdrumer: /* Hardware Interface */

== '''Optimus''' ==
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.

== Abstract ==
== Objectives & Introduction ==
== Team Members & Responsibilities ==

* Motor Controller
** Unnikrishnan
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

* Android and Communication Bridge
** Parimal
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 
** Unnikrishnan

* Geographical Controller:
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare] 

* Master Controller:
** Revathy

* Sensor and I/O Controller:
** Sushma
** Supradeep
** Harshitha

* Integration Testing
** Unnikrishnan
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 

* PCB Design
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

== Project Schedule ==
Legend:

 Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal 
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Planned Task
! scope="col"| Actual
! scope="col"| Status
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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 
| On Track
|}

== Parts List & Cost ==
The Project bill of materials is as listed in the table below.

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Component
! scope="col"| Units
! scope="col"| Total Cost
|-
|-
! colspan="4"| General System Components
|-
|-
| 1
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
| 5
| $400
|-
|-
| 2
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
| 1
| From Prof. Kaikai Liu
|-
|-
| 3
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
| 15
| $55
|-
|-
|-
| 4
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
| 1
| From Preet
|-
|-
| 5
| [https://www.pcbway.com PCB Manufacturing]
| 5
| $70
|-
|-
| 6
| 3D printing
| 2
| From Marvin
|-
|-
| 6
| General Hardware components( Connectors,standoffs,Soldering Kits)
| 1
| $40
|-
|-
| 7
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
| 1
| $41.50
|-
|-
| 8
| LED Digital Display
| 1
| From Preet
|-
|-
| 9
| [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]
| 1
| $12.53
|-
|-
! colspan="4"| Sensor/IO Controller Components
|-
|-
| 10
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
| 1
| $449
|-
|-
! colspan="4"| Geo Controller Components
|-
|-
| 11
| [https://www.amazon.com/DJI-Naza-M-LITE-GPS-Module/dp/B017K2RMCO/ref=sr_1_1?ie=UTF8&qid=1513524634&sr=8-1&keywords=Naza+GPS GPS Module]
| 1
| $50
|-
|-
! colspan="4"| Bluetooth Bridge Controller Component
|-
|-
| 12
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
| 1
| $34.95
|-
|-
! colspan="4"| Drive Controller Component
|-
|-
| 13
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
| 1
| $20
|-
|-
|}

== '''CAN Communication''' ==
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Message ID
! scope="col"| Message from Source Node
! scope="col"| Receivers
|-
|-
! colspan="4"| Master Controller Message
|-
|-
| 1
| 2
| System Start command to start motor
| Motor
|-
|-
| 2
| 17
| Target Speed-Steer Signal to Motor
| Motor
|-
|-
| 3
| 194
| Telemetry Message to Display it on Android
| BLE
|-
|-
|-
! colspan="4"| Sensor Controller Message
|-
|-
| 4
| 3
| Lidar Detections of obstacles in 360 degree grouped as sectors
| Master,BLE
|-
|-
|-
| 5
| 36
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Geo Controller Message
|-
|-
| 6
| 195
| Compass, Destination Reached flag, Checkpoint id signals
| Master,BLE
|-
|-
| 7
| 4
| Turning Angle
| Master,BLE
|-
|-
| 8
| 4
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Bluetooth Bridge Controller Message
|-
|-
| 9
| 1
| Send start command received from Android app to master
| Master
|-
|-
|-
|-
| 10
| 38
| Heartbeat
| Master
|-
|-
| 11
| 213
| Checkpoint Count from AndroidApp
| Geo
|-
|-
| 12
| 212
| Checkpoints (Lat, Long) from Android App
| Geo
|-
|-
|}

== '''DBC File''' ==
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc 

== '''Hardware & Software Architecture''' ==

=== '''Master Controller Design & Implementation''' ===

==== '''Software Architecture Design''' ====

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the R/C car. Two of the major functionalities handled by Mater Controller is Obstacle avoidance and Route Manuevering.

The overview of Master Controller Software Architecture is to shown in the below figure.
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]

As an analogy to Human driving, it receives the imputs from sensors to determine the surrounding of the R/C car and take decisions based on the environments and commands from the user. The input data it receives includes the following. The output of the Master controller is to direct the Motor with target Speed and Steering direction.

1. Lidar Object Detections - To determine if there is any 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

==== '''Software Implementation''' ====
To Add:

Obstacle Detection design

Obstacle Avoidance Algorithm

Overall Control Flow

Debug Leds map

GPIO interface to led, CAN txrx

Description of control flow(periodic tasks)

Handling of Can messages

Unit testing

Issues

== 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 ===
[[File:CmpE243_F17_Motor_Schematic.JPG |frame|left|200px| Motor Hardware Schematics]]

{| class="wikitable"
|-
! scope="col"|
! scope="col"| SJOne Pin Diagram
! scope="col"|
|-
! scope="col"| Sr.No
! scope="col"| Pin Number
! scope="col"| Pin Function

|-
! scope="row"| 1
| P0.1
| HEADlIGHTS

|-
! scope="row"| 2
| P1.19
| BRAKELIGHTS

|-
! scope="row"| 3
| P1.20
| LEFT INDICATORS

|-
! 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

|}

 

*'''Hardware Specifications'''

===== 1. DC Motor, Servo and ESC =====
[[File:CmpE243_F17_Motor_Traxxas.jpg |thumb|left|200px|DC Motor]]

[[File:CmpE243_F17_Servo_Motor.jpg|thumb|left|200px|Servo Motor]]

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:

[[File:CmpE243_F17_ESC_Cali(A).png|thumb|center|200px|ESC Calibration Step 2 and 3]]
[[File:CmpE243_F17_ESC_Cali(B).png|thumb|center|200px|ESC Calibration Step 4 and 5]]
[[File:CmpE243_F17_ESC_Cali(D).png|thumb|center|200px|ESC Calibration Step 6]]

1. Connect a fully charged battery pack to the ESC. 
2. Turn on the transmitter (with the throttle at neutral). 
3. Press and hold the EZ-Set button (A). The LED will first turn green and then red. Release the EZ-Set button. 
4. When the LED blinks RED ONCE, pull the throttle trigger to the full throttle position and hold it there (B). 
5. When the LED blinks RED TWICE, push the throttle trigger to the full reverse and hold it there (C). 
6. When the LED blinks GREEN ONCE, programming is complete. The LED will then shine green or red (depending on low-voltage detection setting) indicating the ESC is on and at neutral (D). 
 
Once, the Calibration is done, ESC is ready to be operated with 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, servo can also be operated in Safe manner using PWM. Here are some notes on '''how not to blow a servo motor''':
 
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. (As i am Talking about hobby servos that all the other hobbyists use.. 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|500px|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 and the one which i use i.e. Atmega16 can mostly source only up to 200mA so it will totally burn it.

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 own 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 =====
 
[[File:CmpE243_F17_RPM_Sensor.jpg ‎|thumb|center|400px|Servo Motor Operation]]
 

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

[[File:CmpE243_F17_RPM_install1.JPG ‎|thumb|center|1000px]]

 
[[File:CmpE243_F17_RPM_install2.JPG ‎|thumb|center|1000px]]

 

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.
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]

=== Implementation ===
The motor controller receives all its signals from Master controller from the CAN bus.
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.
*Speed Regulation:
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.

=== 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.
 
*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.

=== 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). [[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.

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.

[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|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.

[[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. 
[[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. 
[[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. 
[[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. 
[[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. 

=====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]]

=====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.

[Figure of a plot of the LIDAR readings (done in Excel) will be added]

=====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 ===

=== Bluetooth Controller ===
==== Hardware Implementation ====
''' Bluetooth Module:'''
We are using HC-05 Bluetooth module to send and receive the data from our android application.
[[ File: HC-05.jpg|200px|thumb|center|| Bluetooth Module]]
''' Pin Configuration:'''
[[ File: bridge_hc_pin.jpg|679px|thumb|center||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.

''' Periodic Task implementation: '''

''' 1 Hz task '''

1. Send Heartbeat message to Master.

2. Send IO messages which are already received from Geo and Sensor controller to the Android app.

3. Read Data from the Bluetooth module.

''' 100 Hz task '''

1. Read CAN messages.

''' DBC messages: '''

''' 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_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

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

''' Messages received By Bluetooth controller: '''

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_ 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_ 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,SENSOR

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

=== Geographical Controller ===

==== Design & Implementation ====

'''GPS and Compass Module:'''

'''GPS''':

[[ File: CMPE243_F17_Gps.JPG|600px|thumb|center|| GPS ]]

The Global Positioning System (GPS), originally Navstar GPS, is a space-based radio navigation system owned by the United States government and operated by the United States Air Force. It 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''':

[[ File: CMPE243_F17_Compass.JPG|600px|thumb|center|| 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:
[[ File: CMPE243_F17_Optimus_Gps.JPG|600px|thumb|center|| GPS and Compass Module]]

'''Message Structure:'''

'''GPS''':

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
-------------

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
--------------

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
-----------------

BYTE 63-64 (CS): checksum

XOR mask
---------------

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).

'''Compass''':

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

55 AA 20 06 CX CX CY CY CZ CZ CS CS

Values in the message are stored in little endian format.

HEADER
-------------

BYTE 1-2: message header - always 55 AA
BYTE 3 : message id (0x20 for compass message)
BYTE 4 : length of the payload (0x06 or 6 decimal for 0x20 message)

PAYLOAD
--------------

BYTE 5-6 (CX): compass X axis data (signed)
BYTE 7-8 (CY): compass Y axis data (signed)
BYTE 9-10 (CZ): compass Z axis data (signed)

XOR
-----------------

All the bytes of the payload except 9th are XORed with a mask. Mask is calculated based on the value of the 9th byte.

If we index bits from LSB to MSB as 0-7 we have:

mask[0] = 9thByte[0] xor 9thByte[4]

mask[1] = 9thByte[1] xor 9thByte[5]

mask[2] = 9thByte[2] xor 9thByte[6]

mask[3] = 9thByte[3] xor 9thByte[7] xor 9thByte[0];

mask[4] = 9thByte[1];

mask[5] = 9thByte[2];

mask[6] = 9thByte[3];

mask[7] = 9thByte[4] xor 9thByte[0];

'''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.

'''Pin Configuration:'''

The Pin Configuration is as follows:

[[ File: CMPE243_F17_Pin.JPG|600px|thumb|center|| 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

'''Haversine formula:'''

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)

'''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.

'''Formula:'''

θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )

where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.

'''DBC Messages:'''

[[ File: CMPE243_F17_Dbc.JPG|600px|thumb|center|| DBC Messages]]

=== Implementation ===

'''Periodic callback function description:'''

'''1 Hz Function:'''

a. Check CAN bus

b. Send Heartbeat to Master module

c. Send GPS lock to Master and Sensor modules

'''100 Hz Function:'''

a. Get GPS coordinates

b. Get Heading angle

c. Get Checkpoints count

d. Calculate Bearing angle

e. Calculate Turning angle

f. Calculate Distance remaining

g. Send Heading angle

h. Send Bearing angle

i. Send Turning angle

j. Send Distance remaining

k. Check Destination reached

=== Testing & Technical Challenges ===

[[ File: CMPE243_F17_Route.JPG|600px|thumb|center|| GPS Route]]

=== Git Project Management ===

== Common Technical Challenges ==
== Project Videos ==
== Conclusion ==
== Project Source Code ==
== References ==
== Acknowledgement ==

== References Used ==

F17: Optimus

2017-12-18T08:52:16Z

Rgdrumer: /* 2. RPM Sensor = */

== '''Optimus''' ==
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.

== Abstract ==
== Objectives & Introduction ==
== Team Members & Responsibilities ==

* Motor Controller
** Unnikrishnan
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

* Android and Communication Bridge
** Parimal
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 
** Unnikrishnan

* Geographical Controller:
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare] 

* Master Controller:
** Revathy

* Sensor and I/O Controller:
** Sushma
** Supradeep
** Harshitha

* Integration Testing
** Unnikrishnan
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 

* PCB Design
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

== Project Schedule ==
Legend:

 Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal 
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Planned Task
! scope="col"| Actual
! scope="col"| Status
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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 
| On Track
|}

== Parts List & Cost ==
The Project bill of materials is as listed in the table below.

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Component
! scope="col"| Units
! scope="col"| Total Cost
|-
|-
! colspan="4"| General System Components
|-
|-
| 1
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
| 5
| $400
|-
|-
| 2
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
| 1
| From Prof. Kaikai Liu
|-
|-
| 3
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
| 15
| $55
|-
|-
|-
| 4
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
| 1
| From Preet
|-
|-
| 5
| [https://www.pcbway.com PCB Manufacturing]
| 5
| $70
|-
|-
| 6
| 3D printing
| 2
| From Marvin
|-
|-
| 6
| General Hardware components( Connectors,standoffs,Soldering Kits)
| 1
| $40
|-
|-
| 7
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
| 1
| $41.50
|-
|-
| 8
| LED Digital Display
| 1
| From Preet
|-
|-
| 9
| [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]
| 1
| $12.53
|-
|-
! colspan="4"| Sensor/IO Controller Components
|-
|-
| 10
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
| 1
| $449
|-
|-
! colspan="4"| Geo Controller Components
|-
|-
| 11
| [https://www.amazon.com/DJI-Naza-M-LITE-GPS-Module/dp/B017K2RMCO/ref=sr_1_1?ie=UTF8&qid=1513524634&sr=8-1&keywords=Naza+GPS GPS Module]
| 1
| $50
|-
|-
! colspan="4"| Bluetooth Bridge Controller Component
|-
|-
| 12
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
| 1
| $34.95
|-
|-
! colspan="4"| Drive Controller Component
|-
|-
| 13
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
| 1
| $20
|-
|-
|}

== '''CAN Communication''' ==
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Message ID
! scope="col"| Message from Source Node
! scope="col"| Receivers
|-
|-
! colspan="4"| Master Controller Message
|-
|-
| 1
| 2
| System Start command to start motor
| Motor
|-
|-
| 2
| 17
| Target Speed-Steer Signal to Motor
| Motor
|-
|-
| 3
| 194
| Telemetry Message to Display it on Android
| BLE
|-
|-
|-
! colspan="4"| Sensor Controller Message
|-
|-
| 4
| 3
| Lidar Detections of obstacles in 360 degree grouped as sectors
| Master,BLE
|-
|-
|-
| 5
| 36
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Geo Controller Message
|-
|-
| 6
| 195
| Compass, Destination Reached flag, Checkpoint id signals
| Master,BLE
|-
|-
| 7
| 4
| Turning Angle
| Master,BLE
|-
|-
| 8
| 4
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Bluetooth Bridge Controller Message
|-
|-
| 9
| 1
| Send start command received from Android app to master
| Master
|-
|-
|-
|-
| 10
| 38
| Heartbeat
| Master
|-
|-
| 11
| 213
| Checkpoint Count from AndroidApp
| Geo
|-
|-
| 12
| 212
| Checkpoints (Lat, Long) from Android App
| Geo
|-
|-
|}

== '''DBC File''' ==
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc 

== '''Hardware & Software Architecture''' ==

=== '''Master Controller Design & Implementation''' ===

==== '''Software Architecture Design''' ====

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the R/C car. Two of the major functionalities handled by Mater Controller is Obstacle avoidance and Route Manuevering.

The overview of Master Controller Software Architecture is to shown in the below figure.
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]

As an analogy to Human driving, it receives the imputs from sensors to determine the surrounding of the R/C car and take decisions based on the environments and commands from the user. The input data it receives includes the following. The output of the Master controller is to direct the Motor with target Speed and Steering direction.

1. Lidar Object Detections - To determine if there is any 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

==== '''Software Implementation''' ====
To Add:

Obstacle Detection design

Obstacle Avoidance Algorithm

Overall Control Flow

Debug Leds map

GPIO interface to led, CAN txrx

Description of control flow(periodic tasks)

Handling of Can messages

Unit testing

Issues

== 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 ===
[[File:CmpE243_F17_Motor_Schematic.JPG |frame|left|200px| Motor Hardware Schematics]]

{| class="wikitable"
|-
! scope="col"|
! scope="col"| SJOne Pin Diagram
! scope="col"|
|-
! scope="col"| Sr.No
! scope="col"| Pin Number
! scope="col"| Pin Function

|-
! scope="row"| 1
| P0.1
| HEADlIGHTS

|-
! scope="row"| 2
| P1.19
| BRAKELIGHTS

|-
! scope="row"| 3
| P1.20
| LEFT INDICATORS

|-
! 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

|}

 

*'''Hardware Specifications'''

===== 1. DC Motor, Servo and ESC =====
[[File:CmpE243_F17_Motor_Traxxas.jpg |thumb|left|200px|DC Motor]]

[[File:CmpE243_F17_Servo_Motor.jpg|thumb|left|200px|Servo Motor]]

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:

[[File:CmpE243_F17_ESC_Cali(A).png|thumb|center|200px|ESC Calibration Step 2 and 3]]
[[File:CmpE243_F17_ESC_Cali(B).png|thumb|center|200px|ESC Calibration Step 4 and 5]]
[[File:CmpE243_F17_ESC_Cali(D).png|thumb|center|200px|ESC Calibration Step 6]]

1. Connect a fully charged battery pack to the ESC. 
2. Turn on the transmitter (with the throttle at neutral). 
3. Press and hold the EZ-Set button (A). The LED will first turn green and then red. Release the EZ-Set button. 
4. When the LED blinks RED ONCE, pull the throttle trigger to the full throttle position and hold it there (B). 
5. When the LED blinks RED TWICE, push the throttle trigger to the full reverse and hold it there (C). 
6. When the LED blinks GREEN ONCE, programming is complete. The LED will then shine green or red (depending on low-voltage detection setting) indicating the ESC is on and at neutral (D). 
 
Once, the Calibration is done, ESC is ready to be operated with 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, servo can also be operated in Safe manner using PWM. Here are some notes on '''how not to blow a servo motor''':
 
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. (As i am Talking about hobby servos that all the other hobbyists use.. 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|500px|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 and the one which i use i.e. Atmega16 can mostly source only up to 200mA so it will totally burn it.

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 own 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 =====
 
[[File:CmpE243_F17_RPM_Sensor.jpg ‎|thumb|center|400px|Servo Motor Operation]]
 

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

[[File:CmpE243_F17_RPM_install1.JPG ‎|thumb|center|1000px]]

 
[[File:CmpE243_F17_RPM_install2.JPG ‎|thumb|center|1000px]]

 

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. 

=== Hardware Interface ===
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 ===
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]

=== Implementation ===
The motor controller receives all its signals from Master controller from the CAN bus.
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.
*Speed Regulation:
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.

=== 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.
 
*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.

=== 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). [[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.

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.

[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|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.

[[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. 
[[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. 
[[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. 
[[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. 
[[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. 

=====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]]

=====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.

[Figure of a plot of the LIDAR readings (done in Excel) will be added]

=====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 ===

=== Bluetooth Controller ===
==== Hardware Implementation ====
''' Bluetooth Module:'''
We are using HC-05 Bluetooth module to send and receive the data from our android application.
[[ File: HC-05.jpg|200px|thumb|center|| Bluetooth Module]]
''' Pin Configuration:'''
[[ File: bridge_hc_pin.jpg|679px|thumb|center||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.

''' Periodic Task implementation: '''

''' 1 Hz task '''

1. Send Heartbeat message to Master.

2. Send IO messages which are already received from Geo and Sensor controller to the Android app.

3. Read Data from the Bluetooth module.

''' 100 Hz task '''

1. Read CAN messages.

''' DBC messages: '''

''' 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_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

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

''' Messages received By Bluetooth controller: '''

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_ 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_ 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,SENSOR

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

=== Geographical Controller ===

==== Design & Implementation ====

'''GPS and Compass Module:'''

'''GPS''':

[[ File: CMPE243_F17_Gps.JPG|600px|thumb|center|| GPS ]]

The Global Positioning System (GPS), originally Navstar GPS, is a space-based radio navigation system owned by the United States government and operated by the United States Air Force. It 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''':

[[ File: CMPE243_F17_Compass.JPG|600px|thumb|center|| 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:
[[ File: CMPE243_F17_Optimus_Gps.JPG|600px|thumb|center|| GPS and Compass Module]]

'''Message Structure:'''

'''GPS''':

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
-------------

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
--------------

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
-----------------

BYTE 63-64 (CS): checksum

XOR mask
---------------

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).

'''Compass''':

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

55 AA 20 06 CX CX CY CY CZ CZ CS CS

Values in the message are stored in little endian format.

HEADER
-------------

BYTE 1-2: message header - always 55 AA
BYTE 3 : message id (0x20 for compass message)
BYTE 4 : length of the payload (0x06 or 6 decimal for 0x20 message)

PAYLOAD
--------------

BYTE 5-6 (CX): compass X axis data (signed)
BYTE 7-8 (CY): compass Y axis data (signed)
BYTE 9-10 (CZ): compass Z axis data (signed)

XOR
-----------------

All the bytes of the payload except 9th are XORed with a mask. Mask is calculated based on the value of the 9th byte.

If we index bits from LSB to MSB as 0-7 we have:

mask[0] = 9thByte[0] xor 9thByte[4]

mask[1] = 9thByte[1] xor 9thByte[5]

mask[2] = 9thByte[2] xor 9thByte[6]

mask[3] = 9thByte[3] xor 9thByte[7] xor 9thByte[0];

mask[4] = 9thByte[1];

mask[5] = 9thByte[2];

mask[6] = 9thByte[3];

mask[7] = 9thByte[4] xor 9thByte[0];

'''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.

'''Pin Configuration:'''

The Pin Configuration is as follows:

[[ File: CMPE243_F17_Pin.JPG|600px|thumb|center|| 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

'''Haversine formula:'''

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)

'''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.

'''Formula:'''

θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )

where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.

'''DBC Messages:'''

[[ File: CMPE243_F17_Dbc.JPG|600px|thumb|center|| DBC Messages]]

=== Implementation ===

'''Periodic callback function description:'''

'''1 Hz Function:'''

a. Check CAN bus

b. Send Heartbeat to Master module

c. Send GPS lock to Master and Sensor modules

'''100 Hz Function:'''

a. Get GPS coordinates

b. Get Heading angle

c. Get Checkpoints count

d. Calculate Bearing angle

e. Calculate Turning angle

f. Calculate Distance remaining

g. Send Heading angle

h. Send Bearing angle

i. Send Turning angle

j. Send Distance remaining

k. Check Destination reached

=== Testing & Technical Challenges ===

[[ File: CMPE243_F17_Route.JPG|600px|thumb|center|| GPS Route]]

=== Git Project Management ===

== Common Technical Challenges ==
== Project Videos ==
== Conclusion ==
== Project Source Code ==
== References ==
== Acknowledgement ==

== References Used ==

File:CmpE243 F17 RPM install2.JPG

2017-12-18T08:49:11Z

Rgdrumer:

File:CmpE243 F17 RPM install1.JPG

2017-12-18T08:45:29Z

Rgdrumer:

F17: Optimus

2017-12-18T08:41:53Z

Rgdrumer: /* 1. DC Motor, Servo and ESC */

== '''Optimus''' ==
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.

== Abstract ==
== Objectives & Introduction ==
== Team Members & Responsibilities ==

* Motor Controller
** Unnikrishnan
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

* Android and Communication Bridge
** Parimal
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 
** Unnikrishnan

* Geographical Controller:
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare] 

* Master Controller:
** Revathy

* Sensor and I/O Controller:
** Sushma
** Supradeep
** Harshitha

* Integration Testing
** Unnikrishnan
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 

* PCB Design
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

== Project Schedule ==
Legend:

 Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal 
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Planned Task
! scope="col"| Actual
! scope="col"| Status
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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 
| On Track
|}

== Parts List & Cost ==
The Project bill of materials is as listed in the table below.

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Component
! scope="col"| Units
! scope="col"| Total Cost
|-
|-
! colspan="4"| General System Components
|-
|-
| 1
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
| 5
| $400
|-
|-
| 2
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
| 1
| From Prof. Kaikai Liu
|-
|-
| 3
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
| 15
| $55
|-
|-
|-
| 4
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
| 1
| From Preet
|-
|-
| 5
| [https://www.pcbway.com PCB Manufacturing]
| 5
| $70
|-
|-
| 6
| 3D printing
| 2
| From Marvin
|-
|-
| 6
| General Hardware components( Connectors,standoffs,Soldering Kits)
| 1
| $40
|-
|-
| 7
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
| 1
| $41.50
|-
|-
| 8
| LED Digital Display
| 1
| From Preet
|-
|-
| 9
| [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]
| 1
| $12.53
|-
|-
! colspan="4"| Sensor/IO Controller Components
|-
|-
| 10
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
| 1
| $449
|-
|-
! colspan="4"| Geo Controller Components
|-
|-
| 11
| [https://www.amazon.com/DJI-Naza-M-LITE-GPS-Module/dp/B017K2RMCO/ref=sr_1_1?ie=UTF8&qid=1513524634&sr=8-1&keywords=Naza+GPS GPS Module]
| 1
| $50
|-
|-
! colspan="4"| Bluetooth Bridge Controller Component
|-
|-
| 12
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
| 1
| $34.95
|-
|-
! colspan="4"| Drive Controller Component
|-
|-
| 13
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
| 1
| $20
|-
|-
|}

== '''CAN Communication''' ==
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Message ID
! scope="col"| Message from Source Node
! scope="col"| Receivers
|-
|-
! colspan="4"| Master Controller Message
|-
|-
| 1
| 2
| System Start command to start motor
| Motor
|-
|-
| 2
| 17
| Target Speed-Steer Signal to Motor
| Motor
|-
|-
| 3
| 194
| Telemetry Message to Display it on Android
| BLE
|-
|-
|-
! colspan="4"| Sensor Controller Message
|-
|-
| 4
| 3
| Lidar Detections of obstacles in 360 degree grouped as sectors
| Master,BLE
|-
|-
|-
| 5
| 36
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Geo Controller Message
|-
|-
| 6
| 195
| Compass, Destination Reached flag, Checkpoint id signals
| Master,BLE
|-
|-
| 7
| 4
| Turning Angle
| Master,BLE
|-
|-
| 8
| 4
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Bluetooth Bridge Controller Message
|-
|-
| 9
| 1
| Send start command received from Android app to master
| Master
|-
|-
|-
|-
| 10
| 38
| Heartbeat
| Master
|-
|-
| 11
| 213
| Checkpoint Count from AndroidApp
| Geo
|-
|-
| 12
| 212
| Checkpoints (Lat, Long) from Android App
| Geo
|-
|-
|}

== '''DBC File''' ==
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc 

== '''Hardware & Software Architecture''' ==

=== '''Master Controller Design & Implementation''' ===

==== '''Software Architecture Design''' ====

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the R/C car. Two of the major functionalities handled by Mater Controller is Obstacle avoidance and Route Manuevering.

The overview of Master Controller Software Architecture is to shown in the below figure.
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]

As an analogy to Human driving, it receives the imputs from sensors to determine the surrounding of the R/C car and take decisions based on the environments and commands from the user. The input data it receives includes the following. The output of the Master controller is to direct the Motor with target Speed and Steering direction.

1. Lidar Object Detections - To determine if there is any 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

==== '''Software Implementation''' ====
To Add:

Obstacle Detection design

Obstacle Avoidance Algorithm

Overall Control Flow

Debug Leds map

GPIO interface to led, CAN txrx

Description of control flow(periodic tasks)

Handling of Can messages

Unit testing

Issues

== 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 ===
[[File:CmpE243_F17_Motor_Schematic.JPG |frame|left|200px| Motor Hardware Schematics]]

{| class="wikitable"
|-
! scope="col"|
! scope="col"| SJOne Pin Diagram
! scope="col"|
|-
! scope="col"| Sr.No
! scope="col"| Pin Number
! scope="col"| Pin Function

|-
! scope="row"| 1
| P0.1
| HEADlIGHTS

|-
! scope="row"| 2
| P1.19
| BRAKELIGHTS

|-
! scope="row"| 3
| P1.20
| LEFT INDICATORS

|-
! 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

|}

 

*'''Hardware Specifications'''

===== 1. DC Motor, Servo and ESC =====
[[File:CmpE243_F17_Motor_Traxxas.jpg |thumb|left|200px|DC Motor]]

[[File:CmpE243_F17_Servo_Motor.jpg|thumb|left|200px|Servo Motor]]

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:

[[File:CmpE243_F17_ESC_Cali(A).png|thumb|center|200px|ESC Calibration Step 2 and 3]]
[[File:CmpE243_F17_ESC_Cali(B).png|thumb|center|200px|ESC Calibration Step 4 and 5]]
[[File:CmpE243_F17_ESC_Cali(D).png|thumb|center|200px|ESC Calibration Step 6]]

1. Connect a fully charged battery pack to the ESC. 
2. Turn on the transmitter (with the throttle at neutral). 
3. Press and hold the EZ-Set button (A). The LED will first turn green and then red. Release the EZ-Set button. 
4. When the LED blinks RED ONCE, pull the throttle trigger to the full throttle position and hold it there (B). 
5. When the LED blinks RED TWICE, push the throttle trigger to the full reverse and hold it there (C). 
6. When the LED blinks GREEN ONCE, programming is complete. The LED will then shine green or red (depending on low-voltage detection setting) indicating the ESC is on and at neutral (D). 
 
Once, the Calibration is done, ESC is ready to be operated with 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, servo can also be operated in Safe manner using PWM. Here are some notes on '''how not to blow a servo motor''':
 
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. (As i am Talking about hobby servos that all the other hobbyists use.. 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|500px|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 and the one which i use i.e. Atmega16 can mostly source only up to 200mA so it will totally burn it.

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 own 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 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. 

=== Hardware Interface ===
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 ===
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]

=== Implementation ===
The motor controller receives all its signals from Master controller from the CAN bus.
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.
*Speed Regulation:
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.

=== 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.
 
*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.

=== 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). [[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.

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.

[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|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.

[[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. 
[[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. 
[[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. 
[[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. 
[[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. 

=====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]]

=====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.

[Figure of a plot of the LIDAR readings (done in Excel) will be added]

=====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 ===

=== Bluetooth Controller ===
==== Hardware Implementation ====
''' Bluetooth Module:'''
We are using HC-05 Bluetooth module to send and receive the data from our android application.
[[ File: HC-05.jpg|200px|thumb|center|| Bluetooth Module]]
''' Pin Configuration:'''
[[ File: bridge_hc_pin.jpg|679px|thumb|center||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.

''' Periodic Task implementation: '''

''' 1 Hz task '''

1. Send Heartbeat message to Master.

2. Send IO messages which are already received from Geo and Sensor controller to the Android app.

3. Read Data from the Bluetooth module.

''' 100 Hz task '''

1. Read CAN messages.

''' DBC messages: '''

''' 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_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

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

''' Messages received By Bluetooth controller: '''

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_ 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_ 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,SENSOR

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

=== Geographical Controller ===

==== Design & Implementation ====

'''GPS and Compass Module:'''

'''GPS''':

[[ File: CMPE243_F17_Gps.JPG|600px|thumb|center|| GPS ]]

The Global Positioning System (GPS), originally Navstar GPS, is a space-based radio navigation system owned by the United States government and operated by the United States Air Force. It 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''':

[[ File: CMPE243_F17_Compass.JPG|600px|thumb|center|| 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:
[[ File: CMPE243_F17_Optimus_Gps.JPG|600px|thumb|center|| GPS and Compass Module]]

'''Message Structure:'''

'''GPS''':

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
-------------

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
--------------

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
-----------------

BYTE 63-64 (CS): checksum

XOR mask
---------------

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).

'''Compass''':

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

55 AA 20 06 CX CX CY CY CZ CZ CS CS

Values in the message are stored in little endian format.

HEADER
-------------

BYTE 1-2: message header - always 55 AA
BYTE 3 : message id (0x20 for compass message)
BYTE 4 : length of the payload (0x06 or 6 decimal for 0x20 message)

PAYLOAD
--------------

BYTE 5-6 (CX): compass X axis data (signed)
BYTE 7-8 (CY): compass Y axis data (signed)
BYTE 9-10 (CZ): compass Z axis data (signed)

XOR
-----------------

All the bytes of the payload except 9th are XORed with a mask. Mask is calculated based on the value of the 9th byte.

If we index bits from LSB to MSB as 0-7 we have:

mask[0] = 9thByte[0] xor 9thByte[4]

mask[1] = 9thByte[1] xor 9thByte[5]

mask[2] = 9thByte[2] xor 9thByte[6]

mask[3] = 9thByte[3] xor 9thByte[7] xor 9thByte[0];

mask[4] = 9thByte[1];

mask[5] = 9thByte[2];

mask[6] = 9thByte[3];

mask[7] = 9thByte[4] xor 9thByte[0];

'''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.

'''Pin Configuration:'''

The Pin Configuration is as follows:

[[ File: CMPE243_F17_Pin.JPG|600px|thumb|center|| 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

'''Haversine formula:'''

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)

'''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.

'''Formula:'''

θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )

where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.

'''DBC Messages:'''

[[ File: CMPE243_F17_Dbc.JPG|600px|thumb|center|| DBC Messages]]

=== Implementation ===

'''Periodic callback function description:'''

'''1 Hz Function:'''

a. Check CAN bus

b. Send Heartbeat to Master module

c. Send GPS lock to Master and Sensor modules

'''100 Hz Function:'''

a. Get GPS coordinates

b. Get Heading angle

c. Get Checkpoints count

d. Calculate Bearing angle

e. Calculate Turning angle

f. Calculate Distance remaining

g. Send Heading angle

h. Send Bearing angle

i. Send Turning angle

j. Send Distance remaining

k. Check Destination reached

=== Testing & Technical Challenges ===

[[ File: CMPE243_F17_Route.JPG|600px|thumb|center|| GPS Route]]

=== Git Project Management ===

== Common Technical Challenges ==
== Project Videos ==
== Conclusion ==
== Project Source Code ==
== References ==
== Acknowledgement ==

== References Used ==

F17: Optimus

2017-12-18T08:41:03Z

Rgdrumer: /* 2. Speed Sensor = */

== '''Optimus''' ==
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.

== Abstract ==
== Objectives & Introduction ==
== Team Members & Responsibilities ==

* Motor Controller
** Unnikrishnan
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

* Android and Communication Bridge
** Parimal
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 
** Unnikrishnan

* Geographical Controller:
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/sarveshharhare Sarvesh Harhare] 

* Master Controller:
** Revathy

* Sensor and I/O Controller:
** Sushma
** Supradeep
** Harshitha

* Integration Testing
** Unnikrishnan
** [https://www.linkedin.com/in/sneha-shahi-8b1636152 Sneha] 
** [https://www.linkedin.com/in/kripanandjha Kripanand Jha] 

* PCB Design
** [https://www.linkedin.com/in/rajul-gupta-5b366ba9/ Rajul] 

== Project Schedule ==
Legend:

 Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal 
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Planned Task
! scope="col"| Actual
! scope="col"| Status
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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.
|-
! scope="row"| 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
|-
! scope="row"| 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 
| On Track
|}

== Parts List & Cost ==
The Project bill of materials is as listed in the table below.

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Component
! scope="col"| Units
! scope="col"| Total Cost
|-
|-
! colspan="4"| General System Components
|-
|-
| 1
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
| 5
| $400
|-
|-
| 2
| [https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=overview Traxaas RC Car]
| 1
| From Prof. Kaikai Liu
|-
|-
| 3
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
| 15
| $55
|-
|-
|-
| 4
| [http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
| 1
| From Preet
|-
|-
| 5
| [https://www.pcbway.com PCB Manufacturing]
| 5
| $70
|-
|-
| 6
| 3D printing
| 2
| From Marvin
|-
|-
| 6
| General Hardware components( Connectors,standoffs,Soldering Kits)
| 1
| $40
|-
|-
| 7
| [https://www.amazon.com/gp/product/B01G1XH46M/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 Power Bank]
| 1
| $41.50
|-
|-
| 8
| LED Digital Display
| 1
| From Preet
|-
|-
| 9
| [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]
| 1
| $12.53
|-
|-
! colspan="4"| Sensor/IO Controller Components
|-
|-
| 10
| [https://www.amazon.com/RPLIDAR-A2-The-Thinest-LIDAR/dp/B01L1T32PI RP Lidar]
| 1
| $449
|-
|-
! colspan="4"| Geo Controller Components
|-
|-
| 11
| [https://www.amazon.com/DJI-Naza-M-LITE-GPS-Module/dp/B017K2RMCO/ref=sr_1_1?ie=UTF8&qid=1513524634&sr=8-1&keywords=Naza+GPS GPS Module]
| 1
| $50
|-
|-
! colspan="4"| Bluetooth Bridge Controller Component
|-
|-
| 12
| | [https://www.sparkfun.com/products/12582 Bluetooth Module]
| 1
| $34.95
|-
|-
! colspan="4"| Drive Controller Component
|-
|-
| 13
| |[https://traxxas.com/products/models/electric/NOS-Deegan-38-Rally?t=telemetry RPM Sensor]
| 1
| $20
|-
|-
|}

== '''CAN Communication''' ==
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO

{| class="wikitable"
|-
! scope="col"| SNo.
! scope="col"| Message ID
! scope="col"| Message from Source Node
! scope="col"| Receivers
|-
|-
! colspan="4"| Master Controller Message
|-
|-
| 1
| 2
| System Start command to start motor
| Motor
|-
|-
| 2
| 17
| Target Speed-Steer Signal to Motor
| Motor
|-
|-
| 3
| 194
| Telemetry Message to Display it on Android
| BLE
|-
|-
|-
! colspan="4"| Sensor Controller Message
|-
|-
| 4
| 3
| Lidar Detections of obstacles in 360 degree grouped as sectors
| Master,BLE
|-
|-
|-
| 5
| 36
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Geo Controller Message
|-
|-
| 6
| 195
| Compass, Destination Reached flag, Checkpoint id signals
| Master,BLE
|-
|-
| 7
| 4
| Turning Angle
| Master,BLE
|-
|-
| 8
| 4
| Heartbeat
| Master
|-
|-
|-
! colspan="4"| Bluetooth Bridge Controller Message
|-
|-
| 9
| 1
| Send start command received from Android app to master
| Master
|-
|-
|-
|-
| 10
| 38
| Heartbeat
| Master
|-
|-
| 11
| 213
| Checkpoint Count from AndroidApp
| Geo
|-
|-
| 12
| 212
| Checkpoints (Lat, Long) from Android App
| Geo
|-
|-
|}

== '''DBC File''' ==
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc 

== '''Hardware & Software Architecture''' ==

=== '''Master Controller Design & Implementation''' ===

==== '''Software Architecture Design''' ====

The Master Controller Integrates the functionality of all other controllers and it acts as the Central Control Unit of the R/C car. Two of the major functionalities handled by Mater Controller is Obstacle avoidance and Route Manuevering.

The overview of Master Controller Software Architecture is to shown in the below figure.
[[ File: CMPE243_F17_Optimus_MasterSWArchitecture.png|700px|thumb|center|| SW Architecture]]

As an analogy to Human driving, it receives the imputs from sensors to determine the surrounding of the R/C car and take decisions based on the environments and commands from the user. The input data it receives includes the following. The output of the Master controller is to direct the Motor with target Speed and Steering direction.

1. Lidar Object Detections - To determine if there is any 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

==== '''Software Implementation''' ====
To Add:

Obstacle Detection design

Obstacle Avoidance Algorithm

Overall Control Flow

Debug Leds map

GPIO interface to led, CAN txrx

Description of control flow(periodic tasks)

Handling of Can messages

Unit testing

Issues

== 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 ===
[[File:CmpE243_F17_Motor_Schematic.JPG |frame|left|200px| Motor Hardware Schematics]]

{| class="wikitable"
|-
! scope="col"|
! scope="col"| SJOne Pin Diagram
! scope="col"|
|-
! scope="col"| Sr.No
! scope="col"| Pin Number
! scope="col"| Pin Function

|-
! scope="row"| 1
| P0.1
| HEADlIGHTS

|-
! scope="row"| 2
| P1.19
| BRAKELIGHTS

|-
! scope="row"| 3
| P1.20
| LEFT INDICATORS

|-
! 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

|}

 

*'''Hardware Specifications'''

===== 1. DC Motor, Servo and ESC =====
[[File:CmpE243_F17_Motor_Traxxas.jpg |thumb|left|200px|DC Motor]]

[[File:CmpE243_F17_Servo_Motor.jpg|thumb|left|200px|Servo Motor]]

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:

[[File:CmpE243_F17_ESC_Cali(A).png|thumb|center|200px|ESC Calibration Step 2 and 3]]
[[File:CmpE243_F17_ESC_Cali(B).png|thumb|center|200px|ESC Calibration Step 4 and 5]]
[[File:CmpE243_F17_ESC_Cali(D).png|thumb|center|200px|ESC Calibration Step 6]]

1. Connect a fully charged battery pack to the ESC. 
2. Turn on the transmitter (with the throttle at neutral). 
3. Press and hold the EZ-Set button (A). The LED will first turn green and then red. Release the EZ-Set button. 
4. When the LED blinks RED ONCE, pull the throttle trigger to the full throttle position and hold it there (B). 
5. When the LED blinks RED TWICE, push the throttle trigger to the full reverse and hold it there (C). 
6. When the LED blinks GREEN ONCE, programming is complete. The LED will then shine green or red (depending on low-voltage detection setting) indicating the ESC is on and at neutral (D). 
 
Once, the Calibration is done, ESC is ready to be operated with 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, servo can also be operated in Safe manner using PWM. Here are some notes on '''how not to blow a servo motor''':
 
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. (As i am Talking about hobby servos that all the other hobbyists use.. 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|500px|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 and the one which i use i.e. Atmega16 can mostly source only up to 200mA so it will totally burn it.

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 own 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 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. 

=== Hardware Interface ===
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 ===
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]

=== Implementation ===
The motor controller receives all its signals from Master controller from the CAN bus.
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.
*Speed Regulation:
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.

=== 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.
 
*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.

=== 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). [[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.

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.

[[File:CmpE243_F17_Optimus_LIDARconnections.jpg|1000PX|thumb|center|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.

[[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. 
[[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. 
[[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. 
[[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. 
[[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. 

=====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]]

=====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.

[Figure of a plot of the LIDAR readings (done in Excel) will be added]

=====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 ===

=== Bluetooth Controller ===
==== Hardware Implementation ====
''' Bluetooth Module:'''
We are using HC-05 Bluetooth module to send and receive the data from our android application.
[[ File: HC-05.jpg|200px|thumb|center|| Bluetooth Module]]
''' Pin Configuration:'''
[[ File: bridge_hc_pin.jpg|679px|thumb|center||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.

''' Periodic Task implementation: '''

''' 1 Hz task '''

1. Send Heartbeat message to Master.

2. Send IO messages which are already received from Geo and Sensor controller to the Android app.

3. Read Data from the Bluetooth module.

''' 100 Hz task '''

1. Read CAN messages.

''' DBC messages: '''

''' 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_ 2 MASTER_SYS_STOP_CMD: 1 MASTER
SG_ MASTER_SYS_STOP_CMD_stop : 0|8@1+ (1,0) [0|1] "" MOTOR

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

''' Messages received By Bluetooth controller: '''

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_ 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_ 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,SENSOR

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

=== Geographical Controller ===

==== Design & Implementation ====

'''GPS and Compass Module:'''

'''GPS''':

[[ File: CMPE243_F17_Gps.JPG|600px|thumb|center|| GPS ]]

The Global Positioning System (GPS), originally Navstar GPS, is a space-based radio navigation system owned by the United States government and operated by the United States Air Force. It 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''':

[[ File: CMPE243_F17_Compass.JPG|600px|thumb|center|| 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:
[[ File: CMPE243_F17_Optimus_Gps.JPG|600px|thumb|center|| GPS and Compass Module]]

'''Message Structure:'''

'''GPS''':

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
-------------

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
--------------

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
-----------------

BYTE 63-64 (CS): checksum

XOR mask
---------------

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).

'''Compass''':

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

55 AA 20 06 CX CX CY CY CZ CZ CS CS

Values in the message are stored in little endian format.

HEADER
-------------

BYTE 1-2: message header - always 55 AA
BYTE 3 : message id (0x20 for compass message)
BYTE 4 : length of the payload (0x06 or 6 decimal for 0x20 message)

PAYLOAD
--------------

BYTE 5-6 (CX): compass X axis data (signed)
BYTE 7-8 (CY): compass Y axis data (signed)
BYTE 9-10 (CZ): compass Z axis data (signed)

XOR
-----------------

All the bytes of the payload except 9th are XORed with a mask. Mask is calculated based on the value of the 9th byte.

If we index bits from LSB to MSB as 0-7 we have:

mask[0] = 9thByte[0] xor 9thByte[4]

mask[1] = 9thByte[1] xor 9thByte[5]

mask[2] = 9thByte[2] xor 9thByte[6]

mask[3] = 9thByte[3] xor 9thByte[7] xor 9thByte[0];

mask[4] = 9thByte[1];

mask[5] = 9thByte[2];

mask[6] = 9thByte[3];

mask[7] = 9thByte[4] xor 9thByte[0];

'''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.

'''Pin Configuration:'''

The Pin Configuration is as follows:

[[ File: CMPE243_F17_Pin.JPG|600px|thumb|center|| 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

'''Haversine formula:'''

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)

'''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.

'''Formula:'''

θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )

where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)

Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.

'''DBC Messages:'''

[[ File: CMPE243_F17_Dbc.JPG|600px|thumb|center|| DBC Messages]]

=== Implementation ===

'''Periodic callback function description:'''

'''1 Hz Function:'''

a. Check CAN bus

b. Send Heartbeat to Master module

c. Send GPS lock to Master and Sensor modules

'''100 Hz Function:'''

a. Get GPS coordinates

b. Get Heading angle

c. Get Checkpoints count

d. Calculate Bearing angle

e. Calculate Turning angle

f. Calculate Distance remaining

g. Send Heading angle

h. Send Bearing angle

i. Send Turning angle

j. Send Distance remaining

k. Check Destination reached

=== Testing & Technical Challenges ===

[[ File: CMPE243_F17_Route.JPG|600px|thumb|center|| GPS Route]]

=== Git Project Management ===

== Common Technical Challenges ==
== Project Videos ==
== Conclusion ==
== Project Source Code ==
== References ==
== Acknowledgement ==

== References Used ==